Clock boundary crossing

What are the different ways of crossing clock boundaries. Is there any website with good information on that. Thanks Amish

Reply to
axr0284
Loading thread data ...

You might look at an article I published years ago... Peter Alfke

formatting link

Reply to
Peter Alfke

Although a little dated, I've found this 10 Commandments of Excellent Design article useful.

formatting link

Reply to
kkoorndyk

It's actually pretty good, but I'm in a nit-picking mood, so here goes...

On page 10:

Where can I buy one? :)

Why does that rumor/myth keep propagating?

If you understand metastability, it is (or was) a pretty good way to get a quick calibration on a text book. Look in the index. If there is something there, read that section. Does it match what you know? Would you get the idea from reading the text if you didn't alread know the answer?

On page 14:

Gated clocks have similar problems. The gate can't glitch while the clock is active.

This is really just more setup/hold times. The quirk is that the must-be-stable time is much larger than people are used to thinking about for the Q input to simple FFs.

Tools should get this right. If they don't, users should scream.

On page 15, he discusses clock skew and a pair of FFs connected with no logic. His suggested fix is a delay between the FFs.

The important point is that hold time has to cover clock skew.

Again, vendors with buggy tools deserve a lot of bad PR and users should give it to them.

Some systems (tools plus silicon) work on a 0-hold time basis so they don't have to worry about hold time. (It saves 1/2 the computing when the tools are checking setup/hold.) But that has to cover clock skew.

The nasty case that I know of is "skew" from two different outputs of the same DCM. Do the Xilinx tools cover that yet?

Page 17:

...

Somebody asked about this recently.

--
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

Also, "Fourteen Ways to Fool Your Synchronizer" is a reasonable paper

formatting link

-Doug

Reply to
Douglas

I think I understand metastability.

Several/many years ago, I used to use it as a calibration on books. Look in the index under metastability or synchronizer. If you don't find anything you know either the book doesn't cover it or the index is poor. It's hard to imagine a text on digital logic that doesn't mention metastability. Who wants a book with a crappy index?

If you do find something, see if it matches your understanding.

The paper is probably better than average,, but that's relative to a field full of bogus/useless papers. If you don't already understand metastability, it doesn't do a very good job of explaining it. If you do understand it, it has a few patterns that might be good to add to your list.

The real estate people joke about the 3 most important things being location, location, and location. Well, in metastability, the 3 most important things are settling time, settling time time, and settling time.

Assuming you believe in settling time, here are my comments on the paper.

0) Section 2, A Correct Two Flop Synchronizer

It gives the classic MTBF formula. It doesn't mention that the data is hard to get. I haven't seen any data other than lab typicals. Has anybody seen any numbers on VCC or Temp or process? Has anybody seen anything in a data sheet? (as compared to an app-note)

It also doesn't even hint that you might want to be extra conservative if your design is used in safety critical equipment (as compared to a lab hack to collect some data from a one-shot experiment) or if your design will be used in a bazillion systems with good software where a hardware glitch will generate a core dump that the software guys get to pour over.

1) Section 3.2, the One Flop Synchronizer...

This can actually be good enough. Suppose you have a system with the classical 2 FF synchronizer that works OK at 100 MHz. The best case settling time is 10 ns. (That's ignoring clock-to-out, routing, and setup times.) Suppose you run that system at 50 MHz but remove the first FF. The big ugly cloud of gates in the FSM picture is good enough to run at 10 ns but your system clock is 20 ns, so you have a guaranteed 10 ns of settling time. That was more than good enough in the 2 FF case. Why isn't it good enough in the one FF case?

2) They missed another important case - routing delays.

Just because your 2 FFs are right next to each other on the schematic or source code doesn't meant the placement tools will put them next to each other on the chip. If your FFs are far apart, the routing delays can eat up a lot of the cycle time leaving not much left for settling time.

3) Section 3.11, Metastability Blocker

Kludges like this are a good sanity check. There are two reasons to run away when you see one.

First, they are (often) hard to analyze. With the classic 2 FF case you have a good chance of understanding things. You can use the standard formula to estimate MTBF and vendors sometimes publish data to plug into the formula. With a kludge, you have to read all the fine print on the data sheets until you find the catch. One of the classic examples put a runt pulse on the reset to a FF. Please let me know if you find any data to back that up.

The second reason is that kludges eat up prop time, thus reducing settling time. Settling time is exponential. That's much better than the constant factor from a kludge. (If you find one that works, please let me know.)

I can't figure out how that example is supposed to work. The S/R FF gets reset by RESET. It gets set if the mux lets a 1 through. Maybe the S/R FF should get reset by clock low, or something like that. In any case, it only leaves a half cycle of settling time. (assuming 50-50 clocking.)

--
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

I use at least two anyway to rule out duplication of the synchronizing register by synthesis (which could eliminate the synchronization effect).

I could do the same thing with constraints, but these do not always follow the source code around.

-- Mike Treseler

Reply to
Mike Treseler

Two good points. Thanks.

What keeps the system from duplicating a pair of FFs? (Isn't it great that FPGAs have so many FFs? :)

Has anybody worked on putting constraints in the source code? Maybe stylized comments with a script to extract them would work.

Assuming you could say what you wanted. What would that be? 1) Don't duplicate this FF. 2) I need at least N ns of slack time on this signal.

Or would it be better to just mark the FF as a synchronizer and let the script fill in the details. You probably need something like that anyway to avoid errors from clock boundary crossings.

--
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

A pessimist would complain about paying for all those FF's he can't use :-)

Alan Nishioka

Reply to
Alan Nishioka

I have mentioned that previously in discussions on doing asynchronous (self timed) logic in FPGAs. There is then no use for FFs.

-- glen

Reply to
glen herrmannsfeldt

Synthesis might use register duplication to improve routing or fanout. The middle node of a two flop shifter has no such issues.

-- Mike Treseler

Reply to
Mike Treseler

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.