Manipulation on netlist for faster simulation.

[Kelvin]

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

 

[Brian Philofsky]

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]

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]

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]

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 will try out SP3. Thanks for your reply.

I guess, did you write all the ultra-long lines in the xilinx warnings and
fatal errors?
For example, this line, "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."...

Best Regards,
Kelvin





"Brian Philofsky" <brian.philofsky@no_xilinx_spam.com> wrote in message
news:4113A90E.4080506@no_xilinx_spam.com...

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

 

[Brian Philofsky]

Kelvin wrote:

I will try out SP3. Thanks for your reply.

I guess, did you write all the ultra-long lines in the xilinx warnings and
fatal errors?

I have wrote a few of them but I have read many more of them, perhaps
too many of them, if I am starting to talk like that ;-) Actually, I
have been rewriting many of our docs lately and I guess I am just in
that mode of thinking. I do have a tendency to get a little more
verbose like this in a wide audience situation as I find it can save me
typing time to say a little more up front than to get several follow-up
questions for being unclear about something.

-- Brian

For example, this line, "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."...

Best Regards,
Kelvin





"Brian Philofsky" <brian.philofsky@no_xilinx_spam.com> wrote in message
news:4113A90E.4080506@no_xilinx_spam.com...



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