Manipulation on netlist for faster simulation.

Hi, there:

My Xilinx software generated a flattened netlist and SDF each over
100MB...Now NC_Verilog
takes hundreds of hours to simulate that.

Now if I write a perl to replace all the long wire names with some random
10-alphabet string,
it will probably shrink the file size to 10MB...But will that make my
simulation faster?
---sample
  wire
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
0)/F ;
  wire
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
0)/G ;


Thanks.
Kelvin

"Kelvin" <kelvin_xq@yahoo.com> wrote in message news:<41109c40@news.starhub.net.sg>...
> My Xilinx software generated a flattened netlist and SDF each over
> 100MB...Now NC_Verilog
> takes hundreds of hours to simulate that.
> 
> Now if I write a perl to replace all the long wire names with some random
> 10-alphabet string,
> it will probably shrink the file size to 10MB...But will that make my
> simulation faster?
> Thanks.
> Kelvin


My guess is that it will shorten the time needed to perform the steps
that read in these files. With NC that would be compilation and
elaboration. However, I expect it wouldn't really change actual
simulation time because you're not changing the design.

On my last chip, compiling and elaborating the gate-level netlist with
SDF timing took 45 minutes to an hour, so if renaming everything
reduced that even by half, it might have been worth it. Understand
that your renaming script will take a while to run, because it has to
read in these huge files, but if you get lots of simulation runs for
each renaming pass then you should come out ahead.

Only one way to really find out though, you have to try it.

-cb

Hi Kevin,

Kelvin wrote:
> Hi, there:
> 
> My Xilinx software generated a flattened netlist and SDF each over
> 100MB...Now NC_Verilog
> takes hundreds of hours to simulate that.
> 
> Now if I write a perl to replace all the long wire names with some random
> 10-alphabet string,
> it will probably shrink the file size to 10MB...But will that make my
> simulation faster?
> ---sample
>   wire
> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> 0)/F ;
>   wire
> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> 0)/G ;
> 
> 
> Thanks.
> Kelvin
> 
> 
> 
This will not help much, it will just speedup the simulation startup 
because of less file reading.
It will help more to check if you used all performance switches (and 
aviod performance degrading options like +access+rwc or linedebug ;-)).
The online documentation (cdsdoc) has a dedicated chapter ('Maximising 
simulation performance') for it.
HTH

-Eyck

Kelvin wrote:
> Hi, there:
> 
> My Xilinx software generated a flattened netlist and SDF each over
> 100MB...Now NC_Verilog
> takes hundreds of hours to simulate that.
> 
> Now if I write a perl to replace all the long wire names with some random
> 10-alphabet string,
> it will probably shrink the file size to 10MB...But will that make my
> simulation faster?
> ---sample
>   wire
> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> 0)/F ;
>   wire
> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> 0)/G ;
> 
> 
> Thanks.
> Kelvin
> 
> 
> 

Hi Kelvin,

In case your data files are store on a file server and the simulation is 
executed by a separate server, the link between the two servers can be a 
bottle neck.

In SDF simulation the simulator access to the compiled binary files a 
lot, so it is better to put all the files in the same machine that you 
run simulation on.

