11-11-2008 10:10 PM
I am compiling a design for V5 LX330 on a Vista Home Premium with 4GB RAM. I am using ISE 10.1. After a 6 hour of synthesis, translate and map, as soon as compilation moves to place and route, ISE runs out of memory. Any pointers will be appreciated. Here is the error message
Using target part "5vlx330ff1760-2".
Mapping design into LUTs...
Running directed packing...
Running delay-based LUT packing...
INFO:Map:215 - The Interim Design Summary has been generated in the MAP Report
Running timing-driven packing...
ERROR:Portability:3 - This Xilinx application has run out of memory or has
encountered a memory conflict. Current memory usage is 3138320 kb. You can
try increasing your system's physical or virtual memory. For technical
support on this issue, please open a WebCase with this project attached at
Number of errors : 0
Number of warnings : 18
Process "Map" completed successfully
11-11-2008 11:49 PM
11-12-2008 07:47 AM
Windows XP has a hard limit of 3 GB of memory addressing due to the last GB only being available to kernel processes. Vista had a similiar issue but from a quick search, I found that SP1 of Vista fixed this http://support.microsoft.com/kb/929605.
11-19-2008 09:47 AM
You should review this:
http://www.xilinx.com/ise/products/memory.htm (Memory Recommendations)
I have the same problem but I am running Windows XP. Looking at the table in memory.htm linked above, it tells me that for my part it will typically use 1.0 GB and maximum of 1.5 GB.
I have 4 GB of RAM and yet I get the error:
line 382 - Running XST synthesis
ERROR:Portability:3 - This Xilinx application has run out of memory or has encountered a memory conflict. Current memory usage is 2090268 kb. You can try increasing your system's physical or virtual memory. For technical support on this issue, please open a WebCase with this project attached at http://www.xilinx.com/support.
At first I thought this was ~2 Gb but I realized it is actually ~0.2 GB, and yet it fails.This seems to be a common problem in EDK and there are numerous solutions online, all of which do not seem to apply to my design. How does EDK "run out of memory" at under half of a GB of memory? I have plenty available.
AR # 15336 is the most pertinent but still does not solve my problem. It states that this issue will be fixed in EDK 9.1i but it is unclear if this is only the 'if' problem or the running out of memory problem.
- This answer record states that XST can run out of memory when synthesizing large state machines - I have none containing more than a few states.
- It also states there may be an issue when synthesizing heavily nested 'if' statements. I have some nesting but I have done much more in much more complicated designs without any problem.
- It states that you can run out of memory when instantiating components many times - It says to create Black Boxes to get around this problem.
I think this the most related to my issue because I have instances of 16 different Coregen edn/ngc Black Boxes of the dds_synth Core - each a different core configuration with different netlist and a single instantiation for each. I also have several netlist fifos instantiated. All of these were generated by Coregen.
Are all netlists black boxes as Xilinx defines them? Or does 'black box' imply something more than a netlist? Xilinx documentation has failed to answer this question for me, but has led me to believe that they are identical.
Either way - I should be able to instantiate 20 netlists of relatively small footprint with minimal logic without a problem. Secondly - XST should not run out of memory at around a quarter of a GB. I am using the 10.1 version of the Xilinx tools.
Why has this been an issue since version 7 of the tools and continues to be?
Why does XST run out of memory at a quarter GB? How can I solve this problem?
06-09-2009 04:05 PM
06-09-2009 04:30 PM
Thank you. I tried using the /3 and some programs ran while others crashed, including EDK. I went back to my old configuration.
Xilinx highly suggested purchasing a 64 bit machine with a lot of RAM to run this. I went ahead and did this, only to find out that EDK does not run on 64 bit Windows, only on 64 bit Linux. So I then switched to 64 bit Linux and ran my design successfully. This allowed me to find the poor design choices I had made to make the design "blow up". Now the design runs easily on my old 32 bit XP machine without running out of RAM.
I only wish that the Xilinx support person who sucessfully ran my design had mentioned that the part was 1000% overmapped and/or had mentioned that EDK 64 bit is only for Linux while telling me to purchase a new machine. He claimed that 64 bit is the industry standard for firmware designing, my question is why Xilinx would not release a 64 bit Windows version of EDK if this is true. I would guess that 64 bit Linux is not the industry standard.
Anyways, I got a new computer out of the deal. Unfortunately I primarily use EDK and AHDL, which only runs on Windows. So I cannot run 64 bit EDK and AHDL on Linux, so I run two computers, one 32 bit XP with AHDL and one 64 bit Linux with EDK or just EDK and AHDL on my old 32 bit WIndows machine. This causes my new machine to go unused frequently. I am hopeful for a soon release of EDK 64 for Windows.
06-09-2009 04:45 PM
I was having exactly the same problem. I was trying to run EDK on a 64-bit Windows machine and was getting weird crashes. Then I was told by the FAE that Xilinx only supports 64bit+Linux EDK configuration because it's used by more developers.
With ISE 11.1 I can compile my design on 32-bit Windows machine. But I still want to get 64-bit Windows EDK support.
06-09-2009 04:57 PM
My Windows installer would not even allow me to install EDK on my 64 bit XP. Apparently you can do it, but it causes problems.
One of my problems is that I have never been able to get the Linux drivers working for the USB JTAG programmer I am using. So I use 32bit XP to program th FPGA if I use Linux 64 to build it. Frequently when I copy the project folder over, somehow the software projects come detached although the files still are present. Also the UCF path is often lost. This does not always happen, and I am unsure what would cause this, but both happen frequently. This deters me from running on my Linux 64 machine at all since I ultimately have to use XP to program my FPGA in the end.
I like your website. Neat tools - I don't need them now, but perhaps in the future.