Using Skill to change properties on fets..

Discussion in 'Cadence' started by PolyPusher, Aug 31, 2011.

  1. PolyPusher

    PolyPusher Guest

    Hi,

    I am trying to find the proper way(if there is one) to change some
    properties without the Edit Instance Property form.

    I can run this code I wrote that changes the SD connect and poly head
    to top..


    procedure(InstWack()
    cv=geGetEditCellView()
    foreach(inst cv~>instances
    if(inst~>master then
    unless(leIsContact(inst)
    foreach(prop inst~>prop
    if(prop~>name=="connectGates"
    then println("connectGates found")
    prop~>value="Top"
    )
    if(prop~>name=="connectSD"
    then println("connectSD found")
    prop~>value="unconnected"
    )
    )
    )
    )
    )
    )

    This seems to work, but I worry about the unknown unknowns that I
    don't know! I did notice that when I change one of the instances and
    then click on the instance and start Edit Instance Properties the
    Connect Gates and Connect SD are still the former property(say
    connectGates is set to "bottom" in the Form and in layout it is top).

    I did find the below post by Andrew, but I am still confused.

    So, will the above cause any "real" problems, if so any fixes? Is
    there a better way/ BTW, I have hundreds of devices that need to be
    changed, that is the reasoning for using the code rather than the
    form.

    Thank you in advance for your help,
    Eric


    Previous post by Andrew.....


    Changing properties using dbReplaceProp() is perfectly OK, and
    will behave in a similar manner to changing the property another
    way.

    In fact Grant's suggested code isn't quite right - it should be:


    ;; selectedSet() is an old Edge compatibility func
    ;; use geGetSelSet() instead
    inst=car(geGetSelSet())
    ;; don't use ~>value
    inst~>W=2


    Either using dbReplaceProp() or the above will _NOT_ trigger the
    CDF callbacks. There's a good reason for this. CDF callbacks are
    _form_ field callbacks, and not _database_ property callbacks.
    This means they're only invoked when the property is changed from
    a form (for example, the create instance or edit properties forms in
    the schematic or layout editor).


    This means that if you change a database property on an instance,
    you'll need to call any CDF callbacks yourself for that instance
    property. One way of doing that is:


    ; set the global variable used to communicate with callbacks
    cdfgData=cdfGetInstCDF(inst)
    ; assuming W is the parameter that was modified
    paramName='W;
    callback=get(cdfgData paramName)->callback
    when(callback && callback!=""
    ; catch any errors during the evaluation
    errset(evalstring(callback) t)
    )


    Now, using the instance CDF is not strictly correct, because when CDF
    callbacks get invoked, they're actually presented with cdfgData set
    to
    an effective cell CDF, but populated with the instance's values.
    There
    is no easy way to do this (something similar can be done, but it's
    more work than I really want to describe here). Most CDF callbacks
    work fine if called as above - the only issue will be if the callback
    looks at cdfgData->id (e.g. cdfgData->id->name) to do different
    things. With instance CDF ->id points to the instance object; with
    cell CDF it points to the cell object (so ->id->name gives the
    instance name instead of the cell name, hence the trouble).


    Personally I always try to avoid using CDF callbacks at any point.
    They nearly always lead to trouble, because:


    a) There are ways of changing properties which can cause the
    callbacks to not get evaluated
    b) They prevent hierarchical inheritance of properties;
    for example, you can't use pPar() any more


    This is really only true if you're using CDF callbacks to calculate
    the values of other parameters; if using them to validate
    field values, then that's OK.


    What I always suggest to people to do is to use a "pull" model
    instead of the callback-based "push" model. This means that you
    do any computation at the point you need it. So, if you
    were having a CDF callback to compute a value for a pcell;
    put the computation in the pcell code. If it was for a spectre
    model, put it in an inline-subckt (or failing that, in a custom
    netlisting procedure).


    CDF callbacks are an attractive concept, but there are so many
    pitfalls that they're really best avoided except for simple
    user interface checks and manipulations.


    (gets off soapbox).


    Regards,


    Andrew.
     
    PolyPusher, Aug 31, 2011
    #1
    1. Advertisements

  2. PolyPusher

    PolyPusher Guest

    I basically resigned myself to a replay file type solution and used
    the form. CDF callbacks can be tricky!
     
    PolyPusher, Sep 2, 2011
    #2
    1. Advertisements

  3. PolyPusher wrote, on 09/02/11 20:14:
    You might want to look at the code in http://tinyurl.com/3pkxee7 or look on
    Cadence Online Support at http://tinyurl.com/3dj9zba (that's a later version of
    the same code, but with a different prefix to match the Cadence support
    conventions).

    Andrew.
     
    Andrew Beckett, Sep 5, 2011
    #3
  4. PolyPusher

    PolyPusher Guest

    Andrew,

    That is more than what I needed, which is great.

    Your a scholar and a gentleman,
    Eric
     
    PolyPusher, Sep 6, 2011
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.