timed state machines VHDL

[rstofer]

As you add synchronizing FFs in series with an incoming signal you also take the chance of trashing the timing relationship with other signals also coming in.  Arguably, all incoming signals will have the same number of FFs and the same timing relationships after synchronizing.

Latency is also increased - the time from the real input change to the real output change will increase by the delay through the FFs.

There is no free lunch.

[tggzzz]

As you add synchronizing FFs in series with an incoming signal you also take the chance of trashing the timing relationship with other signals also coming in.  Arguably, all incoming signals will have the same number of FFs and the same timing relationships after synchronizing.

Latency is also increased - the time from the real input change to the real output change will increase by the delay through the FFs.

There is no free lunch.

Indeed.

A classic error is to have an asynchronous signal a the input to two flip flops, so the one can go one way and the second the other way.

As for synchronizing two asynchronous signals, you can't guarantee both signal's transitions will be recognised on the same clock. The solution is to use Gray coding.

But TAANSTAAFL.

[SiliconWizard]

Of course.
Theory is one thing, practice sometimes a bit different thing.

I've seen some people really stuck to the theory, who would use very long chains of FF to handle clock domain synchronization, because you know, to lower the probability of a fault to less than 10^-100 on a display controller.

I've personally rarely used more than 3 FFs, 2 being my "default" which works reasonably well in a large range of use cases. YMMV.

[sahko123]

also out of curiosity could temperature of the package affect this behaviour?

[tggzzz]

I've personally rarely used more than 3 FFs, 2 being my "default" which works reasonably well in a large range of use cases. YMMV.

Two is the standard minimum. You need detailed application and process knowledge to work out whether or not you need 3 or more.

The probablility of failure is related exponentially to the clock frequency, so clearly that is a key parameter.

[langwadt]

I've personally rarely used more than 3 FFs, 2 being my "default" which works reasonably well in a large range of use cases. YMMV.

Two is the standard minimum. You need detailed application and process knowledge to work out whether or not you need 3 or more.

The probablility of failure is related exponentially to the clock frequency, so clearly that is a key parameter.

https://groups.google.com/g/comp.arch.fpga/c/xllHmNt5bxU/m/WG1nQuN9aJgJ

[tggzzz]

I've personally rarely used more than 3 FFs, 2 being my "default" which works reasonably well in a large range of use cases. YMMV.

Two is the standard minimum. You need detailed application and process knowledge to work out whether or not you need 3 or more.

The probablility of failure is related exponentially to the clock frequency, so clearly that is a key parameter.

https://groups.google.com/g/comp.arch.fpga/c/xllHmNt5bxU/m/WG1nQuN9aJgJ

Yup!

Plus that also notes the important point I made earlier, ... "A classic error is to have an asynchronous signal a the input to two flip flops, so the one can go one way and the second the other way."

[hamster_nz]

A fun FPGA puzzle is to make a FPGA design that creates and measures a metastable event.

It is much harder than you would expect at first glance.

It is a great way to learn the synthesis tools and extra synthesis attributes.

Far easier to describe than to implement.

[tggzzz]

A fun FPGA puzzle is to make a FPGA design that creates and measures a metastable event.

It is much harder than you would expect at first glance.

It is a great way to learn the synthesis tools and extra synthesis attributes.

Far easier to describe than to implement.

That's a neat conceptual concept and hack

[langwadt]

http://xilinx.pe.kr/_xilinx/html/tip/metastability.htm

[sahko123]

having done some probing with a scope i figured out that the actual issue isnt metastabality but simply in how i read the pin in question  (a comparator output). at some points in time it will simply be out of phase and will miss an entire count of the comparator. shown below is a graph of the what happens when the comparator goes in and out of sync with the comparator.

[sahko123]

and a more telling example

[dmills]

Plus that also notes the important point I made earlier, ... "A classic error is to have an asynchronous signal a the input to two flip flops, so the one can go one way and the second the other way."

Note that this implies that bringing anything more then a single signal across unrelated clock domains is HARD unless you know that the multi bit signal is something like a counter with a defined sequence, in which case gray code gets it done. The issue being that the various bits on the bus may or may not be transferred correctly if they change too close to a sampling edge.
I have seen an attempt to use gray code to bring an arbitrary data bus across clock domains, it worked "poorly".

Almost all the FPGA vendors have a FIFO based block that does this by essentially using hardware that is guaranteed to have the correct timing between the various strobes to ensure that the transfer is atomic. It is not so far as I am aware possible to build this logic in generic fabric and have a guarantee that it will always work.

In the xilinx case this magic is built into the dual port block ram based fifo core.

[tggzzz]

Plus that also notes the important point I made earlier, ... "A classic error is to have an asynchronous signal a the input to two flip flops, so the one can go one way and the second the other way."

Note that this implies that bringing anything more then a single signal across unrelated clock domains is HARD unless you know that the multi bit signal is something like a counter with a defined sequence, in which case gray code gets it done. The issue being that the various bits on the bus may or may not be transferred correctly if they change too close to a sampling edge.
I have seen an attempt to use gray code to bring an arbitrary data bus across clock domains, it worked "poorly".

Almost all the FPGA vendors have a FIFO based block that does this by essentially using hardware that is guaranteed to have the correct timing between the various strobes to ensure that the transfer is atomic. It is not so far as I am aware possible to build this logic in generic fabric and have a guarantee that it will always work.

In the xilinx case this magic is built into the dual port block ram based fifo core.

Intuition makes me suspect that a multibit signal with sufficient added redundancy could traverse a clock domain reliability. But then having a separate single "databus steady" signal is almost certainly better in most cases!

However, instantiation of a predefined block is the way to go, as with many other functional blocks in FPGAs.