> On Jul 14, 2015, at 11:46 AM, Jay Jaeger <cu...@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
