Stats

  • Locked Locked
  • Replies 2
  • Subscribers 91
  • Views 1819
  • 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

routing P/G for I/O cells

andreid
Hi everybody,

Can somebody help me, please, telling how to route P/G pins for I/O cells having a different voltage supply from the core power supply? Beside the I/O cells’ pins connected to the core and included in the verilog netlist I have few pins belonging to the I/O cell and their own power supply pins (vdde and gnde) that should be tied to a different power supply. What is the common way to do such connections?

Thank you a lot.

 
Parents
  • Hi Kari,Excuse me for the delay to reply and thank you very much for your attentionI tried the abutment procedure but didn’t work from the beginning. Actually I couldn’t use the globalNetConnect to route even vdd and gnd. The tool complaints that couldn’t identify the nets and the pins. At the verification phase Encounter reported many connectivity errors. I checked, there are no gaps between IO cells zooming in, at extreme values. Additionally I must say the all the sides of the chip were carefully balanced, choosing all cells with same widths.The things started to settle the moment when I introduced in my netlist vdde, gnde (power supply for IO cells) and other rails used in the IO ring (mostly esd protection related). I don’t know how somebody else handled this stuff, but globalNetConnect couldn’t work based on LEF files. It might be because I don’t have a complete view of layers how somebody suggested. The CMOS family is very recently issued and I got the libs from the manufacturer but I cannot identify the pins vdd, vdde, gnd, gnde (& all pins related to esd protection) in Encounter. I see it in the LEF (which is text) file but I do not see in the layout. The logical pins of the IO cells are easy to identify on the screen. Is this thing normal?As I say, now I don’t have the errors reported but still a thing bothers me and if you could help me would be great. The vdd and gnd traces between the power supply cells and the ring are not equal in width and some of them go to an abutted IO cell with the power supply cell. I placed the core power cells in the middle of each side. The width of the traces is 4 um and 12um.I would like to have all of 4 um as I aked for the power ring. Also I think if I could limit their number, the connections to the abutted IO cells would disappear. The used command for srouting is:sroute -connect { blockPin padPin padRing corePin } -layerChangeRange { M1 LB } -blockPinTarget { nearestRingStripe nearestTarget } -padPinPortConnect { allPort oneGeom } -checkAlignedSecondaryPin 1 -blockPin useLef -allowJogging 1 -crossoverViaBottomLayer M1 -allowLayerChange 1 -targetViaTopLayer LB -crossoverViaTopLayer LB -targetViaBottomLayer M1 -nets { gnd vdd }                where five options are by default (M1 is bottom and LB top layer). I didn’t find in documentation what is -checkAlignedSecondaryPin 1.Can you help me please to get it right?Thank you very much.  

     

Reply
  • Hi Kari,Excuse me for the delay to reply and thank you very much for your attentionI tried the abutment procedure but didn’t work from the beginning. Actually I couldn’t use the globalNetConnect to route even vdd and gnd. The tool complaints that couldn’t identify the nets and the pins. At the verification phase Encounter reported many connectivity errors. I checked, there are no gaps between IO cells zooming in, at extreme values. Additionally I must say the all the sides of the chip were carefully balanced, choosing all cells with same widths.The things started to settle the moment when I introduced in my netlist vdde, gnde (power supply for IO cells) and other rails used in the IO ring (mostly esd protection related). I don’t know how somebody else handled this stuff, but globalNetConnect couldn’t work based on LEF files. It might be because I don’t have a complete view of layers how somebody suggested. The CMOS family is very recently issued and I got the libs from the manufacturer but I cannot identify the pins vdd, vdde, gnd, gnde (& all pins related to esd protection) in Encounter. I see it in the LEF (which is text) file but I do not see in the layout. The logical pins of the IO cells are easy to identify on the screen. Is this thing normal?As I say, now I don’t have the errors reported but still a thing bothers me and if you could help me would be great. The vdd and gnd traces between the power supply cells and the ring are not equal in width and some of them go to an abutted IO cell with the power supply cell. I placed the core power cells in the middle of each side. The width of the traces is 4 um and 12um.I would like to have all of 4 um as I aked for the power ring. Also I think if I could limit their number, the connections to the abutted IO cells would disappear. The used command for srouting is:sroute -connect { blockPin padPin padRing corePin } -layerChangeRange { M1 LB } -blockPinTarget { nearestRingStripe nearestTarget } -padPinPortConnect { allPort oneGeom } -checkAlignedSecondaryPin 1 -blockPin useLef -allowJogging 1 -crossoverViaBottomLayer M1 -allowLayerChange 1 -targetViaTopLayer LB -crossoverViaTopLayer LB -targetViaBottomLayer M1 -nets { gnd vdd }                where five options are by default (M1 is bottom and LB top layer). I didn’t find in documentation what is -checkAlignedSecondaryPin 1.Can you help me please to get it right?Thank you very much.  

     

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.