• 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. Custom IC SKILL
  3. Instantiating instance from command line: no properties...

Stats

  • Locked Locked
  • Replies 6
  • Subscribers 142
  • Views 15975
  • 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

Instantiating instance from command line: no properties stored.

Sheppy
Sheppy over 9 years ago

Hello,

It is possible to instantiate an instance with (CDF) properties/parameters in a cell in two ways: manually through the graphical layout editor or by using SKILL code from the command line in the CIW. The same can be said about instantiating instances in a cell in schematic.

This is what we see when we do it manually:

  1. Create a new cell - view (i.e. cell name = testManual, view name = layout)
  2. Instantiate an instance with properties (i.e. a transistor) with all default values, so do not change any of the properties
  3. After the instance has been instantiated, select it and then perform the following two commands in the CIW:
    1. object=car(geGetSelSet())
    2. length(object~>prop)
  4. The output of 3.b is a numerical value telling you how many properties are stored for that instance. This number should be equal to the number of properties that can be found in the CDF Editor for that particular instance (at least the same as the number of properties with the storeDefault flag set to TRUE)

This is what we see when we do it using commands in the CIW:

  1. Create a new cell - view (i.e. cell name = testSkill, view name = layout)
  2. Perform the following commands in the CIW to instantiate an instance in a cell, use values for libName, cellName, viewName that are valid in your environment:
    1. cv = geGetWindowCellView()   ;;; To get the dbId of the cell view we're editing
    2. newInstId = dbOpenCellViewByType( libName cellName viewName )   ;;; To get the dbId of the instance we're going to instantiate
    3. inst = dbCreateParamInst(cv newInstId "inst_0" 0:0 "R0" 1)
  3. At this point, you should have an instance in the cell - view testSkill - layout
  4. Select this instance in the layout editor and perform steps 3.a and 3.b of the manual instantiation

And this is where we see the difference: when performing the manual instantiation the length is correct, when doing it through SKILL commands the length is 0 (no properties stored). This puzzles us: what is the difference between manual instatiation and code instantiation? We expected this to have the same output.

In some code we're developing we're relying on the availability of all properties when instantiating an instance. When we encountered this, we thought we had the solution by invoking CCSinvokeInstCdfCallbacks(inst ?useInstCDF t ) (this is code we got for a different problem, but it seemed to work in this case). But this did not solve all the problems. Not all properties will be stored after invoking this command. If the list of properties has for instance 35 entries, after CSSinvoke... we only see approximately 27 entries (just to give an idea). The entries that are missing apear to be randomly chosen: we're missing strings, cyclics, booleans and integers/floats. But they all tent to be towards the bottom of the list of properties.

We have tried many other commands to instantiate an instance but all had the same outcome: none of the properties are stored, or not all after CSSinvoke....

What we would like to know:

  • Is this expected behavior, and if so, why?
  • What must I do to ensure that when I instantiate an instance all properties are stored?

A little information:

The PDK is developed by ourselves, so if something needs to be done there, that is possible. All CDF properties have the saveDefaults flag set to TRUE, so all strings, booleans, cylics and integers/floats. All properties are needed since a colleague is developing a validation toolkit to validate the PDK we're developing, to ensure nothing breaks when releasing a new version. This validation toolbox automatically instantiates hundreds of instances in many cells to do various checks (check-and-save, simulation, drc, lvs, etcetera) and is fully automated.

Any help here is highly appreciated.

With kind regards,

Sjoerd

 

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    Hi Sjoerd,

    Setting the parameter to its own value is not particularly expensive - so I'm not sure I would necessarily worry about that. You could use dbFindProp/dbGetPropByName on the instance with each property name to find if it's actually set on the instance or not and only set it if it's not - but I doubt this would really save any time though...

    Note that you could instead add this code to CCSinvokeCdfCallbacks somewhere so that you don't have to put it in each and every callback.

    The main reasons for using storeDefault=t are:

    1. You may want the option to change the default value in the CDF (and maybe PCell too) but want any existing default instances to keep their original defaults
    2. You want to have different defaults between CDF and PCell (hardly ever a good idea though).

    It's definitely far less efficient to use storeDefault on all your parameters though - it costs a lot to store all this info on each and every instance. So my preference would be to not do this.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    Hi Sjoerd,

    Setting the parameter to its own value is not particularly expensive - so I'm not sure I would necessarily worry about that. You could use dbFindProp/dbGetPropByName on the instance with each property name to find if it's actually set on the instance or not and only set it if it's not - but I doubt this would really save any time though...

    Note that you could instead add this code to CCSinvokeCdfCallbacks somewhere so that you don't have to put it in each and every callback.

    The main reasons for using storeDefault=t are:

    1. You may want the option to change the default value in the CDF (and maybe PCell too) but want any existing default instances to keep their original defaults
    2. You want to have different defaults between CDF and PCell (hardly ever a good idea though).

    It's definitely far less efficient to use storeDefault on all your parameters though - it costs a lot to store all this info on each and every instance. So my preference would be to not do this.

    Regards,

    Andrew.

    • 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