2
\$\begingroup\$

Are the ripple counters useful in real life?

I know, for example, if we set an up counter with 3 FFs, CBA. Followings are the block and the waveform diagram:

enter image description here

enter image description here

After the count 001, it will appear 000 (the 2nd CLK period), which makes the operation false. In fact, this situation is inevitable in real life because propagation delay is inherent for all flip flops.

As a result, I wonder how can we implement asynchronous counters?

\$\endgroup\$
  • \$\begingroup\$ CD4060 was the "goto" counter when simple clock generation to high orders of 2 were needed in the 70's and still sold today in high volume. \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Apr 8 '18 at 5:26
1
\$\begingroup\$

It is simply a matter of can you wait for the final output stage to settle before taking a count reading. In which case you build in the sample delay with hardware or software.

When you gate/stop the count to measure each stage in parallel then synchronous counters are better. There is still a minimum wait time before sampling but it is much more predictable, as the wait time applies to the entire counter.

If it is just a 'pre-scaler' used to divide a fixed high frequency to a lower frequency and it runs continuously then there is no delay issue. In a way the count of any one stage is unknown and has a "don't care" policy.

\$\endgroup\$
  • \$\begingroup\$ Do you mean that asynchronous counters are not used when we want to examine the circuit at certain stages, but rather to wait until the exact moment on the count? \$\endgroup\$ – W.Joe Apr 8 '18 at 6:21
  • \$\begingroup\$ Correct. By their nature the count of anyone stage is unknown unless you halt the count and wait before sampling. Many watch's and Real-time-clocks use a 32.768 KHZ crystal that goes through an 11 stage binary divider to end up with a accurate 1 HZ clock pulse. No one cares what count anyone stage has, as it is about dividing down the 32.768 KHZ only. \$\endgroup\$ – Sparky256 Apr 8 '18 at 6:31
1
\$\begingroup\$
  • The problem with asynchronous counter is the "ripple". Say take an example of 4-bit asynchronous counter counting up. The transition from 0111 --> 1000 goes through or ripple through 3 intermediate states because of accumulaton of propogation delays of each preciding Flip-Flop. These are glitches in the asynchronous counters.

enter image description here

If you plug-in some LEDs at the 4-bit outputs of the counter, you wont notice this glitch at all as these ripples are fast enough and you see that its counting correctly. But if you are feeding this count to some other digital logic for sampling, these glitches may cause unwanted errors.

  • A solution to the above problem is strobing. It is basically like latching the count output.

enter image description here

The idea is to sample the count, only after it is settled to a stable value. In the above circuit, the count transition is happening at positive edge of clock. What we do is, we sample the count only when clock is low. The clock is like 'enable' signal of the strobing circuit. The one condition here is that, by the time clock transits from high to low, all ripples should have been passed by. i.e, the accumulated propagation delay should be less than clock's "high time". It make sure that correct count is sampled every time.

  • The problem with asynchronous counter is the limitation of clock frequency/limted speed, due to accumulated delays of each Flip-Flop. The counter should satisfy: $$\Sigma d_i < T_{clk}$$

    Due to these design complexities, we prefer synchronous counters, where timing is predictable.

\$\endgroup\$
0
\$\begingroup\$

Ripple counters are useful in real life. Frequency dividers are an obvious one.

A 16 stage ripple counter will use 1 + 1/2 + 1/4 + ... ~=2 units of power.

A synchronous counter would use 16 units of power.

Generally, synchronous logic solves one set of problems at the expense of

  • more Power
  • more gates
  • lower speed
  • new race conditions introduced by synch
  • increased emi from continuous clocking and spectrally narrow transitions

A better question might be why do people think synchronous counters are so especially useful? Why is synchronising the entire counter/system seen as the correct solution to the timing of some critical outputs?

Philosophically, the orthodoxy of synchronous logic may have resulted in limited skill and techniques and strategies for making complex unclocked logic systems work, and explain why there are so few asynchronous clockless cpus, even for very simple instruction sets. The Greenarrays F18 is the only one that springs to mind, but able to achieve PIC like power consumption at hundreds of MHz

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.