Changing schematic properties and callbacks

Michele,

I'd suggest you either:

1. Use the parameters capability in ADE Explorer/Assembler (or even XL) which allows you to sweep the parameters of a device and the callbacks do get fired in the background (rather than putting a variable on it, you use the parameterisation flow in ADE). This is the simplest because the tool does all the work for you
2. Use my callback calling code (not an ancient version on the comp.cad.cadence forum, but something more recent which is indented and maybe easier to read). This also handles the pain for you. How to call CDF callbacks procedurally from SKILL to update CDF parameters?

Trying to get the right CDF and then doing evalstring() yourself is possible, but sometimes you might need to take care of calling the init proc, or making sure it's the right kind of CDF - it's a can of worms. You can write it succinctly for a specific case, but depending on the PDK there might need to be a chain of callbacks invoked, not just the one you changed.

I'd personally go for option 1 above if you can.

Andrew

Hi Andrew,

thanks. I am not too enthusiastic about using Explorer/Assembler or XL - I would like to have a tighter control on what the simulator is doing.

For instance - but I don't know whether this behaviour can be changed - I can't see the actual simulated netlists if I go for the "parametrisation flow" as you suggest. At least, I wasn't able to find them.

EDIT: I was just looking in the "standard" places (.../spectre/schematic kind of thing) but actually when running Explorer the data is stored under the Maestro folder. I was able to find the netlists but

