Add pins via skill to all symbols in lib

Hi HoWei,

I'm only able to give a very quick, not well thought out answer, as I'm on vacation and so am only having a sneaky answer of posts when I should be in the garden...

One idea would be to modify the SPICE/CDL to not have pins but reference the supplies as globals. Then import the file, and then use my code in SKILL for converting global supplies to inherited connections after VerilogIn, CDLIN, SpiceIn to convert the globals into inherited connections. This avoids having to add pins onto the symbols, and digital and analog users can then both be happy...

Andrew

Hi Andrew,

I appreciate very much that you sacrifice valuable garden time for giving tips in this forum !

I will look into this solution, but I am not sure if it would make the analog users happy, because sometimes they would like to connect the standard cells to different Vdd domains on the chip - but that would not be possible with the inherited nets.  Or do I miss something here ?

That is why our preferred solution for the analog flow would be pins on the symbols.

I am already working myself thru the SKILL documentation and try to write a script that will do so - let see how it turns out.

Have a nice vacation!

The whole point of inherited connections is that you can override the default (global) values on an instance by instance basis, by setting a netSet property on the instance (or even on a higher level instance). So say you had the vdd net within the std cells set by a netExpr property called vdd, you could then add a netSet on your std cell instance to say that it should be connected to vdda. Or you could have a schematic with lots of logic, and the instance of that could set vdd to vdda, which would mean that all the standard cells get their supplies set by an inherited property. 

They’re not global nets - those would be inflexible. The idea is that you get the convenience of not needing to wire supply pins up but the flexibility you would have had it there had been supply pins. 

Andrew

It also would be better if the schematics retained their supply pins and you added netExpr onto those pins - that’s a better flow than the SKILL code I suggested. In general it is better to have explicit pins on the schematic with netExpr (you don’t need the pins on the symbol) rather than having “implicit pins” by adding netExpr on nets. The reason is that the pin name becomes well defined for flows that need to have good control over the pin name (such as Layout XL, abstract generation and so on).

Okay, here is what I understand:

1. The inherited nets are kind of "connect by name" from top-down thru a hierarchy, depending on the netExpr, without any wires

2. The "netExpr" can be either set to a net or a pin. Using it on pin might be advantageous in some cases.

This sounds good - now my question is, how can I import the SPICE netlist and create a schematic out of it, if the symbols do not match the pins ?

I looked for something to ignore this mismatch, but did not find anything.

Once the schematic is created successfully I could start adding those "netExpr" to the pins (via SKILL).

Or can I add the "netExpr" in the SPICE netlist already ?

And one more very important question is, which solution (pins on symbol or inherited nets) has the better compatibility within other tool (e.g. Synopsys/Mentor digital flows and LVS/DRC/PEX/QRC).

We would of course  like to have the one solution that works in all tools ….  any experience/idea ?

There is another caveat related to inherited connections that is described at https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od00000066PhyEAE. I have seen this causing a missing supply connection in a fabricated design (not at my present company).

There is another caveat related to inherited connections that is described at https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od00000066PhyEAE. I have seen this causing a missing supply connection in a fabricated design (not at my present company).