VHDL Synchronization- two stage FF on all inputs?

[hvo]

Hello,

I know this topic is beaten to death but I am a bit unlcear some things.

I've recently encountered metastability issues that caused my FPGA to d
unpredictable things. Someone suggested that I synchronize my inputs t
the clock domain and that seemed to solve the issue. Googling this topi
showed that a two stage Flip Flop is sufficient to increase MTBF fo
metastability. My question is do I need to do this for all input signals?
How would one do this with a design containing 30 to 40 input signals?
Which types of inputs can I get away with not using two stage FF?

So in the sample code below, both INA or INB can change state while the cl
is transitioning and this could lead to metastability. Synchronizing IN
and INB would help, but what about INC and IND?

Would the experts just synchronize everything and forget about it?

-----------------------------------------------------------------------------------------
-- Sample code with asynchronous inputs
-----------------------------------------------------------------------------------------
entity blackbox is
port (
Clk : in std_logic;
RST : in std_logic;
INA : in std_logic;
INB : in std_logic;
INC : in std_logic;
IND : in std_logic;
Out : out std_logic
);
end blackbox;

architecture Behavioral of blackboxis
begin

BB: process(Clk, RST) is
begin

if(RST = '1') then
Out <= '0';
elsif(Clk'event and Clk = '1') then
if(INA = '1' and INB = '1') then
Out <= INC;
else
Out <= IND;
end if;
end if;
end process BB;
-----------------------------------------------------------------------------------------

Any feedback is much appreciated.
Thanks
HV.


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Rob Gaddi]

On Tue, 09 Dec 2014 18:22:41 -0600
"hvo" <91991@embeddedrelated> wrote:

Hello,

I know this topic is beaten to death but I am a bit unlcear some things.

I've recently encountered metastability issues that caused my FPGA to do
unpredictable things. Someone suggested that I synchronize my inputs to
the clock domain and that seemed to solve the issue. Googling this topic
showed that a two stage Flip Flop is sufficient to increase MTBF for
metastability. My question is do I need to do this for all input signals?
How would one do this with a design containing 30 to 40 input signals?
Which types of inputs can I get away with not using two stage FF?

So in the sample code below, both INA or INB can change state while the clk
is transitioning and this could lead to metastability. Synchronizing INA
and INB would help, but what about INC and IND?

Would the experts just synchronize everything and forget about it?

-----------------------------------------------------------------------------------------
-- Sample code with asynchronous inputs
-----------------------------------------------------------------------------------------
entity blackbox is
port (
Clk : in std_logic;
RST : in std_logic;
INA : in std_logic;
INB : in std_logic;
INC : in std_logic;
IND : in std_logic;
Out : out std_logic
);
end blackbox;

architecture Behavioral of blackboxis
begin

BB: process(Clk, RST) is
begin

