opinion, is the teacher correct?

MrChips

Joined Oct 2, 2009
30,720
As @WBahn pointed there are advantages and disadvantages to using asynchronous counters.

If you are only "looking" at the outputs of the flip-flops, in other words, looking with the human eye, such as in a ratemeter or frequency counter design then the glitch is not "visible". Don't say that to circuitry that is looking at all transitions or counting state changes.
 

dcbingaman

Joined Jun 30, 2021
1,065
As @WBahn pointed there are advantages and disadvantages to using asynchronous counters.

If you are only "looking" at the outputs of the flip-flops, in other words, looking with the human eye, such as in a ratemeter or frequency counter design then the glitch is not "visible". Don't say that to circuitry that is looking at all transitions or counting state changes.
By that definition, a circuit that is looking at 'all' state changes or counting state changes would find it impossible for all the outputs of a counter to change at the same time, each register will have its own unique time delay. They can never change all at the same 'time'. By using an expensive enough O-scope, I will always find 'in between' transitions that are not stable.
 
Last edited:

WBahn

Joined Mar 31, 2012
29,979
By that definition, a circuit that is looking at 'all' state changes or counting state changes would find it impossible for all the outputs of a counter to change at the same time, each register will have its own unique time delay. They can never change all at the same 'time'.
That's correct -- and that's what I mentioned in my post above. You have to allow for the potential that the individual changes occur in ANY possible order. This is the big challenge when designing circuits that have ANY kind of asynchronous behavior, be it using set/clear inputs as part of the logic implementation, or using gated clocks. A fully-synchronous design avoids this issue as long as the longest possible propagation delay is less than the time before the next sensitive event (usually a clock edge).
 

dcbingaman

Joined Jun 30, 2021
1,065
As @WBahn pointed there are advantages and disadvantages to using asynchronous counters.

If you are only "looking" at the outputs of the flip-flops, in other words, looking with the human eye, such as in a ratemeter or frequency counter design then the glitch is not "visible". Don't say that to circuitry that is looking at all transitions or counting state changes.
I agree. As long as the 'a-stable' part is 'stable' before the next clock edge (assuming you are using a clock driven system) it should be fine. I think we are in agreement but just trying to say different things.
 

WBahn

Joined Mar 31, 2012
29,979
True the counter itself is asynchronous, but if you only look at the counter output on the rising edge of the clock it does not matter. As shown in the following with the output taken from A,B and C.

View attachment 287032
This is still using the reset logic in a manner that requires careful analysis to ensure that it cannot produce ANY glitches because it is driving asynchronous inputs that will respond to most glitches (if the glitch is short enough, it may not be able to respond).

Registering the state outputs has NO effect on this, for a couple of reasons, not the least of which is that if glitches are an issue for the ripple counter portion of the circuit, they are still going to be a problem for that portion of the circuit. But that would still be the same if the reset logic worked on the registered outputs. Furthermore, you've introduced a cycle delay which may or may not be tolerable for the problem being solved.

But even worse than that, you've very possibly made the problem worse. The reset happens as soon as the output of the first stage of the ripple counter goes HI (when the last stage is already HI). That then changes the output back to a LO very soon after the CLK edge that cause the first change. This has the potential to violate the hold-time requirement for the DFFs being used to register the output. Normally this would be unlikely because commercial flip flops are designed so that the propagation delay is long enough to satisfy the hold-time requirement for logic that is driven by the same clock. However, you are mixing flip-flop types, so if the JKFFs are sufficiently faster than the DFFs, this because more likely and possibly even guaranteed.

I'll say it again -- ANYTIME asynchronous inputs are used as part of the functional implementation of a circuit, the verification of the circuit becomes MUCH more complicated -- there are demons in those waters that most designers are not prepared to deal with.

A recent example of this is this thread. The unwanted behavior of that circuit was completely predictable.
 

dcbingaman

Joined Jun 30, 2021
1,065
This is still using the reset logic in a manner that requires careful analysis to ensure that it cannot produce ANY glitches because it is driving asynchronous inputs that will respond to most glitches (if the glitch is short enough, it may not be able to respond).

Registering the state outputs has NO effect on this, for a couple of reasons, not the least of which is that if glitches are an issue for the ripple counter portion of the circuit, they are still going to be a problem for that portion of the circuit. But that would still be the same if the reset logic worked on the registered outputs. Furthermore, you've introduced a cycle delay which may or may not be tolerable for the problem being solved.

