hierarchical & discrete low power clock gating

[averybadplant]

In low power ASICs, clock gating is essential to save power, as the clock network (wires, buffers, inverters, and transistors in DFF cells) can eat a significant part of the dynamic power of a circuit as it is a high-frequency signal.
Discrete clock gating can be handled automatically by most closed-source simulator when they encounter a code structure such as:

    logic [4-1:0] state_reg, state_reg_next;
    logic out_reg, out_reg_next;
    logic state_reg_update;
    
    always_ff @(posedge clk_i, negedge rst_ni) begin
        if (!rst_ni) state_reg <= 0;
        else if (state_reg_update) state_reg <= state_reg_next; // update condition
    end
    
    always_ff @(posedge clk_i, negedge rst_ni) begin
        if (!rst_ni) state_reg <= 0;
        else if (state_reg_update) out_reg <= out_reg_next; // same update condition
    end 

Here, the signal state_reg_update will be used as a enable condition, and the tool will create a clock gating cell to gate the clock landing on those registers. It is important for power efficiency as well as area efficiency that a clock gating cell drives multiple registers. Thus, registers can be grouped together in a clock gate group if their update condition is similar (maybe at the price of a mux at their input D to take the Q value if they should not be updated at this cycle).

However, the tool does not do hierarchical clock gating. Hierarchical clock gating means to clock gate a group of clock gating cells, to create a clock gating tree, spanning across modules hierarchies. It is up to the designer to OR those *_update signals and lower clock enable conditions of clock gating cells, to create a higher-level clock enable signal used to clock gate at a higher level. Usually, the designer tries to be clever, and hack a smaller clock enable signal condition than the ORing of lower level clock enable signals (and that creates more bugs :D ). Usually, the designer also add a busy / a clk_req output signal to each modules, telling that the block needs the clock to process, that can drive a clock gating cell at a higher level.

Unfortunately, hierarchical clock gating is the least concern for a designer, because it is often added to an existing block / hierarchy of block that was not made with that optimization in mind. Often, a sub-optimal clock enable condition will be guessed to drive a few clock gating cells, leading to poor clock power reduction. Such designs are often legacy or fgpa centric.

I would like to help ease clock gating handling in SpinalHDL. SpinalHDL designs are quite fpga centric, and clock gating, even the discrete/automatic way, is nonexistent. A simple example would be a RegNext popping up in a function used to pipe a stream. This is understandable, as in fpga designs, power is not a concern. Yet I believe that SpinalHDL could be turned into a great HDL for low power asic design at a minimal design cost.

First, SpinalHDL would have some context to be aware if the design requires clock gating or not. Usually for fpga, or area constrained designs, we don't care for instance.

In a Component, registers could be grouped manually into a clock gating group. I considered using something derived from an area, but that would be invasive, as it is a design choice that can be decoupled from the functional logic at hand.

For discrete clock gating of registers & registers created inside a function:

val a = Reg(Bool)
val b = Reg(Uint(32))

val cg1 = ClockGatingGroup()

cg1(a,b)
io.rsp <> cg1{ io.cmd.pipe() }

val cg2 = ClockGatingGroup()
...

It is rather ugly, maybe incorrect, but I am sure Scala could give some syntax sugar. There a clock gating group is created for registers a, b and registers created RegNextWhen in .pipe() function. The update condition of all those registers are OR'ed together to create the clock enable condition. This enable condition could then be used to instanciate a clock gating cell, or just by adding a when(cg_en) {...} into spinalhdl graph.

For designer that like to golf some area, a clock gating condition could be specified manually:

cg.override_enable(io.cmd.valid && someInflightValid)

For hierarchical clock gating, at the end of the elab of a Component, a clk_req output port could be created (todo: what happens if multiple clocks ?). Similarly, some clock gating groups could be created to group component instances together.

To go further into the idea, there can also be a clk_gnt port. If clock is not granted to the module instance, it must be disconnected from other modules instances communicating with it: streams are cut at the boundary. However it is a bit beyond the initial scope.

So I tried to make some inital code for this feature, but it was outside SpinalHDL core to avoid burdening it. However, this implementation means registers instanciated inside functions in libraries are hard to clock gate, or I was unable to. Thus I would like to discuss about with you, developers of SpinalHDL, if you would be interested in such a feature, how the user interface would be, how do you think it could be implemented inside the core. Again, I think SpinalHDL is a great designer tool, and with some features, would prove tremendously efficient in ASIC design as well. I have some limited knowledge of SpinalHDL internals, so I am ready to help developing such features :)

If you read this monster, thank you :D

[Dolu1990]

Hi ^^

So, i'm not an asic guy, and i never practiced glock gating.
What's about the ClockDomain clockEnable feature ?

hierarchical clock gating

So if i understand well, hierarchical clock gating would detect that sub modules local clock gating are in sleep, and so will also gate the clock at a higher level ?

In general, what is the difference between a local clock gating and the following ? :

val r = Reg(UInt(8 bits))
when(cond){
  r := r + 1
}

Regards
Charles

[andreasWallner]

For some components that we put on an ASIC we did what @Dolu1990 proposed: We used some ClockDomains with enable signals and in our toolchain clock gate cells are then automatically inserted by DC (if there are more than ~10 FFs with the same enable)
This gives you the advantage that crossings between different clock-enable domains are detected during generation and you have to flag them accordingly.

