 | Level: Intermediate Clive "Max" Maxfield (max@diycalculator.com), Author, Freelance
20 Mar 2007 Nothing is as easy as one might hope. Since the last article was posted, the Heath Robinson Rube Goldberg (HRRG) Computer team has been battling every step of the way to bring the HRRG emulator's virtual cabinets online. On the way, we've re-engineered everything several times, and run across some unanticipated scenarios...
Good grief, so much has been happening since Part 3 of this series was
published that my head is spinning like a top. So, before plunging into
the fray, let me briefly bring you up to date with what has been going on.
As I mentioned when we first conceived the HRRG project, I had long
wanted to construct a simple relay-based machine. Over the years, I've
used relays for a variety of purposes, but never to implement logical
functions or memory (register) circuits. In the back of my mind I vaguely
thought it would be easy to use relays to implement simple NOT, AND, NAND,
OR, and NOR type functions (I assumed one relay per function). If I'd
given this any thought, I would have guessed that I'd implement a 1-bit
register element out of my simple logic primitives.
Boing! Incorrect. The result if we were to do things my way would be to
use a humongous number of relays to little effect. My problem is that I'm
trying to apply the techniques used to build silicon chips to an entirely
different implementation technology. In the case of a relay-based
register, for example, this can actually be constructed using only one
relay-per-register bit plus one extra relay for control. Furthermore,
although the relay coils are powered by say 0V and +18V -- and although a
logic 1 on the output from a relay will be +18V -- a logic 0 on the output
from a relay is left floating/unconnected (how strange).
The problem is that a lot of this stuff is rapidly becoming a forgotten
art. Most of the digital logic designers I know are as clueless as I am in
this arena. So I started rooting around secondhand bookstores on the
Internet, and I've come up with some real gems (there are still copies out
there if you look hard enough). In the case of relay-based logic circuits,
I've acquired two tomes: Switching Circuits and Logical Design, by Samuel
H Caldwell (I have the 1960 edition published by John Wiley and Son;
Library of Congress Catalog Card Number 58-7896) and The Design of
Switching Circuits, by William Keister, Alistair Ritchie, and Seth
Washburn (I have the 1951 edition published by Van Nostrand). As a point
of interest, Alistair Richie was the father of Dennis Ritchie, who is
famous for co-creating UNIX® and developing the C programming language.
With regard to logic implemented using vacuum tubes, I think we'd be
hard-pressed to find anything that could beat Pulse and Digital Circuits,
by Jacob Millman ad Herbert Taub (I have the 1956 edition published by
McGraw-Hill; Library of Congress Catalog Card Number 55-11930). This
little rascal covers everything from nonlinear wave shaping to
electromagnetic delay lines to digital logic circuits and registers (and
much, much more). It even has a section entitled "Magnetic Core Binary
Elements." Now, I know what you're thinking, but we aren't talking about
magnetic core memory stores; instead, the book shows how the same
ferromagnetic cores can be used to realize logical functions like shift
registers and binary counters.
Have you ever heard of this form of magnetic logic? I certainly hadn't
until several readers suggested that we implement one of the HRRG cabinets
using these techniques. This is how I came to find myself in the
possession of Digital Magnetic Logic, by David Bennion, Hewitt Crane, and
David Nitzan (I have the 1969 edition published by McGraw-Hill; Library of
Congress Catalog Card Number 68-28411). This stuff is just so amazing; the
book describes how to use ferromagnetic cores to realize all types of
functions, including combinational (or combinatorial if you prefer) and
sequential logic.
Speaking of ferromagnetic cores, one thing I want to do in the fullness
of time is build a small magnetic core store memory cabinet for use with
the HRRG. Nothing fancy -- perhaps just an 8x8 array (that's eight words
each containing eight bits). But where is one to find magnetic cores these
days? Well, it's funny you should ask, because I just took delivery of
50,000 of the little scamps (Figure 1).
Figure 1. Some ferromagnetic cores are much smaller than you may expect
Yes, that's correct, I did say 50,000. I purchased them on eBay from a
company in Bulgaria (I believe they originated in Russia or East Germany).
Truth to tell, I had thought the 50,000 quantity was a misprint, but I
wasn't too worried as I require only 64 of the little rascals. Once they
had arrived (in a small box the size of a lady's powder compact), however,
and I saw how tiny they were, I could well believe that there are indeed
the stated quantity (not that I've counted them, you understand).
The point is that as I require only 64 cores to implement my own core
store, I've found myself in the strange position of having 49,936 spare
cores on my hands! So if you are interested in building your own core
store, or if you are an educator who would like a few cores to show your
students, or if you simply want a few cores for your collection, just send
me a stamped addressed envelope telling me how many you need and I'll drop
them in the post to you (my shipping address is provided on the "About Us"
page on my DIY Calculator Web site -- see Resources).
But where is the HRRG emulator?
I know, I know. You aren't interested in my waffling on about books and
magnetic cores. Instead, you are aquiver with anticipation awaiting the
HRRG emulator. Sad to relate, I have to hang my head in shame. Getting
this little rapscallion up and running has been much harder than we ever
anticipated. When not slaving away at his real job, Joe Farr in the UK --
the hero who has been doing the real work converting my random musings and
blathering into something tangible -- has been devoting every spare moment
to the HRRG emulator. As unexpected things have arisen along the way,
we've ended up re-architecting the system several times. In fact, we made
a major architectural decision just yesterday evening as I pen these
words, but let's not wander off into the weeds. Suffice it to say that
things are now racing along, and we have every expectation of having a
working application for you to play with by the time the next part of this
series goes live.
In the meantime, just to show you that things are moving along, you may
be interested to hear that one of our graphics artist friends has
completely refurbished our virtual cabinets. Our spiffy new brushed-steel
look and feel can be seen with the ALU, Status, and Addressing Logic
cabinets as illustrated in Figure 2. Also, all of the LEDs, push-buttons,
and toggle switches have been recreated for us by "the master" (and you
won't believe your eyes when you see the neon and nixie-tube displays
available for use on the Output Port cabinets).
Figure 2. The HRRG's virtual cabinets have a new brushed-steel look-and-feel
Now, you may be thinking something along the lines of: "If this were a
real project, how could we explain to clients or investors the benefit of
spending time on creating shinier, spiffier cabinets when the emulator
itself has not been completed?" In real life, stakeholders aren't always
technical enough to appreciate that the new graphics were created off-line
by the artist, and so did not actually eat up any development time. As
well, we made sure they had the same names as the originals, so that
implementing the new look-and-feel largely consisted of dropping the new
elements into the correct project folder. Depending on your situation in a
real project, though, we'd probably keep mum about the new look for now,
and use it to crown our triumph next time, when we present the
emulator. Having it ready now, though, means things will go more smoothly
in the future.
Lessons learned
Later on in this article I'll stroll through pseudo-code
representation of the Status logic cabinet, and then you can start
pondering how you might create the pseudo code for the ALU Logic,
Addressing Logic, and Control Logic cabinets (you'll see our
versions of these three cabinets in Part 5). But before doing that, I'll pause for a moment to consider some of the lessons learned thus far.
First and foremost, everything always takes longer than you expect. Ever
since I started my engineering career more than a quarter of a century ago
(good grief, it seems strange to be saying that), I've found it to be a
good rule of thumb to estimate how long something will take me and then
double it. The problem is that I always do this "after the fact." Sad to
relate, when a new project comes along, I think: "No problem -- that's
easy -- it will only take me X minutes/hours/days," and off we go again.
Another lesson relates to the old carpenter's adage: "Measure twice then
cut once." In our case, this would translate to: "The more time you invest
on the specification, the less time you'll spend downstream filling in the
holes!" Consider our Device Tester utility, for example. As each cabinet
(both virtual and physical) is implemented, we need some way to test it in
isolation. To this end (as I briefly mentioned in Part 3), Joe
created a Device Tester application (Figure 3).
Remember that all of the cabinets (virtual and physical) forming the HRRG
communicate by bouncing small packets of information back and forth
between themselves. The Device Tester allows us to define Transmit (T)
packets that appear to come from any cabinets we wish. When one of these
packets (indicated by the 'T' in the left-hand column) is seen by the
cabinet under test, it accepts the information and -- if relevant --
processes it and responds accordingly. The expected responses in a
Response packet are indicated by an R in the left-hand column.
Furthermore, each 'R' line is followed by an '=' line that reflects the
actual response that was generated by the cabinet (any unexpected
differences between an 'R' line and its corresponding '=' line would be
highlighted in red).
Figure 3. The HRRG's Device Tester application
(Click to see the full-size image of Figure 3.)
As you might expect, the Device Tester application has evolved to
accommodate a variety of things we didn't think about up front. For
example, we now have much more sophisticated single-step,
run-to-breakpoint, and loop capabilities than existed in the original
version.
Furthermore, although we had anticipated occasions whereby an expected
response might not appear, we completely neglected to consider what would
happen if the cabinet under test were to generate a response that we
didn't expect. This explains the new type of lines in the Device Tester
that are indicated with a '*' character in the left-hand column. Now, the
cabinet under test always returns either a full Response packet (if it
needs to do something), or a simple Acknowledge packet (if it doesn't need
to do anything).
The reason we are spending so much time working on the Device Tester is
two-fold. First, it's much easier to perform initial, low-level
verification on a cabinet in isolation than when it's integrated into a
complete system. Second, the same tests that are used to verify a virtual
cabinet can subsequently be applied to its physical counterpart.
Last but certainly not least, we've learned that working in
geographically distant locations confuses the issue in a variety of ways.
For example, Joe is based in the UK while I currently hang my hat in
Huntsville, Alabama, USA (I moved here for the nightlife). This means that
there is a six hour time difference between us, which significantly limits
our "windows of opportunity" with respect to chatting on the telephone.
The end result is that a lot of our communication takes place in the form
of e-mail notes and files. For example, Joe's software is evolving so
quickly that I tend to keep a "hands-off" approach. Thus, the way we
generate a test sequence for the Device Tester is that I first capture it
as a Microsoft® Excel® spreadsheet, which I subsequently e-mail to Joe.
Joe exports my tests as a comma-separated value (CSV) file, which he then
imports into the device tester. For your delectation and delight, I've
provided an example of one of my original Status Logic tests (see
Resources).
You can only imagine how much fun this is when a test fails. Once we've
finally arrived at a mutually acceptable time, Joe and I have spent hours
on the phone walking through a test packet-by-packet trying to track down
an error. In the early days, the problems were only exacerbated by the
fact that our line numbers didn't match up (I didn't have the '=' lines in
my spreadsheet and -- more recently -- I didn't have the '*' lines). We
have, of course, addressed this issue now.
Our lives would be so much easier if we could meet up say once a week and
work things out on a whiteboard. I've used a variety of teleconferencing
systems before, but they've all left something to be desired. I dream of
having full holographic capabilities that can simulate our being in the
same room ... maybe one day ...
GPIO and VGPIO cards
As I discussed in Part 3, each physical cabinet forming the HRRG
computer will contain a General-Purpose Input/Output (GPIO) card.
Similarly, each virtual cabinet in the HRRG emulator contains a Virtual
GPIO (VGPIO) card. The GPIO and VGPIO cards communicate by transmitting
and receiving packets of information back and forth between themselves.
The heart of each physical or virtual cabinet is its core logic or
"payload." This will be implemented in the technology of choice in the
real world, or as some form of code in the virtual world.
When a general-purpose data packet is transmitted by any of the physical
or virtual cabinets, it will be "seen," examined, and processed (as
necessary) by all of the other cabinets. The GPIO/VGPIO cards in these
cabinets will first check the packet to determine (a) which type of
cabinet sent the packet and (b) what type of information the packet
contains. In some cases, the GPIO/VGPIO card will understand that it is to
do nothing at all; in some cases it will understand that it is to modify
some of the inputs to its payload, but that it is not required to transmit
a response packet; and in some cases it will understand that it is to
modify some of the inputs to its payload, wait for new values to be
generated by the payload, and then transmit a response packet containing
these new values.
The point is that all of the "control" is automatically handled by the
GPIO/VGPIO cards; the only thing required of any cabinet's payload is that
it process any signals fed to its inputs and that it generate appropriate
outputs; the payload neither knows nor cares what happens to these outputs
-- that's the responsibility of its GPIO/VGPIO card.
Every GPIO/VGPIO card may be visualized as maintaining copies of the data
structures shown in Figure 4:
- rx_pkt:
The incoming data packet
- tx_pkt:
The outgoing response packet (if any)
- old_in_buf:
A set of the last values that were applied to the inputs of the logic
- new_in_buf:
A buffered set of the new values being applied to the inputs of the logic
- out_buf:
A buffered set of the values coming out of the logic
Figure 4. A high-level view of the GPIO/VGPIO data structures
These structures are partitioned into major "chunks" as follows:
- Packet Type:
Tells us if this is a general-purpose data packet, a special
configuration packet, a simple acknowledgement packet, and so forth (the
value on the outgoing packet may be different to the value on the incoming
packet)
- MAC Address:
The 6-byte MAC address uniquely identifies the unit that
originates the packet (the value on the outgoing packet will be different to
the value on the incoming packet)
- Source Unit Type:
This is the type of cabinet originating the packet
(ALU Logic, Status Logic, Control Logic, Addressing Logic, RAM, ROM,
and so on)
- Info Type:
The different types of information contained in the packet
(address, data, status, control, and so on)
- CPU Signals:
High-level CPU signals such as ~RD (read), ~WR (write),
~RESET, and ~BUSY
- Address[15:0]:
The current value on the 16-bit address bus
- Data[7:0]:
The current value on the 8-bit data bus
- Status[4:0]:
The current values on the status flags
- Control Word:
The various control signals that are generated by the
Control Logic cabinet and used to control the ALU, Status, and Addressing
Logic cabinets (The control signals for the ALU include a 5-bit instruction
word called inst[4:0].)
A detailed pseudo-code breakdown of the basic general-purpose data
structures used by all of the GPIO and VGPIO cards is provided in the
appropriate Data Structures document (see Resources).
For the purpose of this discussion, we are interested only in the
fact that the signals from the GPIO/VGPIO card's new_in_buf (new
input buffer) are passed into the cabinet's payload. Similarly, signals
coming out of the payload are captured in the GPIO/VGPIO card's
out_buf (output buffer), from whence they will be bundled into a
packet and transmitted to the other cabinets forming the system (if
necessary).
In the case of a physical cabinet, technology translator elements will be
inserted between the new_in_buf and the core logic, and also
between the core logic and the out_buf. These elements will convert
the 0V and 5V signals used by the GPIO card into corresponding
technology-specific values, such as different air pressures in the case of
a cabinet implemented using pneumatic logic (or perhaps food pellets in
the case of a cabinet implemented using juggling hamsters).
The rest of this article will present a pseudo-code representation of the
payload for the Status Logic cabinet. Once we have the HRRG emulator up
and running, you will be able to create your own virtual cabinets. If you
are planning on implementing a physical cabinet, then your virtual
representation should model the anticipated physical realization as
closely as possible. For example, if you are planning on using an
implementation technology that has unusual characteristics, you should
attempt to model those characteristics in your virtual prototype.
In our case, we have enough problems on our hands proving the rest of the
system, so we've assumed a standard "jelly-bean" (simple) integrated
circuit implementation based on the old TTL (Transistor-Transistor Logic)
type devices. Once we have the emulator up and running, I plan on adding a
virtual relay implementation for at least one cabinet; a virtual vacuum
tube representation for another, and so forth.
Pseudo code for the Status Logic VGPIO card's payload
Before you do anything else, may I remind you that the CPU we are using
for the HRRG is the same as the CPU we used for our DIY Calculator
project. The inner machinations of this CPU are described in excruciating
detail in The Official DIY Calculator CPU Data Book, which you can
download from the DIY Calculator Web site for free (see Resources).
A coarse-grained view of the Status Logic VGPIO card and payload is
illustrated in Figure 5. As you see, the two CPU signals that might affect
this cabinet are the ~RESET signal and the ~BUSY signal (in fact, we won't
be using the ~BUSY signal in this implementation -- at least, not in the
payload).
Figure 5. A coarse-grained view of the Status Logic VGPIO card and payload
Observe that, in the case of the incoming data bus, only five signals --
data[4:0] -- are passed into the payload. This is because the
Status Logic cabinet contains only five status flags (I, O, N, Z, and C).
Also, the reason we might be loading these flags from the data bus is in
the case of a POPSR ("pop the status register from the stack") instruction.
(The outgoing data bus has all eight signals, because we tie the
most significant three to logic 0.)
Also observe that, in the case of the incoming status bits, we are only
using status[3:0]. This is because only the O, N, Z, and C bits
come in from the ALU Logic cabinet (sometimes the Z bit comes in from the
Addressing Logic cabinet in the case of an INCX or DECX instruction). By
comparison, the I (Interrupt Mask) flag can only be set or reset using
hard-wired signals generated by the Control Logic to service SETIM ("set
interrupt mask") and CLRIM ("clear interrupt mask") instructions.
Last but not least, only those signals from the control word that affect
the Status Logic are fed into its payload.
Now, consider a slightly more detailed representation of the
internal working of the Status Logic cabinet as illustrated in Figure 6.
Figure 6. A fine-grained view of the Status Logic's payload
Local Variables
Bit reg_i, reg_o, reg_n, reg_z, reg_c;
4-Bit input_mux[3:0]
Byte t_buf[7:0]
On Power-Up
input_mux[3:0] = %0000; {% indicates a binary value}
reg_i = 0;
reg_o = 0;
reg_n = 0;
reg_z = 0;
reg_c = 0;
t_buf = $00; {$ indicates a hexadecimal value}
Body of payload
Note that this version assumes we're using the timed delay mode, so
there's no code for using the virtual ~BUSY signal (the concept of the
~BUSY signal was introduced in Part 3).
If new_in_buf.control_word.sel_status_2_1 = 0 Then
input_mux[3:0] = new_in_buf.status[3:0]
Else
input_mux[3:0] = new_in_buf.data[3:0]
End If
If new_in_buf.cpu_signals.reset = 0 then
reg_i = 0;
Else
If new_in_buf.control_word.clr_im = 0 then
reg_i = 0;
Else
If new_in_buf.control_word.set_im = 0 then
reg_i = 1
Else
If (new_in_buf.control_word.clk_status_i = 1) And
(old_in_buf.control_word.clk_status_i = 0) then
reg_i = new_in_buf.data[4]
End If
End If
End If
End If
If (new_in_buf.control_word.clk_status_o = 1) And
(old_in_buf.control_word.clk_status_o = 0) then
reg_o = input_mux[3]
End If
If (new_in_buf.control_word.clk_status_n = 1) And
(old_in_buf.control_word.clk_status_n = 0) then
reg_n = input_mux[2]
End If
If (new_in_buf.control_word.clk_status_z = 1) And
(old_in_buf.control_word.clk_status_z = 0) then
reg_z = input_mux[1]
End If
If (new_in_buf.control_word.clk_status_c = 1) And
(old_in_buf.control_word.clk_status_c = 0) then
reg_c = input_mux[0]
End If
If new_in_buf.control_word.ena_status_tbuf = 0 Then
t_buf[7:0] = {%000, reg_i, reg_o, reg,n, reg_z, reg_c}
Else
t_buf[7:0] = %00000000
End If
{That's all folks}
|
Well, that wasn't too difficult, was it? (Just wait until you try doing
one of your own.)
At this point I should note that I'm not a programmer -- I'm a hardware
design engineer by trade -- so I make (and evolve) this pseudo code up as
I go along. Joe then takes my meandering musings and converts them into
real code in the language of his choice.
Is there anything we would have done differently if we could go back in
Time (in addition to the points I mentioned in the Lessons learned section
earlier in this article)? YES! We would have defined a signal naming
convention that satisfied both our requirements. Sadly, we didn't consider
this aspect of things until we were knee deep in the mire, but we're
learning as we go along.
Well, that's all for now. Your mission -- should you decide to accept it --
is to take one of the ALU, Addressing, or Control Logic cabinets and see
if you can sketch out your version of the pseudo code you could use as a
basis for implementing it. (I'd recommend you start with the Addressing
logic and then proceed to the ALU Logic.) Also remember that the overall
architecture of these cabinets is described in The Official DIY Calculator
Data Book (see Resources).
As a final note, it would be great if you posted your pseudo code (and/or
any other thoughts and ideas) to the HRRG forum so that others can see
what you're up to and offer their feedback and suggestions.
Resources - Participate in the discussion forum.
- See this spreadsheet containing one of our earlier test sequences used to verify the Status Logic cabinet (PDF format, 40.2KB).
- This Data Structures document provides a detailed pseudo-code breakdown of the basic general-purpose data
structures used by the GPIO and VGPIO cards (PDF format, 59.6KB).
- 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.)
-
Part 1 of this
series describes how the plan for the
Heath Robinson Rube Goldberg multifarious technology computer project came
together.
- 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 various input and output signals for the functional blocks forming
the
HRRG's CPU are detailed on this Partitioning the CPU Web page.
- Get
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.
-
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.
-
The
IBM Semiconductor Solutions Technical Library
hosts a wealth of information -- from
specifications and user manuals to product briefs and errata and much more.
About the author | 
| | 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.
|
Rate this page
| |
