Reproducing old machines with newer technology (Re: PDP-12 at the RICM)

[Paul Koning]

> 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.
> 
> 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.

> 
> 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
> down.

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.

	paul