Stats

  • Locked Locked
  • Replies 13
  • Subscribers 143
  • Views 7684
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How do I avoid the renaming of long net names during netlisting/flattening?

skillet

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

  •  Hi,

    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.

    Regards,

    Lawrence.

  •  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?

    Lawrence.

  • 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. 

  • 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.

    Regards,

    Lawrence.

  •  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.

  • Hi Skillet,

    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.

    regards,

    Lawrence. (skillUser)

  • OK, I just saw your latest post, try the setting and see if it helps, it should with the USR6 based version.

    regards,

    Lawrence.

  • Wow, cool! I'll try it right away! Thanks a lot for your help. Much appreciated!

  • Hi Lawrence,

    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

    dbFindNetByName(geGetEditRep() "_LoNgNeTnAmExyz")

    in 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

    geGetEditRep()~>nets~>name

    I can see all kinds of nets with the prefix "_LoNgNeTnAmE". So that clarified for me that ihdl renames nets.

    So 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) $
    sub-version 5.10.41_USR6-64b.127.29

    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.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. 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. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.