Avoiding meta stability?

For most purposes.

For physical floorplanning, it is not. If the UCF constrains two FFs to a clb, and the FFs are in a SRL16, then build will fail.

For metastability, it is not. As I'm under the impression that SRL16s FFs are slower, I suspect that they are not as metastable hard. Peter or Austin, care to comment? If nothing else, there is not data on SRL16s, so I can't be sure how good or bad the solution is. This is also true of the BlockRAMs.

I should have mentioned this above, but I unchecked the box (shift register extraction) so ISE didn't convert the FFs into a SRL16.

Probably better do cover this in the code. Add this line to the Verilog:

// synthesis attribute shreg_extract of ss is no;

--
Phil Hays to reply solve: phil_hays at not(coldmail) dot com  
 If not cold then hot

Bill -

Typical approach: clock the signal into a flip-flop with a 24 MHz clock, and give it most of a whole clock cycle to settle before applying it to the main circuit.

Your approach: clock the signal into two flip-flops with the 24 MHz rising and falling edges, then apply the AND of the two flip-flop outputs to the main circuit.

The problem with your approach is that the second flip-flop, the one clocked with the 24 MHz falling edge, has less than half as much time to settle (thanks to the AND gate delay) before being applied to the circuit. If the first flip-flop says HIGH and the second flip-flop says "I dunno," what happens to your circuit?

Majority voting has often been proposed as a work-around for metastability. I've yet to see such a scheme that works.

There's really only one way to reduce the probability that metastibility will upset your system: wait.

Bob Perlman Cambrian Design Works

Phil,

I stand corrected,

Thanks.

It was late last night ...

Aust> >

Well it turns out I needed to be corrected by Phil Hays. He is correct that if the shift register is mapped to an SRL16 then you can be in deep doo doo for constraints that expected FFs.

While making corrections to late night typing, please note that in my posting, the following:

should be:

"Both are correct. Paul's circuit is a shift register (2 bits) and it is logically indistinguishable from a two stage synchronizer."

Since Phil Hays points out the mapping problem of a shift register being mapped to the

"not as wonderful as real flip flops for building synchronizers"

SRL16s, then the 2 stage synchronizer, which are indestinguishable from a 2 bit shift registers will also face this problem.

In my code I avoid all this by directly instantiating the FFs, and then it is easy to attach placement constraints and timing constraints.

In another posting by Phil Hays, he gives examples of such constraints

Depending on the synthesizer, these can fail if it renames the signals. Also these only work if they are at the top of the hierarchy. Finding their correct name when the FFs are inferred can be tricky, since changes elsewhere in your code can cause the names to change. I believe that instantiation is justified for the specific case of building synchronizers.

Philip Freidin

=================== Philip Freidin snipped-for-privacy@fpga-faq.org Host for

...

...

...

Not a good solution.

This would actually increase the likelyhood of failure without decreasing worse case delay. Instead of a full cycle of delay for the input register(s) to settle, you only allow a half a cycle worse case, minus the delay of your comparitor. Thus the register after the comparison logic is far more likely to have a bogus signal (improper level or set-up time) as its input. Better to just use a full clock cycle (when sufficiently slow for registers which have been properly characterized by the technology vendor) between registers with no fan out or significant routing delay between them.

Or, *if* the technology is fast enough for a half clock cycle of flip-flop resolution time to easily exceed your desired reliability level (after subtracting maximum clock jitter and worse case duty cycle asymmetry, etc.), then if you need a faster response, you might consider using just a half clock delay without any gating (comparison logic, etc.). But this is riskier because of the larger number of factors which could cut into you timing margin.

IMHO. YMMV.

--
rhn A.T nicholson d.O.t C-o-M

Thanks for this, Phil. My code actually synthesizes to a 3-bit shift register (two for ss plus one for the output). This was implemented in a SRL16 and I was wondering if that "broke" the synchronizer.

If I specify two flip-flops it doesn't use an SRL16.

I'm still learning and I'm not familiar with the whens and whys of contraints, so this is an excellent example for me.

Thanks again.

Regards, Paul.

Paul,

The SR16 is not a chain of master slave flip flops, so their metastability resolution is not going to very good at all. In fact, they may be exactly the wrong choice to use as asynchronous signal synchronizers!

The SRL16 is more like a charge transfer chain with two clock phases internally (bucket brigade). That would make it preserve a metastable state through all 16 stages.....(as it transferred from one stage to the next).

Aust> Phil Hays wrote:

A general question:

Synchronizers seem to be a basic building block, whether you have external signals to sample or internal clock domains to cross. Yet to use them seems to require careful constraint specification.

I wonder if it would make sense for there to be a language construct to describe a sychronizer such that the tools would just do right thing(TM) without having to get into these tricky details?

Or maybe for experienced engineer these details aren't tricky?

Regards, Paul.

If you re-write the code to use these attributes, you will likely get what you want out of the synchronization circuit:

