Stats

  • Locked Locked
  • Replies 12
  • Subscribers 92
  • Views 17099
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Domi Hammerfall

Dear community

I have a design with some unfixable hold violations. After the post-CTS optimization, I get the following output in the log file:

=======================================================================
                Reasons for remaining hold violations
=======================================================================
*info: Total 23 net(s) have violated hold timing slacks.

Buffering failure reasons
------------------------------------------------
*info:    23 net(s): Could not be fixed because it is clock net.

Resizing failure reasons
------------------------------------------------
*info:    23 net(s): Could not be fixed because it is clock net.

When I open the timing debugger, these violations are entitled as clock gating hold checks, which are described here.

If I run

report_timing -check_type clock_gating_setup -max_paths 23

then there is plenty of positive setup slack remaining. What could prevent the tool from fixing thos violations?

Thank you for any advice.

  • in reply to DimoM
    DimoM said:
    However, I would reiterate on my recommendation to use an ICG cell instead of a separate latch and AND gate.

    That's exactly what we are doing. Sorry if I didn't made that clear enough (the schematic is probably confusing because I drew them as separate cells.

    DimoM said:
    you do not need to do anything special about this in the SDC file

    Even if there are transitions from one "domain" to another? For example, our foundry recommends settingt a hold uncertainty of 0.6ns for all paths between 'different clocks' (even if they are generated from each other). Thus, we have something like this in our SDC files:

    set_clock_uncertainty -hold 0.6 -from [get_clocks clk] -to [get_clocks {clk_1 clk_2_n}]
    set_clock_uncertainty -hold 0.6 -from [get_clocks {clk_1 clk_2_n}] -to [get_clocks clk]

    To do so, we define the gated clocks as generated clocks. At least that is my understanding of that statement (might be incorrect). For clarification: In our design, there are no paths between gated clocks, but there is logic driven directly by the main clock clk, and there are transitions from the main clock to the gated clocks, e.g. there is a path from clk to clk_1 and vice versa.

  • in reply to Domi Hammerfall
    Domi Hammerfall said:
    our foundry recommends settingt a hold uncertainty of 0.6ns for all paths between 'different clocks' (even if they are generated from each other).

    Then I have to amend my statement:
    You do not need to do anything special about this in the SDC file, unless you have a reason to do so.

    My intention was to point out that the clock will automatically propagate through the clock gate. In your case, you have other reasons to add a generated clock, and this is fine.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.