Memory leak in Xilinx? Code error?

[Andromodon]

Hello. I am writing VHDL code to be synthesized on a Xilinx Spartan II
FPGA. For the past month, I've been beating my head against one
problem with synthesizing the latest version of my code. I am using
the Xilinx Webpack IDE V7.1.01i available for free from
http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack.
Synthesis usually takes about a minute with my previous code versions.
When I added a few lines about a buffer and references to that buffer,
and try to synthesize, the synthesis goes to 66% of completion
normally, but then stays there for about 15 minutes before spitting out
an out of memory error:

ERRORortability:3 - This Xilinx application has run out of memory or
has encountered a memory conflict. Current memory usage is 1954536 kb.
Memory problems may require a simple increase in available system
memory, or possibly a fix to the software or a special workaround. To
troubleshoot or remedy the problem, first: Try increasing your
system's RAM. Alternatively, you may try increasing your system's
virtual memory or swap space. If this does not fix the problem, please
try the following: Search the Answers Database at support.xilinx.com
to locate information on this error message. If neither of the above
resources produces an available solution, please use Web Support to
open a case with Xilinx Technical Support off of support.xilinx.com.
As it is likely that this may be an unforeseen problem, please be
prepared to submit relevant design files if necessary.
ERROR: XST failed
Process "Synthesize" did not complete.

I have stripped my program down to the simplest version that still
exhibits the problem:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity frameCapture is
port (
clk :in std_logic;
lineBuffer : out std_logic_vector(1780 downto 0); --will buffer most
significant 5 bits of each pixel on even lines.
UV: in std_logic_vector(7 downto 0)); --Digital output from
camera. UV bus.
end frameCapture;

architecture reg_transfer of frameCapture is

signal bufPosOne, bufPosTwo, bufPosThree : integer range 0 to 1785;
--are five more than they needs to be to prevent negative
numbers.
signal colCount : integer range 5 to 25 :=5; -- I picked these values
in this example so that bufPosTwo and bufPosOne are obviously
-- between 0 and 1785.
begin

bufPosTwo<= colCount*5+4;
bufPosOne<= colCount*5+0;

process (clk)
begin
if clk'event and clk = '1' then
if colCount<= 25 then
colCount <= colCount + 1;
else
colCount <= 5;
end if;
LineBuffer(bufPosTwo downto bufPosOne) <=UV (7 downto 3);
end if;
end process;

end reg_transfer;

-------
I have been trying to troubleshoot this problem for the past month, and
have a deadline soon aproaching, so I am in desperate need of help.
I'm even willing to compensate you for your time spent if you resolve
the problem. Is my bit of code doing anything illegal? Can you see
any reason why my code should make the ISE work so hard it runs out of
memory? From my experimentation, the problem does not have to do with
colCount, but the indexing of LineBuffer with bufPosTwo and bufPosOne.

Thanks for any help you can provide. It will be greatly appreciated!

Sincerely,
Andrew Doucette

 

[info_]

Hi,

Not exactly a hardware-friendly code !

You write a huge barrel shifter without necessity -I think-.
Running that at clock speed (no multicycle, in case the synthesis
tool doesn't choke on this is probably not guarantied either.
You'd probably better arrange your line buffer as a shift register,
shifting 5 bits at a time.

LineBuffer <= UV (7 downto 3) & LineBuffer(LineBuffer'high downto 5);
This _will_ run at full speed.

It's not very good either to write a non static length for your
variable posittion assignment. At least, you should use only
one variable (MSB position e.g.) and use a constant for the
slice's nb of bits. I don't think the synthesis tool can "see"
that the slice length is in fact constant. You did hide that nicely.
But really I don't see (in this snippet) why using this huge barrel shifter.

I don't know your application, but maybe it's not most efficient
to store your line information under this form.
Memories have many advantages for storing arrays of data sequentially...

Bert Cuzeau

 

[Andromodon]

Dear Bert,

Thank you very much for your help. I'll try and see if I can make my
design more hardware friendly. Thanks again!

~Andy