5
\$\begingroup\$

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?

Enter image description here Enter image description here

\$\endgroup\$
5
  • 1
    \$\begingroup\$ 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)? \$\endgroup\$
    – Math Keeps Me Busy
    Dec 18, 2020 at 20:06
  • 1
    \$\begingroup\$ Can you make the image a bit larger and sharper? Or draw it using the built-in schematic editor. \$\endgroup\$
    – Bruce Abbott
    Dec 18, 2020 at 21:07
  • \$\begingroup\$ "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? \$\endgroup\$
    – Bruce Abbott
    Dec 18, 2020 at 21:10
  • \$\begingroup\$ 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. \$\endgroup\$
    – Greycon
    Dec 18, 2020 at 21:36
  • \$\begingroup\$ @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? \$\endgroup\$
    – Greycon
    Dec 18, 2020 at 21:39

3 Answers 3

Reset to default
6
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ 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. \$\endgroup\$
    – Greycon
    Dec 18, 2020 at 22:35
5
\$\begingroup\$

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:

Schematic of synchronous counter with registered output

Simulation of synchronous counter with a registered output

\$\endgroup\$
1
  • \$\begingroup\$ 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 ;-) \$\endgroup\$
    – Greycon
    Dec 19, 2020 at 2:21
3
\$\begingroup\$

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.
\$\endgroup\$
4
  • \$\begingroup\$ 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. \$\endgroup\$
    – Greycon
    Dec 18, 2020 at 22:55
  • 1
    \$\begingroup\$ It's not really possible to do a gray-code counter using the ripple approach. But, yes, the lookhead would work fine. \$\endgroup\$
    – hacktastical
    Dec 18, 2020 at 23:14
  • \$\begingroup\$ If I change to using a synchronous counter, and decode that, it still has the possibility of a glitch, is that correct? \$\endgroup\$
    – Greycon
    Dec 19, 2020 at 0:16
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – hacktastical
    Dec 19, 2020 at 2:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.