Set-up and hold times and metastability

Hi,

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up and
hold times, however the enable can be completely asynchronous without ever
causing a problem?

If not, then even something as simple as testing a switch is pressed would
cause problems right? 

Thanks for the help
James

-- PS sorry if this is a double post, I got an error when previously
sending	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

James823 <3681@embeddedrelated> wrote:
 
> I've been looking at synchronising data across clock domains, and have
> managed to confuse myself.
> Can someone confirm (or correct me) that the following is true.
 
> Metastability may occur if the input D changes value during the set-up and
> hold times, however the enable can be completely asynchronous without ever
> causing a problem?

Doesn't seem right to me. If D has the same value as Q, then there
should be no problem. If not, it seems to me just as bad as changing Q.
 
> If not, then even something as simple as testing a switch is pressed would
> cause problems right? 

The traditional method of using a second FF should still work. 

Also, remember the second problem that comes from not meeting
setup/hold, when you have more than one FF some might get the new
value, some keep the old. That is completely separate from
metastability, but also causes systems to fail.

-- glen

> Metastability may occur if the input D changes value during the set-up and
> hold times, however the enable can be completely asynchronous without ever
> causing a problem?

No, the enable will have a setup and hold time as well.

Even async resets can cause metastability, if it violates the recovery time.

> If not, then even something as simple as testing a switch is pressed would
> cause problems right? 

Yes. 

Depending on the type of switch, you also might need to consider debouncing.

Cheers,
Jon

On 22/11/2012 07:35, James823 wrote:
> Hi,
>
> I've been looking at synchronising data across clock domains, and have
> managed to confuse myself.
> Can someone confirm (or correct me) that the following is true.
>
> Metastability may occur if the input D changes value during the set-up and
> hold times, however the enable can be completely asynchronous without ever
> causing a problem?

The enable is really a latch enable with all the same issues of 
metastability of a clock.

> If not, then even something as simple as testing a switch is pressed would
> cause problems right?
>

There are a number of ways of achieving moving data across clock domains.

Simplest is to use a fast clock, where the clock rate is many times the 
data rate.  The original data clock can be sampled to determine when it 
transitions and the data read when it should be stable, if necessary 
using suitably delayed data using parallel latches.

A typical method is to buffer the data in a FIFO which typically uses 
Gray code counters for pointers.  Input and output valid data enables 
can be built into the FIFO.

I often use Block Ram based FIFO for moving line or block data from a 
video source clock domain to memory and back again.  Here I might use 
flags to signify when a block of data is ready for the second clock domain.

In general the problem is reduced to having a single signal to denote 
valid data.  Where any uncertainty will not by itself corrupt data.

Hope that helps.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

On 11/22/2012 9:35 AM, Mike Perkins wrote:
> On 22/11/2012 07:35, James823 wrote:
>> Hi,
>>
>> I've been looking at synchronising data across clock domains, and have
>> managed to confuse myself.
>> Can someone confirm (or correct me) that the following is true.
>>
>> Metastability may occur if the input D changes value during the set-up
>> and
>> hold times, however the enable can be completely asynchronous without
>> ever
>> causing a problem?
>
> The enable is really a latch enable with all the same issues of
> metastability of a clock.
>
>> If not, then even something as simple as testing a switch is pressed
>> would
>> cause problems right?
>>
>
> There are a number of ways of achieving moving data across clock domains.
>
> Simplest is to use a fast clock, where the clock rate is many times the
> data rate. The original data clock can be sampled to determine when it
> transitions and the data read when it should be stable, if necessary
> using suitably delayed data using parallel latches.

What???  How do you "sample" the input without dealing with 
metastability in those samples?


> A typical method is to buffer the data in a FIFO which typically uses
> Gray code counters for pointers. Input and output valid data enables can
> be built into the FIFO.

I'm not sure what circuit you are describing.  The circuit I have always 
used is one where the enable or clock from the sending domain is run 
through a handshake circuit that synchronizes it to the receiving 
domain.  If necessary the data is buffered in a register.  A FIFO is 
only needed when the data rate can burst faster than the receiving clock 
rate.


> I often use Block Ram based FIFO for moving line or block data from a
> video source clock domain to memory and back again. Here I might use
> flags to signify when a block of data is ready for the second clock domain.
>
> In general the problem is reduced to having a single signal to denote
> valid data. Where any uncertainty will not by itself corrupt data.
>
> Hope that helps.
>

