??? 01/21/05 22:41 Read: times |
#85536 - Metastability Responding to: ???'s previous message |
Anyone who knows anything about designing for cpld/fpga will tell you that asyncronous inputs can cause metastability but as long as the asyncronous input fans out to no more than one register or syncronous memory element then the metastabilty does not propagate,in the case where there are more than one flop or memory element driven directly by an asyncronous input then the asyncronous input can be syncronised by the use of cascaded registers at the input.In the case of this design no input fans out to more than one flop,therefor there is no need to syncronise the inputs,which may or may not be asyncronous I would like to add some more words to this: Metastability is not the preserve of cplds/fpgas - it's been with us since the dawn of the flip/flop. So any logic using bistable devices is prone to this phenomenon. Metastability is normally associated with asynchronous inputs as it is near impossible to guarantee the input will not change within the critical clock window - the magic setup and hold times. Yet this can occur in a synchronous system - some signals from a micro are synchronous but due the the torturous logic inside the micro, the outputs may change around the clock transition - this too will cause metastability on a large scale! Jez, of course knows this, as should most(all!) people doing logic design as the number one rule of synchronous design is "don't violate your setup and hold times". Of course, the reason for doing synchronous design is that you can calculate this and thus avoid the problem by design. Again, it all comes down to reading the specs carefully - some signals can have a fairly wide range of timing thus the min/max values. Of course we're getting a little off topic. Payam needs to realise that just showing us some logic and telling us what he wants the logic is to do does not mean that it will work in his application. We can only say "yes this logic will do what you intend" that is for a given input, the output will be what is expected. Getting the propagation delay as small as possible may make little difference - it all depends on the whole application. It might work for a Philips 89C51 but be highly unreliable for a Dallas DS80C320, add in clock frequency etc and we're getting a number of variables. I previously mentioned some problems I had with a cpld device I designed - it was to connect to a bus that I had no specification of - the usual adddress,data, read and write signals. The original design used a handful of HC191 counters so I thought I'd use a cpld and combine two boards into one. The concept worked, except that a manufacturing process change (one batch worked, others didn't) on the cplds made the board unreliable (it had memory on it to store transactions!). After many hours of investigation and measurement, I found the glitch and had to add 74HC14 and some capacitance to slow a signal down a little bit. This was all tacked onto the pcb. It was very embarassing for me and a baptism of fire for my first cpld design! |