What is a ripple clock?

Question

I am reading Chapter 12. Recommended Design Practices from the Quartus II Handbook Version 13.1 Volume 1: Design and Synthesis which states (p. 8):

Ripple counters use cascaded registers, in which the output pin of one register feeds the clock pin of the register in the next stage. This cascading can cause problems because the counter creates a ripple clock at each stage. These ripple clocks must be handled properly during timing analysis, which can be difficult and may require you to make complicated timing assignments in your synthesis and placement and routing tools.

What is a ripple clock? Why is timing analysis difficult on a ripple clock?

score 5 · Answer 1 · answered Jun 19 '14 at 15:53

5

This is a ripple counter:

schematic

^{simulate this circuit – Schematic created using CircuitLab}

It is an asynchronous counter that will divide the input clock by 2 each stage. It is an asynchronous counter because each stage will change at different times and each flip-flop has a different clock input. The time difference between each stage is determined by the CLOCK->Q delay of the flip-flop used. The simulated result is shown below, showing that each stage delays the output transition by the clock-to-output delay.

enter image description here

Now to put the significance of this in perspective of an FPGA, the timing analysis tool wants to make sure everything is getting clocked at the right time. Part of that is make every signal that enters the CLK pin of a flip-flop a system clock that should be synchronized with all the other clocks. As such, if I entered the above schematic into an FPGA synthesis tool, it would consider the nets CLK_IN, DIV_2, DIV_4, and DIV_8 to be "clock" nets regardless of whether they are used to drive any other clocks. This will probably work fine as a counter (there is a possibility for a hold-time violation on each flip-flop), but it's not made in the synchronous logic method.

If you're using this to take a fast input clock and derive a single, slower clock (e.g. make DIV_8 a master clock for the system) then you're probably fine.

The trouble comes in when you want to have fast circuits clocked with CLK_IN interacting with slow circuits clocked with DIV_8. In this case, you want the rising edges of the clock to be synchronized, but you will have a large clock skew between these clock nets. The amount of clock skew generated by one stage could be enough to cause synchronization errors, and more stages will almost guarantee it.

If you want to create two synchronized clocks inside an FPGA, your best bet is to use a synchronous clock generator, or a clock module that is internal to the FPGA, such as a PLL/DCM block.

answered Jun 19 '14 at 15:53

W5VO

18,303
7
63
94

