Author Topic: timed state machines VHDL  (Read 4598 times)

0 Members and 1 Guest are viewing this topic.

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9942
  • Country: us
Re: timed state machines VHDL
« Reply #25 on: March 16, 2023, 11:19:06 pm »
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.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20884
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: timed state machines VHDL
« Reply #26 on: March 16, 2023, 11:29:53 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15540
  • Country: fr
Re: timed state machines VHDL
« Reply #27 on: March 16, 2023, 11:32:49 pm »
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.
 

Offline sahko123Topic starter

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: ie
Re: timed state machines VHDL
« Reply #28 on: March 16, 2023, 11:59:34 pm »
also out of curiosity could temperature of the package affect this behaviour?
Asking for a friend
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20884
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: timed state machines VHDL
« Reply #29 on: March 17, 2023, 12:25:16 am »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4784
  • Country: dk
Re: timed state machines VHDL
« Reply #30 on: March 17, 2023, 08:42:01 am »
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
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20884
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: timed state machines VHDL
« Reply #31 on: March 17, 2023, 08:54:05 am »
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."
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2812
  • Country: nz
Re: timed state machines VHDL
« Reply #32 on: March 17, 2023, 09:54:20 am »
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.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20884
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: timed state machines VHDL
« Reply #33 on: March 17, 2023, 10:19:13 am »
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 :)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4784
  • Country: dk
 

Offline sahko123Topic starter

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: ie
Re: timed state machines VHDL
« Reply #35 on: March 17, 2023, 01:10:58 pm »
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.
Asking for a friend
 

Offline sahko123Topic starter

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: ie
Re: timed state machines VHDL
« Reply #36 on: March 17, 2023, 01:12:01 pm »
and a more telling example
Asking for a friend
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: timed state machines VHDL
« Reply #37 on: March 17, 2023, 01:40:36 pm »
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.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20884
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: timed state machines VHDL
« Reply #38 on: March 17, 2023, 03:21:30 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf