Will using AND gate with clock signal cause timing issues?

Question

I am creating a homebrew CPU with 74 series TTL chips.

I have a clock signal that goes to multiple registers. I have a particular register that I only want to update when the opcode is a particular value. So the solution seems to be an AND gate between the clock signal and the output of the logic used to decide if the register should update. This seems the only viable solution as the TTL chip does not have a separate enable line for controlling if the clock is used or not.

My concern is timing. Will the extra AND gate delay cause problems because it delays the clock signal to this register compared to other registers? Or should I place a double NOT gate on the clock line that is not going to the AND gate so both paths have the same timing?

Answer 1

It's a perfectly valid technique, but unless you're sure the signals are glitch-free you need to do a little extra in order to prevent glitches being treated as spurious clocks.

This page describes clock gating with latches, from which I have lifted these diagrams:

The latches should be the "transparent" type.

In general any signal which is an "enable" can be turned into a clock enable if you account for the effects on timing skew.

(I spent about a decade in a startup built around software for automatically managing clock gates and timing in VLSI design!)

Answer 2

Implementing this asynchronous way at this stage might be ok, but as your appliance grows, you will start getting bugs and delays from various parts of the circuit which may be not matchable and solvable easily and properly.

I propose you to change methodology of your design, and use synchronous circuits.

You latch opcode data into some reg and use opcode decoder connected to this reg. Decoding takes time; but you can be more or less sure that decoding will take not more than predefined nanoseconds (you can see it in decoder's + register's datasheets for your environmental setup). Then, when you are sure that decoder finished decoding, you use next clock pulse to latch state of decoder: true of false, depending if opcode matches or not. Assume your clock is 10 MHz, which gives 100 ns for completing all tasks: first pulse will latch opcode into register (it takes time), then decoding (it takes time) and only then you have good output of the state. If all these operations complete within, let's say, 60 ns, you can think you are safe, and 100% sure that you get stable proper digital signal as an output.

However explained above may add a level of complexity to your circuit (more register chips), all depends how complex whole implementation is and if you are ready to spend time troubleshooting and debugging timing issues.

Why not using CPLD or FPGA?