# Flip Flop D Asynchronous Counter Timing Issue

I have a counter made of several FFDs (see image below and please ignore R wire): Def: N(t) - Signal N at time t, where t is a real value and 1 CLK cycle = 2t units. This will be important further.

Def: E_i - Element E at stage i.

As every Q{i} output will feed into the clock input of the next FFD{i+1}, it is a simple Asynchronous Ripple Counter. Also, in theory, at every stage it should halve the clock frequency compared to the previous stage.

CLK_0 = f (system clock frequency at stage 0)

CLK_1 = f/2

CLK_2 = f/4

...and so on

Will this counter be usable in a synchronous system with a CLK = f? Will it be able to write out values with the right timing?

Consider this example, where I have extracted first 2 stages of the counter: t = 0: at time t = 0 we have following configuration:

Q_0 = 0 & !Q_0 = 1
Q_1 = 0 & !Q_1 = 1
FFD_0 = 0
FFD_1 = 0
CLK_0 = 0
CLK_1 = 0 t = 0.9: first flip flop has already read the new value but the output Q_0 hasn't yet settled. Also, whoever was reading Q_0 and Q_1, read 0 on both. So we have this configuration:

Q_0 = 0 & !Q_0 = 1
Q_1 = 0 & !Q_1 = 1
FFD_0 = 1
FFD_1 = 0
CLK_0 = 0
CLK_1 = 0 t = 1.1+: The clock edge stared to fall but it is not yet 0. FFD_0 outputs have settled and FFD_1 is receiving rising clock edge from Q_0 and it is reading !Q_1 (this is Q_1 bar). It looks like here:

Q_0 = 1 & !Q_0 = 0
Q_1 = 0 & !Q_1 = 1
FFD_0 = 1
FFD_1 = 0 (reading in progress)
CLK_0 = 1 (falling)
CLK_1 = 1 t = 2: By this time, all values have settled:

Q_0 = 1 & !Q_0 = 0
Q_1 = 1 & !Q_1 = 0
FFD_0 = 1
FFD_1 = 1
CLK_0 = 0
CLK_1 = 1 At this point here's the issue: CLK_0 = 0, which is also same as system clock. By the time CLK_0 = 1 we have Q_0 and Q_1 both equal 1. So, whoever reads counter output, reads it in sync with CLK_0. Apparently, it will receive following value:

00 -> 11 instead of 00 -> 01

Now, if my counter had Q_0 settled by the time t=3 (2nd clock edge), everything would work perfectly. But, at this point I don't think it happens. I have CLK_0 as system clock but CLK_1 is triggered as soon as Q_0 settles.

Is it even possible to use this counter in a synchronous circuit? Do I have to make changes? Or should I simply go for a synchronous variant?

It doesn't matter if you use a synchronous or ripple counter, as long as the four Q outputs have settled before the surrounding synchronous system "reads" them.

For instance, the propagation delay, from input clock edge to stable output, through a single 74HC74 flip flop is about 30ns (see $$\t_{PLH}\$$, $$\t_{PHL}\$$ in the datasheet) when the device is powered from +5V. This means that if you cascade four of them in series in a ripple counter arrangement, you can expect the last stage Q to settle, (all four outputs valid and stable), 120ns after the input clock edge.

As long as your surrounding circuit waits at least 120ns following the counter's clock edge, the counter outputs Q0 to Q3 will be ready.

A synchronous counter will have outputs that settle much faster. For example the 74HC161 has $$\t_{PLH}=56ns\$$, when powered from 5V. This means all four Q outputs are ready only 56ns following the clock edge, but you still have to wait.

Even if the the counter is synchronous, there's no guarantee that the Q outputs will all change simultaneously. There could be (and you should assume that there is) a few nanoseconds between the fastest output settling, and the slowest.

### Update

It's not clear what you mean by "reading" the outputs $$\Q_N\$$.

Since this is a counter system, the outputs only make sense as a whole, and as such, the only sane interpretation of their values is if they are "read" (their values actually "used") all simultaneously.

For the ripple counter, to "read" them all simultaneously and have what you "see" actually be a valid meaningful count, requires that you wait 120ns following the clock edge. Importantly, by reading them all together, you impose the constraint that no further clock edge can occur in the meantime, since that would cause lower bits to have adopted new values inconsistent with the higher bits.

While you may clock the ripple counter at $$\f=\frac{1}{30ns}\$$ or $$\f=\frac{1}{38ns}\$$, which the all flip-flops would handle just fine, to do so would render outputs $$\Q_0\cdots Q_n\$$ meaningless at any given instant in time. The values of higher bits would be relevant and correct only in the context of "several clock cycles ago", by which time lower order bits have already moved on, having changed several times already. High order bits are already "old data" way out of date, and stale.

