> On May 21, 2020, at 3:56 PM, Jay Jaeger <[email protected]> wrote:
>
> On 5/21/2020 11:55 AM, Paul Koning wrote:
>>
>> ...
>> This sort of question is why I found starting with the simulator is helpful.
>> In a simulation you can specify delays directly. So for my 6600, I have
>> the gate delay (5 ns) and the wire delays (1.3 ns per foot, in the twisted
>> pair, or 25 ns for coax cables including tx/rx circuit). Actually, I only
>> include wire delays for "long" wires; the design clearly uses wires longer
>> than needed in various places for delay reasons, but my guess is that short
>> wires are not time sensitive. That may be wrong; I need to run it again
>> without that assumption to see if it helps.
>
> I do indeed plan on starting with simulation - just not for that reason.
> Its just easier to debug then the FPGA proper. ;)
>
> I suppose I could figure out the actual wire list, and thus wire
> lengths, but it would be have to be limited only to inter-panel wires,
> and even that much would be painful and very time consuming. But yeah,
> it makes sense to model gate delays in a general way and then perhaps
> lower them to see what happens at higher speeds, as you suggest below.
As I said, for most machines it is not likely to be useful to model wire
lengths. For the 6600, it is mandatory, and obvious from the design files:
when you see a 96 inch wire connecting two modules one inch apart, you know
there is a reason why that wasn't a 4 inch wire instead. Not to mention when
"adjust to get x ns pulse" shows up in an annotation.
One good example of this is the master clock oscillator. In most 6600s it's a
10 MHz crystal clock, but in the first 7 units built, it's a 4 stage ring
oscillator, with 96 inch wires to produce 25 ns delay between the four main
phases. The later version gets rid of the ring oscillator, but retains the
four buffers with wire delays, as n * 25 ns phase shifters.
If I were working on, say, a PDP-11, I wouldn't expect to have to deal with any
of this sort of craziness. But a 6600 is at, if not over, the hairy edge of
possible speed for when it was built. Even the peripheral processors are well
optimized, so they can run many of their instructions in 1 microsecond -- which
is the memory cycle time. Fetching and executing a new opcode every cycle is a
pretty hard task. The PPUs are actually pipelined, though the descriptions
you'll read about them don't make this clear at all.
Come to think of it, another nice optimization example is the process context
switch, which in the 6000 series is a single instruction -- 16
read/modify/write core memory cycles 100 ns apart, so the whole thing including
pipeline drain and restart takes 3 or so microseconds. Watching that in
simulation is fun.
paul