they are not as transparent as I would like them to be, meaning that the transistor now has the swept parameter (# of fingers) put equal to a variable, but the other parameters of the cell view are NOT changing!

Also, I've swept the # of fingers from 1 to 4 but I can't find a netlist with values for the variable assigned to the parameter different from 1.

I'm starting to think, however, that there might be an underlying PDK maturity issue too.

----

Also, I'm now totally in love with my idea of creating a sort of matrix of devices as a single schematic view, and this works best if done programmatically.

Thank you for the link to a newer version of your code - you might remember that in my capacity as Consultant I'll have to go through a couple of hoops to get my hands on the content of the link.
I've started the procedure, anyhow.

I've tried to use your old - Ggroups - code, and I'm not sure whether I'm doing something wrong or the code is obsolete in the new Virtuoso versions or what not.

I do something like this:

load("abMagicCode.il")

cvId = dbOpenCellViewByType("my_lib" "my_cell" "schematic")

abInvokeCdfCallbacks( cvId)

unfortunately, I get a bunch of error messages as a result:

abEffCDF@0x269d2218

*Error* PasCdfGetDpt: argument #1 should be any user-defined (other) type (type template = "o") - 

In general, I got curious and now would like to try and understand the underlying mechanisms a little better.

I can spend time and decypher what your code is doing, I've got a barrier in that Lisp syntax does not come natural to me, I just haven't spent enough time working with it, but it's just a matter of putting more effort into it.

However, what I am missing is some sort of "picture" of the interplay, at this level, of CDFs, callbacks and PDKs, I suppose.

I have the whole Cadence Documentation available: can you suggest me a few pointers for a study path?

Thanks!

Michele

Hi Andrew,

thanks. I am not too enthusiastic about using Explorer/Assembler or XL - I would like to have a tighter control on what the simulator is doing.

For instance - but I don't know whether this behaviour can be changed - I can't see the actual simulated netlists if I go for the "parametrisation flow" as you suggest. At least, I wasn't able to find them.

EDIT: I was just looking in the "standard" places (.../spectre/schematic kind of thing) but actually when running Explorer the data is stored under the Maestro folder. I was able to find the netlists but

they are not as transparent as I would like them to be, meaning that the transistor now has the swept parameter (# of fingers) put equal to a variable, but the other parameters of the cell view are NOT changing!

Also, I've swept the # of fingers from 1 to 4 but I can't find a netlist with values for the variable assigned to the parameter different from 1.

I'm starting to think, however, that there might be an underlying PDK maturity issue too.

----

Also, I'm now totally in love with my idea of creating a sort of matrix of devices as a single schematic view, and this works best if done programmatically.

Thank you for the link to a newer version of your code - you might remember that in my capacity as Consultant I'll have to go through a couple of hoops to get my hands on the content of the link.
I've started the procedure, anyhow.

I've tried to use your old - Ggroups - code, and I'm not sure whether I'm doing something wrong or the code is obsolete in the new Virtuoso versions or what not.

I do something like this:

load("abMagicCode.il")

cvId = dbOpenCellViewByType("my_lib" "my_cell" "schematic")

abInvokeCdfCallbacks( cvId)

unfortunately, I get a bunch of error messages as a result:

abEffCDF@0x269d2218

*Error* PasCdfGetDpt: argument #1 should be any user-defined (other) type (type template = "o") - 

In general, I got curious and now would like to try and understand the underlying mechanisms a little better.

I can spend time and decypher what your code is doing, I've got a barrier in that Lisp syntax does not come natural to me, I just haven't spent enough time working with it, but it's just a matter of putting more effort into it.

However, what I am missing is some sort of "picture" of the interplay, at this level, of CDFs, callbacks and PDKs, I suppose.

I have the whole Cadence Documentation available: can you suggest me a few pointers for a study path?

Thanks!

Michele

For your first question, you can go over each simulation point in the output pane and do right mouse->View Netlist and then see the netlist for that point.

The comments at the top of the code (probably rather hard to see from that old version with messed up formatting) answer your other questions. In fact you could quite safely use the version in this post (I made a recent small change which would have no impact as it was for an internal team that needed a special feature). That has all the formatting and comments preserved and is recent enough (1.17 is the latest version), and that code has the "ab" prefix rather than "CCS" from the support article. Ah, just realised the article talks more about the special cases than the comments in the code.

Some PDKs check the type of the arguments (those done using PAS) and so you'll need to pass ?useInstCDF t to abInvokeCdfCallbacks. You may also need ?callInitProc t too:

abInvokeCdfCallbacks(cvId ?useInstCDF t ?callInitProc t)

There is some documentation on CDF in general, but you may also find this of interest: The Dangers of CDF Callbacks

Andrew

Thanks Andrew!  

About the netlist thing, that's also what I thought. Unfortunately, I don't seem to have that luxury:

(please just click the link, I've tried to add image as link but it does not work)

https://ibb.co/4ZT1N89

when I go "the hard route", looking for the actual input.scs files, I can't make much sense of them, as I wrote.

I've now used your suggested form for the procedure and "it works", in the sense that it returns true.

However, when I change the # of fingers and then call the procedure, this number goes back to 1 and instead the total width/finger width is increased!!

Probably something to do with the order of evaluation of parameters? If I try the more "internal"  procedure abInvokeInstCdfCallbacks() and specify that I want only the

"# of fingers"  parameter callback to be fired, it works as intended.

Needless to say, I can't access "The Dangers of CDF Callbacks"  with my limited powers :-(

---

I would have many questions but probably a good study session is inorder, before I flood the Forum with redundant sentences :-D 

But one thing puzzles me and I would like to ask:

by creating a reference to the particular instance ( inst = car(selectedSet()))  I was able to change one of its parameters, and this was reflected at the schematic canvas level because the properties in the form were  actually  changing, and were stored somewhere because they survived, once saved, a close/reopen cycle. So, from the properties form available in the Schematic Editor, you would say your transistor is just fine.

However, the  netlist  produced by that very same schematic, was  not  showing the "correct"  properties for the netlisted device... This leaves me with the sensation I am really missing something big here.

How is that possible that I open a schematic and see "drain area = xxx"  and when I netlist that very schematic, the parameter ad = yyy?

Thanks!

Michele

AncisMichele said:

About the netlist thing, that's also what I thought. Unfortunately, I don't seem to have that luxury:

(please just click the link, I've tried to add image as link but it does not work)

You're doing the Right Mouse button over the wrong column. You need to do it over the Nominal or the specific corner if corners are used. Each row in the detailed output can have multiple simulations, so you need to be looking at the specific corner because each will have a different netlist. If you do it over the output name, there's no run associated with that column.

AncisMichele said:

when I go "the hard route", looking for the actual input.scs files, I can't make much sense of them, as I wrote.

Similarly you can look at the netlist for each simulation point.

AncisMichele said:

Probably something to do with the order of evaluation of parameters?

Yes. This is one of the challenges with CDF callbacks - if they are written in a way that there is ambiguity in the results, then calling them procedurally can be a challenge. Though the UI the order is always defined, because it's simply the order you change the parameters on the form. If calling callbacks for a set of parameters, you really don't know which is edited first. I normally determine for a particular application which I want to win, and then specify the ?order to be the list of parameters I want to call in the right order. For many PDKs you don't need to call all the callbacks anyway because there is often (not always) some level of policing - but at the very least you only really need to call the callbacks for the parameters you're changing.

You could call abInvokeCdfCallbacks with a ?order which works for all the types of device you've got, or you can call abInvokeInstCdfCallbacks for each instance - it doesn't really matter (it won't save you anything particularly on the efficiency - it's just a common requirement to re-call all the callbacks to ensure everything is consistent and it avoids having to think about it so much to call all the callbacks for all the instances).

AncisMichele said:

However, the  netlist  produced by that very same schematic, was  not  showing the "correct"  properties for the netlisted device... This leaves me with the sensation I am really missing something big here.

How is that possible that I open a schematic and see "drain area = xxx"  and when I netlist that very schematic, the parameter ad = yyy?

The chances are that the PDK has some derived (and maybe hidden) parameter that is used for netlisting. An approach I find particularly horrible because it's a recipe for things going wrong. You can tell by looking in the simulation information in the CDF for a particular simulator (netlister) for the component which parameters are output (note they may be mapped via the propMapping) and you need to ensure that you're calling the right callbacks to ensure that any dependency is followed. It's very hard to be specific without the details of what you're doing and the specific PDK, but it's going to be a matter of a callback not being called, I'm sure. Your ?order may not be enough.

Note that when the callbacks are fired (either interactively, or using this function), modified values are stored on the instance itself in the instance user-defined properties. You can check values on the instance itself by doing:

foreach(mapcar prop car(geGetSelSet())~>prop list(prop~>name prop~>value))

which will show you a list of name-value pairs for properties on the instance. Note that other CDF parameters will pick up the default value from the CDF instead. Put simply, the instance CDF is the Cell CDF with the instance properties overlaid on top to override the value on a per-instance basis.

Regards,

Andrew