09-28-2013 07:07 PM
I am the instructor for a university course using Xilinx ISE Design Suite 14.6 under Linux. In our Linux lab (30 computers), for a number of students completing simple lab exersises (program a MUX and simulate it with iSim....) the tool generates .WDB files that are larger than 1GB. Some of the files exceed 8GB!
I opened on such file in a hex-editor and see that after the first 3450 bytes, the rest of the file is all zeros. I have zipped up this file and attached it here. It extracts to be 1GB.
Is this a known problem? I have not yet narrowed down how to reproduce it reliably. Any suggestions on what to look for to track down the problem?
10-02-2013 09:13 AM
Have not heard this earlier.
But I believe the size of wdb file depends on your simulation run time.
In this case can you confirm if zeros are unwanted outputs and if the issue can be replicated can you upload the design?
10-06-2013 09:13 PM
Thank you for the reply. I believe the simulations are only being run for 1us, and are very simple circuits so I'd be exceptionally surprised if the 8GB .WDB file were correct (as opposed to a very complicated circuit simulating for a long time could generate a huge file, I suppose).
I believe the zeros in the .wdb file are unwanted. Note that I am looking at the file in a hex editor and it seems very unusual that there are so many 0's in the file at the end. When I look at a .wdb file which is a more reasonable size, the contents of the file seem to be non-zero. Hence, I conclude that the billions of zeros at the end of the problem files are in error.
Unfortuantely, I have not been able to replicate the problem consistently. I have heard reports that some of my students are consistently encountering this, so I will follow up with them to try a few avenues of investigation. Here are my thoughts:
1. Find a student who has a project which generates >1GB .WDB files.
2. Try the project on a different machine.
3. Try the project on a different log-in.
4. Try the project in a different installation environment (Windows vs Linux, ...)
Idealy, I'd love to have a project that causes the probelm in all these situations; however, I believe that the problem may not be reproducable enough to get that far.
Is there something else I should be looking at to track down the problem rather than just running a simulation and trying to have it generate huge files? Is there some log, or likely culpret to look at (such as simulation duration, ...)?
Thank you for any ideas you have on how to proceed,
10-16-2013 12:23 AM
01-10-2014 09:15 AM
unfortunately we have the same problem with ISE/ISIM 13.3 running on Redhat Enterprise Linux 5.9. WDB files arbitrarily grow up to 8.1GB even when simulating models as simple as a dual DFF. Since all models are written in VHDL, the Verilog workaround doesn't apply.
I confirm that from some point on the WDB file consists only of zeros. The problem is writing those senselessly large files to disk via NFS heavily impacts system performance.
@Brian: Have you found any solution?
01-20-2014 05:31 AM
we have the same problems with the wdb files with ISE 14.6 running on Kubuntu 12.04 LTS.. Sometimes the files grow up to 8 GB.
For a solution I would be greatful
01-23-2014 08:11 AM
01-28-2014 07:09 AM
our students use the schematic entry to build small circuits eg flips flops, multiplexers, counters ...
Then the students write a testbench, which is then simulated.
In some cases, the wdb files are very large <1GB be. Then the wdb file is filled with zeros.
$finish or $stop commands do not appear in the testbench. But of course we use wait and end process commands.
It is possible that the students have syntax error in their testbench. I can not rule ist out.
02-12-2014 01:05 AM
02-14-2014 01:57 AM
I have asked our students what they have done to produce these large files.
They enter the circuit, write a testbench and simulate the whole.
In some cases, they modify the testbench and then they start the simulation again.
While the software calculates the simulation, they close the first simulation window.
In this case the wdb files are very large.
It seems that a wrong handling with the software produced these large wdb files.
06-23-2014 07:45 PM
I've also encountered this problem. I'm running Ubuntu, with ISE 14.7. Each time I edit and simulate, Project Navigator opens a new ISim window, leaving previous windows open. The large files seem to be created later:
-rw-r--r-- 1 staylor staylor 109 Jun 23 21:04 tb_beh.prj
-rw-r--r-- 1 staylor staylor 7713157120 Jun 23 22:16 tb_isim_beh1.wdb
-rw-r--r-- 1 staylor staylor 8589936366 Jun 23 22:13 tb_isim_beh2.wdb
-rw-r--r-- 1 staylor staylor 8589938646 Jun 23 22:08 tb_isim_beh3.wdb
-rw-r--r-- 1 staylor staylor 26967 Jun 23 22:03 tb_isim_beh4.wdb
-rwxr-xr-x 1 staylor staylor 21792 Jun 23 21:04 tb_isim_beh.exe*
-rw-r--r-- 1 staylor staylor 0 Jun 23 13:45 tb_isim_beh.wdb
-rw-r--r-- 1 staylor staylor 124 Jun 23 21:04 tb_stx_beh.prj
Although not in numerical order. Maybe the files are renamed after they are created. It feels like they are created when I shut down the stale simulation windows.
06-23-2014 10:39 PM
email@example.com Is the simulation ran for a very long duration of time? Also, could you please try not closing the ISIM window and using Re-launch option to re-run simulation? What happens if you add a $stop kind of task to end the simulation or just suspend the simulation in a less time frame does it still create huge WDB file?
09-04-2015 01:17 PM
I'm having this very same issue on linux mint with ISE 14.7.
When I simulate behavioral model from ISE a new isim instance is launched, and if I have several of them open and decide to close them they freeze the system while they make 8.6 GB files.
The obvious solution is to use the Re-launch button on the isim process, so its not a crippling issue, only extremely embarrasing.
As for programs its all fairly basic stuff run at 1 µs, and considering the issue does not happen when I stick to one instance of isim I very much doubt the code could be the culprit.
09-07-2015 10:53 PM
09-10-2015 09:36 AM
It is for a coursework, but once the deadline is passed I'll open the repository and link it, but it will take a while