Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
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.