On 7/14/2015 11:27 AM, Paul Koning wrote: > >> 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.
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 >> 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. 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). > > paul > >
