Propogation delays and setup times

[LC Geldenhuys]

Hi,

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?

Regards,
Lourens

 

[Mario Trams]

LC Geldenhuys wrote:

Hi,

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.

Regards,
Mario

 

[Hendra Gunawan]

"LC Geldenhuys" <lcgeldenhuysNOSPAM@mecalc.co.za> wrote in message
news:kkmbb0tq1di62deu2i1utmg9a80obnsdqc@4ax.com...

Hi,

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.

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.

Hendra

 

[Philip Freidin]

On Thu, 27 May 2004 14:19:18 +0200, LC Geldenhuys <lcgeldenhuysNOSPAM@mecalc.co.za> wrote:

Hi,

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.

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.

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.

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.

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

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.

Regards,
Lourens

Philip



===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM

 

[LC Geldenhuys]

On Sun, 30 May 2004 01:11:09 GMT, Philip Freidin
<philip@fliptronics.com> wrote:

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,

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.

Regards,
Lourens