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