• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Digital Implementation
  3. Hierarchical Design using characterized blocks timing i...

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 91
  • Views 15460
  • 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

Hierarchical Design using characterized blocks timing issues

DStathis
DStathis over 7 years ago

Hello,

I am trying to build a hierarchical design using Innovus, but I have a problem with closing the timing.

My design is composed by different clone and master blocks. I partition the design and I do the block level implementation for each master partition. From the block level implementation I generate DEF, LIB and LEF files, along with the netlist (.v file) of each master partition. I manage to fix the timing in each partition. The problem comes when I am trying to close the timing on the top level. I am using the LIB and LEF files to create the layout and do the clock tree synthesis and Routing. Up to the point before I assemble the design everything looks to be ok. After I assemble the design the timing breaks down. One issue that I notice, is that the clock used after assembling the design, when I do the timing analysis, is the ideal clock. I use the update_clock_latencies command to get the actual clock and that is when the timing gets violated.

 

I have also used the set_propagate_clock command in my constraints when importing the top design. That solved the ideal clock problem (now i am getting propagated clock), but the overall timing violation issue remained. Meaning that before assembling the design everything works as expected and the timing is met. After I assemble the design the timing gets violated.

 

I am sorry if the question is kind of stupid, my experience is limited. Any help would be greatly appreciated.

 

Best Regards,

Dimitrios

  • Cancel
  • Kari
    Kari over 7 years ago

    Did you balance the clock tree to your blocks? I haven't done clock trees in a long time, but in the old CTS method, we would use a "macromodel" that basically told the top-level what the insertion delay inside the block was, so that the top-level tree could balance the leaf flops. Even with that though, you are likely to see some timing violations in flat timing that you did not see at the block-level. This is normal.

    • Cancel
    • Vote Up +1 Vote Down
    • Cancel
  • DStathis
    DStathis over 7 years ago in reply to Kari

    Thank you for your answer. I have balance the clock tree inside the blocks and used the blackbox model (.lib) that does include, to my understanding, the timing information of the block.

    Since it is natural to see that kind of violations in the flat timing, what is the process that you follow in order to fix this kind of violations?

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • sachintaneja
    sachintaneja over 7 years ago in reply to DStathis

    Dear Kari, Dimitrios

    I am also facing issue similar to this.
    I have two blocks separately implemented using the Encounter.


    They have huge CTS Global skew and i am unable to balance the CTS of two blocks.
    This is due to the number of logic elements in the two block. One block has 160 FF and simple in design and other has 550 and complex block in terms of logic.

    Block 1 : CTS : 1 level : Min Trig Skew: 20 ps , Max Trig Skew: 40ps
    Block 2 : CTS : 5 level : Min Trig Skew: 300 ps , Max Trigger Skew: 400ps

    It will be helpful if you can share how to balance (small skew can he handled in post silicon tuning) the CTS of two blocks to avoid top level CTS flow.

    It will helpful if any reference to balance the CTS in hierarchical design (current implementation) and top level CTS (future implementation) can be shared.

    Thanks,
    Sachin

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Kari
    Kari over 7 years ago in reply to DStathis

    We would see the timing violation in the flat timing run, then fix from there. This could mean a fix at the top-level or in the block, just depends on the design and the nature of the violation.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information