6 Jun
2018
6 Jun
'18
5:39 p.m.
On Jun 6, 2018, at 6:30 PM, Jim Manley via cctalk
<cctalk at classiccmp.org> wrote:
...
Seymour Cray was a genius because he observed that the fastest possible
circuit is a wire, and that if you use the same length of wire for each bit
in a word in cables between stages in a computer that you want to go as
fast as possible, all of the bits will arrive at the next stage at the same
time. That was important for computers that took up entire rooms, with
circuit boards and racks far enough apart that upwards of a dozen
nanoseconds could elapse as bits passed from stage to stage.
Yes. "Same length wire" is how I first heard it. When I started reading the
6600 wire lists I discovered that the reality is far messier. The PPUs aren't too
bad, that is a 4 phase clock, where consecutive stages are clocked usually at 50 or 75 ns
apart. For example, the consecutive stages of the barrel are clocked (mostly) at 75 ns
difference.
The CPU is much worse. It sometimes has 4 clock phases, but some parts look more like 6
or 7. If you study the block diagrams you'll see clock signals annotated by their
offset from the zero reference, in increments of 5 ns. Not quite all of the 20 possible
offsets are used, but more than half are. And it matters, as I found out the hard way
while trying to get a VHDL model to work. The model includes the nominal gate delay (5
ns) and the rounded wire delay in 5 ns multiples for "long enough" wires. That
mostly works. Replacing the clock tree by explicitly coded 5 ns multiple clock signals
makes it better. Sometimes the documented value isn't quite right and you need to
move things by 5 ns. Sometimes the same document gives two different timings for the same
clock signal on different pages.
Oh yes, then there are amazingly nutso things like flip-flops (which in the 6600 are R/S
flops) where the R and S inputs are asserted at the same time, with pulses that both rise
and fall roughly at the same time. I can fudge that. But it makes me wonder why the 6600
ever worked in the wild.
For example, in the instruction issue and instruction stack logic I can get an "eq
*-2" to work the first time and the second time but not the third: "not in
stack" works, "in stack" works the first time because the "inch"
is still underway, but by the second time the inch has stopped and my timing is off by 5
ns and things go utterly haywire. By tweaking nanoseconds I can move the problem but I
have not yet made it go away.
One place that does offer a fair amount of sanity is cross-cabinet connections; the coax
cables are all the same and the nominal delay including driver and receiver is 25 ns,
which nicely matches the semi-standard 4 phase clock. So tracing signals around a pile of
cabinets works pretty well. Some of the data paths are quite amazing, because the memory
fan-in and fan-out is routed through several other cabinets and the control signals are
routed separately yet again. Tracking the signals for an exchange operation, for example,
is quite an impressive dance of actions being launched fairly long in advance so they get
to the memory latches at just the right time.
paul