Stats

  • Locked Locked
  • Replies 9
  • Subscribers 91
  • Views 17261
  • 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 handle multiple physical IO pins for a single port?

archive

When I P&R a huge block, there are situations that I need to place several physical IO pins for a single top level port/net, usually, on different sides of the block for the purpose of easing the higher level connection.   FE looks like only understand one physical IO pin for each port/net and when I did trial route, I found only one physical pin per net(port) was hooked up.  In this way, it coundn't estimate the real routing congestion through the whole block when I have hundreds of such kind cases of multiple IO pins (for each net/port).

How can I let FE know that there are several physical IO pins for a signle port and therefore, it will connect all of them together when it route the block for me?


Originally posted in cdnusers.org by tzhou@micron.com
Parents

  • Hi, Li siang,

    Thank you for your message.
    Yes, I have similar syntax in my DEF file for those multiple pins. Actually, after I saved floorplan, I did see the expecting information in the IOPin section. For example, for the "a" pin, I will see two entries, something like:
    ---
    IOPin: a 0.0000 191.3 W 2 0.5000 0.5000 fixed 1
    PinBox: 0.0000 191.3000 0.5000 191.8000
    IOPin: a 111582.4000 191.3000 E 2 0.5000 0.5000 fixed 1
    PinBox: 111582.4000 191.3000 111582.9000 191.8000
    ---
    Also, I tried to do a save-def operation and the new DEF file do have the mutiple pins. So, those multiple pin information did get into the tool correctly.

    Both trialRoute and nanoRoute connect only one pin no matter how many pins given for a net. Actually, this is not what makes me worry most since I can def-out the placement and use other tool (such as ccar) to finish those multiple pins connection. What really irritated me is how to reserve reasonable/proper routing channel. Because FE will not take into account those connections, so, its congestion estimate/report always give me unrealistic better result, especially when those multiple pin number is huge. More importantly, the "Perform Congestion Optimization" option in the placement stage will not work correctly to produce a routable placement. So, if there is any variables that will turn on the "real" recognization of mutiple pins, it will help me a lot.

    Thanks

    Tongju


    Originally posted in cdnusers.org by tzhou@micron.com
Reply

  • Hi, Li siang,

    Thank you for your message.
    Yes, I have similar syntax in my DEF file for those multiple pins. Actually, after I saved floorplan, I did see the expecting information in the IOPin section. For example, for the "a" pin, I will see two entries, something like:
    ---
    IOPin: a 0.0000 191.3 W 2 0.5000 0.5000 fixed 1
    PinBox: 0.0000 191.3000 0.5000 191.8000
    IOPin: a 111582.4000 191.3000 E 2 0.5000 0.5000 fixed 1
    PinBox: 111582.4000 191.3000 111582.9000 191.8000
    ---
    Also, I tried to do a save-def operation and the new DEF file do have the mutiple pins. So, those multiple pin information did get into the tool correctly.

    Both trialRoute and nanoRoute connect only one pin no matter how many pins given for a net. Actually, this is not what makes me worry most since I can def-out the placement and use other tool (such as ccar) to finish those multiple pins connection. What really irritated me is how to reserve reasonable/proper routing channel. Because FE will not take into account those connections, so, its congestion estimate/report always give me unrealistic better result, especially when those multiple pin number is huge. More importantly, the "Perform Congestion Optimization" option in the placement stage will not work correctly to produce a routable placement. So, if there is any variables that will turn on the "real" recognization of mutiple pins, it will help me a lot.

    Thanks

    Tongju


    Originally posted in cdnusers.org by tzhou@micron.com
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.