0
\$\begingroup\$

I have a counter (74HC193) counting up with Qn outputs being decoded by a demultiplexer (74HC138). My clock pulses (CP) are no less than 100 microseconds long and the interval between them is always greater than that. The counter counts on the rising edge of CP. I disable the output of the demultiplexer when CP is high by directly tying CP to the not-enable input of the demux, to avoid random/spurious demux outputs from going true while the counter outputs are in transition.

This seems to work well enough however I am aware of the race condition between the counter outputs changing and the demux output being disabled quickly enough (by CP rising to high). I want to ensure that a spurious output on the demux never happens, given that CP rising is also what causes counting. The outputs from the demux are used sometimes to cause latches to latch and unlatch, and those devices (eg. 74HC74) respond to very narrow pulses, which entirely explains my worries.

I have read the Texas tome on slow or floating CMOS inputs, and datasheets describing propagation times and so forth and I am not finding myself competent enough to penetrate all that without going back to college. It is important to me to not expand the number of packages in my circuit, if I can at all avoid it. Adding a two-phase clock, for example, would be going too far.

My instinct is to just slow something down with a series resistor, either counting on the natural capacitance and high impedance of a CMOS input alone, or by adding some extra capacitance. I only need enough of a delay to solve the potential problem described above. Delaying the clock input to the counter seems the most likely route to me; but then I read the aforementioned tome from Texas and had a doubt. An RC solution slows down the signal, and any delay is just a consequence of that.

I also thought of simply immunising the inputs of any latches with a similar RC solution, and that is something I would like to do anyway.

So any general wisdom on slowing down or delaying CMOS logic input signals will be greatly appreciated as well as any on this specific scenario.

I should add that for sure my circuit will suffer from excess lengths of connections, random idiosyncratic sloppy design features by yours truly, and lots of other bad things. This is partly why I am looking for a little bit of an extra security blanket with this race condition thing. I should also add that I don't anticipate counting frequencies much higher than, say, 10KHz. (which is why I don't mind slowing some things down, if feasible)

I should also add that between CP and the clock input (CPu) there are already a couple of gate delays through separate packages (74HC04 and 74HC00), and there are a couple of spare inverters laying around that could be given a mission.

Representative Schematic

\$\endgroup\$
9
  • \$\begingroup\$ Please draw a schematic of your circuit. If the counter counts on the rising edge, why would you disable the multiplexer when the clock is low...the counter outputs will only be changing while the clock is high (if you clock is really high for 100us). \$\endgroup\$
    – Elliot Alderson
    Dec 23, 2020 at 18:45
  • \$\begingroup\$ Hi Elliot. Yes, I stated that incorrectly. I disable the mux outputs when the clock is high, not low. I enable them only when it is low. Good catch. \$\endgroup\$
    – DarylK
    Dec 23, 2020 at 18:54
  • \$\begingroup\$ You need to add the schematic just in case there is anything else like that. \$\endgroup\$
    – Elliot Alderson
    Dec 23, 2020 at 19:00
  • \$\begingroup\$ The circuit works fine, and is much more complex in totality than the little bit described here. I'm pretty sure the schematic would be more distraction than anything else. My question is more about the race-conditon and delaying signals in principle than about the specific circuit. I am not looking for repair help. Nevertheless, I will see if I can post a picture. I haven't figured out how to do that here yet! \$\endgroup\$
    – DarylK
    Dec 23, 2020 at 19:08
  • \$\begingroup\$ for a slightly and somewhat-inconsistently-delayed copy of the clock, branch off a line going through 2x (or 4x 6x etc) NOT gates in series... their latency is the delay. RC would obviously work too. \$\endgroup\$
    – Pete W
    Dec 23, 2020 at 19:37

1 Answer 1

Reset to default
2
\$\begingroup\$

Could you swap out your 74HC04 ic and replace it with a pin compatible 74HC14 hex schmitt trigger ic in order to avoid adding an extra package as you require.

The schmitt trigger is needed to square up (speed up) the delayed clock transition edges.

This delay circuit will delay the clock by about 10us.

Clock delay circuit

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I hadn't thought of using the schmitt triggers and wasn't actually aware of the 74HC14. It looks to me like this is the exact kind of solution I need for the clock race condition. It also inspires a solution to the idea of "desensitising" latch inputs, albeit at the expense of another package in some applications. Thank you James. \$\endgroup\$
    – DarylK
    Dec 23, 2020 at 21:10

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.