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

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.

Hi Andrew,

Thank you for your reply.

I understand your answer and this has always been how I have been doing schematics/layout and how I was taught to use Cadence when I started "a long time ago" at Philips Electronics (many years before it became NXP...).

Having said that, I see the advantage of doing it "the wrong way". We're in the process of developing a new process node, and to characterize / evaluate a group of new devices, one large schematic/layout is generated manually, and then by select-all or search-replace devices are being swapped. This schematic/layout contains hundreds of devices. So my new question is:

• Is it possible to set a trigger which calls a certain procedure once OK or APPLY has been clicked in the properties form?

I know many triggers can be set within Cadence (i.e. upon opening a viewer), so is this possible? And as a more general question:

• Is there a support document that lists all triggers that are available in Cadence (Virtuoso)?

In stead of going this way, do you advice me to write custom code to automatically swap components? This would be easy to do, since a certain type of NMOS is always swapped with a similar type of PMOS: a PMOS_50 always replaces a NMOS_50, PMOS_85 replaces NMOS_85, and so on. In total there are 10 types, so the code is not difficult to write (might even be possible to use abConvertComponentParamsHier() to do the trick).

Final question for this reply:

• Is abInvokeCdfCallbacks/CCFinvokeCdfCallbacks the same as CCSinvokeCdfCallbacks (code I got years ago to fix an issue with instantiating p-cells from within an other p-cell)?

Thanks in advance,

With kind regards,

Sjoerd

Hi Sjoerd,

Answering your questions in order:

1. There is the CDF doneProc which gets called once the OK or Apply has been pressed on the edit props (or create instance) form. There's also the formInitProc which is called when the form is initialised. Not sure this would help though. There's no general purpose trigger for the form that works everywhere (given that you have edit props in the schematic and layout which are different, plus the property assistant)
2. Not as far as I know. There are lots of triggers for various different applications - I'm not sure documenting them all in one place would be very helpful.
3. Yes. My code is really called abInvokeCdfCallbacks but then I rename it to follow the support naming rules for solutions (I don't always do this, but since I did it for CCSinvokeCdfCallbacks, I've continued to do that). It's possible you may have a different version with slightly different features - the version number in the SCCS info in the header comments shows the version number (the very latest is 1.16). Looking on Cadence online support, it seems that the latest CCSinvokeCdfCallbacks is 1.15 - it's only some relatively  minor enhancement that is missing which I needed to help with a very specific problem I was trying to solve.

Regards,

Andrew.

Sjoerd Herder said:

In stead of going this way, do you advice me to write custom code to automatically swap components? This would be easy to do, since a certain type of NMOS is always swapped with a similar type of PMOS: a PMOS_50 always replaces a NMOS_50, PMOS_85 replaces NMOS_85, and so on. In total there are 10 types, so the code is not difficult to write (might even be possible to use abConvertComponentParamsHier() to do the trick).

Just noticed this additional question. Yes, probably custom code would be the right answer currently in the absence of anything generic in the tool which handles this.

Regards,

Andrew.