eliminate "updated since last schematic save" warnings when netlisting with cells from basic/analogLib 

 We recently switched to defining the artist primitive libraries that come with the IC61 installations:

DEFINE analogLib $(compute:THIS_TOOL_INST_ROOT)/tools/dfII/etc/cdslib/artist/analogLib

DEFINE basic $(compute:THIS_TOOL_INST_ROOT)/tools/dfII/etc/cdslib/basic

The old way was to freeze old versions of analogLib and basic libraries and rev them slowly over time. Since we use the latest ones from the virtuoso installations, Cadence continues to patch and update cells in their lib primitives, runs checkNSave on them, and gives the cellviews a recent lastExtraction/instancesLastChanged (which ever way it now gets stored internally in OA) property date stamp.

This makes it such that IP that is older than these patches needs check-and-save to avoid warnings such as:

*WARNING* (SCH-2159): "basic ipin symbol" updated since last schematic save.

*WARNING* (SCH-2159): "basic opin symbol" updated since last schematic save.

*WARNING* (SCH-2159): "basic iopin symbolr" updated since last schematic save.

*WARNING* (SCH-2159): "basic ipin symbol" updated since last schematic save.

This side effect also slows down netlisting when one has many cells to neltist.

I would like a solution to avoid these warnings. As a workaround, I tried some skill code that used to do the trick in IC51.41 by setting the instancesLastChanged property some 10 years in the past.  It seems that doesn't do the trick in IC615.

I suppose I could run some skill code (once I figure out the recipe in IC61) on the basic and analogLib everytime I install a fresh IC61 build, which makes this solution cumbersome. Anyone have a better idea?

thanks Nicolas

Nicolas,

In OpenAccess, it no longer uses timeStamps to compare the up-to-dateness of symbols (or indeed whether something needs check-and-saving). This was for two reasons - one, the timestamp only had a 1 second resolution, and a lot can happen in a second, and two, it was relatively expensive to keep looking up the clock from the OS. So instead, openAccess uses counters to keep track of the number of database changes.

The modifiedCounter attribute is what represents this in the database. However, whilst you can disable this from being updated (using dbDisableCellViewCounter), you cannot set the modifiedCounter to a value of your choosing.

Cadence tries to ensure that cosmetic changes in the symbols in these libraries don't lead to a change in the modifiedCounter, and so in general keeping in sync with the released analogLib/basic should not lead to the warnings you're seeing. Of course, if you've not been using our libraries but a separate copy of them, maybe the change happened some time ago.

There is the ability to turn off this check - using the checkSymTime cdsenv var (search in cdnshelp for details of this). Note the documentation is not quite up to date; it still references to instancesLastChanged, which is not what is currently done. However, I wouldn't really recommend disabling this check... it's mainly intended to alert you to symbol changes such as pin additions/deletions/move.

Regards,

Andrew.

 Hello Andrew,

 Thank you very much on the primer regarding the new counter implementation in OpenAccess.

I started pointing to the cadence-delivered libraries -- and non-edited versions of these -- a few weeks ago.  I figured my problem was that I was netlisting something that was 'older' than the basic lib from which it instanciates the ioPin master.  Turns out its not exactly that. 

If I create a new schematic, and create a simple IO pin using the VSE 'create pin' callback which drops down the symbol basic/iopin/symbol, while pointing to the official, unmodified copy that ships in $(compute:THIS_TOOL_INST_ROOT)/tools/dfII/etc/cdslib/basic, when I netlist with hspiceD, I still get:

*WARNING* (SCH-2159): "basic iopin symbolr" updated since last schematic save. 

There must be something else going on .... This is too basic (pardon the pun) of a problem ...

 Nicolas

Nicolas,

That's a bit strange. I wouldn't even have expected it to compliain about pins during netlisting, since they are not things that are instantiated and are there as a means for terminals to be created in the database.

I'd log a service request if I were you, then we can take a look at precisely what you're doing (note, I didn't try to repeat your problem, due to being a tad busy today).

Regards,

Andrew.