Resynchronization - important?

[Preben Holm]

Hi everyone..


I read that resyncrhonization of signals is important, but is it
important, if the module is part of a larger design inside the same
FPGA? It causes a lot of delays in the overall design to make these
resynchronizations and results in hard-to-track delays of the signals?


/ Preben

 

[Thomas Stanka]

HI,


Preben Holm wrote:

I read that resyncrhonization of signals is important, but is it
important, if the module is part of a larger design inside the same
FPGA? It causes a lot of delays in the overall design to make these
resynchronizations and results in hard-to-track delays of the signals?

You need resynchronisation when ever you change between two independend
clock domains. When doing very large designs where the wire delay between
two distant modules is nearly the normal delay between two clock edges you
should also insert FF between the modules to meet timing constraints.
Between two adjacent modules within the same clock domain there is no need
to resynchronise signals.

bye Thomas

--
Emailantworten bitte an thomas[at]obige_domain.
Usenet_10 ist für Viren und Spam reserviert

 

[info_]

Preben Holm wrote:

I read that resyncrhonization of signals is important, but is it
important, if the module is part of a larger design inside the same
FPGA? It causes a lot of delays in the overall design to make these
resynchronizations and results in hard-to-track delays of the signals?

You _NEED_ resynch when your input is _A_synchronous and used by more than
one FlipFlop. (But you need resynch also against timing violations).
The big issue is that due to different delays between you input pad
and your FlipFlops, one FF could see a 1 and the other a 0, and would
take a seemingly "impossible" decision !!!! and this can happen even
without a timing violation.
Usual symptom is a one-hot state machine becoming all zero (stuck)
or "multiple-hot". But other variants of this are common, like
counters skipping values, etc etc...
It's probably the most frequent design error I seen in code
from "experts". We do insist a lot about this in our training courses.

Clock domain crossing is another issue especially when you need
to transport busses or group of intercorrelated signals !
Resynchronization FlipFlops stages is NOT the answer in this case.
(Try a small Fifo instead or a mailbox scheme)

In a single domain synchronous design, you only need resynchronization
for external asynchronous signal.
Internal signals will be synchronous and verified by Static Timing Analysis.
External Synchronous inputs are also verified by Static timing Analysis
(Tsu/Th).


Bert Cuzeau

 

[Hal Murray]

You _NEED_ resynch when your input is _A_synchronous and used by more than
one FlipFlop.

You can get in trouble even if you have only one FF.
Consider metastability.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[info_]

Hal Murray wrote:

You _NEED_ resynch when your input is _A_synchronous and used by more than
one FlipFlop.


You can get in trouble even if you have only one FF.
Consider metastability.

My sentence was :

You _NEED_ resynch when your input is _A_synchronous and used by more than
one FlipFlop. (But you need resynch also against timing violations).

The last part said that precisely. (I thought)
Timing violations potentially create metastability, though the real
issue is usually the complete lack of resynchronization which IS
a killer as I explained !
Since old ages, the "official" solution against metastability was
two cascaded FFs...
It seems now agreed by the FPGA vendors that in usual situations and recent
FPGAs, a single FF should be enough for getting away from metastability
issues, but don't take my word for it. Check with your FPGA vendor's
metastability measurements reports. To be accurate, there is a mtbf
calculation involving FF clock frequency and input change rate and
other physical factors.

I would be VERY happy the day I will see a resync FF resynchronizing
every asynchronous FPGA input from every design...
I keep hammering this during our training courses


Bert Cuzeau

 

[Preben Holm]

info_ wrote:

Preben Holm wrote:

I read that resyncrhonization of signals is important, but is it
important, if the module is part of a larger design inside the same
FPGA? It causes a lot of delays in the overall design to make these
resynchronizations and results in hard-to-track delays of the signals?


You _NEED_ resynch when your input is _A_synchronous and used by more than
one FlipFlop. (But you need resynch also against timing violations).
The big issue is that due to different delays between you input pad
and your FlipFlops, one FF could see a 1 and the other a 0, and would
take a seemingly "impossible" decision !!!! and this can happen even
without a timing violation.
Usual symptom is a one-hot state machine becoming all zero (stuck)
or "multiple-hot". But other variants of this are common, like
counters skipping values, etc etc...

It actually happens in the post-map simulation of one of my statemachine
discussed in the comp.arch.fpga-group. But only for a short time and it
settles within the next rising edge of the clock - should I take care of
this some how?

It's probably the most frequent design error I seen in code
from "experts". We do insist a lot about this in our training courses.

