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.
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
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).
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":
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.
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.
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) -
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
Kelv> Anyway, maybe it is because I didn't upgrade my software. I am using 6.2.02i
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."...
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.