module test(input clk, input in_sig, output reg out_sig);

(* ASYNC_REG="TRUE", SHIFT_EXTRACT="NO", RLOC="X0Y0" *) reg [1:0] ss;

always @(posedge clk) begin out_sig >>

(first a modification) lets change this:

to this instead:

1.) At least one of the flip-flops are always correct.

2.) If one of the flip-flop outputs are metastable then the OR-gate says

1 or 0 (if one of it's inputs is metastabel).

And remember this can only happen around the rising or falling edge of the

1.8 MHz signal, so by doing this OR-thing we can get the correct bit-value the first sample time or at the following sample time.

For my design it doesn't matter if I get the right bit-value shifted 1 more clk in the 24 MHz clock domain.

I presume that the OR-gate always deliver a valid 0 (VoutVOH) when one of it's inputs is a valid 0 or 1 and the other is undefined (between VIH and VIL). But i'm not sure of this behavior maybe some one can reply on this?

What I mean is that I want to be sure that the OR-gate in the FPGA has the following truth table:

A B | Q

----+---

0 X | 0 or 1

X 0 | 0 or 1

X 1 | 1

1 X | 1

1 1 | 1

(Where X means metastable, logical 0 or a logical 1)

Then my circuit will work.

Hi Bill, Sorry, but your circuit is not good. In fact it wastes some FFs and logic to make the metastability performance worse by many orders of magnitude. The time from b to q in your circuit is half a 24MHz clock period. The OR gate eats up some of this time. This is much better:-

process(clk_24M) begin if rising_edge(clk_24M) then a

This problem is that an OR gate which could do this absolutely reliably would require either infinite gain or infinite propogation delay. Using real components without infinite gain, the OR gate will have an small analog range of input voltages where the gain won't be enough to drive the output load to either a "1" or "0" in only a few nanoseconds. In fact, since an OR gate does not have internal positive feedback as does the preceeding flip-flop, it may actually slow down the resolution of any metastable transition states.

It's usually better to omit the OR gate and thus provide more settling time into the next register.

I wouldn't doubt that if you could build a fast infinite gain OR gate, you could also use it, not only to design synchronizers, but to design perpetual motion machines.

IMHO. YMMV.

--
rhn A.T nicholson d.O.t C-o-M

: Peter, as I have said before, fast and slow metastability recovery is relative. You very much can still be bitten by metastability in modern FPGAs. Yes the resolution time is decreasing, but so are the clock cycle times.

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

I agree 100%, but remember, the original posting mentioned 1.6 and 24 MHz. It is hard to imagine that metastabilty would cause any trouble in such a system, especially when the routing delay from the single synchronizing flip-flop to it single second synchronizer is kept under control, guaranteeing 5 or more ns of slack.(Which is very easy, just change the time spec). If the original posting had mentioned hundreds of MHz, this thread would have run very differently. Peter Alfke

Thank you, i will do it like you wrote :-)

"Symon" skrev i meddelandet news:434649c7$0$49021$ snipped-for-privacy@news.sunsite.dk...

to

To avoid metastability problems, we use such a median filter. Depending on the input signal rising time (d could be an input pad), the length of the filter is sometimes increased to 5 or 7. In theses cases, we use of a variant of it that we call a recursive median filter in which the output is changed only if we receive a given number of consecutive sample w/ the same value. It reduces latency before taking a decision by 2. It helps if you use handshaking between 2 non-correlated synchronous clock domains w/ relatively close clock frequencies.

BTW, what a complicated style for a median filter which use 2 more DFFs than necessary. Why not:

PROCESS(clk_24M) VARIABLE a : STD_LOGIC := '0'; VARIABLE b : STD_LOGIC := '0'; VARIABLE c : STD_LOGIC := '0'; BEGIN IF RISING_EDGE(clk_24M) THEN c := b; b := a; a := d; q

Eric, With tongue in cheek! ;-)

What a complicated style for a retimer circuit which uses 1 more DFF and one more LUT than necessary. Why not:

PROCESS(clk_24M) BEGIN IF RISING_EDGE(clk_24M) THEN a

The popular misconception is that the output of a metastable latch or flip-flop somehow indicates that it is metastable. Not true. The metastable output (usually) has a perfectly valid level, 0 or 1 (and either one is as acceptable as the other, since the decision was obviously ambiguous.) The trouble is that this "proper" output can spontaneously change state at a completely unpredictable, non-deterministic moment. So you can get a state change that occurs at an unpredictable, non-synchronous moment, and that is what defies any attempt at a "solution". We can only say that any such bad transition occuring more than x ns after the last clock edge is very unlikely. And for modern CMOS latches and flip-flops, it will be a million times less likely if we can wait one additional nanosecond, i.e. (x+1) ns. See XAPP094. For practical circuits and frequencies x=3, or make it 4 if you are a pessimist.

Peter Alfke, Xilinx Applications