Propogation delays and setup times

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

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

Apart from checking for two (or more?) consecutive 'valid' pulses,
what else can I do to avoid or mitigate this problem?


Re: Propogation delays and setup times

Quoted text here. Click to load it

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.


Re: Propogation delays and setup times

Quoted text here. Click to load it

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.


Re: Propogation delays and setup times
On Thu, 27 May 2004 14:19:18 +0200, LC Geldenhuys
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Philip Freidin

Re: Propogation delays and setup times
On Sun, 30 May 2004 01:11:09 GMT, Philip Freidin

Quoted text here. Click to load it


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.


Site Timeline