ROM size on FPGA is a problem

Hi all,
I successfully used a V2Pro development board to develop an 8051 and CAN system on chip. I used the Keil software to get a hex file then converted it to a ROM file in the 8051. All this was successful.

The ROM I used had a 16-bit address and 32-bit word. It is written by code as follows:
always @ (posedge clk)
begin
case(addr)
16'h0: data_out<=32'h12345678;
16'h1: data_out<=32'h12345678;
......
......
default: data_out<=32'h0;
endcase
end

This worked fine for small programs to test my IP.
When I got the hex file for the drivers and converted it to the ROM file, it reached an address of 16'h108D .... which is about 4K-word.
During mapping, 129 out of 44 block RAMs were used ... and so the process didn't continue because the FPGA doesn't have enough space.

I changed the sensitivity list to "addr" instead of "posedge clk". This resulted in distributed RAM being used instead of block RAM. And still I had a problem with size for overmapping of LUTs.

Here are my questions:
1- Is a 4K*32 bits ROM too large in size ??
Note: the CAN and 8051 used only 50% of the FPGA (xc2vp7-6fg456)
2- Is it really a size problem or is it a wrong mapping made by the tool?
3- If the size is the problem, can the on-board flash PROMs (used for programming the FPGA) be used as ROMs?
4- I need a solution to this problem.

Thanks for everyone in advance.

OK,

To question #1, why is the ROM 32 bits wide when the 8051 is a 8 bit device? Regardless, the Virtex2 block RAMs are 2K by 9 bits. Even if you throw way the parity bits, this 4KX32 ROM should only use, 8 block RAMs. Since the compiler seems to be using much more RAM than this, it is misinterpreting your design. You can open the design with FPGA Editor and then try to figure out why so many more block RAMs are being used. Most likely, the data is being mirrored across numberous RAMs because the compiler believes individual modules need independent control.
To fix this, you need to take explicit control of the ROM implementation. Open up CoreGen and use it to specify your ROM. Then, after you get the ROM defined with a reasonable amount of block RAM, save this as a separate module. This separate module will then be instantiated as a "black box" in your design and the compiler will not longer have to guess how to configure your memory.

Those are good suggestions.

If you are using XST, also refer to your "XST User Guide", chapter "HDL Coding Techniques", section "RAMs and ROMs". It shows how to write Verilog so XST correctly infers a ROM using Block RAMs.

You can also directly instantiate a RAMB16 and initialize it with defparam statements. That's described in your ISE "Libraries Guide".