if(RST = '1') then
Out <= '0';
elsif(Clk'event and Clk = '1') then
if(INA = '1' and INB = '1') then
Out <= INC;
else
Out <= IND;
end if;
end if;
end process BB;
-----------------------------------------------------------------------------------------

Any feedback is much appreciated.
Thanks
HV.


---------------------------------------
Posted through http://www.FPGARelated.com

Congratulations, you're asking a fundamentally difficult question.
Expect to struggle with this answer.

What you're looking for is what I call a "single point" of clock domain
crossing. What that means is that, for any set of signals that are
theoretically time-aligned, you need to have a single point (i.e. one
flip-flop) where those signals all neck down to, then all fan back out
from in your internal logic.

Take a UART receiver. You've got several things inside of the state
machine that all need to have the same simultaneous opinion of the
state of the RX line. So you resynchronize the RX line with a dual
flop synchronizer, and everything inside of your synchronous state
machine works off of this synchronized version. If your clock rate is,
for instance, 100 MHz, then everything on your synchronous side knows
that whatever state the sync_rx signal is in, it'll be constant for 10
ns after each clock. Since everyone is only looking at that signal at
the clock edge, and the timing analysis tools make sure that the signal
is settled at each destination in under 10 ns, you're guaranteed that
everything using sync_rx believes it's got the same state.

Now let's say you hadn't resynchronized it. RX can change any time it
likes, let's say 5 ns before your clock edge. If it takes 3 ns to get
to point A in your state machine, point A will see the new value when
the clock edge hits. But if it takes 6 ns to get to point B, it will
still see the old value. You've violated the fundamental rule of
synchronous design, which is that come the clock edge all data signals
are static, and as a result your circuit will behave unpredictably, and
unsimulateably.

So, given your example, you don't need to resynchronize any of that
necessarily. However, given two copies of your example and the desire
to have them always have the same output, you would need to
resynchronize those inputs, then split the resyncronized signals off to
be the inputs to your logic.

Though keep in mind that your reset is asynchronous as well. For all
the same reasons that any other asynchronous signal can be squirrely
around the clock edges, you may well find that one of your two copies
of that logic comes out of reset one clock cycle before the other
does. Does that matter? That's fundamentally a question of your
application. But it's why you see people generate reset signals that
are asynchronous on their assertion, but synchronous on their
deassertion.

There's a lot more to the topic than just this, but that's at least a
quick introduction to the sorts of things that come up.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[glen herrmannsfeldt]

Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

On Tue, 09 Dec 2014 18:22:41 -0600
"hvo" <91991@embeddedrelated> wrote:

(snip)

I've recently encountered metastability issues that caused my FPGA to do
unpredictable things.

(snip)

Congratulations, you're asking a fundamentally difficult question.
Expect to struggle with this answer.

What you're looking for is what I call a "single point" of clock domain
crossing. What that means is that, for any set of signals that are
theoretically time-aligned, you need to have a single point (i.e. one
flip-flop) where those signals all neck down to, then all fan back out
from in your internal logic.

Yes.

While metastability can be a problem, much more common is the multiple
signals crossing time domains without appropriate synchronization.

Take a UART receiver. You've got several things inside of the state
machine that all need to have the same simultaneous opinion of the
state of the RX line. So you resynchronize the RX line with a dual
flop synchronizer, and everything inside of your synchronous state
machine works off of this synchronized version. If your clock rate is,
for instance, 100 MHz, then everything on your synchronous side knows
that whatever state the sync_rx signal is in, it'll be constant for 10
ns after each clock. Since everyone is only looking at that signal at
the clock edge, and the timing analysis tools make sure that the signal
is settled at each destination in under 10 ns, you're guaranteed that
everything using sync_rx believes it's got the same state.

Also, metastability decreases exponentially with decreasing clock rate.

Multiple signal crossing a time domain can fail easily even
at low clock rates.

Now let's say you hadn't resynchronized it. RX can change any time it
likes, let's say 5 ns before your clock edge. If it takes 3 ns to get
to point A in your state machine, point A will see the new value when
the clock edge hits. But if it takes 6 ns to get to point B, it will
still see the old value. You've violated the fundamental rule of
synchronous design, which is that come the clock edge all data signals
are static, and as a result your circuit will behave unpredictably, and
unsimulateably.

So, given your example, you don't need to resynchronize any of that
necessarily. However, given two copies of your example and the desire
to have them always have the same output, you would need to
resynchronize those inputs, then split the resyncronized signals off to
be the inputs to your logic.

There is also the case when multiple signals have to cross a
clock domain and remain consistent. One favorite case is the
counter for a RAM based FIFO. Converting to gray code (or
counting in gray code) means that only one signal changes
at any count transition. Either the before or after value
will be seen on the other side, but not any other miscombination
of bits.

Though keep in mind that your reset is asynchronous as well. For all
the same reasons that any other asynchronous signal can be squirrely
around the clock edges, you may well find that one of your two copies
of that logic comes out of reset one clock cycle before the other
does. Does that matter? That's fundamentally a question of your
application. But it's why you see people generate reset signals that
are asynchronous on their assertion, but synchronous on their
deassertion.

There's a lot more to the topic than just this, but that's at least a
quick introduction to the sorts of things that come up.

-- glen

 

[rickman]

On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:

Also, metastability decreases exponentially with decreasing clock rate.

Can you explain this claim? I can't think of any reason why
metastability would be anything but linear with clock rate if the same
slack time is available.

--

Rick

 

[KJ]

On Tuesday, December 9, 2014 7:22:46 PM UTC-5, hvo wrote:

Hello,

I know this topic is beaten to death but I am a bit unlcear some things.

I've recently encountered metastability issues that caused my FPGA to do
unpredictable things. Someone suggested that I synchronize my inputs to
the clock domain and that seemed to solve the issue.

Actually, it is much more likely that the problem you saw has absolutely nothing to do with metastability. What you described and how you fixed it sounds like either a clock domain crossing or possibly clock skew between the part generating the input signal and your internal design clock...in short it is a setup/hold time problem. What you added to fix your design sounds like a single flip flop per input signal, then that also suggests the problem is not metastability. The point here is not to belabor terminology, but to help you understand it.

Any of your inputs that lead through logic that ends in a flip flop (which will be every input signal in nearly any design) will have setup and hold time requirements that must be met. To find out what your requirements are review the timing analysis report for your design where the setup and hold time requirements for each input will be listed. Those timing requirements are relative to some clock signal in your design. Do those signals actually get generated in the same clock domain? If so, is Tco + PCB prop delay + Setup time requirement + Clock Skew less than the clock period? If those signals are not generated in the same clock domain, then ask yourself how is that input going to be able to meet the setup and hold time requirements? (Hint: The answer is that it will not). This is the situation where you are crossing clock domains and the synchronizing flip flop that you added is needed.

The setup/hold time requirements will still not be met at the input to that flip flop but that is 'OK', since the rest of your design uses the output of the flip flop, not the input. Now that synchronizing flip flop might misbehave (i.e. take a longer than normal time to settle) because the inputs did not meet the setup/hold time requirements, so the solution there is to add a second flip flop and then the rest of your design uses the output of the second flip flop. The first flip flop 'misbehavior' is what is called metastability. Generally, a two flip flop chain is all that is required to cross the clock domain and reduce metastability to an acceptably low number.

The short answer to your question though is that whenever an input signal does not meet the setup and hold time requirements of your design, you will need to synchronize it first before using it elsewhere in your design.

Kevin Jennings

 

[Allan Herriman]

On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:

On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:

Also, metastability decreases exponentially with decreasing clock rate.

Can you explain this claim? I can't think of any reason why
metastability would be anything but linear with clock rate if the same
slack time is available.

http://www.xilinx.com/support/documentation/application_notes/xapp094.pdf

Note the straight lines on the log/linear graph in Figure 2.

For this particular family (V2P) the constants are such that with only a
modest number of ns slack, the probability of failure drops to less than
once in the lifetime of the universe.


Regards,
Allan

 

[rickman]

On 12/10/2014 5:30 AM, Allan Herriman wrote:

On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:

On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:

Also, metastability decreases exponentially with decreasing clock rate.

Can you explain this claim? I can't think of any reason why
metastability would be anything but linear with clock rate if the same
slack time is available.


http://www.xilinx.com/support/documentation/application_notes/xapp094.pdf

Note the straight lines on the log/linear graph in Figure 2.

For this particular family (V2P) the constants are such that with only a
modest number of ns slack, the probability of failure drops to less than
once in the lifetime of the universe.

That's what I thought. You are confusing the time allowed for the
metastable event to settle with clock speed. The two are not the same
thing at all. I can lay out a circuit with a design goal of 100 MHz and
end up with 2 ns slack on the critical route while I lay it out with a
design goal of 50 MHz and end up with 1 ns slack on the critical path.
The *only* thing that is important is the slack time where the output
has time to settle.

It is interesting that the labeling of the two graphs and the text in
the body of the document all describe this data differently and *none*
of them can be interpreted as "slack" time by what I am reading. But
I'm sure that is what they mean.

"Metastable measurement results are listed in Table 1 and are plotted in
Figure 2. The time plotted on the horizontal axis includes the
clock-to-out delay of QA, plus a short interconnect delay, plus the
setup time at the input of the QC flip-flop"

"Cloc-to-Q + Setup + Metastable Delay (ns)"

"Cloc-to-Q + Setup Metastable Delay (ns)"

I expect the label in Figure 3 is just a typo. But given that the label
doesn't make sense either way I'm not sure I care.

--

Rick

 

[Tim Wescott]

On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:

On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:

Also, metastability decreases exponentially with decreasing clock rate.

Can you explain this claim? I can't think of any reason why
metastability would be anything but linear with clock rate if the same
slack time is available.

If you clock a FF at time t, and you don't use the result until time t +
Ts (Ts being your clock period), then the FF has that whole Ts-long period
to resolve the metastability one way or another. That part will be
exponential with Ts.

But yes, you would expect a linear part, too.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Tim Wescott]

