Reproducing old machines with newer technology (Re: PDP-12 at the RICM)
cube1 at charter.net
Tue Jul 14 18:40:26 CDT 2015
On 7/14/2015 11:27 AM, Paul Koning wrote:
>> On Jul 14, 2015, at 11:46 AM, Jay Jaeger <cube1 at charter.net> wrote:
>> Using the structural / gate level techniques, one does run into some
>> issues, most of which have (or will probably have) solutions:
>> 1) R/S latches composed of gates in a combinatorial loop. The problems
>> this causes are several, including the latch getting folded into the
>> look up tables for gates which use the signal, and issues when one
>> brings such a signal out to an I/O pin to feed to a logic analyzer,
>> which can cause problems to appear and disappear. My experience is that
>> one can add a D flip flop after the RS latch. This typically works
>> because at 50 Mhz, it adds only 20 ns delay, which is comparable to gate
>> delays these old machines typically had.
> I didn’t like what happened with flops built out of gates when doing my 6600 model. So I replaced those by behavioral models. The main reason was that the crossed-gate model would produce a mess with R and S both asserted, which that design would do at times, while the behavioral model was written to do something specific for that case.
The approach I have used is a compromise between the two - it isolates
the problems building flip flops out of gates, while still preserving
the original design. That said, when I come across a flip flop on an
SMS card, I will probably build it its own behavioral model.
>> 2) One-shots. I haven't had to address this one yet, but I am sure
>> that I will. I expect that one can simply use a counter to handle it -
>> no big deal at all.
> If you’re creating a model to run in simulation, you can just write a delay. But that’s not synthesizable, so if you really do need a delay then a counter, or a shift register, or something like that will be needed. This is the sort of thing that makes a 6600 design tricky (and may also apply to some other fast machines): there are places where propagation delays are used for correctness, and if the replacement hardware is “too fast” it doesn’t work.
I am creating one to be sythesizable.
>> 3) Flip flops which are clocked from combinatorial signals. These tend
>> to cause timing/glitch issues. For example, in one case the
>> combinatorial output was a zero-check on a counter. Since the counter
>> flip flops did not all change at exactly the same time, that signal
>> could glitch during the simulated machines master clock edge. They
>> respond well to the same general solution as #1 - stick a D flip flop
>> between the combinatorial output and the clock input. In the case I
>> mentioned, that gave the signal an entire 50 Mhz clock period to settle
> That sounds like a bug in the original. If you have a set of flops clocked by some signal, and it matters that the outputs don’t all change at the same time, then the original wasn’t reliable either.
That is just it - the combinatorial inputs were used FOR the clock on
some gates. Right - not a good idea even back in 1972, though it
depends a little on what the rejection time / intertial delay of the
inputs are, but yes - certainly a design that would be prone to failure
(remember that this was a bunch of students trying to put together a
working 12 bit computer in about a month - ours included a cross
assembler and cross-interpreter, so we had real software running our
machine for its demo - including hangman played with the TTY keyboard
and an oscilloscope hooked to a pair of D/A converters for a display).
More information about the cctalk