![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
The Heath Robinson Rube Goldberg (HRRG) Computer ties together modules constructed with all sorts of different implementation technologies. For the whole entity to function, you must define a common interface mechanism between hydraulics, mechanics, and any other sort of hardware you want to attach. You also need to decide how deeply to specify the internal architecture of these modules; there's a cost-benefit sweet spot between maximum flexibility and the network bandwidth required to communicate among the various component parts.
As Part 1 discussed, wrapping one's brain around all of the ramifications associated with "The Beast" -- as the Heath Robinson Rube Goldberg computer is affectionately known (and hereafter referred to) -- can bring even the strongest among us to his or her knees, so we'll take things step-by-step.
As fate would have it, things are actually easier to comprehend if you start at the end and work backwards. For example, you know that -- in the fullness of time -- the physical incarnation of The Beast will be presented as a collection of "cabinets." Each cabinet will contain one of The Beast's primary functional units. These cabinets will each have wooden top, bottom, side, and back panels; their fronts will be transparent (Perspex or hardened glass).
The plan is for you (and a lot of other folks) to be able to implement different cabinets in the technology of your choice. At some time in the hopefully not-so-distant future, there may be a "gathering of the clans" whereby all of the different cabinets are brought together (as opposed to them being run in conjunction with a software emulator or linked through the Internet). Thus, in order to enhance the visual appeal of the final system, plans for the construction of these cabinets will be available. These plans will detail the height, width, and depth of the cabinets; the type of wood or stain; the joints to be used; and the way the Perspex/glass will be attached.
Of course, some cabinets will need to contain more "stuff" than others, depending on the complexity of the functional unit being created and the implementation technology being used (transistors will consume less space than relays, for example). To accommodate this while maintaining visual appeal, all of the cabinets will have the same height, but each cabinet's width may be any integer number of feet (that is, a cabinet might be one, two, three, or more feet wide).
Defining the primary functional units
With regard to the primary functional units forming The Beast, a complete system will comprise one Clock Generator cabinet, one Central Processing Unit (CPU) (which itself comprises four functional units), one or more ROM cabinets, zero or more RAM cabinets, zero or more Input Port cabinets, and zero or more Output Port cabinets. Figure 1 illustrates this cabinet collection.
Figure 1. The primary functional units forming The Beast
The reason for using the "zero or more" qualifier with regard to some of these cabinets is that although a useful system will require RAM and input/output (I/O) capabilities, these cabinets aren't strictly necessary to get a minimal system up and running.
As Part 1 discussed, each of these functional units may be implemented in the physical world or as a virtual representation in the form of the HRRG Emulator (Part 3 introduces this emulator in more detail). For the purpose of these discussions, assume that all of the cabinets have physical incarnations, and that they are equipped with some way to "talk" to each other through a network as Figure 2 illustrates.
Figure 2. Functional units communicating through a network
Joe Farr, introduced in the "Who is to Blame" paper (see Resources), has defined the network, packets, and protocols to be used. All of these details will be presented in the fullness of time; at this stage in the game, however, it is only necessary to know that each physical cabinet will contain a General-Purpose Input/Output (GPIO) card. These cards communicate by broadcasting small packets of information to all of the other functional units on the network.
Among other information, each packet contains an identifier describing from which type of functional unit it originated. When a cabinet receives a packet, it decides what to do depending on the type of unit it is; for example, although the packets generated by the clock cabinet are broadcast to all of the other cabinets, the only unit that actually uses them is the CPU cabinet containing the Control Logic. (You should note that this isn't a design limitation, but merely a result of the currently planned implementation. If, in the future, you decided to add a timer module, for example, this unit might also use the clock signal.)
Each of the cabinets transmits and receives the same packet format, which includes address, data, control, and status fields. (If you are interested, the paper "Partitioning the CPU" presents a a high-level view of the packet format -- see Resources.) When it receives a packet, a cabinet will ignore any information in which it has no interest. For example, memory cabinets have no interest in anything to do with regard to packets that are transmitted by the status logic, so they will discard these packets in their entirety. By comparison, a memory cabinet may be interested in a packet containing a read request from the control logic, but it will pay no attention to the status field in this packet.
Similarly, when it comes to transmitting a packet -- in the case of any information in that packet over which it has no control -- a cabinet will transmit null values. When the memory cabinet responds with a packet containing a requested eight-bit chunk of data, for example, it will set the status field in its packet to a null value.
The CPU itself will be considered in more detail shortly. In the case of the clock generator cabinet, irrespective as to how this is implemented, it will transmit packets containing alternating "tick" and "tock" signals, which correspond to the rising and falling edges of the system clock, respectively. In the case of the ROM, RAM, Input Port, and Output Port cabinets, each will be assigned a range of memory addresses. This means that it will be possible to create a RAM cabinet, for example, containing only say sixteen 8-bit words of memory in the technology of your choice (relays, fluidics, hand-woven magnetic cores, and so on). Taken to its most extreme, you could create a whole series of RAM cabinets, each containing only a single eight-bit word of memory.
Now consider what a physical cabinet will look like in a little more detail as illustrated in Figure 3 (this series will return to consider physical implementations in much more depth later).
Figure 3. High-level view of a physical cabinet
The signals from the GPIO card feeding the internals of the cabinet will be at the trusty TTL (Transistor-Transistor Logic) levels of 0V and 5V. One reason for selecting this technology is that it is relatively immune to noise; another is that devices capable of accepting and generating these signals are relatively "cheap-and-cheerful." These signals will be translated into equivalent versions appropriate to this cabinet's technology; in the case of a cabinet featuring pneumatic logic, for example, 0V might be converted to -15 PSI, while +5V might be converted to +15 PSI (where "PSI" is the abbreviation for "pounds per square inch"). The pneumatic logic will then perform its magic and the output signals from this logic will be translated back into their equivalent TTL voltage levels.
The reason for considering this high-level view of the cabinet architecture here is that it has some bearing on how the CPU is partitioned. Speaking of which...
Which CPU should be used and how should it be partitioned?
A major consideration for The Beast is to settle on its underlying CPU. The original plan was to create the HRRG emulator in such a way that it could be configured to represent almost any CPU architecture. Eventually, however, we ("the HRRG team," particularly Joe and I; see the "Who is to blame" Web page linked in Resources) decided that following the KISS principle ("Keep It Simple, Stupid") and implementing a single architecture would be best all round.
For a number of reasons, we decided to base The Beast on the CPU featured in the DIY Calculator (see Resources) -- not the least that we own all of the rights to this little rascal, a simple editor-assembler utility is already available, and numerous code examples and routines are described in the book How Computers Do Math (see Resources).
Of particular interest with regard to constructing The Beast is the fact that there is already a 200-page "Official DIY Calculator Data Book" that you can download from the DIY Calculator's Web site. This little scamp describes the inner machinations of the CPU architecture (including its timing waveforms) in excruciating detail (see Resources).
The next question relates to the partitioning of the CPU. This is where things become complicated, because it significantly affects the way in which a corresponding emulator is implemented. Ideally, it would be possible to create an almost infinite number of partitions. For example, the DIY Calculator's CPU contains a core Arithmetic-Logic Unit (ALU), which is where all of the "number crunching" is performed. This core ALU can perform only five rudimentary functions (see Figure 4 ).
Figure 4. The core ALU
In the DIY Calculator, this core ALU is subsequently augmented with additional logic on its inputs that enables it to perform additions and subtractions, and more logic on its outputs that enable it to perform shifts and rotates. Last but not least, memory elements called registers are used to connect the extended ALU's inputs to the outside world. Similarly, special gates called "tri-state buffers" are used to connect its outputs to the outside world (by means of a control signal, these gates can be electrically isolated from the outside world).
So, the idea would be to implement the core ALU in its own cabinet in the technology of your choice, and to then run this in conjunction with the rest of the system residing in the emulator or additional physical cabinets (or both). The attraction to being able to implement a small "chunk" of logic like the core ALU in isolation is that it's relatively simple and it's purely combinational (some folks prefer to say "combinatorial").
On this basis, you might think it would be a good idea to support an even finer resolution. For example, one possible implementation of the core ALU (excluding any special status logic) could be as illustrated in Figure 5. In this case, you might decide to create a physical cabinet containing only the main 4:1 multiplexer, and to leave the remaining logic to the emulator or other physical cabinets (or both).
Figure 5. One possible implementation of the core ALU
Once again, the attraction of being able to implement a small "chunk" of logic like the 4:1 multiplexer in isolation is that it makes life simple. At least, it makes life simple when creating the physical cabinet associated with this logic, but things become nightmarish with regard to (a) the emulator and (b) the amount of information in the packets that have to be passed between the various cabinets.
In fact, there are a number of issues with regard to supporting this fine-grained scenario, such as dramatically increasing the amount of data that has to be passed back and forth between the various cabinets. Perhaps the biggest stumbling block, however, is the fact that the act of breaking things down into this fine level of granularity -- which requires defining all of the internal signals -- means that the internal architecture of each block must already be defined. This is not an ideal situation. In the case of the control logic, for example, you might wish to implement this as a great big hairy block of logic, or as a micro-programmed machine, or using some other technique. But if the control logic is defined down to the level of its internal signals, then its micro-architecture has perforce also been defined.
Thus, taking all things into account, we decided to partition the CPU into four functional units: the ALU (and supporting logic), the status logic, the control logic, and the addressing logic (as illustrated in Figure 6).
Figure 6. The four functional units forming the CPU
This approach confers several advantages. First and foremost, it allows you to fully control the internal implementation of any of these functional units for which you decide to undertake a physical implementation. All that is required is that you meet the external interface definition for that unit. It also greatly reduces the amount of communications traffic (the size of the packets) that has to be passed among the various units.
The actual definition of the inputs and outputs to these four functional blocks is a little too involved to go into here; there's a separate paper on these if you are interested (see Resources).
Part 3 introduces the emulator software in more detail, Part 4 shows you how to add your own functional units to the emulator, and Part 5 ... well, let's not get carried away. Until next time, have a good one!
- Participate in the discussion forum.
- Get an RSS feed for this series or subscribe to the zone newsletter IBM microNews and be notified each time a new installment is published. (Find out more about RSS feeds of developerWorks content; find out more about IBM microNews.)
-
See all of the articles in this
series to date.
- Find numerous suggestions for "The Beast" on the HRRG
Project Web page.
-
The various folks involved in the HRRG project in one way or another are
introduced in this Who is to blame? Web page.
- Download a compressed (*.zip) file containing an Adobe Acrobat (*.pdf)
version of "The Official DIY Calculator CPU Data Book" from the Area-51
folder on the DIY Calculator's Web site.
- The Partitioning the CPU Web page details a high-level view of the packet format along with the various
input and output signals for the functional blocks forming the
HRRG's CPU.
- Obtain the book How Computers Do Math, which features the same CPU
that will be used to form the basis for the HRRG, from
www.Amazon.com.
- Download a virtual version of the same CPU that will be used to form the
basis for the HRRG for free from the
"Downloads" page
on the DIY
Calculator Web site.
- "Bit-Slice Design: Controllers and ALUs" is an interesting
text, available for free, online
reading, on the old AM2900 bit-slice processor.
-
The "More Cool Stuff" page on the DIY Calculator Web site
contains a
treasure trove of topics, including, A
History of Calculators and Computers, A
Timeline of Calculators, Computers, and Other Stuff, The
Computing Universe, Rounding Algorithms 101, and a rather interesting
paper on Color Vision.
-
Keep abreast of all the Power Architecture-related
news that's fit to print: subscribe to IBM microNews.
Clive (Max) Maxfield is the author/co-author of a number of books,
including Bebop to the Boolean Boogie (An Unconventional Guide to
Electronics) and How Computers Do Math, featuring the pedagogical and
phantasmagorical virtual DIY Calculator.
In addition to being a hero, trendsetter, and leader of fashion, Max is
widely regarded as being an expert in all aspects of computing and
electronics (at least by his mother). Max was once referred to as "an
industry notable" and a "semiconductor design expert" by someone famous
who wasn't prompted, coerced, or remunerated in any way.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