Another way to deal with the problem is to minimize and encapsulate it. 
  This means using a single clock for the entire FPGA design other than 
the I/O interfaces where you sync the signals as soon as possible.

Rick

On Thursday, November 22, 2012 2:35:31 AM UTC-5, James823 wrote:
> however the enable can be completely asynchronous without ever causing a
> problem?

The rule is that every input to a device that samples one signal with anoth=
er will have either setup/hold or (frequently) both requirements.  Flip flo=
ps, latches, memory, fifos are all examples of devices that sample one sign=
al (the input data) with another signal (the clock).

It's not clear when you refer to 'enable' if you're referring to the clock =
enable of a flip flop (in which case the above rule applies since 'enable' =
is just another input to the logic feeding the flip flop).  Or perhaps you =
mean a transparent latch (in which case the above rule applies...but setup/=
hold requirements will exist for the other signals relative to the active t=
o inactive edge of the enable signal).

Even the supposed 'asynchronous' reset or preset input to a flip flop will =
have timing requirements.  Specifically, the time that the reset/preset inp=
ut is released will almost always need to be controlled relative to the clo=
ck.  In most cases, it cannot be simply allowed to go inactive at any opint=
 in the clock cycle.

Kevin Jennings

On 22/11/2012 17:33, rickman wrote:
> On 11/22/2012 9:35 AM, Mike Perkins wrote:
>> On 22/11/2012 07:35, James823 wrote:
>>> Hi,
>>>
>>> I've been looking at synchronising data across clock domains, and
>>> have managed to confuse myself. Can someone confirm (or correct
>>> me) that the following is true.
>>>
>>> Metastability may occur if the input D changes value during the
>>> set-up and hold times, however the enable can be completely
>>> asynchronous without ever causing a problem?
>>
>> The enable is really a latch enable with all the same issues of
>> metastability of a clock.
>>
>>> If not, then even something as simple as testing a switch is
>>> pressed would cause problems right?
>>>
>>
>> There are a number of ways of achieving moving data across clock
>> domains.
>>
>> Simplest is to use a fast clock, where the clock rate is many times
>> the data rate. The original data clock can be sampled to determine
>> when it transitions and the data read when it should be stable, if
>> necessary using suitably delayed data using parallel latches.
>
> What???  How do you "sample" the input without dealing with
> metastability in those samples?

By taking a latched clock being high say for 2 High-Speed clocks before
accepting it as a real clock-high.

>> A typical method is to buffer the data in a FIFO which typically
>> uses Gray code counters for pointers. Input and output valid data
>> enables can be built into the FIFO.
>
> I'm not sure what circuit you are describing.  The circuit I have
> always used is one where the enable or clock from the sending domain
> is run through a handshake circuit that synchronizes it to the
> receiving domain.  If necessary the data is buffered in a register.
> A FIFO is only needed when the data rate can burst faster than the
> receiving clock rate.

I agree, it depends on relative clock speeds, the continuity of data,
whilst it is sent, and how it can be received by each clock domain.

>> I often use Block Ram based FIFO for moving line or block data from
>> a video source clock domain to memory and back again. Here I might
>> use flags to signify when a block of data is ready for the second
>> clock domain.
>>
>> In general the problem is reduced to having a single signal to
>> denote valid data. Where any uncertainty will not by itself corrupt
>> data.
>>
>> Hope that helps.
>>
>
> Another way to deal with the problem is to minimize and encapsulate
> it. This means using a single clock for the entire FPGA design other
> than the I/O interfaces where you sync the signals as soon as
> possible.

Entirely agree, but that's not always possible.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

>On 11/22/2012 9:35 AM, Mike Perkins wrote:
>> On 22/11/2012 07:35, James823 wrote:
>>> Hi,
>>>
>>> I've been looking at synchronising data across clock domains, and have
>>> managed to confuse myself.
>>> Can someone confirm (or correct me) that the following is true.
>>>
>>> Metastability may occur if the input D changes value during the set-up
>>> and
>>> hold times, however the enable can be completely asynchronous without
>>> ever
>>> causing a problem?
>>
>> The enable is really a latch enable with all the same issues of
>> metastability of a clock.

