11-06-2012 06:50 AM
I'm working on a ASIC emulation platform, and am wanting to allow the software guys to update the "ROM" on the "CHIP" without rerunning the FPGA design flow.
After lots of scouring the internet and forums, I've gotten about 95% the way there, but am stuck trying to get the bits to go to the right places.
My ROM wrapper is
rom1p_2048x32m8 u_rom_0 ( // 8 Kbytes ROM .CLK (mcu_clk), .CEB (rom_ceb0), .A (haddr[12:2]), .Q (rom_rdata0) ); rom1p_2048x32m8 u_rom_1 ( // 8 Kbytes ROM .CLK (mcu_clk), .CEB (rom_ceb1), .A (haddr[12:2]), .Q (rom_rdata1) );
With those two instances being an instance of core-generated 32bits wide, 2048 instances deep single port roms.
I use this .bmm file in the project:
// BMM LOC annotation file. // // Release 13.1 - Data2MEM O.40d, build 1.9 Aug 19, 2010 // Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved. /////////////////////////////////////////////////////////////////////////////// // // Address space 'rom_code' 0x00000000:0x00003FFF (16 KBytes). // /////////////////////////////////////////////////////////////////////////////// ADDRESS_SPACE rom_code RAMB32 [0x00000000:0x00003FFF] BUS_BLOCK u_cortex_top/u_m3_mem_wrap/u_rom_0/u_blockrom/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop.ram.r/v6_init.ram/SP.SIMPLE_PRIM36.ram [15:0]; u_cortex_top/u_m3_mem_wrap/u_rom_0/u_blockrom/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop.ram.r/v6_init.ram/SP.SIMPLE_PRIM36.ram [31:16]; END_BUS_BLOCK; BUS_BLOCK u_cortex_top/u_m3_mem_wrap/u_rom_1/u_blockrom/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop.ram.r/v6_init.ram/SP.SIMPLE_PRIM36.ram [15:0]; u_cortex_top/u_m3_mem_wrap/u_rom_1/u_blockrom/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop.ram.r/v6_init.ram/SP.SIMPLE_PRIM36.ram [31:16]; END_BUS_BLOCK; END_ADDRESS_SPACE;
It gets annotated when the design builds (the "PLACED" and sites get added to the _bd.bmm) file.
Using the following .mem file
@0000 0 ffffffff 0
and updating the bitfile with
data2mem -bm ./rom_code_bd.bmm -bd mem.mem -bt output/fpga_top.bit -o b new_fpga_top.bit
When I look at the ROM from the ARM JTAG debugger, I see this in the first few addresses:
0x00000000: FFFC1EFF 0x00000004: 000000F0
I know the ROM is hooked up right because I have a .COE file that I imported into the generated ROM core that shows up correctly.
As you can see, the tools are choosing a RAMB36 to implement the block memory. I suspect that data2mem is having issues with this, or I'm not properly telling it how to handle it.
11-06-2012 02:34 PM
The BRAM is 36K (K=1024 bits). So, if your memory is 32K (or 8K or 16K) bits .... you have a mis-match!
data2mem maps contents into the 36K (x1 bit wide) BRAM, so you are going to need to understand how your BRAM's are being used (what format, address width, data width), and then understand how to map your 2Kx8 blocks into the proper places inside the 36K (by 1 bit) BRAM block.
11-06-2012 02:55 PM
That is the crux of the problem.
Where is it documented how a simple 32 bit by <X> location memory generated by the core-generator get mapped to the physical RAMB36 rams of the virtex 6 platform, and where is it documented how I describe that in a BMM file?
I know it takes 2 RAMB36 blocks to describe each of my rom banks, and that it seems to be split between the upper word/lower word (from inspecting the unmodified bitfile dump), and it looks like the parity information is simply ignored, but for the life of me I can't figure out how to tell the tools 'this is a 32 bit RAM without parity being mapped onto these two 36bit rams with parity and half the word in this bank, and half in the other bank'
If I use RAMB36 in the BMM file, it complains that [15:0] isn't 18 bits. If I make it [17:0], the memory sizes don't match (it seems like it isn't treating the extra bits as parity, but as part of the data).
This is a VERY straight forward use case: make a 32x2048 single port rom with the 'smallest' algorithm using the core generator and try to use the tool flow to get a mem file updating the "rom" in the bitfile using data2mem.
11-07-2012 07:01 AM
What MIGHT be the problem is my version of ISE (13.1) and block ram generator (6.1) seems to want to make ROMS with 9bit bytes, and says "this will be fixed in a later version".
11-07-2012 04:09 PM
Indeed. I gave up with the generated roms and instanced my own using the BRAM_SINGLE_MACRO method.
After that, and a bit of worrying about word ordering, I was able to update the bitfile after the fact.
06-17-2013 09:51 AM
I am getting the same problem with Vivado 2013.1.
ERROR::26 - Illegal bit lane width in ADDRESS_SPACE 'bram0_top'.
op.ram.r/v6_noinit.ram/NO_BMM_INFO.SP.SIMPLE_PRIM36.ram [15:8]' is 8 bits wid
e. Only 1, 2, 4, 9, 18, 36, 72 bit widths are allowed for this device.
Was there any solution to this problem. I see that Schulte461 gave up on 11/7/2013.