On Tue, 09 Dec 2014 18:22:41 -0600, hvo wrote:

Hello,

I know this topic is beaten to death but I am a bit unlcear some things.

I've recently encountered metastability issues that caused my FPGA to do
unpredictable things. Someone suggested that I synchronize my inputs to
the clock domain and that seemed to solve the issue. Googling this
topic showed that a two stage Flip Flop is sufficient to increase MTBF
for metastability. My question is do I need to do this for all input
signals?
How would one do this with a design containing 30 to 40 input signals?

By having lots of such inputs -- but see the other, more detailed answers
for a better idea.

> Which types of inputs can I get away with not using two stage FF?

Any input that is guaranteed to be settled when you clock it in.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[rickman]

On 12/10/2014 1:05 PM, Tim Wescott wrote:

On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:

On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote:

Also, metastability decreases exponentially with decreasing clock rate.

Can you explain this claim? I can't think of any reason why
metastability would be anything but linear with clock rate if the same
slack time is available.

If you clock a FF at time t, and you don't use the result until time t +
Ts (Ts being your clock period), then the FF has that whole Ts-long period
to resolve the metastability one way or another. That part will be
exponential with Ts.

You are forgetting about the time required for the signal to propagate
to the output, through the logic, and the setup time for the next FF.
These times all need to be subtracted from the clock cycle time yielding
the slack time. This is the only number important to resolving
metastability.

