Reproducing old machines with newer technology (Re: PDP-12 at the RICM)
paulkoning at comcast.net
Tue Jul 14 11:27:16 CDT 2015
> 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
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.
More information about the cctech