Synthesis Error

[naraic]

Hi all,
When I try to synthesise some vhdl code in my project in Xilinx ISE, I get the following error

ERRORortability:3 - This Xilinx application has run out of memory or has encountered a memory conflict. Current memory usage is 2064200 kb.....

It only happens with a couple of my designs, not all.

Anybody know what the problem could be. I tried the fixes that it suggests, but to no avail.

Thanks
Ciarán

 

[RVSachin]

Most of the time, out-of-memory is caused by the software rather than the design, unless, of course, the design is too big to be synthesized with the hardware memory available.

Sometimes, the VHDL structure, such as array of arrays, though it's valid, may cause the software to report this error. In such cases, it's better to contact the vendor's Support.

 

[naraic]

I do have an 255 element array of std_logic_vector(15 downto 0). Could that be causing the problem?

Would I be better to use a ROM block?

 

[RVSachin]

Hi,

An array of just 255 elements cannot cause a problem. Is there any big nested FOR, WHILE loops?
Definetely a 255 element array cannot be the cause.

Can you check your design on any other tool?
OR, can you provide it for us to see why it's going out of memory?

 

[naraic]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_SIGNED.ALL;

entity entropyHuffman is port(
	clk, rst, go, eob: in std_logic;
	zrl, cat: in std_logic_vector(3 downto 0);
	addBits: in std_logic_vector(10 downto 0);
	rfd, done, rdy: out std_logic;
	dout: out std_logic_vector(31 downto 0));
end entropyHuffman;

architecture Behavioral of entropyHuffman is
type mem1 is array (0 to 255) of std_logic_vector(0 to 15);
type mem2 is array (0 to 255) of integer range 0 to 16;
type mem3 is array (0 to 11) of std_logic_vector(0 to 8);
type mem4 is array (0 to 11) of integer range 2 to 9;

constant DC_len: mem4 := (2, 3, 3, 3, 3, 3, 4, 5, 6, 7, 8, 9);
constant DC_code: mem3 := ("000000000","010000000","011000000","100000000",
 "101000000","110000000","111000000","111100000",
 "111110000","111111000","111111100","111111110");

constant AC_len: mem2 := (

256 integer values

 );

constant AC_code: mem1:=(

256 std_logic_vector values

);

signal buf: std_logic_vector(0 to 511);
signal count: integer range 0 to 511;
signal go_int, done_int, rdy_int: std_logic;
begin
	calc: process(clk,rst)
	variable temp, temp1: integer range 0 to 255;
	variable temp_cnt: integer range 0 to 1023;
	begin
		if rst = '1' then
			buf <= (others => '0');
			count <= 0;
		elsif clk'event and clk = '1' then
			done_int <= '0';
			if go_int = '1' then
				temp := CONV_INTEGER(zrl&cat);
				temp1 := CONV_INTEGER(cat);

				if go = '1' then
					temp_cnt := DC_len(temp1) + count - 1;
					buf(count to temp_cnt) <= 
						DC_code(temp1)(0 to (DC_len(temp1) - 1));
				else
					temp_cnt := count + AC_len(temp) - 1;
					buf(count to temp_cnt) <= 
						AC_code(temp)(0 to (AC_len(temp) - 1));
				end if;

				count <= temp_cnt + temp1 + 1;
			     if temp1 /= 0 then
					buf((temp_cnt + 1) to (temp_cnt + temp1)) <= 
						addBits((temp1 - 1) downto 0);
				end if;
			elsif rdy_int = '1' then
				done_int <= '0';
				if count >= 32 then
					dout <= buf(0 to 31);
					buf <= SHL(buf,&quot;100000&quot;);
					count <= count - 32;
				end if;
				if count <= 64 and count > 32 then
					done_int <= '1';
				end if;
			else
				dout <= (others => '0');
			end if;
		end if;
	end process;

	rdySignal2: process(clk,rst)
	begin
		if rst = '1' then
			rdy <= '0';
		elsif clk'event and clk = '1' then
			if eob = '1' then
				rdy <= '1';
				rdy_int <= '1';
			elsif done_int = '1' then
				rdy_int <= '0';
				rdy <= '0';
			else
				rdy <= '0';
				rdy_int <= rdy_int;
			end if;
		end if;
	end process;
		
	goSignal: process(clk,rst)
    	begin
		if rst = '1' then
			go_int <= '0';
		elsif clk'event and clk = '1' then
			if go = '1' then
				go_int <= '1';
			elsif eob = '1' then
				go_int <= '0';
			else
				go_int <= go_int;
			end if;
		end if;
	end process;

	rfd <= done_int;
	done <= done_int;
