It's funny that you've posted a video about timing errors exactly as I was fixing one in my design :) I've found this snippet of SV code somewhere for crossing domains which I find kind of neat, and that's what I always use: bit [2:0] buf; always_ff @(posedge clk) buf

Oh, and I've forgot to mention that Xilinx has a bunch of macros designed specifically to deal with cross-clock syncronization issues - they are xmp_cdc_[array_single | async_rst | gray | handshake | pulse | single | sync_rst], described in UG953 - "Vivado Design Suite 7 Series FPGA and Zynq-7000 All Programmable SoC Libraries Guide", chapter 2.

Great video! Lucid explanation. Always gets something to learn. Keep posting.

Thank you for this video. Explanation on small things using coding is really helpful.

Just what I needed right now. ;) I've had to use registers for async handshake signals on a RAM controller before, and that was fairly hard to debug. I've also been messing with differing video timings recently, where a device (an N64) is using a pixel clock of ~12.5 MHz, and the actual output pixel clock is 27MHz (480p), so I had to use dual-port RAMs for the line buffers. The metastable stuff is weird, because they can calc the exact "MTBF", but it's usually in the range of a few million years. lol

Awesome video! You don't have to know the clock frequencies of the fast and the slow clocks to go from a fast clock to a slow clock. You can use feedback from the slow clock to the fast clock for the pulse stretch. Once the slow clock logic "sees" the pulse, it can signal to the fast clock logic to stop stretching...

The explanations about metastability in the video are imprecise. Metastability refers to a state of unbounded time during which it is unknown which state will be adopted by the system eventually. During that (unbounded!) time the output of the system (e.g. FF) is undefined and might even oscillate. Also, not *every* setup or hold time violation will lead to metastability (it is actually rather rare and it is not that easy to actually provoke it to happen and make it visible in real hardware). However, even without Metastability, setup and hold violations are a problem because the FF might simply not capture the correct state at the right time even though its internal state (and output) is not metastable. *This* is the common reason that leads to problems when crossing clock domain boundaries (which often happens unknowingly) but is indistinguishable from short metastabilities anyway (shorter than the clock period). Also, by no means does using 2 FFs eradicate the possibility of metastability on the second output completely. It is mentioned briefly in the video but is largely ignored (in the video by describing the output of the first FF as metastable (which it is not necessarily but you have to treat it that way) and the 2nd FF as stable (which it isnt absolutely always but we treat it that way anyway). Cf. en.wikipedia.org/wiki/Metastability_in_electronics

Very intuitive explanation thank you !

excellent video, explained very clear.

Hi Russel, Could you tell me what r1,r2,r3_data correspond to in the slow to fast domain diagram? I got confused coz of your in-code comments on metastability. it said r1 is metastable, but the output from the second register is the one showing metastability in the diagram. So, could you please explain which notation corresponds to what in the diagram

For a slow clock that updates a register, I can see how logic clocked with a fast clock could see data in flux.. and so passing it through a few dffs makes sense.. however, regarding the pulse stretching in the case of fast to slow... what if you're not dealing with pulses, i.e. the fast clock is updating data and it remains constant until updated again.. would the slow clock logic that acts on that data need to do anything?

Thank you very much.

Thank you !

thanks from russia fow great content. Very helpful.

thank you for the quick explanation. I was able to fix the emulation of a 3.6 MHz Z80 computer with a 10.7 MHz video controller. Previously I had to run the video at an integer multiple of the CPU clock. Still I don't get why on "real" computers there is no cross-clock domain.

hi, nice explanation. i have one doubt. A clock 100 Mhz and B clock domain 10 Mhz,(fast to slow). how can cross this with out using stretching or fifo

Thank you for posting these videos - I’m learning Verilog with the help of your videos. Looking at the VHDL code at 11:33 are the last two statements swapped? E.g. r_Stable

What are the timing constraints and how are they used to get the place and route score to zero? Also, what is the interpretation of a non-zero P&R score? My thanks in advance....

What are some examples of how I would "APPLY" clock domain crossing techniques.? Are there any modules where I could practice this technique.?

Is it not really robust enough to just use a single flop, then use the incoming async signal to directly check against the flop for a rising or falling edge? I usually just use two flops, then use a combinatorial (wire assign) to check for falling / rising, and it normally works fine? (usually when sampling an async /WRITE signal from an IDE interface, when the FPGA clock is around 50MHz, for example.)

Awesome channel. Wondering what people use to draw this kind of schematic diagram? Visio with some specific stencils for flip flops, registers,... ? Inkscape? Thanks in advance

If I have corrected the timing errors for setup and hold time on first flip flop. Why do we still require second flip fllop? If setup and hold aren't violating at first flip, we won't face metastable problem. I know double flip flop synchronizer is standard way to synchronize a pulse signal. Can you tell me if I m correct or not?

10:35 It's incorrect to directly pass a combinatorial w_Stretched signal into the i_Clk_25MHz domain, because this signal will exhibit glitchs on every r_Counter transition. First you should register this signal by i_Clk_100MHz to make it clean, free of glitches, and then pass this clean version of the signal into the i_Clk_25MHz process.

What if the source and destination clock frequencies are the same but the phase relationship is unknown?

Thank you for the video but I do not think that double buffering fixes the metastability issues for bus signals. It should be FIFOs advised for bus interfaces.

Can you please explain the worst case scenario for why you used rcount as 8? Can't we use anything greater than 4clock cycles of 100MHz clk?

This video is a good start but gets quite some things wrong. 1. Don’t (just) double-sample bus signals, like the std_logic_vector. Either use a proper FIFO or transfer its change by a single wire 2. Use toggle indication instead of transferring pulses. This avoids pulse stretching and allows a higher event indication rate before going full cycle (request-acknowledge) handshake 3. Consider a full-cycle request-acknowledge handshake (with toggle indication). This way the sending clock domain can feed back the event transfer to the sender 4. Only transfer a signal to the other clock domain that is output of a stable flip-flop. No logic, e.g., w_Stretched 5. Always consider the rate of events, not just with a FIFO, with the actual clock rates. Can you afford losing an event? Do you need to count them while the CDC transfer is busy? 6. Keeping setup/hold is not just fighting metastability but ensuring the FF does all of its jobs correctly. The actual window of a FF for entering MS is typically just a few femtoseconds wide, but you don’t know which part of the setup/hold margin 7. Proper RTL design is necessary but don’t forget constraints! Especially ensure that the second sampling stage r_Stable is never split into multiple registers 8. FFs spent properly on CC are well invested. Always.

10:55 is there a latch for the 100MHz block (r_Count = 0)?

If I wanted to test bench this code, where would I get it?

Can you make a video about how to add timing constraint to a design sometime soon please?

if sending and receiving frequency are equal and different phase shift means?

In fast to slow example, from where we receive i_pulse_fast?

Stretching 8 time would be overkilled? I think (Fast/Slow)+1 would be good enough.

can you please provide codes in verilog language

You didn't seem to mention the most obvious solution to handling data going from a 50MHz domain to a 33MHz domain: simply make pairs of data from the 50MHz side and enqueue a double-width item at every odd clock. The 33MHz side will be fetching 2x width, effectively 66MHz worth of data.

is Asynchronous counter.....Synchronous sequential circuit??? No one ever answered me this question.......