> But yes, you would expect a linear part, too.

The linear aspect comes from the probability of having a metastable
event that needs to be resolved. Think of them as edge collisions
between the clock and the data input. The more of them you have in a
second the more likely a metastable event.

--

Rick

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)

Also, metastability decreases exponentially with decreasing clock rate.

Can you explain this claim? I can't think of any reason why
metastability would be anything but linear with clock rate if the same
slack time is available.

I will claim that it is ambiguous enough not to be wrong, but ...

If you clock a FF at time t, and you don't use the result until time t +
Ts (Ts being your clock period), then the FF has that whole Ts-long period
to resolve the metastability one way or another. That part will be
exponential with Ts.

You are forgetting about the time required for the signal to propagate
to the output, through the logic, and the setup time for the next FF.
These times all need to be subtracted from the clock cycle time yielding
the slack time. This is the only number important to resolving
metastability.

In the long time (slow clock) limit, that is pretty insignificant.

People well say "My clock is only 10kHz, metastability can't be
a problem" which is pretty much right.

But clocking multiple signals with different delays, they can
end up on different sides of a clock pulse, even for very slow
clocks.

But yes, you would expect a linear part, too.

The linear aspect comes from the probability of having a metastable
event that needs to be resolved. Think of them as edge collisions
between the clock and the data input. The more of them you have in a
second the more likely a metastable event.

-- glen

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

On 12/10/2014 8:50 PM, hvo wrote:
I think by popular opinion, my issue is not metastability but rather clock
domain crossing as many have pointed out. This explains why adding a
single synchronizing FF fixed my issue as Kevin pointed out. Also, an
interesting point on the conclusion of Xilinx's XAPP094 stating that
"Modern CMOS circuits are so fast that this metastable delay can safely be
ignored for clock rates below 200 MHz." This also support why I Also
don't think its a metastable problem since my CLK rate is 20MHz.

