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

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 

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