On Tuesday 06 April 2004 04:13 pm, Mike Jarabek wrote:You are correct, it's not always a bad idea. I did not qualify my statement adequately. When you use the clock as part of your logic you automatically double the frequency that your circuit must operate at. This is probably not a big deal when your clock is under 20MHz, but it certainly affects your design at speeds like 100MHz. If the design is fully synchronous, the clock automatically qualifies your signals because no state changes happen until a rising (or falling edge).
> The same condition is still there, it has just moved to the address
> inputs instead of the enable signals. It's something of a bad idea to
> use the clock to qualify signals, especially if this is a synchronous
> design anyhow.I'll get to the other experiment you posted above, once I get back from
work.However, your advice is contradictory to real-world experience with the
6502-series of processors, where qualification of bus signals to the
system clock is not only preferred, but often the only way to achieve
such qualification. I refuse to believe it is a "bad idea." Maybe a
bad idea in a certain context, but certainly not for all cases. And you
just can't get any more synchronous than the 6502 bus.
Using a clock as a qualifier inside of an FPGA can be dangerous. Especially if you are using a look up table based FPGA, if one of the signals is asynchronous to the clock, glitches can appear on an otherwise clean output. If the output is then used as an clock input to a FF, this may cause it to sample data at the wrong time. Worse yet, the design might work fine after one place and route cycle, then fail to work after `minor' changes, or stop working after the vendor silently ships you a faster part than you ordered, certainly not what I would like to be debugging in the lab... ;-) This kind of logic can be built, but it usually requires careful attention to detail and instantiations of primitives that call up real multiplexors inside the device.
When you do this in an ASIC, you have to carefully constrain the paths when you attempt timing closure. It's often hard to communicate this critical information to future designers should your block get re-used, as these constraints are generally not stored with the source code for your block. Plus, it is difficult (not impossible) to maintain them in such a way that the documentation for your block is in sync with the actual synthesis and timing constraints.
In fact, the 65816 has far more stringent synchronous constraints, as it
places the upper 8 bits of the address bus (bits 16..23) on the data bus
while the clock is low, with the expectation that they'll be latched at
that time, or on the rising edge of the clock.
Mike JarabekThere are 6502/65816 systems in existance that can go up to and often
beyond 20MHz. So it can't be all that bad a thing to do.--
Samuel A. Falvo II