How to handle multiple physical IO pins for a single port?

Hi Zhou,

In a previous layout that I did, I could not create 2 pins for the same net with pad.io file (use with command " loadIOFile"). I have to use DEF to achieve this. Hope this info is helpful.

Regards,
Eng Han

Hi, Eng,

Thank you for your inform. I did the same procedure to load in multiple physical pin definition (in def, there are 'pin.extra*' for second pin or third pins). However, I couldn't figure out how to let FE really take into account those multiple pin definitions when it do the placement and route. No matter how many pins per net I provide it by DEF in, it only base on one pin location (?randomly picked from multiple locations) per net to carry out its congestion analysis (during placement) and trial route. Did I forget to setup some special variable?

Thanks

Tongju

Is that what you have in the def file? I assumed nanoroute is doing the right connection since you did not mention about nanoroute. If that is true, it must be a bug in the trialRoute.

PINS 2 ;

- a + NET a .... ;

- a.extra1 + NET a ... ;

li siang

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

Hi Tongju,

I load back my old database and I also noticed that trialRoute only connect to one of the pins (the nearest one to the standard cell).

But nanoRoute connect it correctly to all the pins.

Regards,
Eng Han

I am running into this same issue... My incoming DEF has the syntax listed above, but I can't get FE to physically place the pin. Are there any new ideas to remedy this?

I can now get FE to place the pin.. The "square" shows up in the correct places. The "triangle" only shows up in the first port listed in the DEF. As such, nanoroute does not connect to the physical pin without the "triangle."

How did you get nanoroute to do this? I am running FE 6.2 in 64bit linux.

Was there a solution to this problem? I ran into the same issue with FE 6.2 USR2.

FE does not route to the ,extra* pins from a DEF (5.5) generated from an abstract. 

I don't aware there is any official fix to this issue in FE from Cadence since it may not be reported to Cadence as a bug fix or enhancement request (it is my fault that I only put the issue to this forum and haven't report it to Cadence officially yet). However, If you are only interested in creating a physical route for the extra pins, I have a work-around which you may like to try:

(1). create a macro (I called it "routeTo") with only one pin "A" and derive the lef file for it and add it into your stdcell LEF file.

(2). created a eco file to insert this "routeTo" macros to the nets that have extra pins. Your eco file should have lines like:

ADDINST extra_pin_netName_0 routeTo 1

INSTTERM A netName

(3). after "loadECO ecoFile", place those newly added routeTo macro to the location that you like to route to. You can have a placement file that has lines like "placeInstance extra_pin_netName_0 1290.0 2851.0" (don't let the routeTo macros to overlap the extra pins, which may let nanoRoute ignore those routeTo macros)

Then, nanoRoute should be able to route the nets to the points as you expect.

Also, somebody told me the "Wroute" engine may be able to take care the physical routing for the extra pins, but I didn't try it out...

Hope it help! 

Tongju