But even worse than that, you've very possibly made the problem worse. The reset happens as soon as the output of the first stage of the ripple counter goes HI (when the last stage is already HI). That then changes the output back to a LO very soon after the CLK edge that cause the first change. This has the potential to violate the hold-time requirement for the DFFs being used to register the output. Normally this would be unlikely because commercial flip flops are designed so that the propagation delay is long enough to satisfy the hold-time requirement for logic that is driven by the same clock. However, you are mixing flip-flop types, so if the JKFFs are sufficiently faster than the DFFs, this because more likely and possibly even guaranteed.

I'll say it again -- ANYTIME asynchronous inputs are used as part of the functional implementation of a circuit, the verification of the circuit becomes MUCH more complicated -- there are demons in those waters that most designers are not prepared to deal with.

A recent example of this is this thread. The unwanted behavior of that circuit was completely predictable.
I understand what you are saying. I have done this most often with an FPGA with no issues. But then the FPGA is using all the same register types and the tools allow me to perform timing analysis for worst case. Most of the time my clock was rather 'slow'. In order to speed up an algorithm I have frequently used combinatorial logic as long as the output was stable before the next clock edge it seems to work. But yes, there is issues and hold time is one of them.
 

dcbingaman

Joined Jun 30, 2021
1,065
This is still using the reset logic in a manner that requires careful analysis to ensure that it cannot produce ANY glitches because it is driving asynchronous inputs that will respond to most glitches (if the glitch is short enough, it may not be able to respond).

Registering the state outputs has NO effect on this, for a couple of reasons, not the least of which is that if glitches are an issue for the ripple counter portion of the circuit, they are still going to be a problem for that portion of the circuit. But that would still be the same if the reset logic worked on the registered outputs. Furthermore, you've introduced a cycle delay which may or may not be tolerable for the problem being solved.

But even worse than that, you've very possibly made the problem worse. The reset happens as soon as the output of the first stage of the ripple counter goes HI (when the last stage is already HI). That then changes the output back to a LO very soon after the CLK edge that cause the first change. This has the potential to violate the hold-time requirement for the DFFs being used to register the output. Normally this would be unlikely because commercial flip flops are designed so that the propagation delay is long enough to satisfy the hold-time requirement for logic that is driven by the same clock. However, you are mixing flip-flop types, so if the JKFFs are sufficiently faster than the DFFs, this because more likely and possibly even guaranteed.

I'll say it again -- ANYTIME asynchronous inputs are used as part of the functional implementation of a circuit, the verification of the circuit becomes MUCH more complicated -- there are demons in those waters that most designers are not prepared to deal with.

A recent example of this is this thread. The unwanted behavior of that circuit was completely predictable.
The other thing I learned early on had to do with asynchronous inputs such as a UART receiver. Not registering it before using it (synchronizing to the clock). I now typically use a three stage synchronizer for that type of signal just to avoid metastability (though that is another issue).
 

WBahn

Joined Mar 31, 2012
29,979
With an FPGA you have additional demons that would (should) prevent you from even considering using asynchronous logic for anything, including implementing a ripple counter.

FPGAs use look-up tables (LUTs) to implement the bulk of the logic and those are inherently glitchy, even when NONE of the logic signals involved are changing.

I found this out the hard way when I was a new engineer first working with FPGAs. I had a part of the design that had an inverter in it and the output was used to reset a counter in response to an external event using the asynchronous clear on the counter's inputs. It was resetting the counter when there was no external event and, upon porting the output of the inverter to a pin so that I could watch it on a scope, I could see that the signal had glitches all over it even though it was supposed to be absolutely solid. The problem was that that inverter was placed in a LUT that was shared with completely unrelated logic for a completely different part of the design. When any of THOSE signals changes, the address to the LUT changed and there was a momentary glitch on my inverter output as a result -- a glitch that was more than long enough for the registers to reset.
 

WBahn

Joined Mar 31, 2012
29,979
The other thing I learned early on had to do with asynchronous inputs such as a UART receiver. Not registering it before using it (synchronizing to the clock). I now typically use a three stage synchronizer for that type of signal just to avoid metastability (though that is another issue).
Yep. That's pretty standard practice when transitioning clock domains (or coming from a non-clocked domain into one, which is really the same thing).
 

dcbingaman

Joined Jun 30, 2021
1,065
With an FPGA you have additional demons that would (should) prevent you from even considering using asynchronous logic for anything, including implementing a ripple counter.

FPGAs use look-up tables (LUTs) to implement the bulk of the logic and those are inherently glitchy, even when NONE of the logic signals involved are changing.

