# What is a ripple clock?

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?

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

1. 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.

2. 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.

This is a ripple counter:

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.

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.

• 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. Jun 19, 2014 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, 2014 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. Jun 19, 2014 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? Jun 19, 2014 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. Jun 19, 2014 at 19:36

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.

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