Hi,

I'm new to the forum so apologies for what is probably quite a basic question. I am having great difficulty in finding information on designing an Asynchronous 10mod counter using 4 JK flip flops. The lecturer has handed out various notes but it was all very rushed and I cant seem to work out how I can populate truth tables and karnaugh maps in order to get the basic boolean algebra to put into multisim for a circuit design. I understand the basic principles of digital inputs but cant see how each 'ripple' makes the required change. Is it the same process as synchronous, albeit with propagation delay?

Attached are the notes provided but it seems to only deal with synchronous or am I just confused and over complicating it?

 

You should try to be very clear about what the adjective "asynchronous" refers to. It might only refer to the SET and CLEAR features of the counter. JK Flip-Flops are normally synchronous devices. The usual way to make an "asynchronous counter" is to configure a D Flip-Flop as a Toggle Flip-Flop and run the output of one stage to the clock input of the next stage. Since JK Flip-Flops can be configured to Toggle, this might provide a clue.

 

You should try to be very clear about what the adjective "asynchronous" refers to. It might only refer to the SET and CLEAR features of the counter. JK Flip-Flops are normally synchronous devices. The usual way to make an "asynchronous counter" is to configure a D Flip-Flop as a Toggle Flip-Flop and run the output of one stage to the clock input of the next stage. Since JK Flip-Flops can be configured to Toggle, this might provide a clue.

Yes, Apologies. Asynchronous refers to the fact that there is only one clock source on the first flip-flop and the resulting output 'triggers' the next flip flop. I have generated an output from the circuit that was generated in the lecture and quite clearly see the frequency of each flip flop reduces. I'm just unclear as to 'reverse engineer' this circuit by using truth tables and karnaugh maps, if you even have to with asynchronous

 

That is the beauty of the thing -- you don't need any truth tables or Karnaugh maps.

 

That is the beauty of the thing -- you don't need any truth tables or Karnaugh maps.

Thanks Papabravo. Very much appreciated, I had started to come to that conclusion having knocked up a basic circuit and scribbled down the various outputs from each flip flop, which in essence gave me the binary output for each decimal. Just need to put that into some forms of a description.

Cheers

 

Thanks Papabravo. Very much appreciated, I had started to come to that conclusion having knocked up a basic circuit and scribbled down the various outputs from each flip flop, which in essence gave me the binary output for each decimal. Just need to put that into some forms of a description.

Cheers

For the numbers 0 thru 9 there is no difference between a binary counter and a decade(decimal) counter. To implement a decade counter you must decode state 9 (=1001) and force the next state to 0.

 

For the numbers 0 thru 9 there is no difference between a binary counter and a decade(decimal) counter. To implement a decade counter you must decode state 9 (=1001) and force the next state to 0.

Thanks. For the decade I have taken the Q output from flip flop 2 and 4 and fed that back into a NAND gate which is then fed into the NOT clear input on all flip-flops. Running it in SIM shows it works OK.

 

You should try to be very clear about what the adjective "asynchronous" refers to. It might only refer to the SET and CLEAR features of the counter. JK Flip-Flops are normally synchronous devices. The usual way to make an "asynchronous counter" is to configure a D Flip-Flop as a Toggle Flip-Flop and run the output of one stage to the clock input of the next stage. Since JK Flip-Flops can be configured to Toggle, this might provide a clue.

You terms for synchronous and asynchronous in relation to flip flops is correct. When talking about counters synchronous refers to all the latches changing state at the same time. Asynchronous is like a ripple clock with only one latch getting the clock pulse. The output of that latch clocks the next latch, and so on.

 

Thanks. For the decade I have taken the Q output from flip flop 2 and 4 and fed that back into a NAND gate which is then fed into the NOT clear input on all flip-flops. Running it in SIM shows it works OK.