A lot of UNIX machines have /tmp directory that are accessible by 
everyone, and it is possibly not mount to the file server. So you might 
try to copy your files to /tmp directory and run the simulation from 
there.  (But don't tell your sys admin :-> )

Also try run the simulaion in command mode and redirect stdout to a file 
instead of output to display. (messaage display can be another bottle neck).

Joe

Eyck Jentzsch wrote:
> Hi Kevin,
> 
> Kelvin wrote:
> 
>> Hi, there:
>>
>> My Xilinx software generated a flattened netlist and SDF each over
>> 100MB...Now NC_Verilog
>> takes hundreds of hours to simulate that.
>>
>> Now if I write a perl to replace all the long wire names with some random
>> 10-alphabet string,
>> it will probably shrink the file size to 10MB...But will that make my
>> simulation faster?
>> ---sample
>>   wire
>> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1 
>>
>> 0)/F ;
>>   wire
>> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1 
>>
>> 0)/G ;
>>
>>
>> Thanks.
>> Kelvin
>>
>>
>>
> This will not help much, it will just speedup the simulation startup 
> because of less file reading.
> It will help more to check if you used all performance switches (and 
> aviod performance degrading options like +access+rwc or linedebug ;-)).
> The online documentation (cdsdoc) has a dedicated chapter ('Maximising 
> simulation performance') for it.
> HTH
> 
> -Eyck
> 

I agree with what has been said here but offer another possible 
suggestion to help out with this situation.  Why are you flattening the 
netlist?  If you keep some hierarchy (some not all of it), it will 
likely allow you to better manage the simulation in multiple ways. 
First, that will likely shrink many of the signal names you are having 
problems with as the hierarchy is no longer needed to be preserved into 
each individual signal name.  Second, it would allow you to set 
accessibility to separate portions of the design by allowing you to 
specify the optimizing of portions you are not currently debugging and 
allowing visibility to the portions you are.  Third, you can do a full 
timing simulation of part of your design so rather than trying to 
simulate the whole thing at once, you could do it in pieces.  This not 
only makes for smaller and usually faster simulations but also can allow 
the re-use of sub-level testbenches, allow for parallel simulations (if 
you have more licenses available), uses less memory/less machine 
requirements, easier debug since it is smaller and better understood, 
and a handful of other benefits.  Fourth, you could replace the portions 
of the design you are not currently trying to perform a timing 
verification on with behavioral or RTL code thus doing a mixed 
behavioral/RTL/Timing simulation which should perform much better than a 
full structural simulation.

At some point in the design, it is always beneficial to do a full 
netlist timing simulation as it can detect problems that can be easily 
missed in functional simulation and static timing analysis (even in 
fully synchronous designs) however that is generally best done at the 
very end of the design cycle.  Much of the timing verification can many 
times be done more efficiently in pieces by retaining the hierarchy and 
using it in this phase of verification.  For information on hierarchy 
preservation for simulation, look at Chapter 6 in the Synthesis and 
Verification design Guide, the section titled, "Design Hierarchy and 
Simulation": 
http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf

Hope this helps.

--  Brian

Thank you Brian.

The problem was, the netgen always crashed when I attempted to write a
hierarchical netlist.
I was doing some partial reconfigurable design in V2-6000.
I asked this crash question in this ng also but I can't solve that so fat.
Flattening was my
last resort.

Kelvin






"Brian Philofsky" <brian.philofsky@no_xilinx_spam.com> wrote in message
news:cerpdb$li15@xco-news.xilinx.com...
>
>
> Eyck Jentzsch wrote:
> > Hi Kevin,
> >
> > Kelvin wrote:
> >
> >> Hi, there:
> >>
> >> My Xilinx software generated a flattened netlist and SDF each over
> >> 100MB...Now NC_Verilog
> >> takes hundreds of hours to simulate that.
> >>
> >> Now if I write a perl to replace all the long wire names with some
random
> >> 10-alphabet string,
> >> it will probably shrink the file size to 10MB...But will that make my
> >> simulation faster?
> >> ---sample
> >>   wire
> >>
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> >>
> >> 0)/F ;
> >>   wire
> >>
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> >>
> >> 0)/G ;
> >>
> >>
> >> Thanks.
> >> Kelvin
> >>
> >>
> >>
> > This will not help much, it will just speedup the simulation startup
> > because of less file reading.
> > It will help more to check if you used all performance switches (and
> > aviod performance degrading options like +access+rwc or linedebug ;-)).
> > The online documentation (cdsdoc) has a dedicated chapter ('Maximising
> > simulation performance') for it.
> > HTH
> >
> > -Eyck
> >
>
> I agree with what has been said here but offer another possible
> suggestion to help out with this situation.  Why are you flattening the
> netlist?  If you keep some hierarchy (some not all of it), it will
> likely allow you to better manage the simulation in multiple ways.
> First, that will likely shrink many of the signal names you are having
> problems with as the hierarchy is no longer needed to be preserved into
> each individual signal name.  Second, it would allow you to set
> accessibility to separate portions of the design by allowing you to
> specify the optimizing of portions you are not currently debugging and
> allowing visibility to the portions you are.  Third, you can do a full
> timing simulation of part of your design so rather than trying to
> simulate the whole thing at once, you could do it in pieces.  This not
> only makes for smaller and usually faster simulations but also can allow
> the re-use of sub-level testbenches, allow for parallel simulations (if
> you have more licenses available), uses less memory/less machine
> requirements, easier debug since it is smaller and better understood,
> and a handful of other benefits.  Fourth, you could replace the portions
> of the design you are not currently trying to perform a timing
> verification on with behavioral or RTL code thus doing a mixed
> behavioral/RTL/Timing simulation which should perform much better than a
> full structural simulation.
>
> At some point in the design, it is always beneficial to do a full
> netlist timing simulation as it can detect problems that can be easily
> missed in functional simulation and static timing analysis (even in
> fully synchronous designs) however that is generally best done at the
> very end of the design cycle.  Much of the timing verification can many
> times be done more efficiently in pieces by retaining the hierarchy and
> using it in this phase of verification.  For information on hierarchy
> preservation for simulation, look at Chapter 6 in the Synthesis and
> Verification design Guide, the section titled, "Design Hierarchy and
> Simulation":
> http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf
>
> Hope this helps.
>
> --  Brian
>

Thank you very much Joe! The /tmp idea is interesting.

Kelvin



"Joe" <joe_y@invalid_address.nospam.com> wrote in message
news:cern4o$oua$1$8300dec7@news.demon.co.uk...
> Kelvin wrote:
> > Hi, there:
> >
> > My Xilinx software generated a flattened netlist and SDF each over
> > 100MB...Now NC_Verilog
> > takes hundreds of hours to simulate that.
> >
> > Now if I write a perl to replace all the long wire names with some
random
> > 10-alphabet string,
> > it will probably shrink the file size to 10MB...But will that make my
> > simulation faster?
> > ---sample
> >   wire
> >
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> > 0)/F ;
> >   wire
> >
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> > 0)/G ;
> >
> >
> > Thanks.
> > Kelvin
> >
> >
> >
>
> Hi Kelvin,
>
> In case your data files are store on a file server and the simulation is
> executed by a separate server, the link between the two servers can be a
> bottle neck.
>
> In SDF simulation the simulator access to the compiled binary files a
> lot, so it is better to put all the files in the same machine that you
> run simulation on.
>
> A lot of UNIX machines have /tmp directory that are accessible by
> everyone, and it is possibly not mount to the file server. So you might
> try to copy your files to /tmp directory and run the simulation from
> there.  (But don't tell your sys admin :-> )
>
> Also try run the simulaion in command mode and redirect stdout to a file
> instead of output to display. (messaage display can be another bottle
neck).
>
> Joe
>

Kelvin,

    Sorry.  I didn't see your post on the netgen problem.  I am aware 
that there was a problem in Map in a previous version of the tools that 
could cause Netgen to crash with hierarchical designs under certain 
circumstances however that should be fixed by the latest service pack. 
If possible, could you try it again with the 6.2i SP3 version of the 
software.  If that does not work for you, I would be happy to work with 
you to correct this problem.  Just contact me directly (remove the no_ 
and _spam from the e-mail address) if you want to take me up on this 
offer.  It should be working for you and if not, I would like to know why.


--  Brian


Kelvin wrote:
> Thank you Brian.
> 
> The problem was, the netgen always crashed when I attempted to write a
> hierarchical netlist.
> I was doing some partial reconfigurable design in V2-6000.
> I asked this crash question in this ng also but I can't solve that so fat.
> Flattening was my
> last resort.
> 
> Kelvin
> 
> 
> 
> 
> 
> 
> "Brian Philofsky" <brian.philofsky@no_xilinx_spam.com> wrote in message
> news:cerpdb$li15@xco-news.xilinx.com...
> 
>>
>>Eyck Jentzsch wrote:
>>
>>>Hi Kevin,
>>>
>>>Kelvin wrote:
>>>
>>>
>>>>Hi, there:
>>>>
>>>>My Xilinx software generated a flattened netlist and SDF each over
>>>>100MB...Now NC_Verilog
>>>>takes hundreds of hours to simulate that.
>>>>
>>>>Now if I write a perl to replace all the long wire names with some
> 
> random
> 
>>>>10-alphabet string,
>>>>it will probably shrink the file size to 10MB...But will that make my
>>>>simulation faster?
>>>>---sample
>>>>  wire
>>>>
> 
> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> 
>>>>0)/F ;
>>>>  wire
>>>>
> 
> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> 
>>>>0)/G ;
>>>>
>>>>
>>>>Thanks.
>>>>Kelvin
>>>>
>>>>
>>>>
>>>
>>>This will not help much, it will just speedup the simulation startup
>>>because of less file reading.
>>>It will help more to check if you used all performance switches (and
>>>aviod performance degrading options like +access+rwc or linedebug ;-)).
>>>The online documentation (cdsdoc) has a dedicated chapter ('Maximising
>>>simulation performance') for it.
>>>HTH
>>>
>>>-Eyck
>>>
>>
>>I agree with what has been said here but offer another possible
>>suggestion to help out with this situation.  Why are you flattening the
>>netlist?  If you keep some hierarchy (some not all of it), it will
>>likely allow you to better manage the simulation in multiple ways.
>>First, that will likely shrink many of the signal names you are having
>>problems with as the hierarchy is no longer needed to be preserved into
>>each individual signal name.  Second, it would allow you to set
>>accessibility to separate portions of the design by allowing you to
>>specify the optimizing of portions you are not currently debugging and
>>allowing visibility to the portions you are.  Third, you can do a full
>>timing simulation of part of your design so rather than trying to
>>simulate the whole thing at once, you could do it in pieces.  This not
>>only makes for smaller and usually faster simulations but also can allow
>>the re-use of sub-level testbenches, allow for parallel simulations (if
>>you have more licenses available), uses less memory/less machine
>>requirements, easier debug since it is smaller and better understood,
>>and a handful of other benefits.  Fourth, you could replace the portions
>>of the design you are not currently trying to perform a timing
>>verification on with behavioral or RTL code thus doing a mixed
>>behavioral/RTL/Timing simulation which should perform much better than a
>>full structural simulation.
>>
>>At some point in the design, it is always beneficial to do a full
>>netlist timing simulation as it can detect problems that can be easily
>>missed in functional simulation and static timing analysis (even in
>>fully synchronous designs) however that is generally best done at the
>>very end of the design cycle.  Much of the timing verification can many
>>times be done more efficiently in pieces by retaining the hierarchy and
>>using it in this phase of verification.  For information on hierarchy
>>preservation for simulation, look at Chapter 6 in the Synthesis and
>>Verification design Guide, the section titled, "Design Hierarchy and
>>Simulation":
>>http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf
>>
>>Hope this helps.
>>
>>--  Brian
>>
> 
> 
> 

Anyway, maybe it is because I didn't upgrade my software. I am using 6.2.02i
only.
The error is pasted below, though my partial implementation and assembly had
no error.


Kelvin


C:\projects\bt11a_jul28\top_bt\assemble>netgen -sim -ofmt
verilog -w -ism -sdf_anno true -ngm top_sdr_map.ngm top_sdr.ncd
Release 6.2.02i - netgen G.30
Copyright (c) 1995-2004 Xilinx, Inc.  All rights reserved.

Loading device database for application netgen from file "top_sdr.ncd".
   "top_sdr" is an NCD, version 2.38, device xc2v6000, package bf957,
speed -6
Loading device for application netgen from file '2v6000.nph' in environment
C:/Xilinx6.2.
The STEPPING level for this design is 0.
ERROR:Anno - Cannot correlate logic element
'"Mmux__n0004_inst_mux_f6_0/MUXF6"
   (tag=32161 in view "FRAGCOVERED")' is with this component 'bus_left(0)' -
   cannot continue hierarchical correlation)
ERROR:Anno -
    -
    - This application found errors in the Ngm and/or Ncd data files
    - KEEP_HIERARCHY was corrupted and ignored (database will be flattened)
    -





"Brian Philofsky" <brian.philofsky@no_xilinx_spam.com> wrote in message
news:4112B258.1070403@no_xilinx_spam.com...
> Kelvin,
>
>     Sorry.  I didn't see your post on the netgen problem.  I am aware
> that there was a problem in Map in a previous version of the tools that
> could cause Netgen to crash with hierarchical designs under certain
> circumstances however that should be fixed by the latest service pack.
> If possible, could you try it again with the 6.2i SP3 version of the
> software.  If that does not work for you, I would be happy to work with
> you to correct this problem.  Just contact me directly (remove the no_
> and _spam from the e-mail address) if you want to take me up on this
> offer.  It should be working for you and if not, I would like to know why.
>
>
> --  Brian
>
>
> Kelvin wrote:
> > Thank you Brian.
> >
> > The problem was, the netgen always crashed when I attempted to write a
> > hierarchical netlist.
> > I was doing some partial reconfigurable design in V2-6000.
> > I asked this crash question in this ng also but I can't solve that so
fat.
> > Flattening was my
> > last resort.
> >
> > Kelvin
> >
> >
> >
> >
> >
> >
> > "Brian Philofsky" <brian.philofsky@no_xilinx_spam.com> wrote in message
> > news:cerpdb$li15@xco-news.xilinx.com...
> >
> >>
> >>Eyck Jentzsch wrote:
> >>
> >>>Hi Kevin,
> >>>
> >>>Kelvin wrote:
> >>>
> >>>
> >>>>Hi, there:
> >>>>
> >>>>My Xilinx software generated a flattened netlist and SDF each over
> >>>>100MB...Now NC_Verilog
> >>>>takes hundreds of hours to simulate that.
> >>>>
> >>>>Now if I write a perl to replace all the long wire names with some
> >
> > random
> >
> >>>>10-alphabet string,
> >>>>it will probably shrink the file size to 10MB...But will that make my
> >>>>simulation faster?
> >>>>---sample
> >>>>  wire
> >>>>
> >
> >
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> >
> >>>>0)/F ;
> >>>>  wire
> >>>>
> >
> >
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> >
> >>>>0)/G ;
> >>>>
> >>>>
> >>>>Thanks.
> >>>>Kelvin
> >>>>
> >>>>
> >>>>
> >>>
> >>>This will not help much, it will just speedup the simulation startup
> >>>because of less file reading.
> >>>It will help more to check if you used all performance switches (and
> >>>aviod performance degrading options like +access+rwc or linedebug ;-)).
> >>>The online documentation (cdsdoc) has a dedicated chapter ('Maximising
> >>>simulation performance') for it.
> >>>HTH
> >>>
> >>>-Eyck
> >>>
> >>
> >>I agree with what has been said here but offer another possible
> >>suggestion to help out with this situation.  Why are you flattening the
> >>netlist?  If you keep some hierarchy (some not all of it), it will
> >>likely allow you to better manage the simulation in multiple ways.
> >>First, that will likely shrink many of the signal names you are having
> >>problems with as the hierarchy is no longer needed to be preserved into
> >>each individual signal name.  Second, it would allow you to set
> >>accessibility to separate portions of the design by allowing you to
> >>specify the optimizing of portions you are not currently debugging and
> >>allowing visibility to the portions you are.  Third, you can do a full
> >>timing simulation of part of your design so rather than trying to
> >>simulate the whole thing at once, you could do it in pieces.  This not
> >>only makes for smaller and usually faster simulations but also can allow
> >>the re-use of sub-level testbenches, allow for parallel simulations (if
> >>you have more licenses available), uses less memory/less machine
> >>requirements, easier debug since it is smaller and better understood,
> >>and a handful of other benefits.  Fourth, you could replace the portions
> >>of the design you are not currently trying to perform a timing
> >>verification on with behavioral or RTL code thus doing a mixed
> >>behavioral/RTL/Timing simulation which should perform much better than a
> >>full structural simulation.
> >>
> >>At some point in the design, it is always beneficial to do a full
> >>netlist timing simulation as it can detect problems that can be easily
> >>missed in functional simulation and static timing analysis (even in
> >>fully synchronous designs) however that is generally best done at the
> >>very end of the design cycle.  Much of the timing verification can many
> >>times be done more efficiently in pieces by retaining the hierarchy and
> >>using it in this phase of verification.  For information on hierarchy
> >>preservation for simulation, look at Chapter 6 in the Synthesis and
> >>Verification design Guide, the section titled, "Design Hierarchy and
> >>Simulation":
> >>http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf
> >>
> >>Hope this helps.
> >>
> >>--  Brian
> >>
> >
> >
> >
>

Kelvin,

    I just confirmed that this is the type of error that has been 
addressed by the patch and it was included as a part of Service Pack 3 
so I believe this has been fixed.  If you want to verify whether this 
problem does still exist for you, you should re-run the design through 
the software after installing service pack 3 starting at least the Map 
phase since the fix for this resides in that portion of the flow.   The 
problem in Map effects the hierarchy preservation of the design but does 
not effect the functionality or other aspects so it would not cause any 
issues until hierarchy is attempted to be reconstructed by the netgen 
program which can cause the type of errors that you saw and disallow 
hierarchy reconstruction.

     If for some reason you still see this problem with Service Pack 3 
or  a newer version, just contact me or the Xilinx hotline and we would 
like to get to the bottom of the problem.


--  Brian





Kelvin wrote:
> Anyway, maybe it is because I didn't upgrade my software. I am using 6.2.02i
> only.
> The error is pasted below, though my partial implementation and assembly had
> no error.
> 
> 
> Kelvin
> 
> 
> C:\projects\bt11a_jul28\top_bt\assemble>netgen -sim -ofmt
> verilog -w -ism -sdf_anno true -ngm top_sdr_map.ngm top_sdr.ncd
> Release 6.2.02i - netgen G.30
> Copyright (c) 1995-2004 Xilinx, Inc.  All rights reserved.
> 
> Loading device database for application netgen from file "top_sdr.ncd".
>    "top_sdr" is an NCD, version 2.38, device xc2v6000, package bf957,
> speed -6
> Loading device for application netgen from file '2v6000.nph' in environment
> C:/Xilinx6.2.
> The STEPPING level for this design is 0.
> ERROR:Anno - Cannot correlate logic element
> '"Mmux__n0004_inst_mux_f6_0/MUXF6"
>    (tag=32161 in view "FRAGCOVERED")' is with this component 'bus_left(0)' -
>    cannot continue hierarchical correlation)
> ERROR:Anno -
>     -
>     - This application found errors in the Ngm and/or Ncd data files
>     - KEEP_HIERARCHY was corrupted and ignored (database will be flattened)
>     -
<snip>