I'm trying to write an Ocean script to simulate my circuit (comp_test) and within that script I want to fully define the "config" simulation state (e.g. schematic, spectre, verilogA...) of the various blocks within the schematic hierarchy.I have a few lines of code that I've started out with:
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('hdbcBindingRule list("std_lib" "rv" "veriloga")) )6 hdbSave(hdbConfig)7 hdbClose(hdbConfig)8 design( "my_lib" "comp_test" "config_temp")
In line 5 I specify a given cell and force it to be executed as Verilog-A wherever it's encountered in the hierarchy i.e. this is a cell based command. I'm having trouble trying to figure out how I can specify a given cell (e.g. clk_gen, which contains a lot of hierarchy) and force everything within that cell to be executed as Verilog-A. I do not want to have to resort to making a line of code for every single instance contained within the full hierarchy of the clk_gen cell i.e. I'm effectively looking for a way to do wild-card configuration. Is this possible?
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!)
The syntax is:
hdbSetObjBindRule(hdbConfig list(list( "std_lib" "rv" nil nil)) list('hdbcViewListRule list("veriloga" "schematic" "spectre" "cmos_sch" "cmos.sch")))
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:
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!