Design of counter using jk flip flop

[rahul.6sept]

Hello, I want to design a synchronous counter using jk flip flop. So, race around condition may arise in the counter. If at all it arises, what are the possible remedies to overcome the same?
rgds

 

[wwfeldman]

how many bits?
what frequency?
what JK fliflop?
what circuit?

because is it synchronous, likelihood of a race condition is reduced
why design a counter when you can buy working counters? - less components, less wiring, less board spacce

 

[rahul.6sept]

how many bits?
what frequency?
what JK fliflop?
what circuit?

because is it synchronous, likelihood of a race condition is reduced
why design a counter when you can buy working counters? - less components, less wiring, less board spacce

Just a hobby circuit. So want to design and not to purchase.
Why does race condition reduce in case of synchronous?
How to overcome the same in case of asynchronous counter design?

 

[wwfeldman]

as long as the auxiliary gates used to prepare the flip flops for next count meet set up and hold times before the next clock pulse, there should be no race conditions

same issue applies to an asynchronous counter, by which i mean a ripple counter
in this case, you also have to include the time for the rippling through each flipflop
depending on length of counter, the last bit to change can be a significant amount of time between first bit and last bit changing

compare the logic diagrams for an LS393 (4 bit ripple counter) and LS163 (4 bit synchronous counter)
they both do the same thing
BUT
the '393 appears to have a lot less auxiliary parts but they are burried in the toggle flip flop.
but each stage has a clock derived from the prior stage, so the bit ripple through - the bits change in order, one after another
the '163 has a lot of auxiliary gates that handle things like loading data into the counter, clearing and enable-ing
but all the clock inputs are the same, so the bits all change at the same time

yes i know, these parts are almost as ancient as i am, but i've used them in the past, and i'm familiar with them and their documentation

 

[danadakk]

Youtube has a lot of videos you can learn from :

Search on "synchronous logic" at youtibe.com


Regards, Dana.

 

[dick_freebird]

There are "race" problems in both synchronous and
ripple counters. They appear for different reasons at
different places.

The synchronous counter will have some pretty wide
logic at higher bits. This will be the slow path. Once
the bit count (logic width) gets high enough the delay
through it, will end up on the other side of clock edge
(presuming you're using it at high enough frequency,
or rather, this determines the max frequency of operation).
I have had to overlay "pipelined" toggle logic when trying
to make 400MHz counters in 0.5u logic, and figure the
toggle in "smaller bites, ahead of time".

Ripple counters throw the race problem onto whatever
receives those bits. Each output bit is time-staggered
by the FF's prop delay and the MSB output can be N*tpd
later than the LSB. This will be a hazard at the successor
logic which combines the two. Or a big don't-care if all
you wanted was the MSB as a product frequency. And
if you wanted to re-register the outptut word to time align
the bits, there's a similar max frequency where the MSB
may flip after the clock that caused it, and the next - if
tpd(MDB) > clock_period.