That is an interesting load of BS.... er, I mean "opinion". The
question is how do you establish "Modern CMOS circuits"? They are
talking about their own specific FPGA circuits which may have been true
at that time. Someone pointed out to me in another thread that since
that app note was written in 1997, Xilinx processes have changed
considerably and the gain/bandwidth product has actually dropped. So
please take the 200 MHz figure with a grain of salt and verify your
metastable MTBF before deciding to ignore it.

Besides, the extra FF almost never makes a difference to the design.

(snip)

Metastability is the same thing as the multiple destination problem, but
can happen one FF later. If the FF being fed the async signal only
feeds one other FF you don't have a problem so much. But if it feeds
multiple FFs then it is a bigger problem more likely to bite you.
Still, it is easier to fix something that may not be broken than to
analyze the issue to death.

BTW, the issue is *not* fanning out to multiple processes. It is
driving multiple FFs. If the input is driving a FF that controls the
enable on a bunch of logic in the same process, this can be a problem.

(snip)

The way I look at metastability is to imagine the output of each FF that
may go metastable as oscillating for a few ns after the clock. So
either add another FF in front of this to resolve the metastability or
verify there is sufficient settling time in the existing path by adding
a timing constraint. This slack time is the parameter that is in the
exponential term for MTBF. So a little bit goes a long way.

Yes it is exponential, off of a pretty small time. If you are careful,
you might get your slack time within about 5% of the clock period.
Most likely, there is at least 5% already in the times given.

Much of the delay changes with process, voltage, and temperature,
so they have to build in some margin for all those. If you are
within 5%, then the time for an additional FF to resolve is about 20
times longer.

Now, consider increasing the clock period by a factor of 10.
If you still have a slack time within 5%, the slack time is
now also 10 times longer.

About the only way it could fail is using the favorite trick
of overclockers: turn up the clock frequency until it fails,
then back down just a little bit. But then it is more likely
that it fails by not meeting the timing that you didn't check
for, and not so likely metastability.

The other way is with a metastability locked-loop. I might
not have invented it in discussion here some years ago, but
I believe I first named it. That is a circuit that adjusts
the phase of one clock such that it comes as close as possible
to the actual metastability point, similar to the way PLLs
lock onto a frequency.

There are tons of other references to explain this stuff. Do a web
search and you'll find more than you can read.

-- glen

 

[hvo]

I think by popular opinion, my issue is not metastability but rather cloc
domain crossing as many have pointed out. This explains why adding
single synchronizing FF fixed my issue as Kevin pointed out. Also, a
interesting point on the conclusion of Xilinx's XAPP094 stating tha
"Modern CMOS circuits are so fast that this metastable delay can safely b
ignored for clock rates below 200 MHz." This also support why I Also don'
think its a metastable problem since my CLK rate is 20MHz.

I guess what I am taking out of all this is that not all signals need to b
synchronized with a FF. Only those who fan out to multiple processes tha
are time aligned. This ensures two identical process to have the sam
output given the same input.
Now the synchronized FF output can be metastable, in which case a second F
will reduce it probability significantly.

Am I on the right path? or completely out on left field?

PS: is there a way to attach a picture in this forum?

Thanks
HV.

---------------------------------------
Posted through http://www.FPGARelated.com

 

[rickman]

On 12/10/2014 7:26 PM, glen herrmannsfeldt wrote:

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
Also, metastability decreases exponentially with decreasing clock rate.

Can you explain this claim? I can't think of any reason why
metastability would be anything but linear with clock rate if the same
slack time is available.

I will claim that it is ambiguous enough not to be wrong, but ...

??? Not being wrong doesn't sound the same as being right....

If you clock a FF at time t, and you don't use the result until time t +
Ts (Ts being your clock period), then the FF has that whole Ts-long period
to resolve the metastability one way or another. That part will be
exponential with Ts.

