Clock Gating

A project log for SPAM-1 - 8 Bit CPU

8 Bit CPU in 7400 with full Verilog simulator and toolchain

john-lonerganJohn Lonergan 09/07/2019 at 11:545 Comments

I'd prefer not to mess with the clock. If I'm using a chip like the 8 bit register 74HC377 which has a LE (latch enable) and clock then I can bring LE high to disable the input to the latch.

But what if I'm using 74HC574 which is also an 8 bit register which is similar to the 74377 but swaps the LE for OE (output enable). If I need control over whether data is clocked into this chip then the only option left to me is to gate the clock.

One of the main things to avoid with clock gating is the problem of creating spurious clock signals. Whether there is a risk of this depends on the method taken for the gating and the relative timing of the raw clock versus the other signals with which you are gating the raw clock.

Whilst a spurious clock may or may not be a problem when latching it is more likely to cause an issue with a counter, such as in the program counter or within a microcode circuit's timing. Having the counter advance unexpectedly and with an extremely short duty cycle would likely cause a malfunction including violating timing constraints of other components within the overal circuit.

A common case is where the clock is ANDed with some other control signal - I need to do exactly this in a register file I'm designing because I'm using 74HC574 which doesn't have a LE input. I need the 74HC574 for it's tristate output which means I need to compromise on the clock gating. It a question of reducing the complexity. But now I'm worried about gating effects. A spurious clock might make me latch the wrong value. Surely an AND of a control signal and the clock won't cause a problem?

The paper A Review of Clock Gating Techniques covers a few of the approaches to clock gating and the first option discussed is a "simple" AND gated approach. The paper demonstrates how the relative timing aspect can cause spurious triggers.

However in the paper I wondered whether the analysis was correct, whether a hazard had been missed. Below I've highlighted the transition I'm concerned about in this extract.

It seems to me that there is a risk that this transition might cause a spurious clock on Gclk. This might happen if the en went high moments before the fall of the raw clk. Whether or not this potential glitch occurs in practice depends on the derivation of the en. In a CPU the en signal might be generated from some combinatorial logic and is likely to lag the clk due to propagation delays, in which case the problem I'm concerned about wouldn't happen. 

The paper same paper goes on to criticise NOR and also other techniques - worth reading.

Timing matters.


John Lonergan wrote 09/09/2019 at 21:24 point

Is that a possum? (I'm UK what do I know)

  Are you sure? yes | no

Ken Yap wrote 09/09/2019 at 22:35 point

Ringtail possum

  Are you sure? yes | no

Ken Yap wrote 09/09/2019 at 00:59 point

The problem with NOR is just the converse of AND and happens when the input is triggered on the other edge. I encountered this gating issue with the fast forward buttons in a discrete binary timepiece. What I did was put the gate as far back in the counter chain as possible and accept a possible extra count in a low order bit not displayed. Of course if my clock were to be implemented with microcontrollers these days everything is synchronised to the code execution.

  Are you sure? yes | no

John Lonergan wrote 09/07/2019 at 13:41 point

Done thanks for pointing out

  Are you sure? yes | no

Ken Yap wrote 09/07/2019 at 12:54 point

Could you fix the non-working link to the paper please?

  Are you sure? yes | no