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.
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
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
Thanks for the reply! I'm actually planning to go more into details about Setup and Hold time and Metastability so I appreciate this comment. I will be more precise if I go into details about it, but you're right I did gloss over the specifics.
Actually, this video had super precise timing. I coincidentally had a lecture on this topic right after watching this video. It was super useful. When you say, "The explanations in the video are imprecise" and point out what is ignored, you sound frustrated. These are educational videos for learners. Please keep your comments clean and make statements that add educational value.
I wish Russel had made this back in the summer of 2014 when a project I was on failed for just this reason. 99% reliable is just not good enough for customers.
@@greenavos What did you have a lecture after watching this video? Could you tell me what it was because I'm still confused like you did.. please let me know! Thank you
I didn't get the part where having two sequential FFs driven by the same clock would eliminate metastability. I hope I'll find the video that goes into the details.
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...
Good idea! Thanks! This would require writing two timing constraints, one for each direction, but it's a good solution for writing robust portable code.
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
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: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.
@@brad8122 a single flop on the w_Stretched signal in 100 MHz domain would be exactly what is needed. like this: process(i_Clk_100MHz) begin if rising_edge(i_Clk_100MHz) then w_Stretched_1
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.
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?
Hi, One question on 2 flop synchronizer, the settling of metastability causes latency issue at the recever side, as for a signal changing from 0->1 at flop1 might settle to 1 or 0 before getting sampled by flop2, but will settle to value 1 in next clock So if it is settle in first clock the latency is 2 else the latency will be 3 How to update design to make this latency a fix value
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.
It fixes metastability but it adds the issue of consistency. That’s why the shown approach with double-sampling the std_logic_vector is a no-solution. I wish him happy debugging of bugs introduced like that!
Hello! I have an interview question, that I could not answer. There is high speed data coming in the fpga, how do you make sure all 8 bits are arriving at the same time?
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
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....
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
No, I don't believe so. Although, the order doesn't really matter because everything happens at the same time, or the same clock cycle, but it should still be kept the way nandland showed it for human readability sake. The signal w_Stretched is coming in from outside the process and we want to ensure anything else in that process uses r_Stable, because it's stable, therefore keeping the human readability - top to bottom, logically sound.
Jump to, let's say 8:46, pause and watch closely stretched 100MHz clock domain pulse. You see that pulse's rising edge is at the second rising edge of the 100MHz clock (on this diagram). Now, count rising edges of that 100MHz clock, starting from the edge at which pulse edge is there as well. You see if you make the counter count to 4 pulse gets low somewhere on the middle of logic one of the second 25MHz cycle -- not going to catch the pulse in slow domain! If you make the counter count to 5, pulse goes low on falling edge of second cycle in 25MHz domain. Similar goes for 6 and 7, pulse isn't high on rising oedge in the slow domain. Only 8 cycles long pulse in 100MHz will stretch over 2 cycles in 25MHz and thats enough to catch the pulse at least once. I hope I was clear enough.
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.
Hm... can you elaborate a bit more on this? I'm not sure I completely understand. Is the pair of data sending the same data on 2 clock cycles in a row or are you expanding the number of data paths? Also how does this handle the fact that the two clocks will "walk" in time among eachother?
For example, if the 50MHz side is putting a 4-bit word in the FIFO every cycle, then the 33MHz side can't keep up if it reads 4 bits per cycle from the FIFO. Instead, the 50MHz side could hold even words in a holding register, and every odd cycle it could take that registered word, combine it with the current word, and insert an 8-bit value into the FIFO. The insert rate on the 50MHz side would be 25MHz.
Yes this is a good point. Thanks for bringing it to my attention. I usually don't think to change the width of the data but there's no reason that you couldn't do that!
Doug Gale this works, but the sticky part of clock domain crossing is phase relationship, not frequency relationship. This still leaves you with some problems to solve :)
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.)
Hm, interesting, I've never done it that way. I can't say for certain if it's bad. In general I use the rule of thumb that you should never use an async signal in your FPGA unless it's going to an async reset input on a FF. It's only 1 extra register to look for the rising edge.
True. I think I may have had issues with projects before that checked the original async signal before being registered, so I guess at least two flops is preferred. The only thing with adding too many flops is if the faster clock isn't too much higher than the slow clock, and there will be a bit of a clock delay. That may or may not matter in the specific design though, of course. ;) I still find FPGAs confusing though, as a lot of stuff has a delay of one clock. ie. you assign a value to a reg on one clock, but it doesn't update the output signal until the NEXT clock etc. That can be tricky with things like reading from an SRAM etc. Where you have to assert the /Output Enable on the first clock, then grab the data on the next clock.
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
I used visio to draw some of the basic elements. I made my own shapes, I didn't find any stencils that I liked. There's probably a better solution though.
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?
Are you crossing clock domains? Are the clocks in-phase or out of phase? If they're out of phase, you can't guarantee that the timing relationships will be maintained. The clocks will drift in time from each other.
You will never get a latch generated in a clocked (sequential) process. Since it's in a clocked process, the tools will push this logic into a Flip-Flop, not a latch. This is one reason why I like to use clocked processes as much as possible. (Avoiding latches, latches are evil)
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.
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
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
Thanks for the reply! I'm actually planning to go more into details about Setup and Hold time and Metastability so I appreciate this comment. I will be more precise if I go into details about it, but you're right I did gloss over the specifics.
Actually, this video had super precise timing. I coincidentally had a lecture on this topic right after watching this video. It was super useful. When you say, "The explanations in the video are imprecise" and point out what is ignored, you sound frustrated. These are educational videos for learners. Please keep your comments clean and make statements that add educational value.
I wish Russel had made this back in the summer of 2014 when a project I was on failed for just this reason. 99% reliable is just not good enough for customers.
@@greenavos What did you have a lecture after watching this video? Could you tell me what it was because I'm still confused like you did.. please let me know!
Thank you
I didn't get the part where having two sequential FFs driven by the same clock would eliminate metastability. I hope I'll find the video that goes into the details.
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...
Good idea! Thanks! This would require writing two timing constraints, one for each direction, but it's a good solution for writing robust portable code.
@@Nandland instead of stretching based on Freq .. can you try handshake synchronisation? Please do a video on tht
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
Thank you for this video. Explanation on small things using coding is really helpful.
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.
where to read up on this stuff?
Great video! Lucid explanation. Always gets something to learn. Keep posting.
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.
So another double flop then?
process(100MHz)
registerIT
@@brad8122 a single flop on the w_Stretched signal in 100 MHz domain would be exactly what is needed.
like this:
process(i_Clk_100MHz)
begin
if rising_edge(i_Clk_100MHz) then
w_Stretched_1
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.
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?
Hi,
One question on 2 flop synchronizer, the settling of metastability causes latency issue at the recever side, as for a signal changing from 0->1 at flop1 might settle to 1 or 0 before getting sampled by flop2, but will settle to value 1 in next clock
So if it is settle in first clock the latency is 2 else the latency will be 3
How to update design to make this latency a fix value
Very intuitive explanation thank you !
Stretching 8 time would be overkilled? I think (Fast/Slow)+1 would be good enough.
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 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.
It fixes metastability but it adds the issue of consistency. That’s why the shown approach with double-sampling the std_logic_vector is a no-solution. I wish him happy debugging of bugs introduced like that!
Hello! I have an interview question, that I could not answer.
There is high speed data coming in the fpga, how do you make sure all 8 bits are arriving at the same time?
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
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.?
What if the source and destination clock frequencies are the same but the phase relationship is unknown?
Can you make a video about how to add timing constraint to a design sometime soon please?
Good suggestion! Added to my to do list.
excellent video, explained very clear.
In fast to slow example, from where we receive i_pulse_fast?
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
No, I don't believe so. Although, the order doesn't really matter because everything happens at the same time, or the same clock cycle, but it should still be kept the way nandland showed it for human readability sake. The signal w_Stretched is coming in from outside the process and we want to ensure anything else in that process uses r_Stable, because it's stable, therefore keeping the human readability - top to bottom, logically sound.
thanks from russia fow great content. Very helpful.
If I wanted to test bench this code, where would I get it?
if sending and receiving frequency are equal and different phase shift means?
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?
Jump to, let's say 8:46, pause and watch closely stretched 100MHz clock domain pulse. You see that pulse's rising edge is at the second rising edge of the 100MHz clock (on this diagram). Now, count rising edges of that 100MHz clock, starting from the edge at which pulse edge is there as well. You see if you make the counter count to 4 pulse gets low somewhere on the middle of logic one of the second 25MHz cycle -- not going to catch the pulse in slow domain! If you make the counter count to 5, pulse goes low on falling edge of second cycle in 25MHz domain. Similar goes for 6 and 7, pulse isn't high on rising oedge in the slow domain. Only 8 cycles long pulse in 100MHz will stretch over 2 cycles in 25MHz and thats enough to catch the pulse at least once. I hope I was clear enough.
Thank you !
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.
Hm... can you elaborate a bit more on this? I'm not sure I completely understand. Is the pair of data sending the same data on 2 clock cycles in a row or are you expanding the number of data paths? Also how does this handle the fact that the two clocks will "walk" in time among eachother?
For example, if the 50MHz side is putting a 4-bit word in the FIFO every cycle, then the 33MHz side can't keep up if it reads 4 bits per cycle from the FIFO. Instead, the 50MHz side could hold even words in a holding register, and every odd cycle it could take that registered word, combine it with the current word, and insert an 8-bit value into the FIFO. The insert rate on the 50MHz side would be 25MHz.
Yes this is a good point. Thanks for bringing it to my attention. I usually don't think to change the width of the data but there's no reason that you couldn't do that!
Doug Gale this works, but the sticky part of clock domain crossing is phase relationship, not frequency relationship. This still leaves you with some problems to solve :)
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.)
Hm, interesting, I've never done it that way. I can't say for certain if it's bad. In general I use the rule of thumb that you should never use an async signal in your FPGA unless it's going to an async reset input on a FF. It's only 1 extra register to look for the rising edge.
True.
I think I may have had issues with projects before that checked the original async signal before being registered, so I guess at least two flops is preferred.
The only thing with adding too many flops is if the faster clock isn't too much higher than the slow clock, and there will be a bit of a clock delay.
That may or may not matter in the specific design though, of course. ;)
I still find FPGAs confusing though, as a lot of stuff has a delay of one clock. ie. you assign a value to a reg on one clock, but it doesn't update the output signal until the NEXT clock etc.
That can be tricky with things like reading from an SRAM etc. Where you have to assert the /Output Enable on the first clock, then grab the data on the next clock.
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
I used visio to draw some of the basic elements. I made my own shapes, I didn't find any stencils that I liked. There's probably a better solution though.
nandland thanks. Are your shapes /designs online (as vsdx file) by chance?
Hm, no, maybe I could add them somewhere.
is Asynchronous counter.....Synchronous sequential circuit???
No one ever answered me this question.......
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?
Are you crossing clock domains? Are the clocks in-phase or out of phase? If they're out of phase, you can't guarantee that the timing relationships will be maintained. The clocks will drift in time from each other.
10:55 is there a latch for the 100MHz block (r_Count = 0)?
You will never get a latch generated in a clocked (sequential) process. Since it's in a clocked process, the tools will push this logic into a Flip-Flop, not a latch. This is one reason why I like to use clocked processes as much as possible. (Avoiding latches, latches are evil)
can you please provide codes in verilog language