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

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

 

Parents

  • 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.

Reply

  • 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.

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.