Stats

  • Locked Locked
  • Replies 4
  • Subscribers 143
  • Views 14477
  • 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

StrongGroup suffix in net name

Yaosan Yeo

When I use VXL and gen from source, the transistor generated have weird net name assigned to its source/drain terminals. Rather than named "n1", the net name on the inst term is appended with "_StrongGroup_#" e.g. "n1_StrongGroup_1".

FYI in the schematic I have nfet with m=16, source tied to n2, drain tied to n1. After gen from source, the nfet in layout has source term assigned to net n2, but drain term for each transistor is different: n1_StrongGroup_1, n1_StrongGroup_2, ..., n1_StrongGroup_16.

I would like to know under what circumstances would this happen, what's the purpose of these "StrongGroup" and how to deal with these weird nets. To get back the "parent" net, I could potentially do "car(net->signals)". Still, it is confusing because a net is no longer a simple net and we might need addtional queries to get back the actual net without the StrongGroup suffix.

Tried to look for documentation for this but couldn't find anything.

  • Andrew Beckett

    Which version of the tools are you using?

    Kind Regards,

    Andrew.

  • Yaosan Yeo

    Hi Andrew,

    I'm using IC615 ISR 17.

    Thanks! 

  • Andrew Beckett

    This happens when you have pseudo-parallel nets. If you have two m-factor devices in series with each other, the joining node is a pseudo-parallel connection. Say you had M1 with m=2 and M2 with m=2. You'd probably just wire the source of M1.1 to drain of M2.1 and source of M1.2 to drain of M2.2 - but you would join those two bits of wire to each other - because they are at the same virtual potential.

    These subnets are how this expected relationship is described - if you see the flight lines, it only shows the pairs of devices connected.

    Does that make sense?

    Andrew.

  • Yaosan Yeo

    Hi Andrew, thank you so much for the reply. Yes what you mentioned above make sense.

    My question now is what would be the best way to handle these nets using SKILL. Is there any SKILL function that will give me back the original net if a pseudo-parallel net is given as argument? If not, will it be correct to do "car(net->signals)" to get it back?

    It will be great too if there's a built-in API to do something like "isPseudoNet()" to check whether something is a pseudo parallel net. One way I can think of is to check a net's dbID and see if it matches the car of its signals list... This will allow us to handle these type of nets more gracefully since most script that deals with net probably isn't expecting to operate on a pseudo parallel net.

    Thank you for sharing your insight on these special nets.

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.