Flip Flop D Asynchronous Counter Timing Issue

Question

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?

Answer 1

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.

Answer 2

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?

Answer 3

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...