XST - Memory Problems

OK, so I'm trying to synthesize a huge design. Just for quick reference, the inferred macros are below:

HDL Synthesis Report

Macro Statistics # Block RAMs : 112 16x24-bit dual-port block RAM : 64 1024x12-bit single-port block RAM : 48 # ROMs : 3 16x10-bit ROM : 3 # Multipliers : 480 12x12-bit registered multiplier : 480 # Adders/Subtractors : 3856 10-bit adder : 20 8-bit adder : 32 9-bit adder : 16 7-bit adder : 16 12-bit adder : 1792 24-bit adder : 480 12-bit subtractor : 1472 4-bit subtractor : 15 5-bit adder : 1 4-bit adder : 12 # Counters : 1 5-bit up counter : 1 # Registers : 13434 4-bit register : 30 24-bit register : 577 12-bit register : 480 10-bit register : 20 5-bit register : 1 1-bit register : 12325 3-bit register : 1 # Comparators : 44 10-bit comparator greatequal : 12 5-bit comparator lessequal : 2 5-bit comparator greater : 2 10-bit comparator greater : 7 10-bit comparator less : 11 10-bit comparator lessequal : 8 5-bit comparator greatequal : 1 5-bit comparator less : 1 # Multiplexers : 1070 4-bit 2-to-1 multiplexer : 10 1-bit 2-to-1 multiplexer : 2 12-bit 2-to-1 multiplexer : 1040 24-bit 2-to-1 multiplexer : 1 24-bit 64-to-1 multiplexer : 1 24-bit 16-to-1 multiplexer : 16 # Xors : 480 1-bit xor2 : 480

The code is fairly well-optimized and functionally correct. However, it is a huge design, and it should be about 47,000 SLICEs once all is said and done. But, alas:

"ERROR: Portability:3 - This Xilinx application has run out of memory or has encountered a memory conflict..."

I'm sure plenty of you have gotten this error before. On a machine with 2.5 GB of memory and dual 3.0 GHz processors, should I be getting this error? I've been working on optimizing my code but I was wondering if there is a point where the design is simply too large.

Reply to
Eric
Loading thread data ...

Eric wrote: : OK, so I'm trying to synthesize a huge design. Just for quick : reference, the inferred macros are below:

: HDL Synthesis Report

: Macro Statistics : # Block RAMs : 112 ... : # Multipliers : 480

What part do you traget for?

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

your design is two huge to be put in only one FPGA ...

You will need to split your desing in more FPGAs.

Laurent

Reply to
Laurent Gauch

most Xilinx errors are in the "Portability" DLL :( usually such error means you need to wait for next Service pack. or the next one, etc..

2.5Gb is not enough :( I guess you are targetting VP100 not sure if more memory solves the problem, users with 3GB RAM have seen the same error even with VP70

Xilinx is "commited" to fix all fatal errors, such as yours, so just go start complaining! open webcase etc..

Antti

Reply to
Antti Lukats

I hope so. I tried to contact them and get some help. I've tried targeting the 2VP100 as well as the FX140 and LX200. I've since changed my design substantially, making it smaller and more efficient. The real problem, I think, is with the multipliers - once they can't be used in the DSP48s or the embedded multipliers they take up a lot of space.

All in all it ends up running out of memory regardless of what I do, but sometimes at different places.

Reply to
Eric

What you need to do is flatten your code. Remove the hierarchy in your object structure. I've compiled huge designes that were entirely flattened, i.e., only one object -- the top level object. I've compiled for 37k slices by doing that, though you're still 10k above me. The tools seem to run out of memory much faster if you have a steep hiearchy, i.e., you try to do something normal like reuse code. The other thing you can do is instatiate your primitives manually. Declare all your multiplier and RAM primitives instead of using the inferred objects.

It doesn't appear to me that the Xilinx tools ever use more than 2GB of RAM on a 32bit system. I think that is normal. It's possible that is all a process can get access to. However, if you could get your hands on a 64bit system....

Reply to
Brannon King

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.