Hello there,

This is an interesting circuit because it looks like the way the counters are being used may not be the best way.

Internally, the two counters inside each package are both synchronous, but outside of each package the two are being used as asynchronous counters. The reason for using synchronous counters is so that the outputs, no matter how many counters are being used, all switch states at the same time. That means (using a full binary counter) if you go from a count of (say) 15 to 0 each bit will change from 1 to 0 at the same time. If you go from a count of 255 to 0 each bit will still change from a 1 to a 0 at the same time. If you go from a count of 0xFFFFFFFF to 0x00000000 all the bits will change from 1 to 0 at the same time. That last example is 32 bits and it still works well because all of the counters are wire for synchronous operation.
This usually means there is no problem with some bits changing before others, even though they may be of higher order.
The problem comes in where you use ripple counters. That means bit 0 changes slightly ahead of bit 1, and bit 1 changes slighly ahead of bit 2, etc., etc. This causes a lot of problems especially when the counter chain is very long. If you had a chain of 8 BCD counters using ripple carry the delay would be very noticeable in some applications. It would cause count problems for any logic that had to rely on the outputs changing all at the same time.
Now with this circuit, it looks like each BCD section is synchronous, but between the two BCD digits, they are asynchronous. That means bits 0,1,2,3 change at the same time, and bits 4,5,6,7 change at the same time, but bit 4 is delayed from bit 3 by a small amount meaning bits 4,5,6, and 7 are all delayed by a small amount. Now if the external logic is fast enough to catch this, it's not going to detect the right logic states and so you could see small glitches that cause problems in the reset of some of the counter stages.

The best bet is to look up how to connect multiple synchronous counter stages and do it the right way. That will help to avoid these kinds of problems. That assumes everything else is right of course, such as bypass caps, proper wiring, steady DC power source, etc.

I just took a quick look so check it over to make sure the counters are being used right, and if not, correct it.

 

Internally, the two counters inside each package are both synchronous, but outside of each package the two are being used as asynchronous counters. The reason for using synchronous counters is so that the outputs, no matter how many counters are being used, all switch states at the same time. That means (using a full binary counter) if you go from a count of (say) 15 to 0 each bit will change from 1 to 0 at the same time. If you go from a count of 255 to 0 each bit will still change from a 1 to a 0 at the same time. If you go from a count of 0xFFFFFFFF to 0x00000000 all the bits will change from 1 to 0 at the same time. That last example is 32 bits and it still works well because all of the counters are wire for synchronous operation.
This usually means there is no problem with some bits changing before others, even though they may be of higher order.
The problem comes in where you use ripple counters. That means bit 0 changes slightly ahead of bit 1, and bit 1 changes slighly ahead of bit 2, etc., etc. This causes a lot of problems especially when the counter chain is very long. If you had a chain of 8 BCD counters using ripple carry the delay would be very noticeable in some applications. It would cause count problems for any logic that had to rely on the outputs changing all at the same time.
Now with this circuit, it looks like each BCD section is synchronous, but between the two BCD digits, they are asynchronous. That means bits 0,1,2,3 change at the same time, and bits 4,5,6,7 change at the same time, but bit 4 is delayed from bit 3 by a small amount meaning bits 4,5,6, and 7 are all delayed by a small amount. Now if the external logic is fast enough to catch this, it's not going to detect the right logic states and so you could see small glitches that cause problems in the reset of some of the counter stages.

The problem is that, even with synchronous counters, the outputs do not change all at the same time. Differences in propagation delays results in the outputs changing in effectively random, though often largely repeatable for a given counter, order. Logic that is looking at these outputs is therefore subject to producing glitches and the circuit has to be designed to be immune to this. In a fully-synchronous design, this immunity is guaranteed provided as setup and hold times are not violated. But any signal that is used asynchronously is at risk of producing undesired behavior.

The problem is actually simpler to deal with if ripple counters are used, because then you have a predictable sequence of changes that the outputs go through. But with synchronous outputs, you have to allow for the outputs changing in any possible sequence.

 

I wish I could see a couple of schematics side by side of the right and wrong ways of designing a circuit such as this.

 

The problem is that, even with synchronous counters, the outputs do not change all at the same time. Differences in propagation delays results in the outputs changing in effectively random, though often largely repeatable for a given counter, order. Logic that is looking at these outputs is therefore subject to producing glitches and the circuit has to be designed to be immune to this. In a fully-synchronous design, this immunity is guaranteed provided as setup and hold times are not violated. But any signal that is used asynchronously is at risk of producing undesired behavior.

