Stats

  • Locked Locked
  • Replies 4
  • Subscribers 125
  • Views 16390
  • 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

How to trigger call-back procedure when changing cell-name of existing instance?

Sheppy

Hello,

I am developing a PDK containing various components (p-cells with call-back procedures). The designers using it at this moment, are performing the following steps to create large test-layouts, with lots and lots of nearly identical devices:

  1. Create a layout with many instances of a PMOS transistor, varying parameters like width, length, gate-drian space, gate-source space, etc.
  2. Copy this layout to a new cell
  3. Perform a search-and-replace and changing all cell-names from PMOS to NMOS

In an other PDK, this works, all parameters that need an update (like for instance a parameter called Device Info) are updated, but others, like width and length, remain as is. Thus creating a new layout with virtually no effort. So what clearly happens is that a cell-name change triggers the p-cell to update certain parameters.

When they try to do this with my p-cells, it doesn't work. All parameter names are identical (as is in the other PDK), but after the cell-name change the value of all parameters remain teh same. An example:

The parameter called DeviceInfo contains the following for the PMOS: Standard Low Voltage P-Channel MOS Device
After changing the cell-name, it should be updated to: Standard Low Voltage N-Channel MOS Device

However, this update does not happen.

Now is my question: how do I make my devices behave identical to the other PDK?

How do I trigger the call-back procedure to update, if necessary, the parameters of the p-cell?

With kind regards,

Sjoerd

Parents
  • Andrew Beckett

    Hi Sjoerd,

    There is no callback for the cellName being changed (so other PDKs can't be doing this).

    There are two main problems when you change the cellName field (either via search and replace or directly in the edit properties form or the property assistant):

    1. Any CDF parameters which have storeDefault=yes in the original cell's CDF and are still at their default value will remain at their original default value and not update to the new component's default. If storeDefault=no was set in the original CDF and they're still at the default value, then they would update (because nothing is actually stored on the instance for this parameter)
    2. No callbacks are triggered, callbacks are only triggered by changes in parameters. Since nothing changed, no callbacks got called. So any dependent parameters won't get recomputed.

    My article "The Dangers of CDF Callbacks" on Cadence Online Support talks about some of these challenges and why CDF callbacks should be avoided altogether where possible for derived data. 

    Even if there was a callback on the cellName field, it would have to have some knowledge as to the order in which to update the parameters - it's quite common to find that there is an order dependency when calling callbacks (e.g. if you have a callback on total width to set the finger width based on total width and number of fingers, and also a callback on finger width to set the total width based on finger width and number of fingers - you could get a different answer, dependent upon which was called first).

    My proposal (not implemented yet) has been to have:

    1. A mechanism to consistently make the cellName (and libName) greyed out in all places so that you can't change them - you have to delete and re-add. There's partial support for this but not everywhere (and some requires some private functionality)
    2. A callback (of sorts) for re-mastering, where you could choose what to do when something has been replaced by another component.

    Right now, your best bet is probably to call abInvokeCdfCallbacks (or CCFinvokeCdfCallbacks) to trigger all the callbacks - but even then you might need to reset some of the default values if storeDefault has been used.

    Regards,

    Andrew.

Reply
  • Andrew Beckett

    Hi Sjoerd,

    There is no callback for the cellName being changed (so other PDKs can't be doing this).

    There are two main problems when you change the cellName field (either via search and replace or directly in the edit properties form or the property assistant):

    1. Any CDF parameters which have storeDefault=yes in the original cell's CDF and are still at their default value will remain at their original default value and not update to the new component's default. If storeDefault=no was set in the original CDF and they're still at the default value, then they would update (because nothing is actually stored on the instance for this parameter)
    2. No callbacks are triggered, callbacks are only triggered by changes in parameters. Since nothing changed, no callbacks got called. So any dependent parameters won't get recomputed.

    My article "The Dangers of CDF Callbacks" on Cadence Online Support talks about some of these challenges and why CDF callbacks should be avoided altogether where possible for derived data. 

    Even if there was a callback on the cellName field, it would have to have some knowledge as to the order in which to update the parameters - it's quite common to find that there is an order dependency when calling callbacks (e.g. if you have a callback on total width to set the finger width based on total width and number of fingers, and also a callback on finger width to set the total width based on finger width and number of fingers - you could get a different answer, dependent upon which was called first).

    My proposal (not implemented yet) has been to have:

    1. A mechanism to consistently make the cellName (and libName) greyed out in all places so that you can't change them - you have to delete and re-add. There's partial support for this but not everywhere (and some requires some private functionality)
    2. A callback (of sorts) for re-mastering, where you could choose what to do when something has been replaced by another component.

    Right now, your best bet is probably to call abInvokeCdfCallbacks (or CCFinvokeCdfCallbacks) to trigger all the callbacks - but even then you might need to reset some of the default values if storeDefault has been used.

    Regards,

    Andrew.

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.