Does anyone have a hint on how to get data2bram and coregen memory to
I have an SoC with some 32bit memory made up of four 8bit memories
generated with coregen, I've made a bmm file that defines the memory.
I can run data2bram with the bmm file and an .elf file and if I set the
output to verilog the init strings look resonable.
If I run the same bmm and .elf file on my bit file and use the updated
bit file to configure an FPGA DONE doesn't go high so I assume the bit
file is corrupt.
Is there a trick I should know about ?
data2bram does give me a warning the the memory is not LOC'ed, is there
a simple way to
get that info when the memory is generated with coregen?
(xc2v3000 and ISE5.1)
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.
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 -ncd2xdl ncd_file xdl_file
finished BMM file snippet:
ADDRESS_SPACE lmb_bram_0 RAMB16 [0x00000000:0x00003FFF]
openfire0/openfire0/MEM/Mram_MEM_inst_ramb_7 [31:28] PLACED =
Hope this helps,
>Does anyone have a hint on how to get data2bram and coregen memory to
>data2bram does give me a warning the the memory is not LOC'ed, is there
>a simple way to
>get that info when the memory is generated with coregen?
You could get that information via the floorplanner (load the placed
design, then "write UCF" command) and extract the LOC lines relevant to
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.
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
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
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.
Embedded Applications Engineer
General Products Division
Spartan-3 Generation FPGAs