The problem is actually simpler to deal with if ripple counters are used, because then you have a predictable sequence of changes that the outputs go through. But with synchronous outputs, you have to allow for the outputs changing in any possible sequence.

Hello there,

Well, the question is not just about how well the outputs synchronize, it's also about what is connected to them. I would imagine that if you used LS synchronous counters with F gates on the output, all hell would break loose because the F gates are faster than the internal counter gates. There would be wide glitches. Placing F gates on the output of F counters should be ok I would think. I can look into this more if you like or you could link to some interesting data.
I think the main question is how some flip flop say D to Q response time differs from other flip flops. Ideally if they were all exactly the same there would be no difference in the output delays from Q=0 to Q=1 or vice versa. The delay would have to be longer for one FF than the other FF by a difference greater than the gate delay for the gate on the output. Note we are talking about a difference in two delays here too, not just a single delay.
If bit 0 rises in 10ns and bit 1 rises in 11ns, is the gate on the output able to respond to 1ns.

The problem is worse with ripple counters, not better. It seems that there is only one way that would help and that's if we had a delay circuit on the output of every flip flop in the chain so that they all respond at about the same time.
If you have any information about this though this would actually help with a project I had worked on. To be able to 'adjust' the ripple counters output delay times would remove the requirement for synchronous counters.

Oh maybe you meant using more than one physical package.

 

Well, the question is not just about how well the outputs synchronize, it's also about what is connected to them. I would imagine that if you used LS synchronous counters with F gates on the output, all hell would break loose because the F gates are faster than the internal counter gates. There would be wide glitches. Placing F gates on the output of F counters should be ok I would think. I can look into this more if you like or you could link to some interesting data.
I think the main question is how some flip flop say D to Q response time differs from other flip flops. Ideally if they were all exactly the same there would be no difference in the output delays from Q=0 to Q=1 or vice versa. The delay would have to be longer for one FF than the other FF by a difference greater than the gate delay for the gate on the output. Note we are talking about a difference in two delays here too, not just a single delay.
If bit 0 rises in 10ns and bit 1 rises in 11ns, is the gate on the output able to respond to 1ns.

Asynchronous control inputs are typically able to response to very short glitches (as are clock inputs). Let's just consider the part that the TS is using, the CD4518. The TS didn't say (that I saw) what the supply voltage was, so I'll use the 10 V lines in the datasheet. The minimum reset pulse width is 110 ns (while the typical is 55 ns), To achieve this, a high fraction of the parts are going to be able to respond to pulses that are considerably shorter than this, probably in the 10 ns range.

The propagation delay from clock to output can be as high as 230 ns (the typical is 115 ns). Reset to output is about the same.

So it would not be at all unreasonable to see differential propagation delays of 10 ns, or 55 ns, and even 110 ns would be possible while remaining well within spec.

It is unlikely that any effort was made match the propagation delays. Why? Because that requires additional design and layout effort, as well is more silicon area (i.e., few parts per wafer to sell) in order to achieve something that doesn't matter in a properly-designed circuit. Looking at the circuit diagram, the clock signal to one of the FFs goes through an inverter while the other three all go through 3-input NOR gates, so that alone likely biases the first FF to having a slightly smaller delay. On the other hand, the output of that first FF is more heavily loaded than the others.

The problem is worse with ripple counters, not better. It seems that there is only one way that would help and that's if we had a delay circuit on the output of every flip flop in the chain so that they all respond at about the same time.
If you have any information about this though this would actually help with a project I had worked on. To be able to 'adjust' the ripple counters output delay times would remove the requirement for synchronous counters.

I didn't say that the problem was "better" with ripple counters. I said it was "simpler". And I explained what I meant by that.

Oh maybe you meant using more than one physical package.

Nope, talking about parts within the same package. Although issues between packages is a possibility here, since those glitchy gate outputs are also being applied to Enable inputs on other parts, but a proper analysis MIGHT show that these are non-critical races.

 

Asynchronous control inputs are typically able to response to very short glitches (as are clock inputs). Let's just consider the part that the TS is using, the CD4518. The TS didn't say (that I saw) what the supply voltage was, so I'll use the 10 V lines in the datasheet. The minimum reset pulse width is 110 ns (while the typical is 55 ns), To achieve this, a high fraction of the parts are going to be able to respond to pulses that are considerably shorter than this, probably in the 10 ns range.

The propagation delay from clock to output can be as high as 230 ns (the typical is 115 ns). Reset to output is about the same.

So it would not be at all unreasonable to see differential propagation delays of 10 ns, or 55 ns, and even 110 ns would be possible while remaining well within spec.

