Stats

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

Open ports in special route summary

Greatrebel

Hi All,

I got a summary after special routing below. It shows there are some ports open for stripe and core. But when I use verifyConnectivity to check, there are no violations. Is that a serious issue for PnR. How can I locate these open ports. Thanks in advanced

  Number of IO ports routed: 4
  Number of Block ports routed: 6
  Number of Stripe ports routed: 80  open: 2
  Number of Core ports routed: 185  open: 399
  Number of Power Bump ports routed: 0
  Number of Followpin connections: 292
  4 ports open due to poor power planning

Parents
  • Kari

     I think you're doing everything right, but just to double-check, try running:

    verifyACLimit -detailed -report aclimit.rpt

    This will output info for all nets, even if they pass the aclimit check. You can look in this file for your clock nets and make sure they do have some AC values, and that they are under the limit.

    Also try running without verifyACLimitSetFreq - then a toggle rate of 1 (100%) is assumed, which is pessimistic, but may give us some more info to look at. (You can also set the toggle rate with the -toggle parameter.) If you want the data from verifyACLimitSetFreq to be used, then you have to run verifyACLimit with the -use_db_freq parameter.

    The frequency number in the ACCURRENTDENSITY table is not used anywhere in the calculations, so you can ignore that. In fact, it's often listed as just "1". 

    To see how many clock buf/inv were added, look at the clock.report file that was generated during CTS. You can also use the Clock Tree Browser or the Clock Tree Analyst in the GUI.

    Finally, if the design is finished and you want to run everything in signoff mode, do the ac limit check after entering:

    setDelayCalMode -engine signalStorm 

    This will be more accurate.

    Let me know how the clock nets look in the detailed report.

    - Kari

Reply
  • Kari

     I think you're doing everything right, but just to double-check, try running:

    verifyACLimit -detailed -report aclimit.rpt

    This will output info for all nets, even if they pass the aclimit check. You can look in this file for your clock nets and make sure they do have some AC values, and that they are under the limit.

    Also try running without verifyACLimitSetFreq - then a toggle rate of 1 (100%) is assumed, which is pessimistic, but may give us some more info to look at. (You can also set the toggle rate with the -toggle parameter.) If you want the data from verifyACLimitSetFreq to be used, then you have to run verifyACLimit with the -use_db_freq parameter.

    The frequency number in the ACCURRENTDENSITY table is not used anywhere in the calculations, so you can ignore that. In fact, it's often listed as just "1". 

    To see how many clock buf/inv were added, look at the clock.report file that was generated during CTS. You can also use the Clock Tree Browser or the Clock Tree Analyst in the GUI.

    Finally, if the design is finished and you want to run everything in signoff mode, do the ac limit check after entering:

    setDelayCalMode -engine signalStorm 

    This will be more accurate.

    Let me know how the clock nets look in the detailed report.

    - Kari

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.