On 7/14/2015 2:27 PM, tony duell wrote: > >> 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. > > It is very poor design, and not something that I would do, but it certainly > was done in production machines. > With care you can determine the width of the glitch, and if it's small > enough, ignore it.
Yeah, and this original design was a bunch of pre-newbie students just trying to get the darn thing to work by hook or by crook. ;) Hey - at least we did a good enough job of documenting it that it was possible to reproduce! > > But there is a related problem with FPGAs. You learn in introductory digital > electronic courses that there are > 2 types of counter. The Asynchronous, or ripple, counter where each flip-flop > toggles the next when it goes > from 1 to 0. Obviously those do not all change at once, so if you combine > them with gates there can be > quite large glitches. Then there is the synchronous counter where all > flip-flops are clocked together. Now to a > good approximation (all the flip-flops have the same delay from clock to > output), they do all change together. > So if you now combine the outputs (say you AND some of the Q and Q/ outputs > to decode a particular state) > the glitches will be small. That's what is taught. That is what works with > TTL, ECL, etc. > > Now try it in an FPGA (at least the Xilinx ones I've used). You will find > glitches all over the place. The reason > is that the 'wires' linking the outputs of the flip-flops to the gates are > not wires at all. They are paths on the > chip through logic multiplexers, buffers, etc that are set when the chip is > configured. And they introduce > delays. Delays that are enough to cause glitches that are wide enough to > trigger other flip-flops. > > My experience of FPGAs is that if you design a circuit for an FPGA it will > work. If you take an existing design > feed it into a schematic capture program and compile it for an FPGA then it > won't. Actually, you can, and I have done so - provided that the original machine was slow enough. It works, in part, because the FPGA's are sooooooooooo much faster than the original design, that you can use the "trailing D flip flop" approach I described to convert the former into the latter - the glitches occur on the time scale of the FPGA logic, but are gone by the time the next simulated machine clock arrives. For a much faster legacy design that was not done fully synchronously, it would be much more difficult, I agree. But fortunately for me the machine's I am interested in had clocks on the order of 1 to 10 Mhz and propagation delays of 10 or more ns, such that the 50Mhz clock on my FPGA and tiny tiny propagation delays don't cause headaches once you learn how to deal with them. > > -tony > > > > paul > >