If the count rate on a ripple counter is slower than the master clock rate, I would expect that one could reliably get the value by taking multiple consecutive readings (three unless ripple propagation is very slow). I've not seen many chips expose a ripple counter directly to software, but when using e.g. a fast CPU clock to read a counter that runs at 32,768Hz, having code take readings until it gets two consecutive one that match should be no less reliable than having to use a multi-step sequence to capture the value to a synchronized register and read that. – supercat Jun 19 '14 at 16:11
@supercat The issue isn't that it is *impossible*, just that there is a hazard. You have described valid mitigation strategies, but the static timing analysis tool will not make any assumptions on your signal handling. You can override this behavior by configuring the design, but the intent is for the software to fail "safe". – W5VO Jun 19 '14 at 16:16
Fair enough. In looking at the various requirements chips impose when counting asynchronous signals, I often find myself wondering to what extent design tools are servants of chip designers, and to what extent the designers and their designs are slaves of the tools. I would think, for example, that it would be common for a chip to want to throttle down the CPU speed when not doing much, but be able to ramp it up when serial data arrives that needs to be processed, but relatively few microcontrollers allow the CPU speed to be changed without disrupting UART operations. – supercat Jun 19 '14 at 16:39
I recognize that to avoid metastability, zero-wait-state I/O can only be allowed when the CPU is accessing things which are synchronous to the CPU clock; if one can accept wait states, though, should there be any problem with having an I/O subsystem as though it was connected to the CPU via an old-style asynchronous memory bus? Or is the issue largely that design and simulation tools can't deal with such things very well? – supercat Jun 19 '14 at 16:52
A good alternative that avoids all these problems is to implement slow logic based on the fast clock plus clock enable signals that pulse for one clock cycle per slow interval. – Ben Voigt Jun 19 '14 at 19:36
@BenVoigt: That's good if the fast clock will always exist and be "fast". What I'd like to see would be a peripheral subsystem which derived timing from a clock which was separate from the system clock, could be clocked by the system clock when it was running suitably fast (gated by a once-per-peripheral clock signal), or the peripheral clock itself (when the system clock wasn't usable), and would at all times be within two clock of where it would be if clocked continuously by the peripheral clock. No idea how workable such a thing would be, though. – supercat Jun 19 '14 at 20:28
@supercat: I don't think it's feasible. You can lose a clock cycle every time the clock source switches (because you can't violate the minimum cycle time, you'll have to wait for the following edge), so I don't think that "within two clocks" is attainable long-term. Some FPGA clock-distribution blocks do have fallback clock ability, but without the "within two cycle" guarantee. – Ben Voigt Jun 19 '14 at 20:30
@BenVoigt: Suppose one has a 3-bit graycode counter counts the number of pulses of the 1MHz clock which have occurred since power-up, and a 3-bit graycode counter which counts the number of "active" clocks processed by the logic since startup. When from the 1MHz clock to the 4MHz CPU clock, it's possible that two 1MHz clocks might happen without the peripheral logic being clocked, but on the first two 4Mhz clocks it receives, it should notice that the counters don't match and thus activate peripheral logic on both of them. The effect would be that the first clock after the switch... – supercat Jun 19 '14 at 21:43
...would happen "late", but one could switch clock sources any number of times without a net gain or loss of clock events. Some applications would require peripheral-generated edges to be precise to 1us, but in many applications, 1us of jitter would not represent a problem if jitter represented the only uncertainty in counting. – supercat Jun 19 '14 at 21:46
Guys... this isn't the place to debate clock synchronization techniques. My point (in the answer) is that this is a warning, and there are potential dangers if there are interactions between multiple clock domains. If you have implemented one of these techniques, then you have heeded the "Ripple Clock" warning. – W5VO Jun 19 '14 at 21:49
@supercat: Think about it, every time you switch the clock between two unaligned sources, the interval between edges can't be exact (the clocks aren't aligned) so it has to be too long or too short. Too short violates timing constraints, so you have to lose time on every switch. – Ben Voigt Jun 19 '14 at 21:49

score 4 · Accepted Answer · answered Jun 19 '14 at 15:59

In Quartus II, Ripple clock is any clock driven by the output of another register. Couple of issues with ripple clocks:

The last clock will have a delay than the input clock, because it goes through a number of flops. So what is the problem with this delay? You'll have problem when your design have cross-domain paths between these two clocks. If any path have a launching clock from the input clock domain and capturing clock coming from that derived clock domain, that path will have a large skew. So you'll have a hard time to meet the timing.
Another problem is with writing SDC constraints. You have to write the clock definitions on each stage even if they aren't used. See an example here on page 18.

tcrosley · Answer 3 · 2014-06-19T15:31:40.947

This issue affects not only simple binary counters, but also more complicated ones like decade counters (such as the 74HCT4017) where each counter internally counts from 0-9, and are wired to reset back to 0 on the tenth pulse.

Suppose you have a number of decade counters, one for the units position, tens position, hundreds position etc.

Each of the decade counters has a clock input. The clock of the units counter is fed from the main clock source, which can be turned on and off presumably. The clock of the tens counter is connected to carry output of the units counter. When the units counter counts from 9 to 10, two things happen: the counter is reset back to 0 (so there really never is a valid 10 output), and a clock pulse is propagated to the clock input of the next counter, in this case the tens place.

The reason it is called a ripple clock, is that the clock going into the tens counter will be delayed at least one propagation delay from the original clock going into the units place. This will then have what is called a "ripple effect", e.g. if you have a 6-place counter, the clock going into the sixth place on a 099999 to 100000 transition will be delayed five times.

This can create timing problems, for example if one were to try to compare the output of the counters to a particular value, the counters do not change all at once so the comparison circuitry may fire at the wrong time -- there is no signal that says: all outputs are stable.

sherrellbc · Answer 4 · 2014-06-19T16:45:25.487

From what I have seen, Ripple Conters, as they are sometimes called, are digital timers (counters) that are used when precision is not required and simplicity is the goal. They can additionally be used as clock-dividers to prescale an input clock signal by an order of 2 per stage.

Basically, you have a series of connected FlipFlops where the output of the previous stage becomes the clock of the next stage.

See: Ripple Counter

What is a ripple clock?

4 Answers4