Stats

  • Locked Locked
  • Replies 7
  • Subscribers 92
  • Views 24565
  • 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

query on improving clock latency

abhaska

Hi all

Can anyone of you please share your views on improving clock latency in the CTS phase of the physical design flow.

Thanks

-Arun

Parents

  • Great question! Reducing insertion delay is of course particularly important because it reduces the impact of timing derating on achieving timing closure.  Less insertion delay equals less effective derated clock skew, which makes it easier to achieve timign closure.

    I asked around to some of my colleagues and have some additional suggestions to consider:

    • Set a MaxDelay constraint of "0" in your clock tree spec file. This tends to task each stage of the clock tree building to focus more on insertion delay.  Note: I haven't tested this with the 8.1 setCTSMode -optLatency/-optLatencyMoveGate options Kari mentioned.
    • Constraint the clock net routing to be on upper metal layers that are less resistive using the TopPreferredLayer and BottomPreferredLayer constructs.
    • Check for the presence of FIXED, dont_touch or dont_use markings on instances and library cells (for example, clock gating cells) that exist in the clock network prior to calling CTS.
    • Try to provide at least one strong driving cell candidate that CTS can use to drive a large fanout.
    • Supply inverters to CTS rather than buffers.
    • Use the MaxCap construct to help heavily loaded and therefore slower clock buffers.
    Of course these suggestions aren't 100% effective- rather they're things that we've tried with some degree of success that we thought to share for your consideration.

    Any other ideas out there?
Reply

  • Great question! Reducing insertion delay is of course particularly important because it reduces the impact of timing derating on achieving timing closure.  Less insertion delay equals less effective derated clock skew, which makes it easier to achieve timign closure.

    I asked around to some of my colleagues and have some additional suggestions to consider:

    • Set a MaxDelay constraint of "0" in your clock tree spec file. This tends to task each stage of the clock tree building to focus more on insertion delay.  Note: I haven't tested this with the 8.1 setCTSMode -optLatency/-optLatencyMoveGate options Kari mentioned.
    • Constraint the clock net routing to be on upper metal layers that are less resistive using the TopPreferredLayer and BottomPreferredLayer constructs.
    • Check for the presence of FIXED, dont_touch or dont_use markings on instances and library cells (for example, clock gating cells) that exist in the clock network prior to calling CTS.
    • Try to provide at least one strong driving cell candidate that CTS can use to drive a large fanout.
    • Supply inverters to CTS rather than buffers.
    • Use the MaxCap construct to help heavily loaded and therefore slower clock buffers.
    Of course these suggestions aren't 100% effective- rather they're things that we've tried with some degree of success that we thought to share for your consideration.

    Any other ideas out there?
Children
No Data

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.