UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor schult461
Visitor
10,206 Views
Registered: ‎09-07-2012

Updating a ROM in a .bit file

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[0].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[1].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[0].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[1].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.

 

Help!

0 Kudos
7 Replies
Scholar austin
Scholar
10,197 Views
Registered: ‎02-27-2008

Re: Updating a ROM in a .bit file

s,

 

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.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Scholar austin
Scholar
10,196 Views
Registered: ‎02-27-2008

Re: Updating a ROM in a .bit file

or worse yet:  64K bits does not fit in one 36K bit BRAM....

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor schult461
Visitor
10,194 Views
Registered: ‎09-07-2012

Re: Updating a ROM in a .bit file

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.  

0 Kudos
Visitor schult461
Visitor
10,179 Views
Registered: ‎09-07-2012

Re: Updating a ROM in a .bit file

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".

 

:/

0 Kudos
Visitor schult461
Visitor
10,169 Views
Registered: ‎09-07-2012

Re: Updating a ROM in a .bit file

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.

 

 

0 Kudos
Visitor luqman1
Visitor
9,827 Views
Registered: ‎06-17-2013

Re: Updating a ROM in a .bit file

Hi,

 

I am getting the same problem with Vivado 2013.1.

 

ERROR::26 - Illegal bit lane width in ADDRESS_SPACE 'bram0_top'.
    'bram_rom/U0/inst_blk_mem_gen/gnativebmg.native_blk_mem_gen/valid.cstr/ramlo
op[0].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.

 

Thank you

 

 

0 Kudos
Scholar stephenm
Scholar
9,785 Views
Registered: ‎05-06-2012

Re: Updating a ROM in a .bit file

Please see the data2mem debug guide:

http://www.xilinx.com/support/answers/46945.htm

0 Kudos