Stats

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

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

 

  • Andrew Beckett

    Hi Sjoerd,

    If you create an instance with dbCreateInst, it knows nothing about CDF, and so storeDefault is not honoured. It's a lower level API - that's how it is supposed to work.

    If you look at an instance without instance properties, and CDS_Netlisting_Mode is Analog, then doing inst~>paramName will retrieve the instance property if set, or the CDF default if not (this is a function of CDS_Netlisting_Mode Analog). So in general it's not necessary to set storeDefault=yes unless you really, really want the default to be stored on the instance (an example is when you have the CDF default different from the PCell default, which is generally best avoided unless you have a very good reason to).

    CCSinvokeCdfCallbacks (which is my code) won't enforce storing default values if they weren't on the instance already.

    So, if you really need default values on the instance, you should take care of that when you create the instances from SKILL. Or consider whether  you really need storeDefault=yes at all.

    Regards,

    Andrew.

  • Sheppy

    Hi Andrew,

    Thank you for your quick response.

    Okay, so what we see is expected behavior, there's nothing wrong with our set-up or PDK.

    About the storeDefaults flag: after lengthy discussions at my previous job (Philips/NXP) we argued that it is best practice to always store the defaults. I do not remember all the arguments anymore, but I am in favor of always storing as much information as possible. Therefor, I used the same approach for this PDK.

    The defaults of the PCELL are identical to the defaults of the CDF. I ensure this is the case by using this code in the pcDefinePCell procedure:

    pcDefinePCell( list( ddGetObj( pdkLib ) cell "layout" )
        (
            ( tech          string    cdfId->tech->defValue )
            ( devTypeSel    string    cdfId->devTypeSel->defValue )
            ...
        ) ... )

    I know that your code (the CCSinvokeCDFCallback() procedure) wasn't written with this particular use-case in mind. However, we found out that when using it, it was actually putting properties on the instance*. On closer look we found out that not all were stored, hence this forum post. I will invest time to go through your code to fully understand what is happening inside it, to get a better understanding.

    So, to solve our problem, there are several solutions. Either by supplying the dbCreateParamInst with all the parameters and their values. This could be easily done by constructing a list of all parameters and their default value from the CDF of the instance, which could look like this (code from your colleague Hong-Cheang Quek):

    procedure( CCScreateParamInstWithStoreDefault( cv devId instName coord orient numInst )
       let( ( cdf targetParamList paramList )
          cdf = cdfGetBaseCellCDF( ddGetObj( devId~>libName devId~>cellName ) )
          targetParamList = setof( x cdf->parameters x->storeDefault )
          paramList = foreach( mapcar param targetParamList
             list( param->name param->paramType param->value )
          ) ;foreach
          dbCreateExtParamInst( cv devId instName coord orient numInst paramList )
       ) ;let
    ) ;procedure

    This code would make it instance (cell) independent, which is what is needed. However, this has one big drawback: if an other colleague writes some code to automate a part of the design, he will have to do the same. He might not be aware of this problem and invest a lot of time to get it fixed. Instantiating an instance from the PDK using code should work right out of the box.

    We found out that _only_ parameters that are being set in the callback are being put as a property on the instance when the CCSinvoke... procedure is called. Therefor I have tested the following code (it sets all parameters) which I added to the callback procedure which is called when manually (graphically) instantiating an instance, or when CCSinvoke... is called:

    devCdf = cdfGetBaseCellCDF( ddGetObj( devLibName devCellName ) )
    devCdfParamList = setof( devCdfParam devCdf->parameters devCdfParam->storeDefault )
    foreach( devCdfParam devCdfParamList
       get( cdfgData devCdfParam->name )->value = get( cdfgData devCdfParam->name )->value
    ) ;;; end of foreach

    By putting it in the callback, it is always triggered, but we're (miss)using the CCSinvoke... code a bit to get what we want. So now, no matter how an instance in layout or schematic is instantiated, it always has all properties stored. The only condition being: CSSinvoke... must be used. But that procedure must already be used to ensure the callback procedure is called.

    An other drawback of this simple implementation is: it (setting of value) is _always_ done. I'd like to avoid that. Is it possible to determine whether or not all parameters have already been stored and if so, skip re-setting them again? It is not possible to use the information in cdfgData to verify this. This verification step must be performed in the callback procedure. A possible solution could be: adding a hidden boolean parameter which is "nil" by default, but being set to "t" at the end of the callback procedure after it (the callback procedure) has been called for the first time. However, this would mean that I have to add this parameter to all cells in the library. I'd prefer to use the information already available, if possible.

    Is there any other implementation possible to ensure all properties are being stored, even if instantiated through a SKILL script?

    I hope any of this makes sense to you...

    With kind regards,

    Sjoerd

    * = the actual CCSinvoke... script is not putting the properties on the instance, it is a combination of the CCS... procedure and the callback procedure.

  • Andrew Beckett

    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.

  • Sheppy

    Hi Andrew,

    I have tried to implement a check with dbFindProp/dbGetPropByName in the callback procedure, but with no luck. The main reason being: in the callback I don't have an instance ID, only the cdfgData, of the instance that is about to be placed, or updated. Since you state that you wouldn't worry too much about setting the parameter to its own value, I just leave that part of the code in the callback, and now all works perfect.

    I am not going to touch your code (the CCSinvoke...). I leave it as-is, including all procedure names and comments. No need to do that and I think it is not the correct thing to do.

    About storing all defaults: you state that it costs a lot to store all defaults. With a lot, do you mean in database size or in time?

    With kind regards,

    Sjoerd

  • Andrew Beckett

    Hi Sjoerd,

    It's more about database size. Of course, if you only have a handful of instances, it's probably not even worth worrying about...

    Regards,

    Andrew.

  • Sheppy
    Hi Andrew, the database is not big at all, so I am not worried about the amount of data that's going to be stored by doing this. Thanks again for your support. Sjoerd

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.