You are forgetting about the time required for the signal to propagate
to the output, through the logic, and the setup time for the next FF.
These times all need to be subtracted from the clock cycle time yielding
the slack time. This is the only number important to resolving
metastability.

In the long time (slow clock) limit, that is pretty insignificant.

Not sure what that means in the real world.

People well say "My clock is only 10kHz, metastability can't be
a problem" which is pretty much right.

It may be right, but is not relevant to the original issue.

But clocking multiple signals with different delays, they can
end up on different sides of a clock pulse, even for very slow
clocks.

But yes, you would expect a linear part, too.

The linear aspect comes from the probability of having a metastable
event that needs to be resolved. Think of them as edge collisions
between the clock and the data input. The more of them you have in a
second the more likely a metastable event.

-- glen

--

Rick

 

[rickman]

On 12/10/2014 8:50 PM, hvo wrote:

I think by popular opinion, my issue is not metastability but rather clock
domain crossing as many have pointed out. This explains why adding a
single synchronizing FF fixed my issue as Kevin pointed out. Also, an
interesting point on the conclusion of Xilinx's XAPP094 stating that
"Modern CMOS circuits are so fast that this metastable delay can safely be
ignored for clock rates below 200 MHz." This also support why I Also don't
think its a metastable problem since my CLK rate is 20MHz.

That is an interesting load of BS.... er, I mean "opinion". The
question is how do you establish "Modern CMOS circuits"? They are
talking about their own specific FPGA circuits which may have been true
at that time. Someone pointed out to me in another thread that since
that app note was written in 1997, Xilinx processes have changed
considerably and the gain/bandwidth product has actually dropped. So
please take the 200 MHz figure with a grain of salt and verify your
metastable MTBF before deciding to ignore it.

Besides, the extra FF almost never makes a difference to the design.

I guess what I am taking out of all this is that not all signals need to be
synchronized with a FF. Only those who fan out to multiple processes that
are time aligned. This ensures two identical process to have the same
output given the same input.
Now the synchronized FF output can be metastable, in which case a second FF
will reduce it probability significantly.

Metastability is the same thing as the multiple destination problem, but
can happen one FF later. If the FF being fed the async signal only
feeds one other FF you don't have a problem so much. But if it feeds
multiple FFs then it is a bigger problem more likely to bite you.
Still, it is easier to fix something that may not be broken than to
analyze the issue to death.

BTW, the issue is *not* fanning out to multiple processes. It is
driving multiple FFs. If the input is driving a FF that controls the
enable on a bunch of logic in the same process, this can be a problem.

Am I on the right path? or completely out on left field?

PS: is there a way to attach a picture in this forum?

No, but you can post a picture somewhere and give a link.

The way I look at metastability is to imagine the output of each FF that
may go metastable as oscillating for a few ns after the clock. So
either add another FF in front of this to resolve the metastability or
verify there is sufficient settling time in the existing path by adding
a timing constraint. This slack time is the parameter that is in the
exponential term for MTBF. So a little bit goes a long way.

There are tons of other references to explain this stuff. Do a web
search and you'll find more than you can read.

--

Rick

 

[GaborSzakacs]

hvo wrote:

I think by popular opinion, my issue is not metastability but rather clock
domain crossing as many have pointed out. This explains why adding a
single synchronizing FF fixed my issue as Kevin pointed out. Also, an
interesting point on the conclusion of Xilinx's XAPP094 stating that
"Modern CMOS circuits are so fast that this metastable delay can safely be
ignored for clock rates below 200 MHz." This also support why I Also don't
think its a metastable problem since my CLK rate is 20MHz.

I guess what I am taking out of all this is that not all signals need to be
synchronized with a FF. Only those who fan out to multiple processes that
are time aligned. This ensures two identical process to have the same
output given the same input.
Now the synchronized FF output can be metastable, in which case a second FF
will reduce it probability significantly.

Am I on the right path? or completely out on left field?

PS: is there a way to attach a picture in this forum?

Thanks
HV.

---------------------------------------
Posted through http://www.FPGARelated.com

