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

formatting link

Reply to
James823
Loading thread data ...

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.

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

Reply to
glen herrmannsfeldt

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

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

Yes.

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

Cheers, Jon

Reply to
Jon

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

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 
 Click to see the full signature
Reply to
Mike Perkins

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

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.

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

Reply to
rickman

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

Reply to
KJ

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

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.

Entirely agree, but that's not always possible.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

[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?

domains.

[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

formatting link

Reply to
James823

(snip)

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

Reply to
glen herrmannsfeldt

the

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

formatting link

Reply to
James823

Metastability on modern CMOS processes is a pretty rare event. Supposedly, Xilinx has found that the window for metastability on their FFs is no more than a couple of ps wide! So, unless you have extremely fast data rates or a timing that puts the transition right over the window, it could take years for you to get one true metastable event.

The real logic hazard is for a signal that changes near the clock edge to propagate through the chip in such a way that the transition arrives before the clock at some FFs, and after the clock at some others, either due to routing or combinatorial delays. A simple state machine can be sent to never-never land when this occurs. By properly synchronizing when crossing clock boundaries, you allow the tools to be sure that no signal can change state too close to the setup time and cause such a hazard.

Many people claim such problems were metastability, when they were more prosaic logic hazards.

Jon

Reply to
Jon Elson

This is my view and I open to criticism.

Metastability by itself is easy to either cope with or you can eliminate it's effect. Some thoughts:

A consequence of a changing data input for a latch can cause uncertainty of the latch output, and the worst case scenario is where the output is indeterminate, at non high or low output level, ie at mid-level.

Generally that output will end up either high or low at the end of the same clock period, however there is still a miniscule chance that this will remain at an indeterminate level.

If this output is used by a further latch, depending on setup or hold times the probability of still being indeterminate at this latch output is reduced much further. However if this output is used by a number of latches, then these will have different thresholds, set-up and hold times such that these subsequent latches may occasionally each produce a different result. In this case I generally double latch the signal (or more) before making it available for further circuitry.

However, when it comes to passing data, the real problem isn't so much metastability, but clock skew and varying data routing delays. These are far more likely to corrupt data.

In general, if you consider metastability first, then all else tends falls into place.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

Causes of metastability are different thresholds, different delays, noise and a limited slew rate of signals.

I'm not sure if D-Type flip-flops are such simple affairs in FPGAs, nor how an enable is implemented.

In short each latch has more than one gate driven by the D-input, and within the latch each signal will likely drive more than one gate. Hence metastability is inevitable.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

You aren't seeing the picture. This doesn't solve metastability in any meaningful way. The edge detection logic can still be "glitched" by metastability and disrupt the rest of the circuit.

Easier is just to run the slow clock input through two FFs with no logic between them and getting a metastability minimized signal. Then you can use it as you wish.

When is this not possible? The only limitation would be that the "master" clock to rule them all has to be the fastest by enough margin to accommodate the jitter in the two clocks. This prevents ever missing a transition.

Rick

Reply to
rickman

I don't have the stats memorized, but I don't think this is an accurate description. If you design is truly async then the rate is such that with a number of units in the field you will likely see failures long before the warranty period is up... lol But by providing even as little as two nanoseconds of settling time the probability is hugely reduced so that it would then be years if not centuries between failures for thousands of units.

But this is also related to the significance of a failure. If it is a router handling Internet traffic in a user's home, I think a failure once a month per unit will never be noticed. If it is a more critical application a failure once a decade across the product line might be a problem.

Static timing analysis is typically used to eliminate such timing problems. That is FPGA 101 type stuff. Timing tools can't help you with clock crossings, but they are easy to do if you pay attention and don't miss any... that is the domain of project management.

Yes, the two are sometimes confused.

Rick

Reply to
rickman

I didn't explain myself very well.

The technique I was eluding to (badly) regards noisy and slow inputs (such as from a PS2 mouse) is to have a counter; to count up when the input is high, and to count down when the input is low. The output would only be changed to a "1" if the counter was at maximum and changed to a "0" if the counter was at minimum.

I agree and I said earlier the same about being latched through two FFs.

I was thinking of a modem example I came across where there were two clocks at near FPGA max speed; where each interface could wander in frequency either way. Given it was dealing with packets of data, it was much easier to a Block RAM FIFO to cross clock domains.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

(snip)

Well, how do you check if a signal was high for two clock cycles? Seem to me that you delay it through two FF's and AND them together.

That could ignore real signals that are high for a short enough time, but there really shouldn't be any of those. Doesn't seem a bad thing to do in many cases.

Metastability resolves exponentially. It is pretty much only a problem when the signal goes into logic with a propagation delay a large fraction, maybe 80% or 90% of a clock cycle. In that case, the extra FF multiplies the resolution time by a factor of 5 or 10, which decreases the probability of a problem by a power of 5 to 10.

If it could happen one in 1e9 clock cycles without the extra FF, then it will then be one in 1e45 to 1e90 clock cycles.

A am pretty sure no circuit has ever survives 1e90 clock cycles.

-- glen

Reply to
glen herrmannsfeldt

(snip)

For an asynchronous system, you usually assume that the probability is uniform in time. So a 1GHz clock, with a pulse every ns, will hit your 1ps window on in every 1000 times, about every microsecond.

Well, an important thing left out is the resolution time. You need two numbers, the window size (or probability) of going into a metastable state, and the time constant (it goes into an exponent) on how long you stay in that state. Even if the window is 1ps, if it resolves in

100ps you aren't likely to see it. (You really can't set the clock period less than 90% of the actual delay, though most of that should be included in the specifications.)

Yes. But once it gets into the lifetime of the universe range, it is usually good enough.

Well, you have to have at least on FF on an asynchronous input.

Metastability says you should have two.

That still leaves the problem of multiple inputs. For FIFO's, the solution is to use gray code. You get either the previous or new value of the count, never any other values.

Yes, both the single and multiple input case show up in actual designs.

-- glen

Reply to
glen herrmannsfeldt

OK, this is for decoding the output of a quadrature encoder.

Even if you know the maximum rate, in the mouse case, how fast the mouse could move, if it is sitting right on the edge the outputs can change very often, or even stay between "0" and "1".

The fast clock method works well in that case. Properly designed, only one input can be in a bad state at once, and the output can switch between those values (+1 and -1).

-- glen

Reply to
glen herrmannsfeldt

The article

formatting link
seems to have some pretty good data (actual numbers) on metastability.

-- glen

Reply to
glen herrmannsfeldt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.