Triggering callbacks

[Jackson Harvey]

I have some Cadence schematics, which have components whose parameters I
am changing via dbReplaceProp(). This does not trigger the callbacks
for these components. Is there a way to force to callbacks to be
triggered?

Jackson Harvey

[Grant Erwin]

Are you modifying the value of an instance property and failing to see the
callback trigger?

I don't think you can modify the value of a property using dbReplaceProp. Unless
I'm wrong (I'm posting from home, no access to docs) I believe dbReplaceProp
will
completely delete a property and replace it with another.

Suppose you have an instance selected, and suppose this instance has a property
called "W" which you want to change from 3 to 2. Then try:

inst = car(selectedSet()) ;; get instance handle in Skill
inst~>W~>value = 2

Try that.

Actually, make sure your callback works OK by using the property editor GUI.
Then replicate it using Skill (as above). I am confident that if your callback
is OK and you are modifying a property value which is contained in your CDF
and defined with a callback, that your callback will be triggered.

Grant Erwin
Kirkland, Washington

[Jackson Harvey]

Grant Erwin wrote:

> Suppose you have an instance selected, and suppose this instance has a property
> called "W" which you want to change from 3 to 2. Then try:
>
> inst = car(selectedSet()) ;; get instance handle in Skill
> inst~>W~>value = 2

That makes sense. I will try that.

Thanks.

Jackson Harvey

[Andrew Beckett]

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.

On Wed, 24 Apr 2002 17:37:41 -0700, Grant Erwin <gr...@tinyisland.com>
wrote:

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd