Sign In

Don't have a Xilinx account yet?

  • Choose to receive important news and product information
  • Gain access to special content
  • Personalize your web experience on Xilinx.com

Create Account

Username

Password

Forgot your password?
XClose Panel
Xilinx Home
Reply
Regular Contributor
kensou
Posts: 81
Registered: ‎05-15-2009
0

RAMB36 vs IPCORE Block RAM Generator

Hello everybody, I have to implement a Block Ram inside my project with Xilinx ISE 12.1 for Virtex-5 and I know there are two ways to get it: I can implement an IPCore component using IPCORE Block RAM Generator v4.1 or I can use the primiteive RAMB36.

The RAM component requests are:

 

-Single port RAM

-Write Width: 16 bits

-Read Width: 16 bits

-Write Depth: 256

-Always Enabled

 

So this mean 16 bits x 256 area memory.

 

I need to reache the best combination of

-Highest frequency supported

-Minimum Block Ram Area used

-Minimum delay between data written and his availability in reading mode (so I'd need to have the data available for reading as soon as possible after its writing... I hope you understand what I mean)

 

What I should choose: IPCore or RAMB36?

 

I hope you could help me, thanks a lot in advance for all your answers!

 

Expert Contributor
rcingham
Posts: 2,010
Registered: ‎09-09-2010
0

Re: RAMB36 vs IPCORE Block RAM Generator

"What I should choose: IPCore or RAMB36?"

I do not think that there will be any difference in achievavble speed nor BlockRAM usage whichever you use. The memory size you require will easily fit in a single BlockRAM.

The CoreGen path is probably easier for a novice. Also, it will give you the option to change to using Distributed RAM easily, should you wish to experiment with that.

------------------------------------------
"If it don't work in simulation, it won't work on the board."
Regular Contributor
kensou
Posts: 81
Registered: ‎05-15-2009
0

Re: RAMB36 vs IPCORE Block RAM Generator

I usually im plement IPCore but I've seen in My project there was a RAMB36 module yet implemented so I was wondering why someone should choos RAMB36 instead of IPCore (and vice versa, of course).

 

I also tried to insert the ram as

 

entity RAM_BLOCK is
 port (
		 clka: IN std_logic;
		 rsta: IN std_logic;
		 wea: IN std_logic_VECTOR(0 downto 0);
		 addra: IN std_logic_VECTOR(7 downto 0);
		 dina: IN std_logic_VECTOR(15 downto 0);
		 douta: OUT std_logic_VECTOR(15 downto 0)
       );
end RAM_BLOCK;

architecture Behavioral of RAM_BLOCK is

type ram_type is array (255 downto 0) of std_logic_vector (15 downto 0);
signal RAM : ram_type;
attribute ram_style : string;
attribute ram_style of RAM: signal is "block";

begin

	wr_rd_proc : process(clka, rsta)
	variable index : integer range 0 to 255 := 0;
	begin
	if (rsta = '1') then
	    douta <= x"0000";
		 index := 0;
	    for i in 0 to 255 loop
		     RAM(i) <= x"0000";
	    end loop;
	elsif rising_edge(clka) then
			index := to_integer(unsigned(addra));
			if (wea = "1") then
				 RAM(index) <= dina;
			else douta <= RAM(index);
			end if;
	end if;		
	end process;


end Behavioral;

 

But in this way the Area Constraint increases very very high (from around 68 out of 100 of IPCore coice to 168 out of 100 of RAM_BLOCK component, with an increment of Number of Slice Registers from 43% to 115% and an increment of Number of Slice LUTs from 63% to 94%

 

I don't know where could it be the problem... in my project, this way would be preferred

 

Do you know where could it be the error?

 

Thank you!

Expert Contributor
rcingham
Posts: 2,010
Registered: ‎09-09-2010
0

Re: RAMB36 vs IPCORE Block RAM Generator

To properly infer a RAM, rather than a register file, I think that you need to declare 'RAM' to be a shared variable, and NOT have reset functionality. Probably the lack of reset is more important.

------------------------------------------
"If it don't work in simulation, it won't work on the board."
Expert Contributor
gszakacs
Posts: 5,253
Registered: ‎08-14-2007
0

Re: RAMB36 vs IPCORE Block RAM Generator

Both the XST manual and the ISE language templates show examples for inferring block RAM.

There are a number of things to get right or you will end up with either a lot of fabric flops or

distributed memory.  Generally it's best to start from the templates if you're not sure how the

internals of the block RAM work.

 

You need to remember that the block RAM needs one clock cycle to push a read through,

and it generally doesn't matter if you code this as a delay on the address into the RAM or

on the data coming out.  However all of the code describing the array, the registers, and

any initialization data has to be in the same module.

 

-- Gabor

-- Gabor