end Behavioral;[\code]

Sorry for the length of the code. I won't try explain exactly what I'm trying to do.

Could it be the nested if-elsif-else blocks? Though there aren't that many depply nested. 

Any help would be greatly appreciated. I have been lumped with rather a large project for a beginner.

Thanks
Ciarán Hughes

 

[VHDLguy]

There is a lot of logic there to figure out what location in the buf array to modify.

I can see a synthesizer getting chewed up over it.

When I have a bit more time today I will see if I can come up with a way of making it a little easier. But nothing obvious springs to mind with a 15 second look at it.

 

[berett]

Hi

What I see there is a reset value missing for rdy_int, done_int and maybe more. It is a good custom to provide a reset for all the regs, generally.

The lines

rdy_int <= rdy_int;

go_int <= go_int;

in the last two processes are absolutely redundant. It will be a Synchronous Latch (Flip Flop with enable pin) plus a MUX or other logic anyway. I wolud not be very surprised if this caused the problem ... Ofcourse it is correct from the point of language definition itself but such constructs are ... not commonly recognised/used so the folks writing the synthesis software and algorithms could simply forget/ignore such possibility.

Nothing more for the moment ;(

regards

 

[VHDLguy]

Those lines are redundant, however I have met a few very good engineers who insist on puttinf them in just so you don't miss cases. If you have a declaration for every signal in every if or case statement then it makes it harder to miss a case (in theory).

having said that - I rarely do it myself.

Also, why do you say it will be a Latch? It is within a clk'event if statement, so wouldn't it simply be a normal flip-flop?

 

[berett]

This one is just the general comment & response to VHDLguy's questions

(I cannot point to the source of the original problem,
sorry)

Well I have written &quot;Synchronous Latch: i.e. the Flip Flop with enable pin&quot; which provides it keeps the old value when none of the &quot;writing into&quot; conditions from the process is met. Whilst for the regular Flip-FLop there is always something written into (when the clock ticks).

This way we touch the problem of the must for giving all the conditions in if-else statement.

When there is no clock involved then missing a condition will lead to the (very bad) ASYNCHRONOUS Latch instead of the nice MUX probaly intended.

And when there is a clock then we will get either a MUX plus a simple Flip-Flop (when all conditions are described)
or a MUX plus a SYNCHRONOUS (clocked, nice) latch = Flip-Flop with the ENABLE pin.

Thus for the clocked process we don't need anything like

else
a <= a;

Whilst for the not clocked process we cannot do anything like that, because this would be making
a feedback in the combinatorial logic. No sense in digital hardware.
Usually making the simulators
&quot;reaching the max number of deltas&quot; an breaking down.

Eventually I could hardly point the reason for making the &quot;a <= a&quot; in any context other than &quot;just for fun study&quot;

rgds

 

[VHDLguy]

berett, nice summary on that issue.

naraic, you are trying to do a lot of work shifting different values from arrays into your buf. I can see that you are trying to create a big 1 dimensional buffer out of lots of constants based on inputs zrl and cat.

Did you stop and think about how many different multiplexers are going to be needed to create this logic. It is going to be astronomical... I think you will have to rethink your strategy.

I tried to put your design through Synplicity's Synplify and it can back with the error:
Expecting constant expression.
That was on the following line.
buf(count to temp_cnt) <=
DC_code(temp1)(0 to (DC_len(temp1) - 1));
(from the if go='1' line).

Now in theory I don't see why that can't be done, but my synthesiser is oviously following some rule that is probably saying that you can't have more than 1 array index as a non-constant. (because the results will be HUGE).

Your synthesizer is probably not applying that rule, but is trying to create the logic. As a result your system runs out of memory before it figures it all out.

 

[naraic]

Thanks guys. This is a real pain in the ass. I'm probably going to have to break this thing right down, and come up with new logic.