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?

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?