invoke pcell callback - simple case of abInvokeCdf... functions?

Sorry, here's the full question text:


We would like to invoke a layout pcell callback from SKILL code.

After reading through the forum post on design migration and abInvokeCdfCallbacks (community.cadence.com/.../1340918) and the help case 'How to call CDF callbacks procedurally from SKILL?' (support.cadence.com/.../ArticleAttachmentPortal;pageName=ArticleContent&sq=0050V000006PHLGQA4_201772013217119 


I have a couple of questions:

1) are those two related? Did CCSinvokeCdfCallbacks originate from abInvokeCdfCallbacks?

2) is the full complexity of the lookalike CDF needed if I'm just operating on one instance of once layout pcell, and not on a cellview or library?

3) if you invoke one callback, will it automatically cascade to invoke the child callbacks? If we call a callback for a, which changes b, will the callback for b get called automatically or do we need to separately invoke the

callback for b? Seems like the answer is 'no' for safety reasons, i.e. to prevent unintentional dependency loops?

3) is there any hope of this functionality becoming a supported part of the normal SKILL API that ships with Virtuoso? It seems pretty dang handy and universal, and it seems like a whole lot of folks would need something

like this.


Our particular use case is something like this:


We place a pcell of a certain capacitor type from code. We specify its capacitance. Since the area capacitance coefficient is a constant for this device type, and we assume a square capacitor at this point, W and L are

(basically) just a function of C.

The pcell has a parameter 'force square' which is a boolean, and if t

(by default), then w and l will be the same (or very close), and a non-editable cdf parameter showing the actual realized capacitance based on w and l, and another param showing how close that is to the intended

capacitance, will get automatically updated when the form is open.


So - when the form is open and we change C and 'force square' is on, that one change results in changes to W, L, 'C(actual)' and 'error'.


When we place the capacitor using code, and specify C, none of W, L, C(actual), or error are updated. This is no surprise since the callbacks are not called - just wanted to be clear about what we are seeing.


So really we want to call the callback for the intended capacitance field, and if there is no automatic cascading, also call the callbacks for W, L, and C(Actual).



Thanks

As the author of this code, I can answer this ;-)

1. Yes. My code historically has the "ab" prefix (my initials). However, when publishing code for articles, we normally should use the "CCS" (Cadence Customer Support) prefix - so all I did was update the code to change the prefix. There may be a version mismatch now and again as small features are changed, but essentially the CCS and ab version are interchangeable (at least if the code has the same version number).
2. The idea of the "lookalike" CDF is to get around the fact that strictly speaking the CDF callbacks are invoked with cell CDF not instance CDF. Getting the instance CDF for an instance is easy - cdfGetInstCDF(inst). In many cases calling the CDF callback with cdfgData bound to an instance CDF will work fine. The trouble tends to occur when callbacks start depending on differences that only show up with cell CDF (so for example with cell CDF ->id points to the ddId of the cell, whereas for inst CDF ->id points to the instance id of the instance; you see a difference if your callback relies on cdfgData->id->name for example). So to play safe, I construct something that looks like the Effective Cell CDF (the Cell CDF overlaid with the instance CDF values). Unfortunately there weren't (still aren't) any reasonable APIs that do all this for you, and I thought it was safer than actually clobbering the cell CDF temporarily. Unfortunately in some cases this doesn't work because in some PDKs they do type checking on the cdf to make sure it really is a CDF object rather than my fake "lookalike". Then there's the whole problem with cdfgForm and so on... Anyway, this is nothing to do with applying it to a single instance or a whole library - it's just a matter of ensuring that it looks like an effective Cell CDF.
3. Yes, I agree. This has been requested numerous times, and in fact there is more than one internal API (for different parts of the tools) to try to do the same thing when there's a need to call callbacks procedurally. In practice each always had a slightly different need and so wasn't suitable for extending to a general public API. The other concern was always that you have to be careful about ordering - CDF callbacks are intended to be called interactively as a user changes the form, and the order they are applied in is clear - whereas when called from SKILL, you don't have a desired order (this is why I provide the ?order argument). In many PDKs, calling one callback is sufficient because they take care of doing all the calculations from that single invocation - and so attempting to follow the chain of dependencies would just be expensive and prone to getting stuck in loops (or worse still, ending up with unstable loops!). So unfortunately my code has ended up being an almost de-facto solution for doing this for many years.

You can find out more about the full headache of CDF callbacks in my article The Dangers of CDF Callbacks

Regards,

Andrew 

Just got back from a few weeks off, sorry for the late reply.

Referring to support.cadence.com/.../ArticleAttachmentPortal;pageName=ArticleContent and CCSinvokeCDFCallbacks.il, what should be my entry point for just invoking a certain callback on a certain instance, instead of the whole schematic? CCSinvokeInstCdfCallbacks with an order argument?

Yes - that's the right function. Whether you need ?order depends on whether you can get away with running just some of the callbacks (quite often that's the case with many PDKs) or whether you need to force them to be run in a particular order. Often I specify ?order for performance reasons rather than purely because of ensuring they are called in the right order.

Andrew.

I will give it a shot soon. Thanks