Your original problem was most definitely *not* metastability.
However mitigating the probability of metastability is still
worth while. It's important to understand the mechanisms involved.
From a simple perspective, you can consider that any flip-flop
has a "window" near the sampling clock edge where metastability
can happen. For modern CMOS, that window is very small, probably
less than 1 ps. In any case it's *much* smaller than the window
you normally try to stay out of between setup and hold when using
synchronous logic.

The chances of getting a metastable event at the first flip-flop
when introducing an asynchronous signal is simply the probability
that an edge of the incoming signal falls within this metastability
window. Note that the expected failure rate is related to both
the clock rate, which determines how often in time a window is
"open" and the edge rate of the incoming signal.

Now we come to why you want a second flip-flop. A metastable
event has the effect of increasing the clock to output timing
of the first flip-flop. There is theoretically no upper bound
on the amount of time that the event can last, but the chances
of the event lasting any particular length of time go down
*very* quickly as the length of time goes up. In real world
applications, there are secondary processes (mostly system
noise) that "help" an event to end in a way similar to a
coin standing on edge on a bar where there are a lot of
patrons picking up and setting down mugs. In any case you
can see that you want "slack" time in the path from this
first flip-flop to all other synchronous elements.

The second flop is an easy way to ensure the ease of adding a
lot of slack in the path. However it has a secondary impact
on the chance of failure. When the first flop has an event
that increases its time such that all subsequent flops no
longer meet setup requirements, your circuit will fail. With
the second flip-flop in place, instead of having an upper
bound after which the circuit will fail, what you need for
failure is an event that causes the second flip-flop to go
metastable. This means that instead of the probability of
an event being greater than "x" you now are looking at the
probability of an event being exactly "x" +/- something
very small. So even if the first path doesn't have the
slack to prevent a metastable event from violating the
setup/hold of the second flop, the system won't actually
fail unless the event is within a very small range. This
dramatically reduces the MTBF.

Now deciding whether you really need a second flop depends
on requirements for MTBF and the amount of slack you can
give between the first flop and all of its loads. At a low
clock frequency it's likely that you can ensure enough slack
that you don't need the second flop to meet the MTBF requirements.
A slower clock also means that you add more delay by inserting
another flop. If latency is an issue, you probably don't want
to do that. It's a bit counterintuitive, but in this case you
could actually improve MTBF without adding delay by using a
second flop on the opposite clock edge, assuming you can meet
timing to subsequent flops in 1/2 clock period.

--
Gabor

 

[glen herrmannsfeldt]

Tim Wescott <seemywebsite@myfooter.really> wrote:

On Wed, 10 Dec 2014 14:21:01 -0500, rickman wrote:

On 12/10/2014 1:05 PM, Tim Wescott wrote:
On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote:

(snip on metastability and slack time)

If you clock a FF at time t, and you don't use the result until time t
+ Ts (Ts being your clock period), then the FF has that whole Ts-long
period to resolve the metastability one way or another. That part will
be exponential with Ts.

You are forgetting about the time required for the signal to propagate
to the output, through the logic, and the setup time for the next FF.
These times all need to be subtracted from the clock cycle time yielding
the slack time. This is the only number important to resolving
metastability.

