How can I avoid a clock glitch?

I have a clock with a 50% duty cycle, driving a 3-bit ripple counter.

When Q2 is high, external lines such as address are stable. I want to generate a short read pulse between 50% and 75% of the Q2 signal to latch in data from external RAM / ROM.

Below is what I am using in LogiSim. But if I remember back to my digital electronics days (1980!), I can get a glitch between when the counter (Q2, Q1, and Q0) changes state, which might trigger a spurious RdPulse.

Is there a race hazard (e.g., when the counter changes from 111 to 000)? And if so, how can I avoid it?

• Yes, your image is hard to read. Are those J-K Flip-Flops? The terminals below Q, are they $\bar{Q}$? When you say state 11 and 00, do you mean the clock signal and the clock signal divided by 2 (I can't read the name, ClkExt?)? or between that second signal and ClkInt (which I believe is the previous signal divided by 2)? Dec 18, 2020 at 20:06
• Can you make the image a bit larger and sharper? Or draw it using the built-in schematic editor. Dec 18, 2020 at 21:07
• "I want to generate a short Read pulse between 50% and 75% of the ClkInt signal to latch in data from external RAM / ROM" - exactly what will you be using to 'latch' in the data? Dec 18, 2020 at 21:10
• Slightly better diagrams. They are D Flops, the diagram is a screenshot from Logisim. The "O" pins on the bottom of the FFs are Async Clear inputs. Dec 18, 2020 at 21:36
• @BruceAbbott Does it matter? It's a CPU built from LS TTL chips, so I currently use a 74LS273. Sorry, that sounds smart-assed (unintentional), I just mean, does that have a bearing on how I generate the RDPulse? Dec 18, 2020 at 21:39

To avoid the possibility of the glitch, you might consider making the read signal a registered output. This will require some redesign of your state machine, since if you simply put a register in front of your AND gate, the read pulse will occur almost one clock cycle later than without the register. Therefore you will have to change the fan-in to your AND gate to select state 101 rather than what you currently have, which selects state 110. With this done, you may put a register in front of the AND gate clocked from the same clock as the counter. This will generate the read pulse at about the same time in the 8 state cycle as what you currently have but without the possibility of the glitch.

• Elegant, that's the thinking I was missing! I'm a software guy, it's been many years since I did hardware design - it's a hobby project. Thank you. Dec 18, 2020 at 22:35

The 74LS273 is a D-type flip-flop which won't toggle.

You need to use J-K flip-flops (74LS73 or 74LS76) in toggle mode, i.e. J and K tied together and pulled high.

The output register can be a J-K flip-flop operating in D-type mode, i.e. using a NOT gate so that K equals not J. Or it can be a dedicated D-type (74LS273).

Something like this synchronous counter with a registered output:

• Tim, In my original post I do indeed use JK Flops for the ripple counter. I mentioned 74LS273 in a reply to @BruceAbbott w.r.t. how I "Latch" input data into my little CPU project. But thank you so much for the synchronous solution - I will steal that for sure ;-) Dec 19, 2020 at 2:21

Generally, using a ripple count is not a good idea if you care about skew and/or decoding the output.

So let's say you fix that. There's still the issue of inter-output skew and multiple outputs changing state, which can lead to glitches. There's several ways to address that:

• use a registered output for the decoded signal. Look ahead 1 state, decode that, then run it through a flop.
• Use gray-code count sequence. Gray-codes have the property of having one output at a time change state. This can be decoded without glitching.
• Use one-hot coding. Basically, dedicate a flop to each state. Then take the output of the one flop as your decoded signal.
• Thanks - I did look at Gray-codes, but I didn't find an easy way to create a GC counter. I think I will go with the 1 state-ahead Flop, that feels right to me. Dec 18, 2020 at 22:55
• It's not really possible to do a gray-code counter using the ripple approach. But, yes, the lookhead would work fine. Dec 18, 2020 at 23:14
• If I change to using a synchronous counter, and decode that, it still has the possibility of a glitch, is that correct? Dec 19, 2020 at 0:16
• Yes, that’s correct. When more than one output changes there is skew between the outputs that can cause a glitch. It’ll be smaller than the ripple counter but still present. Dec 19, 2020 at 2:34