Can I specify the config state of a cell containing hierarchy by wildcard?

This can be done with an inherited view list for that cell which puts veriloga first everything within that cell. Can't remember the syntax and don't have my work computer with me, so will look it up in the morning (assuming you've not foudn the answer based on this hint in the meantime - if you do, please post here so that I know that I don't need to do it!)

Andrew.

The syntax is:

hdbSetObjBindRule(hdbConfig list(list( "std_lib" "rv" nil nil))  list('hdbcViewListRule list("veriloga" "schematic" "spectre" "cmos_sch" "cmos.sch")))

Regards,

Andrew.

That works - perfect! Many thanks.

So I was documenting this in my notebook to make it easier to find again and it occurred to me that that your solution is a broad cell based thing instead of a specific instance based thing i.e. say I have multiple instances of the same cell throughout the hierarchy but wanted to specify only one differently to the others.

I did try to look up the documentation for hdbSetObjBindRule to figure out what I wanted, but I'm a circuit designer and sometimes my brain just doesn't comprehend the gobbledygook (no offense!!) commands I end up needing to use. Would you mind please providing an example of doing the same thing as your previous solution but having it include some hierarchy to a specific instance e.g. /top/level_1/level_2/rv

There are two types of bindings for instances:

1. instance bindings: This means that a named instance in the containing schematic is bound to a particular view or inherited view list, for all occurrences of the containing cellView
2. occurrence bindings: This means that only that specific hierarchical path has the binding

So for example:

hdbSetObjBindRule(hdbConfig list(list( "mylib" "amplifier" "schematic" "Q3")) list('hdbcViewListRule list("veriloga" "schematic" "spectre" "cmos_sch" "cmos.sch")))

This is an instance binding. You say that Q3 within mylib/amplifier/schematic receives this different view list. So if you then have several instances of amplifier (e.g. I7, I21), then I7/Q3 and I21/Q3 would all see the different inherited view list.

hdbSetObjBindRule(hdbConfig list(list( "mylib" "ampTest" "schematic" "I7") list("mylib" "amplifier" "schematic" "Q3")) list('hdbcViewListRule list("veriloga" "schematic" "spectre" "cmos_sch" "cmos.sch")))

This is an occurrence bindings. You have to give the hierarchical path down to the instance you're binding - so I give the top level lib/cell/view and the instance within that as the first list entry, then the lib/cell/view (that I7 is an instance of) and the instance within that. So in this case I7/Q3 has the inherited viewlist, but I21/Q3 remains at the default view list.

This is apparent if you look at the tree view and expand the various paths. 

So the key is that for a simple instance binding, you just need to provide a list of a single list (of lib/cell/view/inst), whereas for an occurrence binding you need to provide a list of lists, each is the successive lib/cell/view/inst down to the final destination.

You probably will now wish you'd not asked. The commands probably are less gobbledegook than the explanation!

Andrew.

I always appreciate the lengths you go to to educate your readers and I always learn something every time you reply! Interestingly, when I read the documentation for hdbConfig it kind of looked like it was going to end up just like you illustrated in your second example, and I thought to myself "no way would they do this to us!". But they did :-( ...

The schematics I'm working with have significant hierarchy so you're going to be able to see those hdbSetObjBindRule lines of code from the moon. It might be worth my while writing a simple2gobbledygook() function to expand a "normal" hierarchy (e.g. "/top/level_1/level_2/.../level_27/my_cell") into a correspondingly huge and wordy list of lists.

And with all that being said, my original problem now is fully solved and thanks very much (yet again).

OK, I spoke too soon saying everything was fixed. I've repeated my code below to keep things under your eyeballs, only this time I've included your modified line 5 and I added lines 9-10.

1 hdbConfig = hdbOpen( "my_lib" "comp_test" "config_temp" "w")
2 hdbSetTopCellViewName( hdbConfig "my_lib" "comp_test" "schematic" )
3 hdbSetDefaultViewListString( hdbConfig "schematic spectre cmos_sch cmos.sch veriloga ahdl schematic0" )
4 hdbSetDefaultStopListString( hdbConfig "spectre" )
5 hdbSetObjBindRule(hdbConfig list(list( "std_lib" "rv" nil nil)) list('hdbcViewListRule list("veriloga" "schematic" "spectre" "cmos_sch" "cmos.sch")))
6 hdbSave(hdbConfig)
7 hdbClose(hdbConfig)
8 design( "my_lib" "comp_test" "config_temp")
9 do stuff in my Ocean script. The next line is to prevent config_temp getting caught up in our SOS world.
10 ddDeleteObj(ddGetObj("lhasa" "comp_test" "config_temp"))

I first ran the script with line 5 commented out and the rv cell executed as schematic (as expected). I then uncommented it and it executed as Verilog-A, and I was a happy camper. However, I later commented out line 5 again only this time when I ran the script it continued to use Verilog-A instead of reverting to schematic. I've blown many hours trying to figure this out. Now all of this was run in the CIW by loading my Ocean script. If I quit Virtuoso and start over with line 5 commented out I'm back where I started and the problem is repeatable. As near as I can tell, the hdbSetObjBindRule in line 5 adds the corresponding information to the config file, but once that information has been added it's permanently remembered and it can't effectively be removed until I quit Virtuoso. Hopefully this is helpful - if I run the Ocean script in a terminal it completely works as expected i.e. line 5, whether commented out or not, always does the right thing.

So I think either I'm doing something dumb or maybe this is a bug...

I was surprised, but this is a bug - I've reproduced it in the latest IC618 hotfix. It appears to create the new config with the previous binding rule for the cell, which is rather odd.

Could you log a case with support.cadence.com and then post the case number here (please reference this post in the case and state that I would like the case assigned to me)? I'd far sooner report this to R&D with a real customer behind it.

As a workaround, you could just switch between two versions of line 5, where one is setting the cell inherited view list to the same as the default view list (I tried that, and it worked).

Regards,

Andrew.