Over the course of my first year of blogging, I covered a number of the design issues that have to be addressed before any kind of useful ag-robot can be offered to the farming community.
Regarding issues of mechanical design, all but one of the challenges I could foresee were either solved or solvable engineering problems. The one remaining/missing piece of the puzzle, as far as the mechanical side of deployable robotics is concerned, is the invention/discovery of an electro-mechanical equivalent to biological muscle. Once this last hurdle is crossed, the world of field-deployable robotics will expand through the farming industry exponentially. The only concern, then, is: What will society do with the resultant unemployed semiskilled work force?
The programming side of field-deployed robotics is a different issue. Whatever methods are used to program field-deployed robots in the future must be something that the existing workforce already has the competency to do.
So just exactly what does it mean to program a field-deployed robot? And, what exactly is the competency level of the individuals you can already find working in the farm industry?
/***********************/
Regarding the question of workforce competency, when it comes to working with machinery, working with your hands, and getting dirty in the process, I’m afraid that many within the academic world have a prejudice against such individuals. I’ve found there is an ever-present attitude that, unless you have college degrees and are professionally successful, you can’t possibly be intelligent.
Thankfully, life gave me a wonderful lesson in this regard. Over the years I attended Humboldt State University earning my degrees in physics and math, I supported myself working in the woods as a logger. I was blessed with the good fortune to work with many individuals (equipment operators, mechanics, and rigging men) who, if you paid attention to the complexity of the tasks they performed, and their ability to think through solutions, were most certainly above average in intelligence and mechanical ability.
Here’s a nice video showing the rebuilding of the D8 Caterpillar tractor. Pay attention to the complexity of the tasks required for rebuilding such a machine. Hopefully this will give a good appreciation for the technical expertise that can be found within our modern skilled industrial workforce, “CAT D8R Dozer: Full Machine Rebuild”.
To suggest that the existing workforce, that can already be found within the farming industry, is incapable of dealing with the complexities of robot programming is a faulty assumption. The only challenge for the academic engineering community is to create a programming modality that can be adapted to the skill set already existing there.
/***********************/
Now, in order to answer the question, “What does it mean to program a field-deployed robot?” let’s start by asking the question, “How does one currently “program” a crew of field workers?” Field supervisors do not occupy their time creating lists of written instructions for each fieldworker to read and execute. Crew supervisors can assume that individual workers under their direction are already skilled at their assigned tasks. So, as supervisors, they only need to act as task managers, giving instructions verbally in a natural language setting.
This last observation suggests what the proper model for field-deployed robot programming should be. Rather than the compiled source code model of programming you find in languages such as C/C++, Java, Python, and etc., it should be more reminiscent of a scripting language expressed in verbal form.
Robots should arrive for work already programmed with the basic functionality they will need in order to complete the tasks expected of them. Additionally, their internal programming needs to include a learning mode that allows them to adjust their preloaded code to the ever-changing working conditions of the moment. Given this alternate paradigm for programming, the field supervisor “programmer” just continues to do their job exactly as they always have; giving verbal instructions to the deployed worker ag-bots.
Honestly, how can anyone within the engineering community imagine that ag-robot programming should/could be done by someone sitting with a laptop computer, out in the rain and mud or in the hot sun and dust, typing in code before downloading it to some robot? But over the years that I’ve tried to keep up with developments in agricultural robotics, this seems to be an implicit, but unrecognized, assumption underlying a lot of the ideas I see put forth.
/***********************/
The act of programming is really just the act of expressing a list of instructions that will delineate the operation of some intelligent processing system. Our typical association of programming with writing source code in a formal language format stems from the fact that the underlying processing system in these cases are digital micro-processors; with the objects manipulated being bits, bytes, and words of information. In the case of human field workers, though, the underlying processing entity is a person; while the objects being manipulated are tasks to be performed.
The “programming” design challenge, then, is to re-create in field-deployed robots, the same programming modalities that are currently employed with their human counterparts. Taking up this challenge will be the subject of part 4 in this series of posts.
Tuesday, December 24, 2019
Saturday, December 21, 2019
The Economic Reality of Agricultural Robotics and the Return of Widjets, Part 2 of 4
The first post of this series begins to reveal, in backdrop, the interplay between several different design constraints and design paradigms for robots.
• The first of these interplays is between the design requirements for stationary floor-mounted robots versus those for mobile field-deployed robots. In the case of a stationary floor-mounted robot, the work comes to the robot, and the work environment is known; the tasks are repeatable and predictable. For a field-deployed robot, the robot needs to travel to the work, and the work environment is neither known, nor repeatable, nor predictable. These two qualitatively different work environments force qualitatively different economic expectations onto the resulting robot’s design. While this blog focuses on agricultural robots, it should be noted that what applies to ag-robots will apply equally to any field-deployed robot, whether the industry is farming, logging, mining, and/or construction.
• The second interplay is the perennial conflict that faces every design engineer between what can be built versus what should be built.
If your interest, dear reader, is in designing robots using existing technologies, then you can stop here.
Otherwise, the assertion being made in this post, is that the only way to make any real progress in agricultural robotics is first, stop trying to build more robots! Focus on the hardware side of ag-robot design and let the hardware tell you what it wants to be. Next, define what actuator technologies will need to be developed before such ag-robot hardware can be built. Finally, the engineering design community needs to focus some of its creative energy on developing those new technologies. For example, there is no electro-mechanical equivalent to biological muscle. If such an actuator already existed, our dream ag-robot would have been a reality years ago.
/***********************/
Starting with my first post on agricultural robotics back in 2011 and following on for the rest of that year’s posts, I tried to address in detail many of the design issues that would have to be tackled before one can make a useful robot replacement for a typical farmworker: “Agricultural Robotics, Design Challenges”.
In the process I coined a few “WID Rules” for robot design: “WID Rules for Robotics”.
• WID Rule: It makes no economic sense to replace a worker with a robot if that robot's total cost-of-ownership is not competitive with the total cost-of-labor for the worker it is going to replace.
• Corollary 1: When designing a robot, it is the worker you want to duplicate, not the worker’s task.
• Corollary 2: Regarding operation, service and maintenance, follow the K.I.S.S. principle (“Keep it simple, stupid!”), since the workers who will be responsible for these jobs in the future will be the same people that now operate, service and maintain the existing farm equipment.
The WID Rule implies that the only way robots will ever leave the engineering lab and move out to the farm field will be when they can finally compete economically with their minimum wage human counterparts. This basic cost of employment puts a severe cost constraint on any AI/robotic system intended for field deployment.
Corollary 1 implies that, for a robot to be a worthwhile investment for the farmer, it must be multipurpose. A farm tractor can be repurposed by just swapping out attachments; something that can be done in under an hour. While human labor, for example, can go straight from picking cauliflower to moving irrigation pipe without any pause for repurposing. Any piece of robotic equipment that cannot be repurposed, in short order, and in similar fashions, will always be a non-starter for any farmer.
Finally, Corollary 2 implies that a field-deployed robot needs to be modular. Its mechanical construction needs to be based on interchangeable subassemblies. And its computational architecture should come in the form of pre-programmed bricks or modules connected together using a single shared serial interface to form a system of distributed intelligence. This form of construction allows for easy manufacture, easy maintenance, and easy service. Programming, in any traditional sense, is not part of this paradigm. If one wants to change some functionality in a robot, just swap in a different module. The upside of this kind of construction is that this is the level of service, maintenance, and rebuild competency that already exists within the workforce currently employed in the industries of farming, construction, logging, and mining.
/***********************/
As a “worked example” of the point I’m trying to make: I touched again on the economics of field-deployed robots in a post on the now-defunct startup Willow Garage: “Willow Garage's Legacy, Blessing or Curse”. What was once a celebrity startup in the field of robotics disappeared into the dustbin of tech history in the space of a few years. The hubris of the developers behind Willow Garage was that they thought that by creating a standardized general-purpose robot, they could then divorce software development from the underlying hardware development. The desire seems to have been to turn robot design into a software developer’s game; and it is the ghost of this desire that still haunts the earth to this day in the form of ROS.
But reality will always bite back hard on any ill-conceived startup venture. It’s the hardware side of a robot's design that connects it to physical reality and, most importantly, to the economic reality of its intended arena of application. By divorcing software development from any underlying hardware development, Willow Garage also divorced itself, in its corporate thinking, from any consideration of the underlying economic factors involved in robot design such as the costs of manufacturing, operation, and maintenance. The foregone result was that the PR2 never became anything more than a vanity purchase for a few dozen financially well-endowed research and academic institutions.
/***********************/
At this point, I’m ready to assert that, in regards to stationary/floor-mounted robots, traditional software development modalities are sufficient. But when it comes to mobile field-deployed robots, some new way of programming needs to be articulated and implemented.
What this last, somewhat fuzzy, statement might mean in practical terms will be the subject of the remaining two parts of this post.
• The first of these interplays is between the design requirements for stationary floor-mounted robots versus those for mobile field-deployed robots. In the case of a stationary floor-mounted robot, the work comes to the robot, and the work environment is known; the tasks are repeatable and predictable. For a field-deployed robot, the robot needs to travel to the work, and the work environment is neither known, nor repeatable, nor predictable. These two qualitatively different work environments force qualitatively different economic expectations onto the resulting robot’s design. While this blog focuses on agricultural robots, it should be noted that what applies to ag-robots will apply equally to any field-deployed robot, whether the industry is farming, logging, mining, and/or construction.
• The second interplay is the perennial conflict that faces every design engineer between what can be built versus what should be built.
If your interest, dear reader, is in designing robots using existing technologies, then you can stop here.
Otherwise, the assertion being made in this post, is that the only way to make any real progress in agricultural robotics is first, stop trying to build more robots! Focus on the hardware side of ag-robot design and let the hardware tell you what it wants to be. Next, define what actuator technologies will need to be developed before such ag-robot hardware can be built. Finally, the engineering design community needs to focus some of its creative energy on developing those new technologies. For example, there is no electro-mechanical equivalent to biological muscle. If such an actuator already existed, our dream ag-robot would have been a reality years ago.
/***********************/
Starting with my first post on agricultural robotics back in 2011 and following on for the rest of that year’s posts, I tried to address in detail many of the design issues that would have to be tackled before one can make a useful robot replacement for a typical farmworker: “Agricultural Robotics, Design Challenges”.
In the process I coined a few “WID Rules” for robot design: “WID Rules for Robotics”.
• WID Rule: It makes no economic sense to replace a worker with a robot if that robot's total cost-of-ownership is not competitive with the total cost-of-labor for the worker it is going to replace.
• Corollary 1: When designing a robot, it is the worker you want to duplicate, not the worker’s task.
• Corollary 2: Regarding operation, service and maintenance, follow the K.I.S.S. principle (“Keep it simple, stupid!”), since the workers who will be responsible for these jobs in the future will be the same people that now operate, service and maintain the existing farm equipment.
The WID Rule implies that the only way robots will ever leave the engineering lab and move out to the farm field will be when they can finally compete economically with their minimum wage human counterparts. This basic cost of employment puts a severe cost constraint on any AI/robotic system intended for field deployment.
Corollary 1 implies that, for a robot to be a worthwhile investment for the farmer, it must be multipurpose. A farm tractor can be repurposed by just swapping out attachments; something that can be done in under an hour. While human labor, for example, can go straight from picking cauliflower to moving irrigation pipe without any pause for repurposing. Any piece of robotic equipment that cannot be repurposed, in short order, and in similar fashions, will always be a non-starter for any farmer.
Finally, Corollary 2 implies that a field-deployed robot needs to be modular. Its mechanical construction needs to be based on interchangeable subassemblies. And its computational architecture should come in the form of pre-programmed bricks or modules connected together using a single shared serial interface to form a system of distributed intelligence. This form of construction allows for easy manufacture, easy maintenance, and easy service. Programming, in any traditional sense, is not part of this paradigm. If one wants to change some functionality in a robot, just swap in a different module. The upside of this kind of construction is that this is the level of service, maintenance, and rebuild competency that already exists within the workforce currently employed in the industries of farming, construction, logging, and mining.
/***********************/
As a “worked example” of the point I’m trying to make: I touched again on the economics of field-deployed robots in a post on the now-defunct startup Willow Garage: “Willow Garage's Legacy, Blessing or Curse”. What was once a celebrity startup in the field of robotics disappeared into the dustbin of tech history in the space of a few years. The hubris of the developers behind Willow Garage was that they thought that by creating a standardized general-purpose robot, they could then divorce software development from the underlying hardware development. The desire seems to have been to turn robot design into a software developer’s game; and it is the ghost of this desire that still haunts the earth to this day in the form of ROS.
But reality will always bite back hard on any ill-conceived startup venture. It’s the hardware side of a robot's design that connects it to physical reality and, most importantly, to the economic reality of its intended arena of application. By divorcing software development from any underlying hardware development, Willow Garage also divorced itself, in its corporate thinking, from any consideration of the underlying economic factors involved in robot design such as the costs of manufacturing, operation, and maintenance. The foregone result was that the PR2 never became anything more than a vanity purchase for a few dozen financially well-endowed research and academic institutions.
/***********************/
At this point, I’m ready to assert that, in regards to stationary/floor-mounted robots, traditional software development modalities are sufficient. But when it comes to mobile field-deployed robots, some new way of programming needs to be articulated and implemented.
What this last, somewhat fuzzy, statement might mean in practical terms will be the subject of the remaining two parts of this post.
Wednesday, December 18, 2019
The Economic Reality of Agricultural Robotics and the Return of Widjets, Part 1 of 4
If by progress in agricultural robotics one means that concepts being explored in the engineering lab are maturing into viable commercial products that farmers are willing to make capital investment in, then there really hasn’t been any progress over the last decade or more. When I look at a trade publication today showcasing the latest ag-robot commercial venture, what I see looks exactly the same as what people were doing 10 years ago.
The easy, and least charitable, explanation is that researchers in agricultural robotics are more concerned with making clever robots than they are in addressing the economic realities that farmers are constrained to work within. I personally think the real answer goes much deeper than this. But I would like to start by addressing this first speculation.
Regarding the economic reality farmers face; not once have I seen any article or research group address the fact that in the farming industry, productivity and profit do not necessarily correlate. In fact, often they are found in inverse correlation. If one farmer has a productive crop yield, chances are other farmers in that region have done as well. At harvest time, this gluts the market causing the price per commodity to go down; at which point the farmer actually ends up losing money. It is not unheard for a farmer to let a field go fallow midseason when it becomes apparent that a crop has become a money loser for the year.
And regarding the question of crop rotation, at least in my area (Pajaro Valley), except for the apple orchards and berry fields, I never see the same crop in the same field for more than one growing cycle. For example, for vegetable crops, it’s a given that there will be several different crops in the same field over the course of any growing season. This means that any ag-robot technology that requires permanent field-installed components will also become a nonstarter for the farmer.
For these reasons, farmers are extremely reluctant to make any kind of capital investment in equipment or infrastructure beyond what is minimally necessary. In other words, telling a farmer, as a sales pitch, that using a certain ag-robot technology can raise his/her productivity is not going to be, by itself, a useful marketing strategy.
For a farmer, a robot will be just another piece of equipment like a tractor or harvester; and, whether purchased or leased, machine payments come every month whether the equipment is working in the field or not. Contrast this with the economic reality of hiring a field worker; when the work stops, the field worker can be let go and the farmer’s financial commitment ends. This is a point universally overlooked. Yes, machinery and robotics, on paper, will appear to be far more productive then human labor. But the financial commitment that comes over the lifetime of ownership of a single-crop ag-robot negates any short-term/seasonal financial advantage it has over human labor.
The large corporate farms, whose operations encompass thousands of acres, can make the risky financial choice of purchasing a large sophisticated single-crop harvester or planter.
But for family farms, whose operations are measured in hundreds of acres rather than thousands, investing in such large sophisticated machinery is an out-of-reach financial decision; which is why smaller farming operations are more dependent upon hand labor.
One needs to be careful in reading the last two paragraphs. One has to make the distinction between mechanization and robotics. There are crops like wheat, corn, potatoes, peanuts, sugar beets, and etc., that lend themselves to a high degree of mechanization. From soil preparation to planting through to harvesting, each phase of the farming operation can be taken care of in one pass and at one point in time, with the handling of these particular crops all done mechanically. Contrast this with crops like berries, green beans or zucchini squash, where the harvesting goes on continually over the course of a plant's growing cycle, and which also require careful handling to avoid damage to both the food item and the plant itself.
When looking at those crops that lend themselves to mechanization, one finds that the farming industry has already reduced the need for human labor down to a handful of equipment operators running large integrated computerized machines. At this current state of affairs, robotics and AI offer little-to-no marginal return on investment. The best the robotics community can offer is to replace the remaining equipment operators with AI-based control systems. But the truth is, having a reliable, conscientious and responsible human operator on payroll represents a far greater return on investment to the farmer than spending money on a complicated computer-based AI control system that leaves them at the mercy of some outside, distant, and often unresponsive tech support.
To appreciate how serious this last situation is for farmers, one only needs to look to the recent controversy over the “right to repair” that has affected John Deere tractor owners across this nation.
• Wired Magazine, "John Deere Just Swindled Farmers out of Their Right to Repair".
• YouTube, "Right to Repair”.
• YouTube, "Tractor Hacking: The Farmers Breaking Big Tech’s Repair Monopoly”.
Where robotics can offer a true return on investment to the farmer is with crops that require special handling: picking fruit and berries and harvesting a variety of the vegetable crops. These are the crops for which the cost of labor is the largest single expense the farmer has to face. And with coming minimum-wage laws and other rules respecting work week hours, these are the kinds of expenses that will break a farmer financially. So, the incentive to replace the human fieldworker with an equivalent AI-driven machine could not be more immediate. For example: YouTube, “Harvesting Squash & Eggplant in Fresno County”.
In other words, agricultural robotics will only/finally arrive commercially on the farm when it can offer the farmer a human fieldworker equivalent.
But, here’s the catch, until there is an electro-mechanical equivalent to biological muscle, such a human equivalent robot is an unattainable dream.
Developers develop the ideas they can based on the current technologies available to them. Electromagnetic, hydraulic, and pneumatic are the only robust actuator technologies available to design with. So whatever ag-robot might be designed, its functionality, by necessity, will always be constrained to what these actuator technologies are capable of implementing.
This last observation brings this post back to the speculation as to why the field of agricultural robotics is not progressing. The answer is that, given the existing technologies available, it simply can’t.
The easy, and least charitable, explanation is that researchers in agricultural robotics are more concerned with making clever robots than they are in addressing the economic realities that farmers are constrained to work within. I personally think the real answer goes much deeper than this. But I would like to start by addressing this first speculation.
Regarding the economic reality farmers face; not once have I seen any article or research group address the fact that in the farming industry, productivity and profit do not necessarily correlate. In fact, often they are found in inverse correlation. If one farmer has a productive crop yield, chances are other farmers in that region have done as well. At harvest time, this gluts the market causing the price per commodity to go down; at which point the farmer actually ends up losing money. It is not unheard for a farmer to let a field go fallow midseason when it becomes apparent that a crop has become a money loser for the year.
And regarding the question of crop rotation, at least in my area (Pajaro Valley), except for the apple orchards and berry fields, I never see the same crop in the same field for more than one growing cycle. For example, for vegetable crops, it’s a given that there will be several different crops in the same field over the course of any growing season. This means that any ag-robot technology that requires permanent field-installed components will also become a nonstarter for the farmer.
For these reasons, farmers are extremely reluctant to make any kind of capital investment in equipment or infrastructure beyond what is minimally necessary. In other words, telling a farmer, as a sales pitch, that using a certain ag-robot technology can raise his/her productivity is not going to be, by itself, a useful marketing strategy.
For a farmer, a robot will be just another piece of equipment like a tractor or harvester; and, whether purchased or leased, machine payments come every month whether the equipment is working in the field or not. Contrast this with the economic reality of hiring a field worker; when the work stops, the field worker can be let go and the farmer’s financial commitment ends. This is a point universally overlooked. Yes, machinery and robotics, on paper, will appear to be far more productive then human labor. But the financial commitment that comes over the lifetime of ownership of a single-crop ag-robot negates any short-term/seasonal financial advantage it has over human labor.
The large corporate farms, whose operations encompass thousands of acres, can make the risky financial choice of purchasing a large sophisticated single-crop harvester or planter.
But for family farms, whose operations are measured in hundreds of acres rather than thousands, investing in such large sophisticated machinery is an out-of-reach financial decision; which is why smaller farming operations are more dependent upon hand labor.
One needs to be careful in reading the last two paragraphs. One has to make the distinction between mechanization and robotics. There are crops like wheat, corn, potatoes, peanuts, sugar beets, and etc., that lend themselves to a high degree of mechanization. From soil preparation to planting through to harvesting, each phase of the farming operation can be taken care of in one pass and at one point in time, with the handling of these particular crops all done mechanically. Contrast this with crops like berries, green beans or zucchini squash, where the harvesting goes on continually over the course of a plant's growing cycle, and which also require careful handling to avoid damage to both the food item and the plant itself.
When looking at those crops that lend themselves to mechanization, one finds that the farming industry has already reduced the need for human labor down to a handful of equipment operators running large integrated computerized machines. At this current state of affairs, robotics and AI offer little-to-no marginal return on investment. The best the robotics community can offer is to replace the remaining equipment operators with AI-based control systems. But the truth is, having a reliable, conscientious and responsible human operator on payroll represents a far greater return on investment to the farmer than spending money on a complicated computer-based AI control system that leaves them at the mercy of some outside, distant, and often unresponsive tech support.
To appreciate how serious this last situation is for farmers, one only needs to look to the recent controversy over the “right to repair” that has affected John Deere tractor owners across this nation.
• Wired Magazine, "John Deere Just Swindled Farmers out of Their Right to Repair".
• YouTube, "Right to Repair”.
• YouTube, "Tractor Hacking: The Farmers Breaking Big Tech’s Repair Monopoly”.
Where robotics can offer a true return on investment to the farmer is with crops that require special handling: picking fruit and berries and harvesting a variety of the vegetable crops. These are the crops for which the cost of labor is the largest single expense the farmer has to face. And with coming minimum-wage laws and other rules respecting work week hours, these are the kinds of expenses that will break a farmer financially. So, the incentive to replace the human fieldworker with an equivalent AI-driven machine could not be more immediate. For example: YouTube, “Harvesting Squash & Eggplant in Fresno County”.
In other words, agricultural robotics will only/finally arrive commercially on the farm when it can offer the farmer a human fieldworker equivalent.
But, here’s the catch, until there is an electro-mechanical equivalent to biological muscle, such a human equivalent robot is an unattainable dream.
Developers develop the ideas they can based on the current technologies available to them. Electromagnetic, hydraulic, and pneumatic are the only robust actuator technologies available to design with. So whatever ag-robot might be designed, its functionality, by necessity, will always be constrained to what these actuator technologies are capable of implementing.
This last observation brings this post back to the speculation as to why the field of agricultural robotics is not progressing. The answer is that, given the existing technologies available, it simply can’t.
Sunday, December 1, 2019
The T2-Tile Project, Publications, Race Conditions, and Breaking Symmetry in Asynchronous Arrays
To get myself back up to speed with the MFM, I went back and reread Dave Ackley’s two papers on the subject: “Pursue Robust Indefinite Scalability”, Ackley, Cannon, 2011, and “A Movable Architecture for Robust Spatial Computing”, Ackley, Cannon, Williams, 2011.
Then I dove further, reading publications cited in these two papers; at least, those that are accessible on the Internet. There are two main design considerations that have come to mind as I have been reading through this literature.
The first is that for very large and indefinitely scalable arrays, power considerations will dominate any design effort and asynchronous arrays are the only ones that satisfy this design constraint. Why this is so is that, neglecting leakage currents, CMOS circuits only consume power when being switched. For large synchronous CMOS logic circuits, the current consumed with the constant clock switching of 100's of MHz to GHz speeds, becomes the dominant power drain. For example, the datasheet for the fifth generation Intel core processor family lists I-ccmax values from 18 to 40 Amps!
Reducing power consumption in CMOS circuitry means clocking individual logic elements only when necessary. How this works in practice is that each individual processor cell in an asynchronous array is given a ring oscillator to act as its own local clock. The crucial feature of a ring oscillator is that it only turns on when an individual processor cell is accessed, then turns off when the cell’s internal programming has run to a stopping point. Therefore, when not in use, the individual processor cells turn off, effectively consuming no power at all. The potential drawback of this scheme is that once a cell has gone to “sleep”, it will only wake up again when accessed from a neighboring cell; that is, only when its ring oscillator gets “rung” again.
The second consideration came to mind as I read through this paper: “Embedding Universal Delay-Insensitive Circuits in Asynchronous Cellular Spaces”, Lee, Adachi, Peper, Morita, 2003.
It struck me as a good example of the kind of disconnect one finds between the theory of array computation versus the reality of hardware design. In this case, the authors considered the situation of a communication race condition; that is, the situation when two neighboring cells initiate communication at the same time. The question, then, of “who goes first?” comes into play with the possibility of a resultant lockup situation occurring. The authors presented a theoretical fix which they called delay-insensitive circuits. Theoretically, this is a fascinating piece of work in that it shows that every synchronous array is equivalent to some asynchronous version of it. But in reality, at the timescales where such communication race conditions would occur, digital electronics starts to behave in an analog fashion, in which case the paper’s straightforward theoretical results will no longer apply.
Race conditions within asynchronous arrays will always be the norm, not the exception. Some way has to be found, so that when communication is initiated between individual cells, they will automatically know who gets to go first and who waits. Just like in any social group, there has to be some kind of dominance hierarchy imposed on the global array.
In terms of what can be accomplished in a practical sense, one has to break the array’s global symmetry – directions have to be defined: up/down, right/left, top/bottom. Then communication is given preferred directions either based on a rule set or by the addition of a “breathing mode”; that is, a phase during which all communication goes in one preferred direction, followed by an alternate period of time when all communication flows in an opposite direction, with information flowing back and forth within the array something like the tides in the ocean.
This is one of the aspects of asynchronous array design that makes simulation qualitatively different than running on bare silicon. In simulation the programming for the virtual machine can be written to arbitrate any race condition that might come up between the individual CA-atoms. But when you forgo the virtual machine and try to run your asynchronous cellular automata on bare-metal processors, then the processor coding itself has to take care of these race conditions. It’s an extra layer to the hardware design that needs to be added to the MFM concept in order to make it work for real.
Then I dove further, reading publications cited in these two papers; at least, those that are accessible on the Internet. There are two main design considerations that have come to mind as I have been reading through this literature.
The first is that for very large and indefinitely scalable arrays, power considerations will dominate any design effort and asynchronous arrays are the only ones that satisfy this design constraint. Why this is so is that, neglecting leakage currents, CMOS circuits only consume power when being switched. For large synchronous CMOS logic circuits, the current consumed with the constant clock switching of 100's of MHz to GHz speeds, becomes the dominant power drain. For example, the datasheet for the fifth generation Intel core processor family lists I-ccmax values from 18 to 40 Amps!
Reducing power consumption in CMOS circuitry means clocking individual logic elements only when necessary. How this works in practice is that each individual processor cell in an asynchronous array is given a ring oscillator to act as its own local clock. The crucial feature of a ring oscillator is that it only turns on when an individual processor cell is accessed, then turns off when the cell’s internal programming has run to a stopping point. Therefore, when not in use, the individual processor cells turn off, effectively consuming no power at all. The potential drawback of this scheme is that once a cell has gone to “sleep”, it will only wake up again when accessed from a neighboring cell; that is, only when its ring oscillator gets “rung” again.
The second consideration came to mind as I read through this paper: “Embedding Universal Delay-Insensitive Circuits in Asynchronous Cellular Spaces”, Lee, Adachi, Peper, Morita, 2003.
It struck me as a good example of the kind of disconnect one finds between the theory of array computation versus the reality of hardware design. In this case, the authors considered the situation of a communication race condition; that is, the situation when two neighboring cells initiate communication at the same time. The question, then, of “who goes first?” comes into play with the possibility of a resultant lockup situation occurring. The authors presented a theoretical fix which they called delay-insensitive circuits. Theoretically, this is a fascinating piece of work in that it shows that every synchronous array is equivalent to some asynchronous version of it. But in reality, at the timescales where such communication race conditions would occur, digital electronics starts to behave in an analog fashion, in which case the paper’s straightforward theoretical results will no longer apply.
Race conditions within asynchronous arrays will always be the norm, not the exception. Some way has to be found, so that when communication is initiated between individual cells, they will automatically know who gets to go first and who waits. Just like in any social group, there has to be some kind of dominance hierarchy imposed on the global array.
In terms of what can be accomplished in a practical sense, one has to break the array’s global symmetry – directions have to be defined: up/down, right/left, top/bottom. Then communication is given preferred directions either based on a rule set or by the addition of a “breathing mode”; that is, a phase during which all communication goes in one preferred direction, followed by an alternate period of time when all communication flows in an opposite direction, with information flowing back and forth within the array something like the tides in the ocean.
This is one of the aspects of asynchronous array design that makes simulation qualitatively different than running on bare silicon. In simulation the programming for the virtual machine can be written to arbitrate any race condition that might come up between the individual CA-atoms. But when you forgo the virtual machine and try to run your asynchronous cellular automata on bare-metal processors, then the processor coding itself has to take care of these race conditions. It’s an extra layer to the hardware design that needs to be added to the MFM concept in order to make it work for real.
Subscribe to:
Posts (Atom)