14 Jul
2015
14 Jul
'15
4:40 p.m.
On 7/14/2015 11:27 AM, Paul Koning wrote:
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.
I am creating one to be sythesizable.
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).
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