If clocked again sooner than the highest order bit can settle, The combined instantaneous value of all bits together (at any instant) is meaningless garbage. To avoid this, and have a set of many simultaneously coherent and meaningful bits, a valid "count" so to speak, requires that you wait until all outputs are settled before reading and before clocking again. That is, for a 4-bit ripple counter with 30ns flip-flops, your clock cannot be faster than $$\f=\frac{1}{120ns}\$$. And that's not including the time it takes for you to capture the count value.

It may be possible to compensate for ("undo") the time shifts and delays which are different for each bit, using a shift register, or by adding extra gates in the path from each flip-flop output, but I have never come across such a system, and have never even considered doing this. To me, that would be insane. I would rather use a really fast synchronous counter.

With a synchronous counter, the same constraints apply, but the delay between clock edge and all bits being valid will be much much shorter. For the output to be meaningful when viewed as a whole, all simultaneously, and representing a valid count, you still must wait for them all to be settled, but that happens much faster than a ripple counter.

If the propagation delay from clock to output is $$\t_P=58ns\$$, then you can't use a clock with frequency higher than $$\f=\frac{1}{58ns}\$$, since clocking again before the outputs are settled will prevent the outputs from ever settling into a valid meaningful state to be "read".

Everything hinges on what you do with the outputs. If you care that the combined simultaneous value of all bits represents a valid count every time you "read" them, then these are the facts and conditions, however inconvenient.

• @shadox The counter won't lose any values, or make any errors. It will count reliably from 0000 to 1111 and back to 0000 (unless you don't use bypass capacitors on the supply). Setup time isn't an issue, because the D inputs are already setup long before the clock edge, since they come from the flip-flop's own output, which settled 30ns after the previous clock edge. Jun 29 at 15:36
• @shadox FF1 is clocked only on the falling edge of FF0-Q. So Q1 can only change value when Q0 returns to 0. Same for Q2, it only flips when Q1 returns to 0, Q3 only flips when Q2 returns to 0, and so on. You cannot possibly ever have 0000>0001>0011. The sequence will always be 0000 > 0001 > 0010 > 0011 > 0100 etc. If your clock period is 120ns, and the current state is 0000, then at the first falling input clock edge you get 0001. After another 120ns (the next input clock edge) you get 0010. After yet another 120ns you have 0011, and so on. Jun 30 at 14:30
• @shadox In other words, flip flops 1, 2 and 3 are not clocked by the main clock,at all, only by the preceding flip-flop. The only flip-flop that responds directly to the input clock is FF0. All other flip-flops respond only to changes (falling Q) of the one before, so each flip-flop "sees" its own clock having half the frequency of the preceding one. That's how the counting works. Jun 30 at 14:35
• @shadox maybe this is the whole misunderstanding. If you want to make a counter, you must use negative edge triggered flipflops (or you can achieve the same effect using positive edge triggered flip-flops by clocking each one on NOTQ of the previous one, instead) Jul 1 at 18:37
• @shadox Wow! Funny how we can't "get" each other for the most surprising and simple thing, huh? I really should have spotted this earlier, especially considering I was talking about the 7474, a definitely positive edge triggered device! Sorry! Anyway, you're welcome. Jul 1 at 18:51

I think the statement "t = 0.9: first flip flop has already read the new value but the output Q_0 hasn't yet settled" makes an assumption that is not necessarily true.

The rising edge of CLK into the first flip flop will cause that FF to toggle it's value. The duration of this event is dependent on Tco of the FF and unrelated to the input clock frequency 1/(2t).

However, the clock frequency will be limited in the datasheet.

If you are planning to use the counter value in a synchronous circuit, I would recommend using a synchronous counter design.

Is this a discrete design, or being implemented in a programmable?

• It is a discrete design but I am trying to understand how this type of counter works. It seems much simpler to me that a synchronous design but maybe it's harder to use? Jun 29 at 15:00

If there was no delay, it could be done.

But with delays, it can't be. See the answers of the gates Qout1 and Qout2... • The problem is not the delay on Qn but my clock timing. Considering I have only 1 FFD with system clock and all others just multiples of the 1st one, I am not sure how ca I read correct sequence with this design. Jun 29 at 15:02
• If my clock is too slow it won't be able to read all the values. This counter does not stop and wait for me to read values. If I have a faster clock, then I might not respect Tsu+Th which means that even my 1st FFD might not flip the value. So I am confused. Jun 29 at 15:04