• 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. special net not being routed when sroute ran

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 91
  • Views 14040
  • 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

special net not being routed when sroute ran

diablo
diablo over 15 years ago

 Hi all,

I am trying to route special net "bdpd_5v" using sroute. However, sroute is not routing the net.

This bdpd_5v signal connects output pin in one of the IO cell  to input pin 'BDPD_5V' of rest of the IO cell. This signal detecs the presence of power in IO cell and prevent backdrive leakage on absence of power.

I have set this signal  as special net

 "setnet -net bdpd_5v     -type special -setTermSpecial"

Then used 'sroute' with following options 

sroute -connect { blockPin padPin padRing corePin floatingStripe }
-layerChangeRange { 1 6 } -blockPinTarget { nearestRingStripe
nearestTarget } -padPinPortConnect { allPort oneGeom }
-checkAlignedSecondaryPin 1 -blockPin all -allowJogging 1
-crossoverViaBottomLayer 1 -allowLayerChange 1 -targetViaTopLayer 6
-crossoverViaTopLayer 6 -targetViaBottomLayer 1 

The net was not routed by sroute. I had also connected the net to the global net using

"globalNetConnect bdpd_5v    -type net -net bdpd_5v -all -verbose" 

and ran 'sroute' with the same option as above. This net is still not routed.

Any suggestions?

The reason I wanted to use sroute for this net is while routing this net through nanoroute, it is buffering this net inside core using standard cells which is at 1.8V and this net is at 5V. 

Thanks a lot for your time. 

 

  • Cancel
Parents
  • Kari
    Kari over 15 years ago

     You're kind of talking about two different things.

     1. You don't want any buffers added on these nets. The optDesign command is what adds the buffers, not nanoRoute. You would need a set_dont_touch on all of the nets that you don't want to buffer. That way, optDesign will leave them alone. 

    2. You don't want these nets to route in the core area. Just because there are no buffers added to the nets, that does not guarantee that the net won't possibly veer into the core area if routing resources on the edge of the chip are tight. Maybe your main goal is just to avoid buffering the nets, in which case taking care of the first issue is enough. But if you don't want any of these nets' wires inside the core area, you would have to use routing blockage, route these nets first, then remove the routing blockage to route the rest of your design.

    Let me know if I misunderstood your intent.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Kari
    Kari over 15 years ago

     You're kind of talking about two different things.

     1. You don't want any buffers added on these nets. The optDesign command is what adds the buffers, not nanoRoute. You would need a set_dont_touch on all of the nets that you don't want to buffer. That way, optDesign will leave them alone. 

    2. You don't want these nets to route in the core area. Just because there are no buffers added to the nets, that does not guarantee that the net won't possibly veer into the core area if routing resources on the edge of the chip are tight. Maybe your main goal is just to avoid buffering the nets, in which case taking care of the first issue is enough. But if you don't want any of these nets' wires inside the core area, you would have to use routing blockage, route these nets first, then remove the routing blockage to route the rest of your design.

    Let me know if I misunderstood your intent.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
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.

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

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