I've been able to read a Verilog file into DFII via ihdl to create a netlist view. My intent is to create an autoLayout view, so I go to "Tools --> Floorplan/Netlist in my window that shows me the netlist view and then go to the Hierarchy Browser. After preparing all my settings I click on "Hierarchy ---> Generate Physical Hierarchy". Eventually I get my autoLayout view.
Everything seems hunky-dory, except that some nets have gotten renamed to something like "_LoNgNeTnAmE108(123)". It appears the flattener didn't like the original net name (even though it's not really that much longer and I don't think there are restrictions on net names in the CDBA, or maybe it's 256 bytes but I'm nowhere near that length).
The problem now is that I can't correlate some of my nets in the Verilog netlist with the nets in my floorplan.
I haven't found any documentation on net renaming or the generation of a mapping file that would help me sort this out. There's nothing to be found in the adpFlatten directory that I could take advantage of.
Any comments what else I could try to remedy this problem? I need my symbolic netlist match exactly my Verilog netlist. BTW, my netlist is flat. In other words, there is no hierarchy involved. It's just a bunch of blocks (represented by abstracts) interconnected by a bunch of nets.
The DFII version I'm using is IC5.1 on Solaris (Sparc V9).
I've seen this in the past, and I believed that for many cases this was fixed/improved.
Which exact subversion of IC5141 are you using? This may be important information.
I forgot to mention that the net names created by the flattening process were long because the hierarchical path was combined with the net name to essentially make a long string - are you sure that the net names are relatively short?
In reply to skillUser:
The version is icfb.exe version 5.1.0 09/13/200
Yes, I'm perfectly sure the net name is short because the design is flat to begin with. No hierarchy involved whatsoever.
In reply to skillet:
What I am asking for is the subversion information, i.e. the line that says "sub-version" in the CDS.log, or type getVersion(t) in the CIW to get this information. My guess is that your IC5141 installation is not the latest, which probably contains fixes for this issue.
Oops, sorry, forgot about the command, but here it is:
icfb -W: sub-version 5.10.41_USR4.54.77
I just switched to sub-version 5.10.41_USR6.127.29 with the same results. I think it is the latest IC5 version I have access to.
Do you have a .cdsenv in your home directory (or current directory, if the CDS_LOAD_ENV environment variable is set appropriately)?
Add or change the following setting:
ihdl maxNetNameLength int 8000
You don't want to set this any higher than 8000 in case it prevents other tools from working, further down the line, but you can certainly set it lower - if this has no effect, then the installation is too old to use it, in other words, the setting was added after your subversion.
I've got a strong feeling that USR4 does not include this and so you will need to update the software to avoid this issue.
OK, I just saw your latest post, try the setting and see if it helps, it should with the USR6 based version.
Wow, cool! I'll try it right away! Thanks a lot for your help. Much appreciated!
So far I haven't had any luck. However, I need to
clarify a few things. When I started this thread, I thought that long
net names were changed by the flattener. The reason I thought so is
because I checked the database and looked for a specific net name that
I found in the autoLayout view, using
the netlist view. Well, turns out I must have searched for the wrong
net name and when nil was returned, I thought this proved that the
netlister causes the net mapping. Now when I do a
I can see all kinds of nets with the prefix "_LoNgNeTnAmE". So that clarified for me that ihdl renames nets.
now to ihdl. I'm generally able to read in a netlist using our Linux
version of DFII. The SPARC Solaris versions we have (incl. the latest
one, namely 5.10.41_USR6.127.29) crash with a segmentation fault during
VerilogIn. When trying to read the Verilog file via the Linux version
layout.exe_64 version 5.1.0-64b 10/28/2008 16:04 (cicamd4) $
it doesn't seem to recognize the entry
ihdl maxNetNameLength int 1024
in my .cdsenv file in my directory. I first left CDS_LOAD_ENV untouched, but even after setting
setenv CDS_LOAD_ENV CWD
it doesn't work. I'm stuck. If you had any other suggestion, I'd be very greatful.
I think that I missed an important point - the above .cdsenv setting is used by VerilogIn when running from the GUI, but if you are running "ihdl" from the command line, then you will need to pass the option to ihdl through a setting in the parameters file, e.g.
maxNetNameLength := 4000
This setting was added from about USR3 onwards I believe, so the version that you are using should understand and use it.
Also I noticed in your version strings that you might be running in 64-bit mode; I'm not sure this will work for ihdl, so you might want to ensure that you turn off 64-bit mode for ihdl from the command line.
Hope this helps!
max_net_name_length := 4000
maxNetNameLength := 4000
ihdllnx86 -f ihdl_files -p paramFile <topRTL>.v
dest_sch_lib := <destLibName>
ref_lib_list := basic, <otherLibs>
import_if_exists := 1
import_cells := 0
import_lib_cells := 0
structural_views := 6
schematic_view_name := schematic
functional_view_name := functional
netlist_view_name := netlist
symbol_view_name := symbol
log_file_name := ./verilogIn.log
map_file_name := ./verilogIn.map.table
work_area := /home/<user>/verilogIn
power_net := vdd
ground_net := vss
create_map_table := 1
max_net_name_length := 4000
sheet_symbol := Asize
page_row_limit := 512
page_col_limit := 256
label_height := 12
line_line_spacing := 0.2
line_component_spacing := 0.5
density_level := 0
client := synthesis
alias_module := cds_alias
cont_assign_symbol := basic patch symbol
Oops, sorry about the mistake in my post.
I think that you may need to file a Service Request with customer support; this may be a data specific case, or something that was missed in the fixes, and so Cadence R&D may need to see this in order for there to be progress on the issue.