Check the resolution of the sim. This approach will cause a glitch on the Q2 and Q4 outputs as they briefly produce a 10 in binary before that 10 gets decoded and turned into a system reset, changing those outputs to zeros. This is one of two common problems with asynchronous counters. The other is that the counters do not produce the correct output briefly after each clock edge while the appropriate state changes ripple through the flip flop string.

ak

 

For the numbers 0 thru 9 there is no difference between a binary counter and a decade(decimal) counter. To implement a decade counter you must decode state 9 (=1001) and force the next state to 0.

Forcing "the next state" to be something in particular is usually easier said than done with asynchronous logic. The more common way of doing it is to detect the first abnormal state and immediately force the present state to be what is should be. So you detect State 10 and use asynchronous logic to directly reset all of the flip flops to State 0.

@Ben Horton TMIET :In general, for most designs, asynchronous logic is a bad choice (of course, if an assignment calls for doing it, you do it). In particularly, you have to be very certain that you don't have any critical races or produce any glitches on edge-sensitive inputs or asynchronous control inputs. Asynchronous logic has its place and it comes with significant advantages much of the time, but properly designing such logic is considerably more involved and requires much greater attention to detail.

 

MOD NOTE: Moved to Homework Help.

 

Check the resolution of the sim. This approach will cause a glitch on the Q2 and Q4 outputs as they briefly produce a 10 in binary before that 10 gets decoded and turned into a system reset, changing those outputs to zeros. This is one of two common problems with asynchronous counters. The other is that the counters do not produce the correct output briefly after each clock edge while the appropriate state changes ripple through the flip flop string.

ak

Thanks AK, the assignment was handed in and ended up with a merit. Thanks to everyone that kindly contributed, I can imagine students wanting people to dig them out of the clart for assignments could get frustrating. The assignment to was very rushed and didn't attempt the distinction questions so all in all happy with the result. Walked away with a distinction overall for the module.

 

Check the resolution of the sim. This approach will cause a glitch on the Q2 and Q4 outputs as they briefly produce a 10 in binary before that 10 gets decoded and turned into a system reset, changing those outputs to zeros. This is one of two common problems with asynchronous counters. The other is that the counters do not produce the correct output briefly after each clock edge while the appropriate state changes ripple through the flip flop string.

ak

While I agree with you, it should be noted that even synchronous counters produce glitch states after clock edges while the registers update, unless the counter is a gray code counter. While the glitches produced from an asynchronous counter tend to be longer, this seldom is of any consequence since if a glitch matters (because some part of the circuitry will respond to it) then it seldom matters how long it is, only that it exist. On advantage of ripple counters in this regard is that the sequence of glitch states is much more predictable than for a synchronous counter.

 

One advantage of ripple counters in this regard is that the sequence of glitch states is much more predictable than for a synchronous counter.

True, but the difference in settling time for two 16-bit counters, one sync and one async, can be at 20 times longer. While all of the flipflops in the sync counter have different propagation times, the difference between the fastest and slowest is much less than the average. for example, the prop delay through each flipflop might be 5 ns typical, but vary by only 0.5 ns among the group. For the same flipflops in an async counter, the minimum settling time from the first stage to the last would be 75 ns plus gating delays. Predictable and monotonic, but long.

ak

 

As noted, the glitch times are longer, but the main point is simply that they exist in either case; glitches that are meaningful if they are 75 ns long are almost certainly meaningful if they are 0.5 ns long (meaning that logic that could respond to the former will very likely be able to respond to the latter, particularly since it will probably be using the same logic that the flip flops themselves are using).

 

While I agree with you, it should be noted that even synchronous counters produce glitch states after clock edges while the registers update, unless the counter is a gray code counter. While the glitches produced from an asynchronous counter tend to be longer, this seldom is of any consequence since if a glitch matters (because some part of the circuitry will respond to it) then it seldom matters how long it is, only that it exist. On advantage of ripple counters in this regard is that the sequence of glitch states is much more predictable than for a synchronous counter.

Agree on the benefits of Gray code counters and Johnson counters, like the 4017 uses, as well.