Crossing clock domains

Hi newsgroup,

I have observed a strange behaviour in our VHDL design:

One signal goes low and stays low (133MHz clock domain)(No Reset case). That flag is synchronised with one FF into a 125MHz clock domain where a FSM is running. The flag (flag=3D'0') is checked in one of the states of the FSM.

When using one FF for synchronization the circuit shows strange behaviour, when using two FFs it works fine.

I mean the flag does not show much activity, it becomes high or low and remains stable. So why should one FF not be sufficient for synchronization ?

Any ideas ?

Rgds Andr=E9

Reply to
ALuPin
Loading thread data ...

Hi André, Use two FFs? :-) First, are you sure that the synthesis tool is implementing your domain crossing in just one FF? Similarly, are there any other domain crossing paths apart from the one you describe? Finally, here's a question, what's the total delay from the output of the synchronization FF to the next FFs in the FSM? Include setup time, routing and logic delays. Then remember that metastability will eat into this time. Also, what part is this in? Cheers, Syms.

Reply to
Symon

Hi Symon,

I use two FFs but I would like to understand the issue.

We are using Lattice EC10-5F. There are no other domain crossing paths apart from the one I have described.

The static timing analysis shows no warnings. The two clocks are unrelated so maybe the timing tool does not include that path in its calculation.

But as I explained the flag goes low and stays low. The checking of the flag in the FSM is performed when the flag should be stable.

Rgds Andr=E9

Reply to
ALuPin

snipped-for-privacy@web.de ( snipped-for-privacy@web.de) wrote: : Hi newsgroup,

: I have observed a strange behaviour in our VHDL design:

: One signal goes low and stays low (133MHz clock domain)(No Reset case). : That flag : is synchronised with one FF into a 125MHz clock domain where : a FSM is running. The flag (flag=3D'0') is checked in one of the states : of the FSM.

: When using one FF for synchronization the circuit shows strange : behaviour, when : using two FFs it works fine.

Is the one FF feeding more than one element? If so is it being duplicated by the Lattice tools?

cds

Reply to
c d saunter

Hi André, I understand, but what happens as the flag transistions from '1' to '0'? If the synchronization FF hasn't resolved in time for the checking circuit to do its work, you would be in trouble. Try constraining the time from the synchronization FF to the rest of the FFs to (say) 4ns and see if it gets better. BTW, are you using any falling edges in your destination clock domain? This might cut the time you have in two. Good luck! Syms.

Reply to
Symon

If

Hi Symon,

we only use rising edges. I will try to play with some constraints to find out what the fitter is doing ...

Rgds Andr=E9

Reply to
ALuPin

The probable issue is metastability. Whenyou cross clock domains, you will inevitably encounter every conceivable timing relationship between the timing on D and CLK. In some cases, the flip-flop will not be able to decide its output level in the usual short time. This is called "metastable delay", and in can occasionally be a few ns. If your design cannot accomodate this extra delay, strange things will happen. Rule: Make sure that the output of the synchronizing flip-flop drives only one input, and that this path has the longest slack possible. The common solution is a second synchronizer flip-flop. There is lots of literature about metastability, I have written some of it myself... Peter Alfke, Xilinx.

Reply to
Peter Alfke

The problem you are describing sounds a lot like metastability. You can read about it here:

formatting link

In terms of timing analysis, the path for the flag signal (in the 133 MHz domain) to the input of your first synchronizing flipflop (in the 125 MHz domain) does not matter much, as the signal is crossing the clock domains.

The synchronizing FF can go metastable. You have to look VERY CAREFULLY at what happens to this synchronized version of your flag. First you need to look at the timing for this signal. At 125 MHz, you only have 8 ns. Meeting this timing requirement is not enough! That is because you need some additional time to resolve metastability. Your goal should be that the routing delay (+ clock to output + setup time to FSM FF) is less than

5 ns. This would give you 3 ns of resolving time. Second, you should make sure that when this flag changes, the change in the state machine's state encoding only changes 1 FF.

The reason that 2 FFs works so much better, is that you get to do the resolving between the two FFs, which if they are close together, may leave as much as 5 ns resolving time.

Philip Freidin

Philip Freidin Fliptronics

Reply to
Philip Freidin

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.