How to resolve clock gating hold checks (nets could not be fixed because it is clock net)?

Hi,

what the report is telling you is that it could not add a buffer to a net to fix hold, because the net is marked as part of a clock tree.
Is it possible that you have a clock serving as data on this clock gate EN pin?

You can try to define an exclude or ignore pin on an applicable position in the fanin to this pin, such that the clock tree is pruned before reaching the EN pin. Thus optDesign will be allowed to add buffers to these nets, since they will not be considered part of the clock tree anymore.

Alternatively you can try to tweak CTS to synthesize the clock tree such that the violation does not occur.

- Dimo

Dear Dimo

Thank you for your response.

DimoM said:

Is it possible that you have a clock serving as data on this clock gate EN pin?

Yes, the errors occure inside the clock gating logic. I attached a schematic of said logic below:

The startpoint of the violating path is the D-latch (DLHQHDLLX1) and the endpoint is the AND cell (AND2HDLLX4). The bottom input of the AND cell is the clock clk, and the top input is an enable signal.

DimoM said:

Alternatively you can try to tweak CTS to synthesize the clock tree such that the violation does not occur.

So if I understand you correctly, these erros can only be fixed by ccopt_design and not by optDesign -postCTS. Can you give me some more information on how to tweak CTS, i.e. what section of the user guide do I need to consume?

Hi,
from your screenshot it seems like the clock gating check is between the clock signal on the bottom and a regular data signal on the top path. 
This means that the cells behind the register (BU and NA2I1) on the top path should not be considered path of the clock tree.

You can try to enable to verbosity of your reports to see exactly which nets are being reported as unfixable.
How to report the list of nets that are failing after DRV optimization

On a separate note, is the DLHQHDLLX1 positive or negative level sensitive ? If it is positive level sensitive, you might consider replacing it for a negative level sensitive latch to follow best practices for robust clock gating.

- Dimo

Dear Dimo

Thank you very much for your support.

I used setOptMode -verbose true and re-ran the work flow. It appears that it is just the very last net before the AND gate that is failing. Here are some examples (the violating paths are highlighted in yellow):

Moreover, DLHQHDLLX1 is a high-active D-latch. Here is the truth table:

Negative triggered D-latches would be available, i.e. I could switch them.

So my tasks include:

- Switch all the high-active D-latches to low-active ones in the netlist
- Exclude the logic after the latch from the clock tree

If that is correct, could you provide a dummy example for the latter one?

Thank you.

I would like to partially answer my own question.

The commant to define ignore pins is

modify_ccopt_skew_group -skew_group <skew_group_name> -add_ignore_pins <path/to/pins>

However, my understanding is that this command is usually not written by the user; instead, it is generated automatically in the ccopt-spec file according to SDC constraints. An example can be found in the user guide at Clock Tree Synthesis -> Concepts and Clock Tree Specification -> Automatic Clock Tree Specification Creation. Here is an excerpt:

which results in

modify_ccopt_skew_group -skew_group ck2/func -add_ignore_pins d1/CK

at some point in the ccopt.spec file. My problem is that I don't quite know how to transfer this example to my design. In our design, there is one main clock (clk) which has several gated child clocks, all running at the same frequency. There are domain transitions from the parent clock to a child clock and vice versa, but there are no transitions between child clocks. So it would make sense to balance the parent clock with its child clocks, right?

Also, where do I define the source and startpoint of the generated clocks? At the latch? At the AND gate? In the schematics I provided earlier there is additional logic besides the latch and the AND gate. This is due to multiplexers that are present in those paths. Should their output be considered as the clock source?

Domi Hammerfall said:

So my tasks include:

- Switch all the high-active D-latches to low-active ones in the netlist
- Exclude the logic after the latch from the clock tree

Hi,

I would suggest to focus on fixing the clock-gating topology first and see what results Innovus produces.

Looking at the schematic again I see that there is a second signal fanning in to the clock gate through the NA2I1 cell. I would suggest to move this logic gate in front of the latch.
Also what is the purpose of the logic gate ON21 on the clock path towards the latch?

What you want to achieve is a topology similar to the one in the picture below, where also the clock tree is not diverging between the latch and AND gate.
So if you have an integrated clock gating (ICG) cell in the std. cell library, it is best to use it.

If not, try to recreate the ICG shown here, and also add constraints to the placer to keep the cells together.

https://youtu.be/LK12R_PbBts

- Dimo

DimoM said:

I would suggest to focus on fixing the clock-gating topology first and see what results Innovus produces.

I did a quick run where I manually replaced all active-high latches in the netlist with active-low ones. This leads to the same 23 hold violations, but with a slack as large as halve a clock period (?).