Since ClockDomains can be derived from each other it should also be quite doable to get a tree.
Where this could use some extension though is in additional functions that derive a ClockDomain - your example with a clock request could be one (i.e. a SlowArea(4, grant=someSignal)) or for some other common patterns like switching between dividers on demand (xxArea(slow=64, fast=4, useFast=someSignal)?), using a provided divider.

The other place where I see some possible work it with sync primitives between those domains. Going to/from a CD and a version of it with enable can use much more lightweight sync than between async CDs (i.e. just making sure that in the fast CD you don't fire multiple times on the same valid of a Stream). That is one of the major reasons why I often don't use a separate CD (especially if I targetting an FPGA).

[andreasWallner]

I think it would still make sense to think whether we can stick with the current model (having the enable signal in the ClockDomain) - otherwise we end up with two (incompatible) ways how to describe a CD with an enable signal? But yes, I see how it's not totally trivial to do that.

ClockEnableArea would just be some API on top of the "low level api"

yes, that is what it already is ATM? (but with the "old" way to make a CD with enable, so I'm not sure there is a backwards compatible way to change that)

[Dolu1990]

otherwise we end up with two (incompatible) ways how to describe a CD with an enable signal?

Is it incompatible ?

I mean something like :

class ClockDomain{
  ...
  def withEnable(enable : Bool, withGatedClock : Boolean = GlobalData.get.defaultWithGatedClock) : ClockDomain = withGatedClock match {
    case false => this.copy(enable = enable)
    case true => {
      val bb = new ClockGate()
      bb.clkIn := this.readClockWire
      bb.enable := enable
      this.copy(clock = bb.clkOut)
    }
  }
}

(but with the "old" way to make a CD with enable, so I'm not sure there is a backwards compatible way to change that)

I see what you mean, for it to have a chance to generate a blackbox, the user would have to either use myCd.withEnable(xx) or the ClockEnableArea.

hmmm
Don't know what is best

[Dolu1990]

Or maybe we can have both at the same time, meaning early elaboration time blackboxing, and eventualy SpinalHDL phase blackboxing if it appear that some API usage came from legacy API

[andreasWallner]

Is it incompatible ?

I understood your proposal as:

• Add a withGatedClock method, which generates the ClockGate in-place if the global setting is configured as such
• Keep the current method where we have a constructor with the enable signal parameter

That would leave us with two ways of defining a ClockDomain with an enable, both of which would behave differently - possibly I misunderstood. This is what I meant with incompatible - the different behavior that a user would get.
That and the possibly disappointment if one wants to reuse a block that uses the wrong way.

If we had a working blackboxing phase, would we still want to do the ClockGate instantiation in withEnable - or should we just generate a new CD with enable set accordingly and return that (and let blackboxing take care of it)? I'm not sure there is an advantage to that.
The drawback is that the returned ClockDomain from the withEnable that you sketched above would return a CD where we couldn't read the enable signal from - but I'm not totally sure that's a bad thing...

[Dolu1990]

That would leave us with two ways of defining a ClockDomain with an enable, both of which would behave differently

Yes, and idealy, when people create clock domain that has a enable / BB, they would always use withGatedClock

This is what I meant with incompatible

Ahh incompatible maybe a bit too strong to qualify it.

Using a phase instead => there is a few corner cases to handle :

• ClockDomain.readClockWire need to be patched in Phase
• What's about the the user logic which used the ClockDomain.readEnable
• The blackbox clockdomain mapping may need to be changed / pushed into Phase

in other words, a few descisions may already have been taken by user time depending the presence of the enable signal.

I'm not saying this can't be solved. but it may be tricky, while the user time handeling using withGatedClock handle "everything" early.

[Readon]

@Readon what is missing for this is a kind of blackboxing that generates the Blackbox for a clock gate instead of using clockEnables as we do in the normal case.

I still could not understand the logic underneath, why the BlackBox is expected? Does it mean a hack point for user who want to customize the function?

[andreasWallner]

If you don't want to depend on your synthesis tool to detect groups of registers with the same enable and insert a clock gate but want to be able to manually place them, then we need to have a way to instantiate a technology specific clock gate from SpinalHDL.
I see this was similar to memory blackboxing where we also insert blaxkboxes so that the user can provide technology specific modules.
At the same time this keeps the option to generate without the blackbox in case you e.g. want to synthesize for an FPGA for verification

[Readon]

So is that means there might be a bunch of use cases that people want to use their customized block instead of what lib provided?
These would include Mem or more generic, Components, Areas, and so on; also Clock Domains concentrate on clock and reset signals?

1. For Components a high level rework like mechanism might be a good choice, the existing rework works but could not be applied by Class.
2. Focus back on this topic, the Clock Domains related things, like I state before if a ClockTree is maintained globally, then user can use it everywhere, of course the drawback is also obvious, the design and clock are coupled too tight, making Component reuse hard.

Of course a reworkable ClockDomain is also necessary as you said for technology specific things.

[andreasWallner]

I wouldn't argue that generally - but there is a use-case for which we currently do not have a solution, even though we have the information to it: generate verilog where ClockDomains with an enable is generated with a ClockGate. Since there is no general ClockGate cell it would have to be a BlackBox (similar to, as you mentioned, memories)