[Mike]
This is where I have a problem. My understanding is that internally, the
clock is simply gated by the enable, so the effect of an asynchronous
enable is that the (clock AND enable) signal can have arbitrarily small
pulse width, i.e. if the following occurs:
 0) Initially clock is '0', enable is '1'
 1) clock goes to '1'
 2) enable goes to '0' after 1 ps or some other arbitrary time

Now, consider the standard NAND (or NOR) gate implementation as 2 layers of
SR latches. So long as the (clock AND enable) pulse width is sufficiently
long to propagate through the two NAND gates which it is connected, the
signal has now reached layer 1. Again, because the input was a pulse, so
too will this signal. The same thing now happens between the inputs to
layer 2, and the output updates. 
The reason for metastability caused by D changing is that a change in D
needs to propagate through 3 stages of NAND gates (due to the feedback
structure) before it reaches the inputs to layer 2.
This explains why we now typically have negative hold times and positive
set-up times. The clock takes 1 NAND propagation to get to the inputs of
layer 2, but the D signal takes 3, hence if the D signal changes 1 NAND
prop. time before the clock changes, the clock will reach the layer 2
inputs before the D signal i.e. negative hold time. 

Following the signals through like this, I can't see any reason that a
small pulse width will cause metastability at all. In fact the only issue I
can see is that if the pulse is short enough, then the signal won't
propagate because of the capacitance of the gates and internal
interconnect. However, this just means that the signal never gets anywhere,
so it's as if the pulse never occurred - hardly a problem at all.

Where's the flaw in my reasoning?

>>
>>> If not, then even something as simple as testing a switch is pressed
>>> would
>>> cause problems right?
>>>
>>
>> There are a number of ways of achieving moving data across clock
domains.
>>
>> Simplest is to use a fast clock, where the clock rate is many times the
>> data rate. The original data clock can be sampled to determine when it
>> transitions and the data read when it should be stable, if necessary
>> using suitably delayed data using parallel latches.
>
>What???  How do you "sample" the input without dealing with 
>metastability in those samples?
>
[Rickman]
This is exactly the reason that I started this thread - the more I thought
about it, the more I realised that the clock rate to data rate ratio is
irrelevant, and it kind of pulled the rug from under me.


Thanks for the quick replies :)	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

James823 <3681@embeddedrelated> wrote:
>>On 11/22/2012 9:35 AM, Mike Perkins wrote:

(snip)
>>> The enable is really a latch enable with all the same issues of
>>> metastability of a clock.
 
> [Mike]
> This is where I have a problem. My understanding is that internally, the
> clock is simply gated by the enable, so the effect of an asynchronous
> enable is that the (clock AND enable) signal can have arbitrarily small
> pulse width, i.e. if the following occurs:
> 0) Initially clock is '0', enable is '1'
> 1) clock goes to '1'
> 2) enable goes to '0' after 1 ps or some other arbitrary time

Ones I know, have a MUX between Q and D before the FF logic.
Assuming a no-glitch MUX, if Q and D are the same, then there
should be no problem, but if they aren't, then it is the same
as changing D.

-- glen

>James823 <3681@embeddedrelated> wrote:
>>>On 11/22/2012 9:35 AM, Mike Perkins wrote:
>
>(snip)
>>>> The enable is really a latch enable with all the same issues of
>>>> metastability of a clock.
> 
>> [Mike]
>> This is where I have a problem. My understanding is that internally,
the
>> clock is simply gated by the enable, so the effect of an asynchronous
>> enable is that the (clock AND enable) signal can have arbitrarily small
>> pulse width, i.e. if the following occurs:
>> 0) Initially clock is '0', enable is '1'
>> 1) clock goes to '1'
>> 2) enable goes to '0' after 1 ps or some other arbitrary time
>
>Ones I know, have a MUX between Q and D before the FF logic.
>Assuming a no-glitch MUX, if Q and D are the same, then there
>should be no problem, but if they aren't, then it is the same
>as changing D.
>
>-- glen
>

I've noticed that this is how the compiler will synthesize code that has
complicated enable logic, but for simpler code it uses the enable (at least
using Quartus Web edition for a Cyclone II - the RTL viewer could be lying
to me about the true synthesis implementation though).

The reason presumably is that having more than a small amount of logic on
the enable line effectively introduces a clock skew. 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com