Resynchronize external signals

What is meant by the statement - Resynchronize external signals - when using
them is a state machine? What's it do, how do you do it and why?

Thanks,

Weddick

Weddick wrote:

> What is meant by the statement - Resynchronize external signals - when using
> them is a state machine? What's it do, how do you do it and why?
>
> Thanks,
>
>
I guess you got that in my Coding Style Guide.

A good practice is to always resynchronize asynchronous inputs.
You just have to make them traverse a D FlipFlop, or two FlipFlops if
you're scared.

As one can easily understand, this is extremely critical when the async
signal is driving several FFs (some may see a 1 and others a 0 and take
"impossible" decisions (and drive an FSM crazy for example). This can
happen without even a timing violation !
It's a major source of buggy designs which simply don't work reliably or
at all, yet it's usually not taught properly.

When in doubt, follow the guide
But I agree that it's better to understand the reasons behind the rules.

Bert Cuzeau

Bert Cuzeau

> A good practice is to always resynchronize asynchronous inputs.
> You just have to make them traverse a D FlipFlop, or two FlipFlops if
> you're scared.

This is to avoid metastability I believe?

Also, resynching using the flops only *reduces* the probability of
metastability to acceptable levels (reduced further by using 2) - it does
not completely eliminate it - correct?

Cheers,

Ken

Ken

Ken wrote:
>>A good practice is to always resynchronize asynchronous inputs.
>>You just have to make them traverse a D FlipFlop, or two FlipFlops if
>>you're scared.
>
>
> This is to avoid metastability I believe?

The main issue is what I explained : related to temporal incoherence of
the same signal distributed to several paths.

Metastability is another issue, but it's much less severe than sometimes
believed. _Every_ time I inspected failures that were believed to be
related with metastability, the issue was a (more or less) simple lack
of resynchronization...

>
> Also, resynching using the flops only *reduces* the probability of
> metastability to acceptable levels (reduced further by using 2) - it does
> not completely eliminate it - correct?

What would your suggestion be ?

The correct answer (if any) is an mtbf calculation, but it's often
difficult to get all the parameters related with a given technology.
Usually, knowing your technology, the input change rate and your
sampling clock frequency gives you an idea of whether you should get
concerned by metastability through a single Flop or not. Indeed, the
type of application can make lots of difference. Failues may have much
different consequences according to the design. A set-top box is less
critical than a plane.

In most current situations, the mtbf through 2 flops is simply well
above other mtbfs sourcing from other factors.

Bert Cuzeau

In message <424d8ebb$0$28527$>
Bert Cuzeau <_no_spa_m_info_no_underscore_@alse-fr___.com> wrote:

> Metastability is another issue, but it's much less severe than sometimes
> believed. _Every_ time I inspected failures that were believed to be
> related with metastability, the issue was a (more or less) simple lack
> of resynchronization...

Hmm. I /believe/ I've seen metastability in an FPGA design I did a few
years ago. There were 4 identically programmed FPGAs to a PCB, each
FPGA with 4 channels (16 channels total). The channels were all identical
instantiations, as you'd expect. They sampled two asynchronous inputs
each, and resynchronised them through one DFF each. Resynchronisation
was present, therefore, on all 16 channels, with 1 level.

However, 4 channels suffered badly from noise, and 4 channels less badly.
It was the same channel in each FPGA that was affected, to the same
extent. The noise went away when I did nothing more than add a second
level of resynchronisation, with a second DFF. Nowadays I tend to do
the same sort of design with 4 stages - they're a free resource, why
take the risk?

It's very hard to prove one way or the other, I grant you.

Dave

Dave Higton

Thank you all for your inputs. I think I have the picture now.

Thanks,
Joel


"Bert Cuzeau" <_no_spa_m_info_no_underscore_@alse-fr___.com> wrote in
message news:424cee24$0$26387$...
> Weddick wrote:
>
>> What is meant by the statement - Resynchronize external signals - when
>> using them is a state machine? What's it do, how do you do it and why?
>>
>> Thanks,
>>
>>
> I guess you got that in my Coding Style Guide.
>
> A good practice is to always resynchronize asynchronous inputs.
> You just have to make them traverse a D FlipFlop, or two FlipFlops if
> you're scared.
>
> As one can easily understand, this is extremely critical when the async
> signal is driving several FFs (some may see a 1 and others a 0 and take
> "impossible" decisions (and drive an FSM crazy for example). This can
> happen without even a timing violation !
> It's a major source of buggy designs which simply don't work reliably or
> at all, yet it's usually not taught properly.
>
> When in doubt, follow the guide
> But I agree that it's better to understand the reasons behind the rules.
>
> Bert Cuzeau
>
>
>

Weddick

Dave Higton wrote:
.. . .
> However, 4 channels suffered badly from noise, and 4 channels less badly.
> It was the same channel in each FPGA that was affected, to the same
> extent. The noise went away when I did nothing more than add a second
> level of resynchronisation, with a second DFF. Nowadays I tend to do
> the same sort of design with 4 stages

There is a very logical reason to describe
at least three synchronization stages in
the source code. Synthesis can and often
does branch an n-state shifter to multiple
D or CE inputs at stage n-1.

I might expect this:
/-->
>---[DQ]--[DQ]--[DQ]-|--->
1 2 3 \-->

But I might actually get this:

/-[DQ]-->
>---[DQ]--[DQ]-|--[DQ]-->
1 2 \-[DQ]-->


This effectively eliminates one stage
of synchronization, even though the
functional sim is the same.

-- Mike Treseler

Mike Treseler