It is unlikely that any effort was made match the propagation delays. Why? Because that requires additional design and layout effort, as well is more silicon area (i.e., few parts per wafer to sell) in order to achieve something that doesn't matter in a properly-designed circuit. Looking at the circuit diagram, the clock signal to one of the FFs goes through an inverter while the other three all go through 3-input NOR gates, so that alone likely biases the first FF to having a slightly smaller delay. On the other hand, the output of that first FF is more heavily loaded than the others.



I didn't say that the problem was "better" with ripple counters. I said it was "simpler". And I explained what I meant by that.



Nope, talking about parts within the same package. Although issues between packages is a possibility here, since those glitchy gate outputs are also being applied to Enable inputs on other parts, but a proper analysis MIGHT show that these are non-critical races.

Hello again,

Yeah loading could have something to do with it also.

I was really looking at the "F" series TTL because I've used them in the past.
You mentioned the differences in one package (like the 74F191). I do not see a spec for that. What I do see though is MATCHED rise and fall times. So, I find it difficult to think that there are differences in the CP to Q delay in a single package case because they must have realized the issues that would come up if they were not at least somewhat matched with matched loads.

I had a number of counters similar to that one but not sure I have them anymore so I can't do any real-life testing, and I am not sure I want to buy one just to test it. After the last cleanup I got rid of a lot of parts I was not using for more than 2 years.

I remember one project vaguely where the counters were driving RAM and ROM chips. No problems there.
Also, the microprocessors I've used in the past like the Z80 did not seem to have a problem with memory addressing, even though there were gates used to decode different device access and input/output ports. Maybe the RAM and ROM chips were too slow to pick up any difference in address line bit delays, but the discrete gates would have.

One thing I think we can all agree on. If you have a long string of ripple counters and a long string of synchronous counters and drive them with the same clock, the last ripple counter could take 10 microseconds (not nanoseconds) to settle to the right states, while the last synchronous counter will settle within its delay time of maybe 2ns to 8ns just like the first counter stage. So we see a difference in output states between ripple vs synchronous of almost 10 microseconds for the last stage.

For now I'll take your word for it though, no problem.

I was interested in hearing if you have any idea how to fix the ripple counter issues when there is a long chain of counter packages. For example, eight packages of BCD counters. At high frequency, the last BCD counter takes a while to respond to the clock, and that causes a problem with the states if they are latched at any given time. There's almost no way they could be replaced with synchronous counters, so a solution for fixing the ripple counter chain would be really good.

 

I added a 15pF on the output of each AND gate to 0V and that has fixed the problem.

 

Many years back I had a strange error on a multi-digit ripple counter tachometer. At every hundreds change it would be wrong, off by a few hundreds. Since the hardware was already built and being checked prior to installation, a re-design was not an option. So the fix was, similar to post #27, adding a very small capacitance to delay the latch pulse to just a bit longer than the ripple delay time. Easy and it worked.

 

Many years back I had a strange error on a multi-digit ripple counter tachometer. At every hundreds change it would be wrong, off by a few hundreds. Since the hardware was already built and being checked prior to installation, a re-design was not an option. So the fix was, similar to post #27, adding a very small capacitance to delay the latch pulse to just a bit longer than the ripple delay time. Easy and it worked.

That's interesting because I was going to try that too for my application. I have to delay by about 320ns though. That could mean adding another gate, but I'll check if there were any left over first. Even adding a single gate would be cake compared to having to replace every single counter in the string.

