Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Resynchronize external signals

Reply
Thread Tools

Resynchronize external signals

 
 
Weddick
Guest
Posts: n/a
 
      04-01-2005
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,


 
Reply With Quote
 
 
 
 
Bert Cuzeau
Guest
Posts: n/a
 
      04-01-2005
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



 
Reply With Quote
 
 
 
 
Ken
Guest
Posts: n/a
 
      04-01-2005
> 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


 
Reply With Quote
 
Bert Cuzeau
Guest
Posts: n/a
 
      04-01-2005
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.


 
Reply With Quote
 
Dave Higton
Guest
Posts: n/a
 
      04-01-2005
In message <424d8ebb$0$28527$(E-Mail Removed)>
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
 
Reply With Quote
 
Weddick
Guest
Posts: n/a
 
      04-02-2005
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$(E-Mail Removed)...
> 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
>
>
>



 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      04-02-2005
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
forcing external signals in VHDL 2008 MiguelM VHDL 0 02-05-2011 02:14 AM
Multiplex 2 external I2C signals to one FPGA internal signal hhanff VHDL 8 07-23-2010 11:48 AM
driving "external" signals from a procedure Eli Bendersky VHDL 15 04-28-2007 08:16 PM
Create references to external scipt files from within an external script file Mellow Crow Javascript 6 11-04-2005 01:16 PM
unresolved external symbol/using an external dll Scott Allen C++ 8 05-02-2004 06:11 PM



Advertisments