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?

  • \$\begingroup\$ Latency is unlikely to be a problem, but a timing latency analysis will prove that. One way is to use 2 gates in SET RESET ( low inputs) config. SET on opcode match , Clock the Q high into counter and let That pulse RESET the latch. If CPU is faster than 50MHz use faster logic 74LS00 responds in 10ns max \$\endgroup\$ Commented Oct 3, 2016 at 1:15
  • \$\begingroup\$ Luckily I am only aiming at 1MHz for the CPU. Anything about that would be a bonus so maybe I am worrying about nothing. It would have 1000ns between each clock signal. \$\endgroup\$ Commented Oct 3, 2016 at 1:21
  • \$\begingroup\$ why TTL when CMOS is soup de Jour? \$\endgroup\$ Commented Oct 3, 2016 at 1:28
  • 1
    \$\begingroup\$ Latency is not a problem, but skew is, and using an AND gate on the clock is an invitation to runt pulses. And which chip are you using, and why not use one with an enable? \$\endgroup\$ Commented Oct 3, 2016 at 3:44
  • 1
    \$\begingroup\$ Also, the signal that drives the AND gate must be glitch-free during positive phase of the clock. \$\endgroup\$
    – rioraxe
    Commented Oct 3, 2016 at 4:44

2 Answers 2


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!)


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?


Your Answer

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

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