> 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