Should I worry about metastability

Hi,
I need to synchronize an incoming 27MHz signal (50% duty cycle) with
an internal clock running at 108Mhz (which is 27*4, but the signals do
not have a known phase relationship). The target technology is Spartan
II-E.

Is a simple 2-stage DFF synchronizer a safe way to handle this ? (I
remember a Xilinx article stating that metastability can be ignored
for clock rates < 200MHz).

Many thanks,
Guy.

I don't think you can ever ignore metastability.  It will get up and bite
you if you do.

Simon


"Guy Eschemann" <geschemann@yahoo.fr> wrote in message
news:b9f16a5b.0310060044.4f3f135@posting.google.com...
> Hi,
> I need to synchronize an incoming 27MHz signal (50% duty cycle) with
> an internal clock running at 108Mhz (which is 27*4, but the signals do
> not have a known phase relationship). The target technology is Spartan
> II-E.
>
> Is a simple 2-stage DFF synchronizer a safe way to handle this ? (I
> remember a Xilinx article stating that metastability can be ignored
> for clock rates < 200MHz).
>
> Many thanks,
> Guy.

Quick question, is your 27 MHz signal a single bit line or a bus?

If it's a single bit, I was taught that 2 stage FFs was "good enough," but I
think it depends on how you're planning to use that single bit line.  Is it
merely some sort of status flag thing?  It's not a data stream is it?

Now if your 27 MHz signal is a bus, then you should consider using an
asynchronus fifo (which I think Coregen has a core for that, or if not, i'm
sure there's a reference design on Xilinx's website).  The problem with
using 2 stage FFs with a bus is that some bits might go metastable, and get
delayed one cycle, while others don't, so the bits on your bus get
misaligned.  For example, if you have a 4-bit bus that transitions from a
0x0 to an 0xF, on the 108 MHz side you might see it go from 0x0 to 0xE then
finally to 0xF.

One important thing to keep in mind is that even if you have two "seperate"
"single bit" signals coming in, you might have to treat them as a bus if
they are related to each other.  Again, it depends on how you're planning to
use them.


--Vinh

> (I remember a Xilinx article stating that metastability can be ignored
> for clock rates < 200MHz).

It might be a good idea to see what situation that < 200 MHz thing applies
to.

Metastability can happen at any frequency.  Say you have just a 1 Hz signal
that you're resynching to just a 2 Hz clock.  If the phase relationship is
just right, your FFs can go metastable all the time.

Besides, bugs caused by metastability are a pain to track down.  If you're
unlucky, they'll occur with the customer's equipment, but not with the one
in your lab.  Worse yet, when you pay to ship the customer's equipment back
to your lab, the bug mysteriously disappears.  Prevention is far more
valuable than a cure, in this case.  :_)

--Vinh

On 6 Oct 2003 01:44:54 -0700, geschemann@yahoo.fr (Guy Eschemann) wrote:
>Hi,
>I need to synchronize an incoming 27MHz signal (50% duty cycle) with
>an internal clock running at 108Mhz (which is 27*4, but the signals do
>not have a known phase relationship). The target technology is Spartan
>II-E.

See Vinh's response in regard to whether this 27MHz thing is one
or more signals.

For a better understanding on Metastability, I recommend:

   http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

>Is a simple 2-stage DFF synchronizer a safe way to handle this ?

This MAY be sufficient. The primary requirement is that there be
maximum possible slack time in the path between the two FFs that
make up your synchronizer. At 108MHz, the cycle time is about 9.25ns.

If the first FF has a clock to output delay of .5 ns, and the second
FF has an input setup time of .5 ns, and the max delay of the routing
between them is 1ns, then you have a slack of 7.25ns.

A 3 stage synchronizer would effectively have double this slack time
(2 x 7.25ns) , but would add another cycle of latency.

If you don't control the routing delay, your efforts may be wasted.

For example, if you set a the timespec to 9ns for this path, the
current Xilinx router will stop optimizing the path as soon as it
has met this requirement, and you will have a miserable synchronizer
because the slack time will be far less than 7.25 ns. Maybe as
little as .25ns . 
 
You need to set specific timespecs that cover this critical path,
and set it far more aggressively than the clock frequency would
indicate. I would recommend a target of 3 ns for the path, which
if the spec is met, will give you at least 6 ns of slack.

The most useful thing you can do to help the tools is to put
placement constraints on the two FFs of the synchronizer, and
place them in the same CLB. This makes it far easier to meet the
aggressive timespec that you must also specify.


>(I remember a Xilinx article stating that metastability can be ignored
>for clock rates < 200MHz).

