data2bram and coregen

I've looked into doing this several times but never found a working solution.

I ended up creating my own HDL for the memory that instantiates BRAM primitives and wrote a corresponding bmm file as decribed in the documentation. That's worked fine even if it is a little more hassle.

Paul

snipped-for-privacy@ieee.org wrote:

Lasse,

I had a similar problem which I solved by writing a Perl script to create a BMM file containing the locations of the BRAMs after placement. In my case the tools inferred the BRAMs and I wasn't using CoreGen, but the idea may work in your case as well. This script uses XDL to convert the placed NCD file into a text format that can then be parsed to find the locations of the placed BRAMs. Data2mem then uses this BMM file to load the BRAMs.

xdl command: xdl -ncd2xdl ncd_file xdl_file

finished BMM file snippet: ADDRESS_SPACE lmb_bram_0 RAMB16 [0x00000000:0x00003FFF] BUS_BLOCK openfire0/openfire0/MEM/Mram_MEM_inst_ramb_7 [31:28] PLACED = X3Y13;

Hope this helps, Stephen

You could get that information via the floorplanner (load the placed design, then "write UCF" command) and extract the LOC lines relevant to the BRAMs.

To ensure consistency in future placements, you can add those LOC lines to your UCF file. Or you could place the BRAMs yourself, again with the floorplanner first time round, and subsequently via UCFs.

- Brian

"Paul Hartke" schrieb im Newsbeitrag news: snipped-for-privacy@Stanford.EDU...

data2bram seems to work properly only when used by the EDK.

the BMM file that it requires *must* have LOC info

on possibility is to LOC the BRAMs in the UCF and then inject the same LOC info into BMM manually, doable but hassle

the BMM issue has been a problem all the time, maybe its better in 8.1 havent checked but so far it really hasnt be any joy when attempting to use it

Antti

As far as I can tell, the model is that a bmm file without placement info is fed to ngdbuild with the -bm option. Each BRAM is associated with a hierarchical name and its location in the memory address space. That info is passed through the design flow until bitgen. Bitgen recognizes this info in the design database and creates a new *_bd.bmm file which includes the hierarchical names and the physical location information. data2mem uses the memory address space info and the physical location information to insert the elf/mem into the fpga bitstream.

EDK generates the original bmm; currently coregen does not and its not clear what the BRAM hierarchical names are in the internal database. There is no need to manually look into floorplanner and/or ucf LOCs to use data2mem if you can figure out what the BRAM hierarchical names are. Since coregen doesn't automatically export a bmm with its internal hierarchical names, the floorplanner *.fnf file can be used to determine them. Doing it this way allows the placement to change and the backend flow keeps working once you know exactly what coregen memories are needed.

Paul

Antti Lukats wrote:

Paul,

You are correct that is the proper use model through NGDbuild. If you are using Project Navigator then you can add the *.BMM and *.ELF file to the top level file in your project and it should feed it to NGDBUILD. BITGEN will automatically call Data2MEM to initialize the memory. BITGEN will also output a *_bd.bmm file that can be used with Data2MEM standalone to update the memory with the LOC constraints.

Unfortunately, I have not seen any good way to find the hierarchy name for the Block RAM to be place in the BMM file. I normally run the project through one and try to find them in FPGA Editor. But the XDL flows also works.

Cheers, Shal> As far as I can tell, the model is that a bmm file without placement