I suspect that the paper (which doesn't sound very thorough) is
presupposing that you take a design with a given propagation delay, and
just start turning the frequency down on the clock.

Much easier than increasing the propagation delay. If your clock is
1MHz, it takes a lot of logic and routing to make a significant fraction
of that in propagation delay.

-- glen

 

[GaborSzakacs]

rickman wrote:

On 12/12/2014 5:05 PM, GaborSzakacs wrote:
rickman wrote:
On 12/12/2014 2:45 PM, GaborSzakacs wrote:
rickman wrote:
On 12/11/2014 9:08 AM, GaborSzakacs wrote:

[snip]


No. The second flip-flop has the same sort of metastable window as the
first. If the first flop misses that window because the metastability
was longer, then the second flop will resolve on the following clock
cycle. I think you may be under the misapprehension that the
metastable
state means that the first flop is outputing a "1/2" rather that "0"
or "1" logic level and any sampling during that time would cause
metastability in the second flop. In fact that's not the case.

I don't think that is correct. A metastable event can create all
sorts of problems on the output including oscillations and
indeterminate levels. These can produce metastability in the second
stage without having to hit a bullet with a bullet.



Think again. A flip-flop has positive feedback gain. Oscillation
is definitely not a possibility. Somewhere inside the flop you
could sit at a threshold voltage for a while, but once you start
to resolve, the swing will be monotonic. The next flop doesn't
get fed directly by the node sitting at its threshold, but from
a buffered copy. You'd need a buffer that oscillates when its
input sits near a threshold for a nanosecond or two. You won't
find anything like that in an FPGA.

There is some 40 years of experience and documentation showing the
effects of metastability. Please do a little research on the topic.

Rick,

If you had even started to look into some of that 40 years of
research, you may have come across a host of articles like this one:

http://webee.technion.ac.il/~ran/papers/Metastability-and-Synchronizers.IEEEDToct2011.pdf

The only mention of oscillation is that it doesn't happen. At least
not at the output latch node.

 

[rickman]

On 12/15/2014 6:14 PM, GaborSzakacs wrote:

rickman wrote:
On 12/12/2014 5:05 PM, GaborSzakacs wrote:
rickman wrote:
On 12/12/2014 2:45 PM, GaborSzakacs wrote:
rickman wrote:
On 12/11/2014 9:08 AM, GaborSzakacs wrote:

[snip]


No. The second flip-flop has the same sort of metastable window as
the
first. If the first flop misses that window because the metastability
was longer, then the second flop will resolve on the following clock
cycle. I think you may be under the misapprehension that the
metastable
state means that the first flop is outputing a "1/2" rather that "0"
or "1" logic level and any sampling during that time would cause
metastability in the second flop. In fact that's not the case.

I don't think that is correct. A metastable event can create all
sorts of problems on the output including oscillations and
indeterminate levels. These can produce metastability in the second
stage without having to hit a bullet with a bullet.



Think again. A flip-flop has positive feedback gain. Oscillation
is definitely not a possibility. Somewhere inside the flop you
could sit at a threshold voltage for a while, but once you start
to resolve, the swing will be monotonic. The next flop doesn't
get fed directly by the node sitting at its threshold, but from
a buffered copy. You'd need a buffer that oscillates when its
input sits near a threshold for a nanosecond or two. You won't
find anything like that in an FPGA.

There is some 40 years of experience and documentation showing the
effects of metastability. Please do a little research on the topic.

Rick,

If you had even started to look into some of that 40 years of
research, you may have come across a host of articles like this one:

http://webee.technion.ac.il/~ran/papers/Metastability-and-Synchronizers.IEEEDToct2011.pdf


The only mention of oscillation is that it doesn't happen. At least
not at the output latch node.

This one says it can oscillate...
http://www.ganssle.com/articles/MetastabilityandFirmware.htm

This one does too...
http://a.vita.com/home/Learn/vmefaq/metastability.html

Another...
http://www-classes.usc.edu/engr/ee-s/552/coursematerials/ee552-G1.pdf

This one has pictures...
http://www.asic-world.com/tidbits/metastablity.html

You can talk about positive feedback, but that does not preclude
oscillations. With the appropriate condition such as the data input
changing at the right time just around the clock edge, both outputs of
the master FF (Q and Q not) can be in the same state. With
approximately equal delays in each gate, this condition will change to
both outputs changing to the opposite state, then back, etc until one of
the states "catches up" with the other and the circuit reaches a stable
state.

Some of the very earliest work analyzing the metastable state in digital
logic well documented oscillations in such circuits. Anyone who tells
you otherwise is talking through their hats.

--

Rick

 

[Tom Gardner]

On 15/12/14 23:14, GaborSzakacs wrote:

The only mention of oscillation is that it doesn't happen. At least
not at the output latch node.

Oscillation vs invalid level is dependent on the logic family.
I would go and dig out some 30/40 year old oscillograms, but
they are currently inaccessible.