clock wide pulse transfer b/w clock domains

1. Stretch the pulse in the fast clock domain so that it is guaranteed to be long enough to capture in the slow domain.

2a. If the two domains are *synchronous* (derived from a common clock source), just put a capture flop in the slow clock domain. You're done. 2b. If the two domains are asynchronous, put a synchronizer (a chain of flip-flops with as much slack time as possible) followed by a strobe generator in the slow clock domain.

-hpa

And perhaps the more important potential homework question: why would you want to do this? Hint: the real world is generally asynchronous, and one needs to synchronize to external events.

JTW

Pardon my initial response; however, the question is one that you could expect in a digital logic class, or perhaps in an interview.

With a simple google on "pulse clock domain crossing", I come up with this article in EDN a few years back:

JTW

General rule of thumb is that you want 2 registers to cross between clock domains, follow that rule to deal with any metastability issues. Now you just have the problem that your first clock domain is faster and you might not catch it with the slower domain.

Personally, my approach here would be to "hold" the signal in your CLK_FAST with an enabled register until you receive some sort of feed back that you've grabbed it in CLK_SLOW, bearing in mind that those feedback / feedforward signals should all be double registered to prevent metastability. Also keep in mind that an enabled register does NOT count as one of your two "synchronization" registers, because an enabled register is actually implemented as a register with a mux in front of it - only direct D-to-Q connections with NO combinational logic count for clock domain crossing issues. Now, depending upon the timing of it all, this could end you up with more than 1 clock pulse width. Assuming that you know your input pulses are spaced far enough apart that you KNOW it's not ACTUALLY multiple pulses, then a simple edge detect will fix this problem for ya.

The ideal beh> Hi,

Maybe this is a homework question, but I took it as a challenge.

I can solve it with one 4-input LUT driving a flip-flop, clocked in the slow domain. The LUT inputs are: the incoming pulse, the slow clock, the LUT output, and the flip-flop output.

What happens with metastability? If the ris> General rule of thumb is that you want 2 registers to cross between

Maybe this is homework, or it is an interview question, but I took it as a challenge. Being a minimalist, and understanding metastability fairly well, I came up with the following solution:

Only one 4-input LUT plus a flip-flop clocked by the slow clock. LUT inputs are: INput pulse, slow CLK signal, its own output O, the flip-flop output Q ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep O. O drives flip-flop D)

Ah, but how about metastability? If IN and CLK both go High within a certain bulls-eye that is General rule of thumb is that you want 2 registers to cross between

Nice - although this pre-supposes that the source clock domain is faster than the destination clock domain. So the next exercise is to generalise the circuit to cope with any arbitrary clock ratio. :-)

I've found this sort of circuit useful when a circuit in one clock domain needs to tell a circuit in another clock domain to start (or stop) doing something, but only infrequently. For example, the pixel-generating portion of a video circuit might want to inform the frame-buffer reader of the start and end of a line or a frame. In such a situation, asynchronous FIFOs and complicated synchronization logic are usually overkill.

-Ben-

Peter,

I know you folks at Xilinx like to claim that you've permanently solved all the world's metastability problems, our xilinx fae tells us the same things.... And maybe you're right for telecom applications and whatnot. But I hope you don't support many Hi-rel applications because I promise you, no defense or aerospace company is going to happy being told they don't need to double register asynchronous signals. Our design guidelines here at unstated defense company (sorry, i dont disclose that on the net) are VERY strict about double registering ALL asynchronous signals, no questions asked. 2 D-Q crossings and nothing else. Right or wrong, I haven't been in the business long enough to know for sure, we view metastability as a statistical thing...and like most naturally occurring statistics, zero probability tends to never exist, very very very small near zero probabilities exist.

At anyrate... yes, I'm well aware of Xilinx's current stand on the metastability problem. But you yourself just said that the problem exists for "a few ns" statistically exceeding 3ns once in a universe. So lets say 2 ns is something we should design for then.... 2ns =

500MHz.... What's Xilinx's Fmax these days??? Even if its not a problem now, it's soon to become a problem again unless you're going to tell me you're done increasing your operating frequencies.

anywho... our view and i believe the view of most of the defense/ aerospace world is that something as simple as 2 registers is not worth ANY impact on system reliability.

Why not use three registers to make the probability of failure even less? How about 4?

When the metastability window is in the sub-femtosecond range, the probabilities of hitting the window get very small. The double register will reduce the probability significantly. But it's already an extremely small probability.

If you *do* hit the metastability window, having timing margin to support the extra metastability delay by applying constraints will guarantee all paths get the correct value except for once every... what is it? Several billion years?

If you're running at speeds such that the timing path cannot be reduced then yes - having the second register guarantees every register downstream gets the same value. Even if the metastability time is longer than the clock period, the possibility of hitting the metastability window in that second register is almost negligible. Almost. But there's always a chance.

If you're running a 100 MHz design, you may be able to afford an 8ns cycle for your synchronized input from a single flop to the remaining logic. It may not be practical in that 100 MHz system to wat an extra clock cycle for every toggle of the asynchronous signal. If it's fine to delay an extra clock cycle, the reduced timing constraint burden is a good thing to have. For designs that push the devices' top speeds, the 2 ns difference may not be acceptable. But not everyone is designing at 500 MHz and can accommodate an extra clock cycle.

I call this kind of decision-making "engineering."

- John_H

Paul, you don't have to teach me about the dangers of metastability. I am the one who has performed lots of quantitative measurements. But I am also fighting any un-qualified paranoia.

In this particular design I pointed out that the effect of metastability is an uncontrollable statistical delay on the output of the flip-flop that, per description, is clocked by the "slow clock". I wrote that the "slow clock" domain probably has enough slack to accomodate a few ns of uncontrollable delay at the flip-flop output. "Slow clock" does not mean 500 MHz, in my book.

I know what I am talking about, and I was forthcoming and explicit. This was a specific circuit, no need to bombard me with generalities.

And for the record: Xilinx and I personally have NEVER EVER claimed to have solved the metastability problem. Because we all known that to be impossible. I have just, quite often, quantified the probabilities.

BTW: I c> Peter,

Paul, I would rate Peter as one of the most knowledgable people in the area of metastability, He has published papers and performed experiments characterizing metastability as Xilinx products have evolved. I think you have to take the comment within the context of what he was explaining, that the circuit could be done with one LUT and one FF. As to whether it is worth the trouble of arguing and guaranteeing that there is enough slack time to all the other FF's is another story, and adding another stage may be the most expedient method. He did mention it, and it is probably the way to go for those of us less knowledgable in this area.

- Newman

Aha, the common spotted "that's the way we've always done it"! Guess what, you should do the maths to work out if you can use 1,2 or maybe more FFs as the technology changes rather than relying on what's gone before! Cheers, Syms. p.s. Here's a tip for the top, if want your unstated defense company employer to stay undisclosed on this, ahem, 'NG', you might consider not posting from work. Bless!

use the pulse in one domain to toggle a semaphore each time the pulse occurs. Synchronize that semaphore across the clock domain boundary, then synchronously edge detect it in the second domain.

process(clk1) begin if rising_edge(clk1) then if pulse1='1' then toggle