Hi everyone,

I've a question about digital counter, specifically the asynchronous counters.

I was taught that I could design any sequential asynchronous up counter with log2(M) of flip-flops (usually JK FFs), where M is the number of the states (e.g. 8 states would take 3 flip flops), the main clock will enter to the first flip-flop, while the others will be clocked by the normal output of the previous flip-flop.

(P.S. In the lab, I didn't need to connect the J and K to anything, I just connected the clock input)

The same goes for the down counter, except that the second and the third FFs clock inputs will be the complement output not the normal.

If the states are not sequential (e.g. 0 1 2 3 4 5 8 9 10 11 12 13), then I need to make a table with Present and Next states and the excitation tables for every J and K, then I need to draw the timing diagram to decide which flip flop may lead the other.

What if I couldn't a suitable clock pulse (one of the FFs outputs) that may lead one of the flip flops?

 

What if I couldn't a suitable clock pulse (one of the FFs outputs) that may lead one of the flip flops?

Then you are stumped. That is why you have to use a synchronous counter design:

http://forum.allaboutcircuits.com/threads/submission-another-look-at-synchronous-counters.82082/

 

I mean, are there cases where we can't represent some sequence using ripple counters?

 

In general, designing asynchronous logic is risky and should be avoided. It definitely has its place, but it is not something to take lightly as you become very susceptible to race conditions and timing hazards.

 

I mean, are there cases where we can't represent some sequence using ripple counters?

In a ripple counter each FF changes state only as a consequence of another FF changing state (except for the FF that is directly clocked by the clock signal). So how would you implement a Gray Code counter given that only one FF can change state each clock cycle?

 

WBahn

I really didn't understand your question, but I guess if there is only one FF that changes each cycle, then we don't have a counter in the first place. (?)

 

WBahn

I really didn't understand your question, but I guess if there is only one FF that changes each cycle, then we don't have a counter in the first place. (?)

Why not? Gray Code counters (notice that they are called "counters") are used a lot specifically because only one bit changes each time. Consider the following sequence of states:

000 -> 001 -> 011 -> 010 -> 110 -> 111 -> 101 -> 100 -> 000

That's a 3-bit Gray Code sequence.

Can you do this using a ripple counter approach?

 

No. I could not.
I drew the timing diagram for this sequence (for each bit), but I couldn't find any flip flop that could lead the other.

 

And so you have your answer -- or at least one that is anecdotal. But you can generalize from it pretty well if you consider WHY you couldn't find a FF that could "lead" the other. On each clock cycle you need exactly one FF to change, but since only one FF is changing, that means that there isn't any other FF that is changing and, hence, no other FF can provide the clock signal to the one that IS changing. As a direct consequence, the one clock signal MUST be involved in producing the clock signal for ALL of the FFs.

 

Now I understand. So ripple counter should be avoided. But why they're used in the first place?

 

Because they are simple, they are easy to understand, they use less power, they take less area (when implemented on an IC), and sometimes they are good enough.