The Task:

I was given the task of designing a decade counter using J-K Flip-Flops. What I immediately thought of was whether I should make it Synchronous or Ripple. And here is where I started getting confused.

What I know:

Now, the main advantage (that I am aware of) of synchronous over ripple counters is that they are more reliable, as in they do not have propagation delays, which can make an output go from
0111 (7) --> 1111 (15) --> 1011 (11) --> 1001 (9) --> 1000 (8) (transiently)
otherwise, they are more complex to design and generally require more circuitry.

My Question:

So, can a ripple counter count in Gray Code? And would it solve this propagation delay problem? I thought this would make any propagation delay irrelevant, because, for example, a number would change from 0100 (7) to 1100 (8) without going through transient states no matter what delays are present in the circuit. This would, in turn, make the asynchronous counter the better choice.

I must also say that the clock's frequency is really low (1Hz), Will any of this matter in this case?

  • 1
    \$\begingroup\$ It really isn't clear what you mean by the term "asynchronous counter". Usually we speak of "synchronous counters" and "ripple counters" -- the latter being when the output of one stage is used as the clock input to the next stage, so that a change "ripples" from stage to stage as far as needed to produce the next state. (Note that the transient states in your example would actually be 0111 -> 0110 -> 0100 -> 0000 -> 1000, as the change ripples from LSB to MSB.) Clearly, that can't happen in a Gray counter, in which only one output ever changes at a time. Please clarify. \$\endgroup\$ – Dave Tweed Apr 14 '17 at 0:46
  • \$\begingroup\$ Sorry dave, by adynchronous I mean ripple. :) \$\endgroup\$ – karim ahmed Apr 14 '17 at 10:18
  • \$\begingroup\$ So, given that the concepts of Gray code and ripple counter are clearly incompatible, what is the actual problem you're trying to solve here? Decade counters, both ripple and synchronous, are readily available as single chips. Do you have implementation constraints that make them unacceptable? ... Or is this a homework assignment? If that's the case, you need to be up-front about that, and show that you've made a good-faith effort to solve it on your own. \$\endgroup\$ – Dave Tweed Apr 14 '17 at 14:18
  • \$\begingroup\$ Dave, instead of just going for the safe bet of using a synchronous counter, I tried to decrease the error in the ripple counter, in order to have no cons (compared to synchronous), all I could think of was Gray code. And yes, it is an assignment, I could simply have used synchronous counters but instead I tried to think out of the box. Since I am new to this, I came to ask experts for their opinions about trying to use Gray code and ripple counters somehow together, which I felt couldn't be done, but as I previously said, i'm new to this and needed a bit of guidance. Thanks anyway :) \$\endgroup\$ – karim ahmed Apr 14 '17 at 14:47
  • 1
    \$\begingroup\$ @DaveTweed: In what sense are the concepts of "ripple counter" and "gray code" incompatible? If one starts with a two-bit graycode counter PQ one can turn that into a three-bit counter XYQ with asynchronous logic; when Q is set, Y=P xor X. When Q is clear, X=P xor Y. Feeding the top two bits of a 3-bit counter into a similar circuit will yield a 4-bit counter, and the principle can be extended arbitrarily. \$\endgroup\$ – supercat Jul 2 '17 at 19:59

It's possible, and not overly difficult, to design an asynchronous counter which takes a two-bit gray code input and produces a three-bit graycode as output. Such stages may be cascaded to arbitrary depth to yield an arbitrary-length gray code counter. An interesting feature of such a counter is that unlike normal binary ripple counters, it can count in both directions equally well, and will tolerate momentary instability or metastability on either input, provided that no input changes unless the other input is stable.


simulate this circuit – Schematic created using CircuitLab

When In0 is 0, output 2 will switch if needed to make (In1 xor Out1 xor Out2) be 0. When In0 is 1, output 1 will switch if needed to make (In1 xor Out1 xor Out2) be zero. If In0 is stable, junk on In1 will cause junk to appear on either Out1 or Out2, but the other output will remain stable. Once In1 stabilizes, its corresponding output will stabilize as well. If In1 is stable, nothing besides Out0 will switch in response to In0, so noise on In0 will have no effect provided that it stabilizes before In1 changes.

Note that the design shown may have some practical considerations such as logic hazards with muxes or the lack of a reset signal; those are addressed as exercises for the reader.


In a ripple counter, the input clock goes directly to only one flipflop, the LSB, and is cascaded to the others. This explains why the LSB always has to change state, and changes at a slightly different time to higher weight outputs.

In Gray code, any output may change state. It's therefore obvious that you can't have a ripple (asynchronous) implementation of a Gray counter that's as simple as a binary ripple counter.

A synchronous counter, on which all outputs change state on the same input edge, is not necessarily more reliable, it is just as reliable when its characteristics are taken into account when designing the system that uses it.

If a ripple and a synchronous counter are made from the same technology, the outputs of the synchronous counter will stop changing in a shorter time from the clock edge. However, the ripple counter will count correctly up to a higher input frequency. The ripple counter is guaranteed to have significant skew between the outputs, the synchronous counter might have some skew depending on how symmetrically it's been designed, and how equally loaded the outputs are. In both cases, read the data sheet, and design to accommodate the part's behaviour.

In a synchronous counter, the clock goes to all flipflops, and internal gating is used to decide which ones change state. Look at the internal diagram in the datasheet for an HC163 to see this for instance. Seen like this, the HC163 is just a 16 state state machine, with the sequence through the output states controlled by the internal gating. To alter the output sequence, to Gray code for instance, is only a matter of altering the state decoding.

Obviously you need a suitable target to implement such a decode and control circuit. You could do it from discretes, HC74s and HC86s for instance. Or with VHDL on a CPLD or FPGA target. Be warned that for the discrete case, if you go for a minimum gate solution, which will mean cascading down the XORs, it will be a little slower than the binary version.

An alternative way to get a Gray weighted count is to use a binary counter, and recode the outputs. This may seem like cheating a bit, but with the decoding already done for you to make an HC163 work, it's probably the easiest way to do it in discretes. It's probably also the fastest, as the HC163 outputs are registered. Encode the binary outputs to Gray with an XOR cascade, then register them again on the same clock. I fear this last one isn't in the spirit of what you're trying to do.

Perhaps a route closer to a 'ripple counter' or asynchronous Gray counter is suggested by the observation that the 'LSB' changes state every other clock input. If the LSB is a T type (a 'toggle' latch, also constructable as a JK with J and K tied together, or an XOR wrapped round a D latch), then a single asynchronous divide by 2 can control that to flip state every other input. A higher bit changes state when the LSB doesn't, and according to other conditions. See if you can figure out the gating for a 2 bit, and then how it changes to a 3 bit Gray counter, then you'll have the pattern for constructing the cascade for the n bit Gray counter.

  • \$\begingroup\$ If one were to cascade the circuit given in my answer, would that not be a ripple graycode counter? It may be a little more complex than an up-only binary ripple counter, but it's capable of counting in both directions. \$\endgroup\$ – supercat Apr 24 '18 at 20:00
  • \$\begingroup\$ @supercat maybe. Just looking at it, it's not clear to me how the storage works. Gates cascaded through muxes obviously have the capability to store state, but it makes my head hurt trying to figure out whether it does, and does correctly. Would you post a 'logic analyser' type trace of it switching through several states please, to clarify its operation, and again with two in cascade. \$\endgroup\$ – Neil_UK Apr 25 '18 at 4:26
  • \$\begingroup\$ Each mux is used as a transparent latch, but the simulator didn't have transparent latches. \$\endgroup\$ – supercat Apr 25 '18 at 13:43

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.