Changing schematic properties and callbacks

Hi,

I am in the process of evaluating a new PDK and I would like to run some sweeps for different geometries and device types.

The issue with sweeping "the standard way" is that this substitution process does not update those parameters of the model which rely on callbacks.

These days, things like perimeter/area and total width of transistors are caclulated via callbacks.

In trying to overcome this issue, I thought of automating the creation of an array of devices, each with its own properties.

Changing the properties of an instance created in a schematic view looks easy enough (I just learned about it today),

I gathered most of the info I now have, from this post on the Forum, and about the "callback plague" a bit here and there.

This thread in Ggroups has a full-fledged "callback caller" but I am still hoping (since I cannot understand the code) to get away with something simpler

like what I've found here (again Ggroups).

My first steps are - of course - interactive, so I have:

A symbol cellview on a schematic canvas, which I can select and then type on the CIW:

inst = car(selectedSet())

gives me a handle to the instance. I can either inspect the CDF from within the GUI (Tools->CDF->Edit)  or do a cdfGetInstCDF(inst) to get a handle to the db object.

The cell has a property called "fingers", which is as you guessed, the number of fingers of the device. If I do, from the CIW:

inst->fingers="2"

then I can see from the form of the cell instance, which I can of course inspect as I have the schematic canvas open, that the number of fingers is now - correctly - set to two.

But not only! (And this is where it starts to puzzle me)

Also other elements have changed in the form, the very same way one would expect when changing the n. of fingers manually, in the form.

The total witdth, areas and perimeters have changed as well (perimeters and areas are not editable, btw).

The joy does not last long, however. A call to ADE and successive netlisting brings up a device which has only the n. of fingers I've set. All other parameters are the "old" ones!!

Now as a side question, I would like to ask: how is it possible that I have a schematic showing me devices with property XYZ which, once netlisted, have different ones? This of course

opens an abyss of questions... But back to the main point.

Although I don't understand the above, i.e. how can it be that the schematic is showing me something that is not netlisted in that precise way, I thought that maybe I can solve this incongruency

by using callbacks. I used the snippet found in the 'simple version'  thread (2nd link). 

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)
)

If I understand the gist of it, to invoke a callback is just performing an evalstring() on its name.

This name, a string, is what's returned by get(cdfgData paramName)->callback.

I've tried to do this, to no avail. The netlisted device has only the property I directly changed and none of the derived ones recalculated in any way.

I'm thinking I don't really know how to invoke the callback function, because how is the tool supposed to know on which instance to perform the operation?

Just to name one.

Any pointers highly appreciated, keeping in mind that what I'm really looking to implement is a very basic thing: just an array of automatically generated devices with a series of values for their main properties (length, width, n. of fingers...) so in my simple world (tell me if it's not so simple), the whole thing should go like:

for (X in instance_list):

  create instance X

  for parameter in par_list:

     X --> parameter = "myval"

     callback_for_parameter_1

so, nothing too complicated. Of course I'm missing something, hopefully not too much!

Thanks for your help,

Michele