I have a number of address lines feeding into a combinatorial address decoder, the output of which is clocked twice before being used in my state machine. It could happen that, due to different propagation delays on the address bus, the first flop clocks an incorrect 'valid' address selected. In the next clock period the address lines will have settled and the correct address will be decoded and either selected or not.
Apart from checking for two (or more?) consecutive 'valid' pulses, what else can I do to avoid or mitigate this problem?
I think what you are doing is a little bit strange. You should advise your synthesis tool that the allowable asynchronous path length from the register of your address to the flip flop that stores the comparator result is two clock cycles. And, of course, you would only use one flip flop.
I don't think there should be any problem. Your Synthesis / Place and Route tool should be able to determine the delay of your address decoder. And if your address decoder happen to be the longest combinational logic delay in your system, the tool should be able to report back to the user that the system can run at a clock rate that doesn't run faster than the delay of your address decoder.
On the right track here, but since you are dealing with multiple signals changing (the address bus) the transition from one decode value to another is not going to be monotonic, and so you may get a rapid sequence of transitions prior to a final stable value.
Right. This is quite a likely outcome. While the double register you are using is normally associated with dealing with metastables, you are dealing with something that happens far more often, a race condition between the various address lines, and your multiple decoded outputs.
As an aside, multiple synchronizers, based on the same base signal set (the address in your case) is a bad scheme anyway, as synchronizers always have a +/- 1 cycle uncertainty in their resolving function. A better architecture is to synchronize the source signals, then do the decode in the synchronous domain. You still need to deal with the variable delays (address stable time of each address line) of the inputs to your synchronizer. I'm comming to that soon.
This is the heart of your problem. Even looking at the 'valid' pulses may not be enough, as there is still the problem of metastability, and there are scenarios where you may two 'valid' decodes that overlap. I.E. a decode of 4XXX and CXXX might look like this:
4XXX 00001100000 CXXX 00000111111
Unless the system has been really poorly designed, there should be a signal that says either that the address has changed, or that the address is valid.
Here is what a robust system might look like:
Address changes. Address valid signal goes high. The address valid signal goes through 2 stage synchronizer (just 2 FFs) When the address valid signal is seen out of the second FF, a register is loaded with the address (We know it has been stable for at least 2 clocks, so it is safe to clock into a register. The decode is done in the synchronous domain.
If the decode is known to be faster than 2 clock cycles, then the decode could be in the address bus domain, and the register that is clocked when the address valid signal comes out of the second FF, could be the output of the decoders.
If you dont' have either the address valid signal, or the address does not stay stable for at least 2 cycles, then you have some real tough problems to solve.
Philip
=================== Philip Freidin snipped-for-privacy@fpga-faq.com Host for
Thank you, your explanations have made a lot of things clear to me. As this decoder is for the VMEbus, I do indeed have an address valid strobe, and the solution is now actually quite obvious.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.