Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Mapping block RAMs to specific address space

Status
Not open for further replies.

sajjad.hussain

Junior Member level 1
Joined
May 20, 2015
Messages
17
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,477
I am trying to load my program to a Block RAM using Data2mem, after the bitfile is generated. Here are the steps:

I have generated a BLOCK RAM as single port ROM with 32 bit-width and 16384 bit-depth.
Then translated the design without any BMM file and looked at the PlanAhead tool to see which BRAM are used and which ramloop is assigned. There are 15 ramloop lines. There are 14 PRIM36 primitives and 1 PRIM18 primitive as shown below:
Code:
BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/v5_init.ram/SP.SINGLE_PRIM18.SP **(RAMB18)**

BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/v5_init.ram/SP.SINGLE_PRIM36.SP **(RAMB36_EXP)**

BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/v5_init.ram/SP.SINGLE_PRIM36.SP (RAMB36_EXP)

BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/v5_init.ram/SP.SINGLE_PRIM36.SP (RAMB36_EXP)

⋮⋮
BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[14].ram.r/v5_init.ram/SP.SINGLE_PRIM36.SP (RAMB36_EXP)

I wrote the following .BMM file for address the ROM from 0x0000 to 0xFFFF. and add it to the xilinx project.
Code:
ADDRESS_SPACE pr_mem1 RAMB32 [0x00000000:0x0000ffff]
BUS_BLOCK

BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/v5_init.ram/SP.SINGLE_PRIM18.SP [31:0];
    END_BUS_BLOCK;
    BUS_BLOCK

BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/v5_init.ram/SP.SINGLE_PRIM36.SP [31:0];
    END_BUS_BLOCK;
    BUS_BLOCK

BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/v5_init.ram/SP.SINGLE_PRIM36.SP [31:0];
    END_BUS_BLOCK;
    BUS_BLOCK

BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/v5_init.ram/SP.SINGLE_PRIM36.SP [31:0];
    END_BUS_BLOCK;
    BUS_BLOCK

⋮⋮
BROM_instance/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[14].ram.r/v5_init.ram/SP.SINGLE_PRIM36.SP [31:0];
    END_BUS_BLOCK;
    END_ADDRESS_SPACE;

But when I tried to compile it again it gives me the error:
ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE 'pr_mem1'.

Can you please help me out where the error is occurring? Is ramloop[xx] correctly used?
 
Last edited by a moderator:

does the coregen core have an example .bmm file that you can use? It is clear that the core has some form of space saving that isn't accounted for in your bmm attempt.
 

Hi,

I'm no specialst in this area...therefore just some thoughts:

Isn't it so that the block RAM of 16384 depth gives 14 address lines....and you want to divide them in different sections, then you need some address decoder (or address selector). This is extra logic and you are free to divide the whole address space into logical sections.

Klaus
 

The range you specify seems to be for depth 65536.
Try

Code:
ADDRESS_SPACE pr_mem1 RAMB32 [0x00000000:0x00003fff]
 

14 BRAM 36 = 516096
+ 1 BRAM 18 = 534528
16384*32 = 524288
15 BRAM 32 is 491520

The 14+1 implementation is the smallest implementation that has enough storage. A 15 BRAM32 implementation not using the parity space is not large enough. (16 is exactly large enough.) From this, it is clear the BRAM has some form of area efficient mapping that makes use of the parity space. The exact mapping isn't clear, only that some combination of clock enables and muxes allows this number of BRAM to work. As a result, the BMM doesn't provide enough information about the RAM to allow the tools to pre-program it. Luckily, the tools realize this from a mismatch in the size of the BRAM vs the size of the components that are claimed to be used -- which do not claim to use parity space.

The addressable space of 0xffff assumes this is also byte addressable. I'm not 100% sure if the space is done in word-addressable or byte-addressable sizes. I didn't see a way to construct a byte-writable version of the ram without read-modify-write. perhaps a ROM is ok.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top