This is NEVER (absolutely, categorically NEVER) true. (can you remember
which article you saw this in? 

>Many thanks,
>Guy.

Well designed synchronizers are your friend!

Philip




Philip Freidin
Fliptronics

As Vinh says, once you have more than one related signal that you need to
synchronize, the two flop method breaks down.  Have look at the following
tutorial/paper that describes various ways to handle asynchronous design.
I've posted it before, but it never hurts to do so again...

www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf

- Paul Leventis
Altera Corp.

My 27 MHz signal is a single bit line, not a bus.
Actually it is the clock line for an 8-bit video data stream. My
problem is to synchronize this incoming data stream with the 108MHz
system clock.

I know I could be using an asynchronous FIFO for this, but this might
be overkill. In order to save resources, wouldn't it be better to
synchronize the 27 MHz clock with my system clock (2-stage pipeline
should do the job), then use some logic to detect the appropriate edge
and use the output of the edge detector as a clock enable signal for
the input data FFs, which are clocked by the system clock ?

Regards,
Guy.


"Vinh Pham" <a@a.a> wrote in message news:<ONagb.26378$Ak3.15511@twister.socal.rr.com>...
> Quick question, is your 27 MHz signal a single bit line or a bus?
> 
> If it's a single bit, I was taught that 2 stage FFs was "good enough," but I
> think it depends on how you're planning to use that single bit line.  Is it
> merely some sort of status flag thing?  It's not a data stream is it?
> 
> Now if your 27 MHz signal is a bus, then you should consider using an
> asynchronus fifo (which I think Coregen has a core for that, or if not, i'm
> sure there's a reference design on Xilinx's website).  The problem with
> using 2 stage FFs with a bus is that some bits might go metastable, and get
> delayed one cycle, while others don't, so the bits on your bus get
> misaligned.  For example, if you have a 4-bit bus that transitions from a
> 0x0 to an 0xF, on the 108 MHz side you might see it go from 0x0 to 0xE then
> finally to 0xF.
> 
> One important thing to keep in mind is that even if you have two "seperate"
> "single bit" signals coming in, you might have to treat them as a bus if
> they are related to each other.  Again, it depends on how you're planning to
> use them.
> 
> 
> --Vinh

Guy Eschemann wrote:

> My 27 MHz signal is a single bit line, not a bus.
> Actually it is the clock line for an 8-bit video data stream. My
> problem is to synchronize this incoming data stream with the 108MHz
> system clock.
> 
> I know I could be using an asynchronous FIFO for this, but this might
> be overkill. In order to save resources, wouldn't it be better to
> synchronize the 27 MHz clock with my system clock (2-stage pipeline
> should do the job), then use some logic to detect the appropriate edge
> and use the output of the edge detector as a clock enable signal for
> the input data FFs, which are clocked by the system clock ?

At the risk of proposing something you've already thought of, is there 
really no way to use the 108 MHz clock in the FPGA as the source of the 
27 MHz clock that video data source uses, so that there is a known phase 
relationship between the two?  If you can swing that, they'll be in the 
same domain and all you have to worry about is a non-varying setup time.

    Marc

Vinh Pham wrote:
> 
> > (I remember a Xilinx article stating that metastability can be ignored
> > for clock rates < 200MHz).
> 
> It might be a good idea to see what situation that < 200 MHz thing applies
> to.
> 
> Metastability can happen at any frequency.  Say you have just a 1 Hz signal
> that you're resynching to just a 2 Hz clock.  If the phase relationship is
> just right, your FFs can go metastable all the time.
> 
> Besides, bugs caused by metastability are a pain to track down.  If you're
> unlucky, they'll occur with the customer's equipment, but not with the one
> in your lab.  Worse yet, when you pay to ship the customer's equipment back
> to your lab, the bug mysteriously disappears.  Prevention is far more
> valuable than a cure, in this case.  :_)

I think the frequency reference is talking about ignoring metastability
once you have used the 2 FF sync trick.  The sync circuit depends on the
timing slack between the two FFs to allow the output of the first FF to
settle.  Above 200 MHz the slack time gets pretty short even if your
routing is pretty good.  

The other effect of frequency is on MTBF.  This is a linear effect
related to the product of the two frequencies.  So when reading a
pushbutton at 32 kHz, I would not worry too much about metastability. 
But at much higher clock rates without a sync circuit, it can be a
problem as you say.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Guy Eschemann wrote:
> 
> My 27 MHz signal is a single bit line, not a bus.
> Actually it is the clock line for an 8-bit video data stream. My
> problem is to synchronize this incoming data stream with the 108MHz
> system clock.
> 
> I know I could be using an asynchronous FIFO for this, but this might
> be overkill. In order to save resources, wouldn't it be better to
> synchronize the 27 MHz clock with my system clock (2-stage pipeline
> should do the job), then use some logic to detect the appropriate edge
> and use the output of the edge detector as a clock enable signal for
> the input data FFs, which are clocked by the system clock ?

Since your internal clock is 4 times the external clock, you should have
no problem.  Use the 27 MHz clock to register the data and sync the 27
MHz clock to the 108 using two FFs.  The resulting synchronized clock
will give a rising edge between a quarter and a half period of the 27
MHz clock and can be safely used to enable reclocking of the data.  You
should use an edge detector which will delay the clock one more quarter
of a 27 MHz period and will still be safe.  

               ---                                      ---  Sync'd
Data ---------|D Q|------------------------------------|D Q|------
27 MHz --+----|>  |                          ---       |   | Data
         |     ---             +------------|   |      |   |
         |     ---       ---   |   ---      | & |------|CE |
         +----|D Q|-----|D Q|--+--|D Q|----O|   |      |   |
108 MHz ------|>  |     |>  |     |>  |      ---       |>  |
               ---       ---       ---                  ---

View this in a monospaced font.

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX