Should I worry about metastability

But you said that the clock was not truly asynchronous, but was 4 times
the data rate, with an unknown ( but stable?) phase relationship.
Click to expand...
Maybe my description was a bit confusing, sorry for this. The clocks
really are asychronous. There is no stable phase relationship between
them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync
of a video signal, and the 108MHz system clock is derived from a 27MHz
crystal oscillator.
 
If you pick the right xilinx you could multiply the 27MHz up to 108MHz
internally. Just use the internal PLL

Simon


"Guy Eschemann" <geschemann@yahoo.fr> wrote in message
news:b9f16a5b.0310062304.4b75202a@posting.google.com...
But you said that the clock was not truly asynchronous, but was 4 times
the data rate, with an unknown ( but stable?) phase relationship.


Maybe my description was a bit confusing, sorry for this. The clocks
really are asychronous. There is no stable phase relationship between
them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync
of a video signal, and the 108MHz system clock is derived from a 27MHz
crystal oscillator.
Click to expand...
 
I'm guessing this is video. If that is the case, you've probably got an
incoming pixel clock and data that is timed to that clock that you want to
get on to the internal 108 MHz clock. In an ideal world, you could use
the DLLs to multiply the pixel clock by 4 to get your internal clock.
Unfortunately, the pixel clock from most of the popular decoders has far
too much jitter to keep the DLLs happy, so you are more or less forced to
use an unrelated local clock.

So how to do it? Clock your incoming pixel data into the FPGA on the 27
Mhz pixel clock, and also toggle an additional flag bit. A change on the
flag bit corresponds to new data getting clocked in. Synchronize that
flag bit output to the 108 Mhz clock using a single flip-flop, then detect
the change in the synchronized flag with a synchronous edge detect state
machine. I use a state machine designed so that only one bit is
sensitive to the synchronized toggle signal and which generates a 1 clock
wide pulse in response to a level change on the toggle input. For low
clock rates, you can do without the synchronizing flip flop preceding the
state machine because the toggle input only effects one state bit. The
state machine I use is:

case state is
when "00" =>
if sync='1' then
next_state<="01";
else
next_state<="00";
end if;
when "01" =>
next_state<="10";
when "10" =>
if sync='0' then
next_state<="11";
else
next_state<="10";
end if;
when "11" =>
next_state<="00";
when others=>
null;
end case;

The state(0) bit out of that state machine is a one clock wide pulse.
That is used to copy data from the register holding the pixel data to a
second register in the 108 MHz clock domain. This method takes up about 3
clock cycles of time, leaving little margin for the 27 MHz to 108 MHz
transfer, so a modification is in order. In order to handle the
relatively frequent 27 mHz inputs, instead of presenting each pixel, the
27 MHz logic consists of a 2 deep shift register that captures 2 pixels
and holds them both for 2 cycles of the 27 MHz clock. The flag flip-flop
is replaced by a 2 bit counter whose MSB toggles at the same time the 2
pixel register outputs are updated. Then the synchronized write pulse is
used to transfer 2 pixels at a time (in parallel) to the register in the
108 MHz clock domain. By construction, the data at the clock domain
boundaries is guaranteed to be stable when the state machines write pulse
(state bit 0) pulses.

Now, somehow you'll have to provide some elasticity since the 108 MHz
clock is not exactly 4x the 27 MHz clock. This can be handled with a
FIFO, or by dropping or repeating samples. In the case of video, it is
often best handled by writing to a frame buffer, and then fetching from
the frame buffer later so you don't have to deal with missing or extra
pixels later in your process.

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.

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.
Click to expand...
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
If he is using the Phillips decoder, then no. The decoder has a PLL in it
that adjusts itself to match the sync data in the incoming stream. The
decoder's PLL output also has way too much jitter for the DLL in the FPGA.

Marc Randolph wrote:

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
Click to expand...
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
Nope, Jitter out of the video decoders is about 10x what is allowed by the
DLL/DCM. I posted earlier a solution that works fine for this, and is used in
a number of my customer's products.



Simon Peacock wrote:

If you pick the right xilinx you could multiply the 27MHz up to 108MHz
internally. Just use the internal PLL

Simon

"Guy Eschemann" <geschemann@yahoo.fr> wrote in message
news:b9f16a5b.0310062304.4b75202a@posting.google.com...
But you said that the clock was not truly asynchronous, but was 4 times
the data rate, with an unknown ( but stable?) phase relationship.


Maybe my description was a bit confusing, sorry for this. The clocks
really are asychronous. There is no stable phase relationship between
them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync
of a video signal, and the 108MHz system clock is derived from a 27MHz
crystal oscillator.
Click to expand...
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
Have a talk to your friendly Xilinx Apps engineer Spartan 3's can tolerate
a high jitter (So I've read) .. they just wont tell you that except under
NDA.

Simon


"Ray Andraka" <ray@andraka.com> wrote in message
news:3F8325DD.371B7949@andraka.com...
Nope, Jitter out of the video decoders is about 10x what is allowed by
the
DLL/DCM. I posted earlier a solution that works fine for this, and is
used in
a number of my customer's products.



Simon Peacock wrote:

If you pick the right xilinx you could multiply the 27MHz up to 108MHz
internally. Just use the internal PLL

Simon

"Guy Eschemann" <geschemann@yahoo.fr> wrote in message
news:b9f16a5b.0310062304.4b75202a@posting.google.com...
But you said that the clock was not truly asynchronous, but was 4
times
the data rate, with an unknown ( but stable?) phase relationship.


Maybe my description was a bit confusing, sorry for this. The clocks
really are asychronous. There is no stable phase relationship between
them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync
of a video signal, and the 108MHz system clock is derived from a 27MHz
crystal oscillator.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Click to expand...
 
I think the correct term is higher jitter. As I recall, the Philips video
decoders have
something like 8 uS max jitter, which is nearly 100x the permissible jitter on
Spartan2 and Virtex. Also, that jitter spec is for an established video
signal. If
you disconnect and reconnect the video signal, the PLL output goes out to lunch
for
a period of time, which is something the DLLs decidedly don't like.

Simon Peacock wrote:

Have a talk to your friendly Xilinx Apps engineer Spartan 3's can tolerate
a high jitter (So I've read) .. they just wont tell you that except under
NDA.

Simon

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F8325DD.371B7949@andraka.com...
Nope, Jitter out of the video decoders is about 10x what is allowed by
the
DLL/DCM. I posted earlier a solution that works fine for this, and is
used in
a number of my customer's products.



Simon Peacock wrote:

If you pick the right xilinx you could multiply the 27MHz up to 108MHz
internally. Just use the internal PLL

Simon

"Guy Eschemann" <geschemann@yahoo.fr> wrote in message
news:b9f16a5b.0310062304.4b75202a@posting.google.com...
But you said that the clock was not truly asynchronous, but was 4
times
the data rate, with an unknown ( but stable?) phase relationship.


Maybe my description was a bit confusing, sorry for this. The clocks
really are asychronous. There is no stable phase relationship between
them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync
of a video signal, and the 108MHz system clock is derived from a 27MHz
crystal oscillator.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Click to expand...
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
If I create a two-FF chain (with common clock), XST will likely pull
those two FFs into a SRL16. Is it permissible to use two bits of a
SRL16 as a synchroniser in this way? (It surely must be the
shortest-possible path between two FFs).

Peter Alfke <peter@xilinx.com> wrote:

:You should always be concerned about metastability, whenever
:asynchronous signals are being synchronized. Let me add some numbers to
:phil Freidin's excellent comments:
:
:Metastability creates unpredictable additional settling delays (even
:eek:scillations can be considered delays to valid out). The probability of
:a specific max delay depends on the clock rate, the data rate, and the
:IC technology.
:
[snip]
 
Metastability is unavoidable. Whether it hurts you depends on the clock
and data frequencies and also on the technology used.
I will not guarantee that SRL16s recover as fast from metastability as
the "normal" flip-flops that I documented, since SRLs are implemented in
a different circuit design. (Different might mean better or worse).

Peter Alfke
=================
David R Brooks wrote:
If I create a two-FF chain (with common clock), XST will likely pull
those two FFs into a SRL16. Is it permissible to use two bits of a
SRL16 as a synchroniser in this way? (It surely must be the
shortest-possible path between two FFs).

Peter Alfke <peter@xilinx.com> wrote:

:You should always be concerned about metastability, whenever
:asynchronous signals are being synchronized. Let me add some numbers to
:phil Freidin's excellent comments:
:
:Metastability creates unpredictable additional settling delays (even
:eek:scillations can be considered delays to valid out). The probability of
:a specific max delay depends on the clock rate, the data rate, and the
:IC technology.
:
[snip]
Click to expand...
 
Actually, the SRL's are probably no good for that. They have a considerably
longer minimum pulse width than the regular flip-flops. I'm not privy to the
actual construction, but I'd be it is more akin to latches than to real
flip-flops. Your best resynchronizer will use the regular flip-flops,
floorplanned to use adjacent slices within a CLB and using the fast direct
connect route between the flip-flops.

Peter Alfke wrote:

Metastability is unavoidable. Whether it hurts you depends on the clock
and data frequencies and also on the technology used.
I will not guarantee that SRL16s recover as fast from metastability as
the "normal" flip-flops that I documented, since SRLs are implemented in
a different circuit design. (Different might mean better or worse).

Peter Alfke
=================
David R Brooks wrote:

If I create a two-FF chain (with common clock), XST will likely pull
those two FFs into a SRL16. Is it permissible to use two bits of a
SRL16 as a synchroniser in this way? (It surely must be the
shortest-possible path between two FFs).

Peter Alfke <peter@xilinx.com> wrote:

:You should always be concerned about metastability, whenever
:asynchronous signals are being synchronized. Let me add some numbers to
:phil Freidin's excellent comments:
:
:Metastability creates unpredictable additional settling delays (even
:eek:scillations can be considered delays to valid out). The probability of
:a specific max delay depends on the clock rate, the data rate, and the
:IC technology.
:
[snip]
Click to expand...
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
Xilinx guys : wouldn't it be cool to integrate such a resynchronizer
circuit in each IOB ?
 
Guy Eschemann wrote:

Xilinx guys : wouldn't it be cool to integrate such a resynchronizer
circuit in each IOB ?
Click to expand...
Yea. It's called a flipflop. There is already one there.


--
Phil Hays
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top