Asynchronous Signal

Hi,

there is also a web training to understand the backgrounds of this topic.

http://www.altera.com/education/training/courses/odsw1113

Greets

sim

Two registers at least. Let me also answer the issue of probability that was raised by original post. The tool gives probability figures for asynchronous paths in terms of propagating through to the rest of design. One register will increase that dramatically.

On the other hand an asynchronous signal hitting timing window will have 100% or so possibility of failure at that register. The original post was trying to compare the async signal with its registered version and that caused the problem quickly.

--- Quote Start ---

Using at least 1 register will help;

--- Quote End ---

It will work in the lab, but will at some time in the future fail, because a 'one stage synchroniser' may not not reliable enough, especially at high frequencies. So it is good practice to always use a synchroniser chain of at least two successive registers.

Of course the lower the frequency of the sampling clock the more reliable a 'one stage' synchroniser gets up to the point where the clock period is sufficiently long enough to let every metastable condition settle in time for the next clock edge.

--- Quote Start ---

For conclusion: whether I run into timing problem or whether it's metastability problem, both of them should be dissipating if I'll use at least three synchronization register before I'll use the external data on my design. Am I right?

--- Quote End ---

Using at least 1 register will help; using two or more will make it more reliable so you should aim for at least two if possible.You should also set a false path exception, so Quartus will recognize the synchronization register chain.set_false_path -from [get_ports Idan_Input_Signal]

--- Quote Start ---

Hi,

Thank you all for your quick response!

For conclusion: whether I run into timing problem or whether it's metastability problem, both of them should be dissipating if I'll use at least three synchronization register before I'll use the external data on my design. Am I right?

(Assuming, of course, that the design logic sustain it…)

Thanks,

Idan

--- Quote End ---

correct and more... we usually use two stage synchroniser but it depends how rich you are.

timing or metstability? these are linked but I prefer to say wrong sampling thus if you think of metastability you will think of statistics. But if signal transition hits the sampling window the flip will fail in one way or the other and wouldn't able to recognise the level which could be any.

Hi,

Thank you all for your quick response!

For conclusion: whether I run into timing problem or whether it's metastability problem, both of them should be dissipating if I'll use at least three synchronization register before I'll use the external data on my design. Am I right?

(Assuming, of course, that the design logic sustain it…)

Thanks,

Idan

--- Quote Start ---

Hi.

I have a problem that my FPGA design failing after several seconds. The code purposes isto measurement frequency from external signal generator (50kHz)*. I'm working with 50Mhz clock, LPM_Divide [0-27], Pipe Line [20], Fmax=90MHz.

On ModelSim, the code works perfectly, but on Altera Evaluation Board (Cyclone IV)- the code stuck!. Using Altera SignalTap, I sew that my state machine is missing states and even jump to undefended state (completely disregard from the "when others =>Idan_State_Machine<=Idle_State;" line at the end of the state machine??!!).

When I transfered the external input signal to another register and then used it in my code- the problem seems to be disappearing.

How this is even possible? I agree that I should expect for one clock latency due to diss synchronization between the external input signal to the FPGA main clock, but to sent the state machine to the undefined state?! To stuke the code?

*Using two falling edge (idan_input_signal is the external input):

This is the partial code that failed:

" elsif clk'event and clk='1' then

idan_input_signal_buf <= idan_input_signal;

case Idan_State_Machine is

when Idle_State =>

if (Idan_input_signal_buf = '1' and idan_input_signal = '0') then "

This is the partial code that didn't failed:

" elsif clk'event and clk='1' then

Idan_input_signal_buf <= Idan_Input_Signal;

idan_input_signal_buf_two <= idan_input_signal_buf;

case Idan_State_Machine is

when Idle_State =>

if (Idan_input_signal_buf_two = '1' and Idan_input_signal_buf = '0') then "

Thanks,

Idan

--- Quote End ---

Reading your post again I feel it is very likely you run into timing problem. you are trying to detect change of signal (1 => 0).When input signal

is not registered you may get it anywhere including close to clock edge such that update does not occur in time and the change is therefore never detected as update occurs on next clock edge when both have changed by then.

When an asynchronous signal is fed into an FSM we have two pitfalls:

• difference in path delays:
  As the single input must propagate to all registers in the FSM it takes different paths and one (or more) registers see the change after the clock edge resulting in an undefined state.

• metastability:
  Even if all the changes are seen by the same clock edge some register input may fail to meet the required setup time and the register may transit in a metastable state, and the register may or may not reflect the intended change and you can end up with an undefined FSM state as well.

You can appreciate that the difference in path delays is dominant, because even if metastability did not exist (which it does) you still would end up with registers missing the intended value.

When you register the incoming asynchronous signal with a single register stage, the circuit will work (as long as the path delay + register setup times are smaller than the clock period, but TimeQuest will flag that error). But that single register synchroniser is now susceptible to metastability itself, in which case the output of the synchroniser register may take too long to settle bringing us back to the condition of different path delays upsetting the FSM. But don't hold your breath to see a single register synchroniser turn metastable: your circuit will work in the lab but fail at the customer.

iozana,

the frequency of failures due to meta-stability is statistical and will depend on the toggle rate of the signals, the hardware and the number of points of failure. It's not hard to get a design with MTBFs measured in seconds or less.

Considering that you have a design that works in real life but get's stuck on hardware, I wouldn't be so quick to dismiss meta-stability

There are multiple possibilities, some more mundane than others

a) This has nothing to do with meta-stability on asynchronous signals and you have just mis-constrained the synchronous parts of your design.

b) This is a meta-stability problem and you need to fix it.

c) You've got a jittery clock input. You need to fix that and/or account for it in the constraints, by adding clock uncertainty.

d) You've got power supply issues. You need to fix that.

e) You did everything right but TQ is missing a timing violation. You can try to over-constrain your design by adding (more) clock uncertainty to your constraints.

Regarding a, b, c and e, you should be able to reproduce the issue with a proper gate level simulation.

By default Quartus does not ignore the "others" clause, but it does optimize the SM logic by assuming the SM will never go into undefined states.

You can ask Quartus to generate more robust SM logic with the syn_encoding attribute.

VHDL: attribute syn_encoding of state_t : type is "safe";