Clock domain crossing is another issue especially when you need
to transport busses or group of intercorrelated signals !

intercorrelated signals?

Resynchronization FlipFlops stages is NOT the answer in this case.
(Try a small Fifo instead or a mailbox scheme)

In a single domain synchronous design, you only need resynchronization
for external asynchronous signal.
Internal signals will be synchronous and verified by Static Timing
Analysis.
External Synchronous inputs are also verified by Static timing Analysis
(Tsu/Th).

Okay, I find this rather logic anyway so!!

 

[Kai Harrekilde-Petersen]

Preben Holm <64bitNOnoNOSPAM@mailme.dk> writes:

info_ wrote:
Preben Holm wrote:

I read that resyncrhonization of signals is important, but is it
important, if the module is part of a larger design inside the same
FPGA? It causes a lot of delays in the overall design to make these
resynchronizations and results in hard-to-track delays of the
signals?
You _NEED_ resynch when your input is _A_synchronous and used by
more than
one FlipFlop. (But you need resynch also against timing violations).
The big issue is that due to different delays between you input pad
and your FlipFlops, one FF could see a 1 and the other a 0, and would
take a seemingly "impossible" decision !!!! and this can happen even
without a timing violation.
Usual symptom is a one-hot state machine becoming all zero (stuck)
or "multiple-hot". But other variants of this are common, like
counters skipping values, etc etc...

It actually happens in the post-map simulation of one of my
statemachine discussed in the comp.arch.fpga-group. But only for a
short time and it settles within the next rising edge of the clock -
should I take care of this some how?

Sounds like that you're just seeing the delay within the device in
your simulation. In that case, no worries.

It's probably the most frequent design error I seen in code
from "experts". We do insist a lot about this in our training courses.
Clock domain crossing is another issue especially when you need
to transport busses or group of intercorrelated signals !

intercorrelated signals?

Multiple bits that *must* be sampled simultaneously. E.g. a databus,
where sampling some bits in slot N and the rest in slot N+1 really
bad.

At work, it has been an official rule that if you want a databus to
cross a clock boundary, you *must* use one of the existing
resynchronization buffers. We have a selection of resync buffers that
have been scrutinized and tested in real designs.

Basically, they all consist of a number of buffers, and two gray-coded
read/write pointers, which are then double-synced across the clock
boundary. Some variants have full and empty flags as well. Other
variants can only transfer data at approx 1/8th clock rate, for
"seldomly-updated" status information.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[Bert Cuzeau]

Thank Kai !!!

I was away from the office (or home) but you explained
it perfectly.

My grief is why those basic issues are (almost) never taught
properly ???


Kai Harrekilde-Petersen wrote:

Preben Holm <64bitNOnoNOSPAM@mailme.dk> writes:


info_ wrote:

Preben Holm wrote:


I read that resyncrhonization of signals is important, but is it
important, if the module is part of a larger design inside the same
FPGA? It causes a lot of delays in the overall design to make these
resynchronizations and results in hard-to-track delays of the
signals?

You _NEED_ resynch when your input is _A_synchronous and used by
more than
one FlipFlop. (But you need resynch also against timing violations).
The big issue is that due to different delays between you input pad
and your FlipFlops, one FF could see a 1 and the other a 0, and would
take a seemingly "impossible" decision !!!! and this can happen even
without a timing violation.
Usual symptom is a one-hot state machine becoming all zero (stuck)
or "multiple-hot". But other variants of this are common, like
counters skipping values, etc etc...

It actually happens in the post-map simulation of one of my
statemachine discussed in the comp.arch.fpga-group. But only for a
short time and it settles within the next rising edge of the clock -
should I take care of this some how?


Sounds like that you're just seeing the delay within the device in
your simulation. In that case, no worries.


It's probably the most frequent design error I seen in code
from "experts". We do insist a lot about this in our training courses.
Clock domain crossing is another issue especially when you need
to transport busses or group of intercorrelated signals !

intercorrelated signals?


Multiple bits that *must* be sampled simultaneously. E.g. a databus,
where sampling some bits in slot N and the rest in slot N+1 really
bad.

At work, it has been an official rule that if you want a databus to
cross a clock boundary, you *must* use one of the existing
resynchronization buffers. We have a selection of resync buffers that
have been scrutinized and tested in real designs.

Basically, they all consist of a number of buffers, and two gray-coded
read/write pointers, which are then double-synced across the clock
boundary. Some variants have full and empty flags as well. Other
variants can only transfer data at approx 1/8th clock rate, for
"seldomly-updated" status information.


Kai