Line Decoder Logic Race

Question

I have a problem with this logic circuit I have designed:

The intended behaviour is: when the clock comes high, the counter's state is latched and decoded

What happens is: when the clock is high, the old state of the counter (if it has been incremented last cycle for example) is very briefly present on the line decoder's input before the latches switch to the 'new' data and the decoder's output then becomes correct

This means the 'fetch' mode is enabled again for a few ns before the decoder switches to 'load'. This causes the counter to be incremented again amongst other problems!

I have tried adding a string of NOT gates on the line decoder's enable, but it does not seem to help. Also, I tried using a capacitor+resistor to add a delay but this only helps when the created delay is a few micro seconds - far too long.

In summary I need to make sure the data is valid on the decoder's input before it is enabled - to prevent false triggering of its outputs.

NOTE: The increment input is decided by other circuitry that is triggered by the decoder - it is in phase with but is not necessarily the same as the clock

tl;dr line decoder is enabled too soon, chains of gates to delay signal don't help

Answer 1

In general you have to be careful when mixing different logic IC technologies:
The output of a LS gate (e.g, IC2a, 74LS08) cannot be used directly for an input of a CMOS gate (e.g. IC3, 4029).

In your case this may cause that the reset pusle is detected way too late.

At least you should add a pull-up resistor (because LS high output is not high enough for CMOS high input) or better just use CMOS AND-gates (4081) for IC2.

BTW: You can replace this whole circuit by one 4017 IC (Johnson Counter) with O3 shorted back to reset and 3 AND gates:

^{simulate this circuit – Schematic created using CircuitLab}

Answer 2

It's quite uncommon for inputs to arrive in-phase with the clock. The usual design is for inputs to be sampled at the rising edge of the clock. You see this in the 7474 you use; it triggers on the rising edge. See, for instance, https://commons.m.wikimedia.org/wiki/File:SPI_timing_diagram2.svg .

If you allow inputs to come in at the same time as the clock, you're going to have hazards. If nothing else, there's the race of the input vs the clock! As you try to design around that, you usually introduce hazards in other stages - as you've seen here.

That's one reason that you often see timing diagrams showing rise and fall times (as in the above-linked example). It makes it more clear when your timings are introducing hazards.

You may want to draw a Karnaugh map for your circuit to identify hazards and make sure that you're ok.

Answer 3

I think this is because of latch delay in 4514. You could consider to remove 7474 flip/flops or if you really need them replace 4514 with few nand gates all you need is three decoded outputs after all.