Stats

  • Locked Locked
  • Replies 10
  • Subscribers 61
  • Views 25161
  • 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

Properly optimizing enable to clock gating enable

archive

Hi,

I am curious to know how you handle the path to clock gating enable  pin.

I have a design containing multiple level of clock gating on the clock network and when synthesizing using ideal clock all my patht o enable pins have a full  cycle but when My CTS will introduced the latency of the network will reduce the available time to reach those pins.

I understand I could perform post CTS optimization but I would prefer a more robust method to constraint those in ideal clock mode.

I'am thinking of the 2 following approach and would like to hear from you if you have use them or if you have used any others.

- max_delay to enable pins equal to (clock period - expected network latency post clock gating element)
- defining generated clock after each clock gating element with different latency

Those 2 methods have the inconvenience of requiring a lot of data management  :(

Thanks for your help,
Eric.


Originally posted in cdnusers.org by evenditti
Parents

  • Hi Crispy Duck,

    Before the technical discussion, I am surprise that you are in Europe as "Crispy Duck" sound Asian. A surprise for you too; I am in Paris, but will be in Asia next month.

    You bring up a good point to explain why depending on who you talk to, some designers want the clock tree  to be after the clock gater (obviously to save power), and some designers want the clock tree to be before the clock gater (obviously to meet timing).

    In the design that I have here, the clock gaters at the base of the clock tree are hand instantiated, and there is always a pair of FFs (like the synchroniser) to drive the enable of the clock gaters. In this way, the logic from the FF to the clock gator is just a wire, and meeting  timing become easy.

    It is tricky to decide what should be the latency for the pair of FFs (in front of the clock gator). Ideally, they should have shorter latency. However, if you want to include them in the scan chain, then it is better to balance them. Also depend on where you place the clock gater. If it is placed next to the PLL, and is miles away from the core (and somehow you decide to place the pair of FF next to the clock gaters), then it is better to not balance the latnecy, and also exclude them from the scan chain (too many if here...).

    Now, back to the original question. If the designer does not know the impact of clock gaters on timing closures, the backend engineer will suffer; and the quality of the layout will be bad. The new RC 6.1 has some feature that can merge/split the enable condition of clock gaters. This might help, or make thing worse. Also, if timing closue due to clock gater inserted by the tool is a problem, then use a smaller fan-out for the clock gater (and don't do declone after that. "declone" is actually merging clock gaters together...). This will move the clock gater "near" to the FF, and thus have similiar clock latency.


    Regards,
    Eng Han

    PS: CD, could you send me a mail at enghan@eda-utilities.com. Would like to introduce some of the works I am doing to a experienced backend engineer like you.


    Originally posted in cdnusers.org by EngHan
Reply

  • Hi Crispy Duck,

    Before the technical discussion, I am surprise that you are in Europe as "Crispy Duck" sound Asian. A surprise for you too; I am in Paris, but will be in Asia next month.

    You bring up a good point to explain why depending on who you talk to, some designers want the clock tree  to be after the clock gater (obviously to save power), and some designers want the clock tree to be before the clock gater (obviously to meet timing).

    In the design that I have here, the clock gaters at the base of the clock tree are hand instantiated, and there is always a pair of FFs (like the synchroniser) to drive the enable of the clock gaters. In this way, the logic from the FF to the clock gator is just a wire, and meeting  timing become easy.

    It is tricky to decide what should be the latency for the pair of FFs (in front of the clock gator). Ideally, they should have shorter latency. However, if you want to include them in the scan chain, then it is better to balance them. Also depend on where you place the clock gater. If it is placed next to the PLL, and is miles away from the core (and somehow you decide to place the pair of FF next to the clock gaters), then it is better to not balance the latnecy, and also exclude them from the scan chain (too many if here...).

    Now, back to the original question. If the designer does not know the impact of clock gaters on timing closures, the backend engineer will suffer; and the quality of the layout will be bad. The new RC 6.1 has some feature that can merge/split the enable condition of clock gaters. This might help, or make thing worse. Also, if timing closue due to clock gater inserted by the tool is a problem, then use a smaller fan-out for the clock gater (and don't do declone after that. "declone" is actually merging clock gaters together...). This will move the clock gater "near" to the FF, and thus have similiar clock latency.


    Regards,
    Eng Han

    PS: CD, could you send me a mail at enghan@eda-utilities.com. Would like to introduce some of the works I am doing to a experienced backend engineer like you.


    Originally posted in cdnusers.org by EngHan
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.