I found this out the hard way when I was a new engineer first working with FPGAs. I had a part of the design that had an inverter in it and the output was used to reset a counter in response to an external event using the asynchronous clear on the counter's inputs. It was resetting the counter when there was no external event and, upon porting the output of the inverter to a pin so that I could watch it on a scope, I could see that the signal had glitches all over it even though it was supposed to be absolutely solid. The problem was that that inverter was placed in a LUT that was shared with completely unrelated logic for a completely different part of the design. When any of THOSE signals changes, the address to the LUT changed and there was a momentary glitch on my inverter output as a result -- a glitch that was more than long enough for the registers to reset.
That really is a strange issue. I would never thought that would be possible. (Referring to your using of a LUT for a reset to a counter) I did once run into a situation I was helping troubleshoot. We had a board with an 'event counter' inside an FPGA. It was registering multiple events even though only one event had technically occurred (intermittently). I watched that signal on a scope, it had some noise on it and a fairly long rise time thus the FPGA interpreted it as multiple events. I recommended adding a digital buffer before the FPGA with some hysteresis that fixed it. I would have thought a high end FPGA would have hysteresis on the digital inputs to begin with, but I was wrong.
 
Last edited:

WBahn

Joined Mar 31, 2012
29,979
That really is a strange issue. I would never thought that would be possible. (Referring to your using of a LUT for a reset to a counter) I did once run into a situation I was helping troubleshoot. We had a board with an 'event counter' inside an FPGA. It was registering multiple events even though only one event had technically occurred (intermittently). I watched that signal on a scope, it had some noise on it and a fairly long rise time thus the FPGA interpreted it as multiple events. I recommended adding a digital buffer before the FPGA with some hysteresis that fixed it. I would have thought a high end FPGA would have hysteresis on the digital inputs to begin with, but I was wrong.
It wasn't a problem with the digital input to the FPGA. The problem was there even with the input tied to a static value. The problem is inherent in LUT-based logic.

Let's say that you have an SRAM that is two bits wide and has four address lines. You can implement an arbitrary two-bit output function of four inputs. But you can also implement two completely independent one-bit output functions each with two input or a one-bit input function with three inputs and a separate one-bit input with one input (e.g., an inverter). This is accomplished by making two copies of the three-input logic and eight copies of the one-input logic within the LUT. As an input changes for one of the functions, the other function then merely transitions to a different copy. But ANY time ANY of the inputs to the LUT change, the outputs are read from a different memory location and there is the possibility for glitches to happen -- possibly multiple glitches. depending on how the address-decode logic is implemented. This is what was happening in my case -- the synthesis tool chose to put that inverter in the same LUT as the combinatorial logic for an unrelated part of the design.

The would be true even if a single component were implemented, such as a 4-input OR gate. Let's say that the input was 1011. That should result in the output being a 1. Now the input changes to a 1001, which should also result in an output of 1. But these two 1 values are stored in different memory locations and as the address bus changes from 1011 to 1001 the output can (and frequently will) glitch. As a result, ALL LUT-based logic exhibits static-0 and static-1 timing hazards and usually also exhibits dynamic timing hazards as well. This makes it completely unsuitable for ANY logic generation that is going to asynchronous inputs, including the generation of clock signals (referred to as gated-clocks).
 

dcbingaman

Joined Jun 30, 2021
1,065
It wasn't a problem with the digital input to the FPGA. The problem was there even with the input tied to a static value. The problem is inherent in LUT-based logic.

Let's say that you have an SRAM that is two bits wide and has four address lines. You can implement an arbitrary two-bit output function of four inputs. But you can also implement two completely independent one-bit output functions each with two input or a one-bit input function with three inputs and a separate one-bit input with one input (e.g., an inverter). This is accomplished by making two copies of the three-input logic and eight copies of the one-input logic within the LUT. As an input changes for one of the functions, the other function then merely transitions to a different copy. But ANY time ANY of the inputs to the LUT change, the outputs are read from a different memory location and there is the possibility for glitches to happen -- possibly multiple glitches. depending on how the address-decode logic is implemented. This is what was happening in my case -- the synthesis tool chose to put that inverter in the same LUT as the combinatorial logic for an unrelated part of the design.

The would be true even if a single component were implemented, such as a 4-input OR gate. Let's say that the input was 1011. That should result in the output being a 1. Now the input changes to a 1001, which should also result in an output of 1. But these two 1 values are stored in different memory locations and as the address bus changes from 1011 to 1001 the output can (and frequently will) glitch. As a result, ALL LUT-based logic exhibits static-0 and static-1 timing hazards and usually also exhibits dynamic timing hazards as well. This makes it completely unsuitable for ANY logic generation that is going to asynchronous inputs, including the generation of clock signals (referred to as gated-clocks).
Thanks for the very detailed response! That makes sense. What is surprising to me is that the synthesis tool would allow that but then again I suppose there is no way the synthesis tool would have known the reset was an asynchronous input/output.
 
Last edited:
Top