DimoM said:

Looking at the schematic again I see that there is a second signal fanning in to the clock gate through the NA2I1 cell. I would suggest to move this logic gate in front of the latch.
Also what is the purpose of the logic gate ON21 on the clock path towards the latch?

There are two multiplexers. The first one, which is in front of the clock gateing logic, is needed because of pin sharing. The second one, which comes after the clock gating logic, is needed to bypass the clock gating logic completely (there is an operational mode where the whole design is clocked with the main clock). The two cells we see in the schematic is the solution the synthesis tool comes up with to implement those multiplexers I guess.

DimoM said:

So if you have an integrated clock gating (ICG) cell in the std. cell library, it is best to use it.

Our process has a wide variety of clock gating cells, all of which are attributed as dont_use cells. In my CTS script, I set

set_ccopt_property clock_gating_cells {LSGCPHDLLX0 LGCNHDLLX2 LGCNHDLLX4 LGCPHDLLX2 LGCPHDLLX4 LSGCNHDLLX2 LSGCNHDLLX4 LSGCPHDLLX2 LSGCPHDLLX4 LSOGCNHDLLX2 LSOGCNHDLLX4 LSOGCPHDLLX2 LSOGCPHDLLX4}

but Innovus does not seem to care about them. if I check the design after the work flow, no clock gating cells have been inserted.

DimoM said:

If not, try to recreate the ICG shown here, and also add constraints to the placer to keep the cells together

I already use

setPlaceMode -place_global_clock_gate_aware true

in my placement script, which should achieve a similar behaviour. But I will consider using createInstGroup in my upcomming runs as well according to this guide.

Domi Hammerfall said:

There are two multiplexers. The first one, which is in front of the clock gateing logic, is needed because of pin sharing. The second one, which comes after the clock gating logic, is needed to bypass the clock gating logic completely (there is an operational mode where the whole design is clocked with the main clock). The two cells we see in the schematic is the solution the synthesis tool comes up with to implement those multiplexers I guess.

The logic synthesis tools are not well suited to synthesize the clock network. You will get a topology that is logically equivalent to what you asked for, but not necessary what you intended it to be.

That is why in many cases the clock network is described on the gate level to have a tighter control on the results. A toy example:
LGCN clk_gate1 (.EN(a), .Q(b),.CLK(clk));
MUX2 clk_mux (.S(sel), .A(clk_a), .B(clk_b), Z(clk));

In this way you have tight control on the clock topology.  Often designers would keep the file that maps the cells to a separate file to keep the code technology independent. For example :
ck_gate clk_gate1 (.EN(a), .Q(b),.CLK(clk));
And do the mapping to the lib cell in a separate file: LGCN ck_gate (.EN(EN ...

You can certainly refactor the code to make use of the ICG cells from your library. When you hard instantiate library cells in the design, the dont_use is not relevant, this attribute only prevents the tool from automatically using them in the design at its own discretion.

One clarification - set_ccopt_property clock_gating_cells will not make CTS replace the already existing logic with these cells, it cannot do logic transformations. This attribute lists the allowed cells that the tool can use to swap logically equivalent cells to fix DRCs, improve insertion delay etc.

- Dimo

Dear Dimo

Thank you for the clarifications.

It seems like the issue lies in the synthesis. If I investigate the VHDL code, all latches should be triggered when the clock is low (except for inverted clocks). However, when I look at the generated netlist, I can see that there are several active-high latches where there shouldn't. It seems like the synthesis tool optimizes some logic and replaces it with equivalent logic.

Following your recommendations, we now hard-coded the clock gating cells into our VHDL code and also removed any unnecessary logic. (this also eliminates the need of using instance groups to keep the cells together during placement) Furthermore, we rearranged the remaining logic such that it is placed before the clock gating cell. In the end, we can break down the logic of the clock tree to this:

Quick note: I am not sure whether the logic of the inverted gated clock is correct.

What is left is the correct constrainment of those gated clocks. Can you provide an example for clk_1 and clk_2_n, i.e. what do I need to write into the SDC file?

Hi,

you do not need to do anything special about this in the SDC file. Clock gating check will be automatically inferred on the gate, as explained in this article : What are the conditions to perform clock gating checks?
Furthermore, there should be no need to define generated clocks on the output of the clock gating logic.

However, I would reiterate on my recommendation to use an ICG cell instead of a separate latch and AND gate. You will then have the clock gating logic always tightly packed together and the single cell design of the clock gating will make sure there are no violations internally between latch and gate.

I do not see a conceptual difference between the top and bottom figure related to the clock gating. Of course, the timing on the input of the latch will change, but this will be indicated in the timing reports and will be taken care of by the tools.