(FF=Flip Flop)
As an interesting side note, it is interesting to think about what is happening to the counters (or FF's) in between the first and last when a pulse on the first FF comes in that causes all of the FF's to go back to zero. Here, they would all have Q=1 until that next pulse, and then they would all have to go to Q=0. Since they are ripple carry FF's, it would be one at a time so it would take time for that pulse to 'propagate' from the input to the last FF (which could be the output). This means that while the input is going to the next pulse, there is still a chain of events like dominos traveling down the line of FF's. If the string of FF's is long enough, we could see more pulses come in to the first FF (or the first BCD counter really). If 5 more pulses came in, that would mean the first counter would show a count of '5' as the last FF in the string goes to Q=0. So instead of 0x00000000 we would see 0x00000005 just as the last FF in the last counter flipped to zero.
This would normally preclude the use of a delay on the latches, but if the input pulse was disabled at the right time, I think it would work as that would mean after that last input pulse the input would be disabled, and after say 300ns the count would be all 0's.
This quasi-propagation would make the whole string look like a digital transmission line for that short time.

 

The capacitor is not to increase delay but to suppress the short duration glitch. See post #4.

 

The capacitor is not to increase delay but to suppress the short duration glitch. See post #4.

Oh ok no problem, in my application it would be to delay the latching of the entire count.

 

That's interesting because I was going to try that too for my application. I have to delay by about 320ns though. That could mean adding another gate, but I'll check if there were any left over first. Even adding a single gate would be cake compared to having to replace every single counter in the string.

(FF=Flip Flop)
As an interesting side note, it is interesting to think about what is happening to the counters (or FF's) in between the first and last when a pulse on the first FF comes in that causes all of the FF's to go back to zero. Here, they would all have Q=1 until that next pulse, and then they would all have to go to Q=0. Since they are ripple carry FF's, it would be one at a time so it would take time for that pulse to 'propagate' from the input to the last FF (which could be the output). This means that while the input is going to the next pulse, there is still a chain of events like dominos traveling down the line of FF's. If the string of FF's is long enough, we could see more pulses come in to the first FF (or the first BCD counter really). If 5 more pulses came in, that would mean the first counter would show a count of '5' as the last FF in the string goes to Q=0. So instead of 0x00000000 we would see 0x00000005 just as the last FF in the last counter flipped to zero.
This would normally preclude the use of a delay on the latches, but if the input pulse was disabled at the right time, I think it would work as that would mean after that last input pulse the input would be disabled, and after say 300ns the count would be all 0's.
This quasi-propagation would make the whole string look like a digital transmission line for that short time.

If your clock rate is faster than the maximum propagation delay through the ripple counter, then your design is pretty much hopelessly bad. Anything you do to "fix" it largely amounts to design-by-happening, in which you make slapdash changes hoping that, somehow, someway, something happens to work.

 

Many years back I had a strange error on a multi-digit ripple counter tachometer. At every hundreds change it would be wrong, off by a few hundreds. Since the hardware was already built and being checked prior to installation, a re-design was not an option. So the fix was, similar to post #27, adding a very small capacitance to delay the latch pulse to just a bit longer than the ripple delay time. Easy and it worked.

So, in other words, a bad design that was poorly validated resulting in a slapdash hack "fix" that happened to work under the conditions at the time, with no guarantee that it would work in the future on a particularly hot or cold day or when the voltage supply was a bit higher or lower, or when a chip was swapped out a few years down the road.

Sure hope it was not any kind of critical component in some system.

 

So, in other words, a bad design that was poorly validated resulting in a slapdash hack "fix" that happened to work under the conditions at the time, with no guarantee that it would work in the future on a particularly hot or cold day or when the voltage supply was a bit higher or lower, or when a chip was swapped out a few years down the road.

Sure hope it was not any kind of critical component in some system.

It was a "one off" creation of a display used in a setup mode. And the supply voltages were all regulated. and if there had ever been an issue it is CERTAIN that we would have been notified.

 

If your clock rate is faster than the maximum propagation delay through the ripple counter, then your design is pretty much hopelessly bad. Anything you do to "fix" it largely amounts to design-by-happening, in which you make slapdash changes hoping that, somehow, someway, something happens to work.

What do you base this idea on?

For example, say we have 8 binary counters, 4 bits each, for a total of 32 bits. Each 4 bit package has max 40ns delay. Total delay for the string is 320ns. Does this mean you think the max input frequency would be 3125000 Hz?
Keep in mind that the frequency out of the first flip flop would be half that,1562500Hz, then 78125Hz (2nd), then 390625Hz (3rd), and then out of the last FF of that 4 bit counter 195312.5Hz. That's under 200kHz, so the next stage 4 bit counter would only have to be able to handle a frequency of around 200kHz.
The only problem seems to be that at 10Mhz which has a clock period of 100ns, as the last stage FF is getting it's last pulse, which takes 300ns (rounded from 320ns) the first stage would have counted 3 more pulses.
So instead of a total count of 0x00989680 we'd see a total count of 0x00989683.
I would think the output frequency from the last FF would be the right value, but the phase would be off by 3 counts.

 

In most cases, you are using a counter to count something, which means that you need to be able to reliably look at the collection of output bits as meaning some value. If some of the bits reflect subsequent clock events and other bits reflect earlier clock events, your counter's output value is meaningless. You can't reliably recover which bits are associated with which clock in order to correct things, because you have no reliable way to know where the clock event boundaries are. Worse, you can't even reliably capture the counter's state because you can't ensure that setup and hold times will be met.

In the very narrow application of using a ripple counter to obtain a divided-down clock, you can get away with this, but if you want to use more than one stage's output, you have a lot of potential issues that you are responsible for validating.

In general, having a longer propagation time than the clock period is extremely problematic, which is why so much effort was (and continues to be) put into developing fast look-ahead logic implementations to reduce end-to-end propagation delays.

 

In most cases, you are using a counter to count something, which means that you need to be able to reliably look at the collection of output bits as meaning some value. If some of the bits reflect subsequent clock events and other bits reflect earlier clock events, your counter's output value is meaningless. You can't reliably recover which bits are associated with which clock in order to correct things, because you have no reliable way to know where the clock event boundaries are. Worse, you can't even reliably capture the counter's state because you can't ensure that setup and hold times will be met.

In the very narrow application of using a ripple counter to obtain a divided-down clock, you can get away with this, but if you want to use more than one stage's output, you have a lot of potential issues that you are responsible for validating.

In general, having a longer propagation time than the clock period is extremely problematic, which is why so much effort was (and continues to be) put into developing fast look-ahead logic implementations to reduce end-to-end propagation delays.

Ok that makes sense.

What are your thoughts on a frequency counter using ripple carry counters only?
We can assume binary counters for simplicity, although BCD counters would be actually used.

The operation would be that the input clock pulses would be gated by an independent divider so that the enable is set for exactly 1 second. At the end of that 1 second, the count would be latched, but due to the total propagation delay of that last counter perhaps the latching could be delayed by some small time period like 350ns. There would be no additional input pulses in this operation.

 

Ok that makes sense.

What are your thoughts on a frequency counter using ripple carry counters only?
We can assume binary counters for simplicity, although BCD counters would be actually used.

The operation would be that the input clock pulses would be gated by an independent divider so that the enable is set for exactly 1 second. At the end of that 1 second, the count would be latched, but due to the total propagation delay of that last counter perhaps the latching could be delayed by some small time period like 350ns. There would be no additional input pulses in this operation.

No problem there. There is a delay between the end of the gate signal and the start of the latch signal. Better still if the latch signal is level sensitive, i.e. the data is latched on the trailing edge of the signal.

Glitches are more likely to occur when trying to interrogate outputs of the counters.

 

No problem there. There is a delay between the end of the gate signal and the start of the latch signal. Better still if the latch signal is level sensitive, i.e. the data is latched on the trailing edge of the signal.

Glitches are more likely to occur when trying to interrogate outputs of the counters.

Hello,

This became interesting to me because I haven't thought about this in probably 20 years, and the frequency counter I built was done probably 50 years ago (yikes).

By "no problem" I guess you mean with the added 320ns delay for the latches? Actually assuming 10ns per FF and 10ns gate delays and 10ns latch delays that would mean (ideally) 310ns.

What is amazing now that I think about it is that if the input clock gate signal goes low and the latch is enabled 10ns later, since there are a total of 32 FF's in the ripple counter line and each has a CP to Q delay time of 10ns, that would mean it would take about 300ns for the last FF to flip, and that means that even the one before that did not flip yet, and the one before that, and the one before that, all the way up to the 2nd FF. That would mean that 30 FF's would not have flipped yet to the correct states (each one takes 10ns to flip). That would be worst case though. So I think the extra delay of 310ns would be needed, or maybe 350ns to be sure.
That's what it seems like anyway.

 

Ok that makes sense.

What are your thoughts on a frequency counter using ripple carry counters only?
We can assume binary counters for simplicity, although BCD counters would be actually used.

The operation would be that the input clock pulses would be gated by an independent divider so that the enable is set for exactly 1 second. At the end of that 1 second, the count would be latched, but due to the total propagation delay of that last counter perhaps the latching could be delayed by some small time period like 350ns. There would be no additional input pulses in this operation.

This will work -- and notice that it employs the constraint that I was talking about. You need to allow enough time for everything to propagate fully before you allow the next thing to happen. In this case, before you can use the counter value, you have to wait that 350 ns or so and that is the fastest that your logic that uses the counter output can run at. Let's call it 3 MHz for simplicity. This is the fastest that your "system clock" can run at. The counter itself can work with a faster input signal because nothing it being done with it's outputs while it is counting, but the counting signal (which, conceptually, isn't a clock but just an input signal to the system) is being gated by the 3 MHz system clock. It disables the input signal to the counter on one clock period and captures the counter's output value on the next.

Now, from an implementation standpoint, cheats and shortcuts can be taken, for instance having a sequencer that enables the gate for one second and, upon expiring, starts a delay that holds off capturing the counter output for the needed propagation time, as long as they observe the constraints where critical. In most systems, those constraints are critical at every clock cycle, placing that upper limit on achievable clock frequency.