Bart van Deenen <bart@vandeenensupport-com.invalid> wrote:
> I've told ISE to Locate the bram at X0Y0, and from the FPGA Editor i can
> see that this works. It has implemented a BRAMB16BWE at site
> RAMB16_X0_Y0
it's not necessary to locate the BRAM on a fix position in the
design for a fast data2mem update cycle. All you have to do is to anaylze,
copy and adapt the design flow from the EDK for your own softcore or
your own BRAM usage. To do so you don't need EDK, all the tools like
data2mem are part of ISE.
newest picoblaze (KCPSM3) use it's own design tool like pb_bmm.exe
to get the BRAM-location information from the placed design, but this
pb_bmm tool is not useable in a general way. (maybe Ken Chapman
wasn't aware of the EDK design flow?)
I. for the HDL synthesis:
1. generate a myfile.bmm (ascii textfile) without any location
information as a template for ngdbuild. This .bmm file describe the
data/address width of the BRAM, the number of BRAMs in your
design, the component names, etc.. See the example at the end of
this message [1].
2. use the -bm switch from ngdbuild to "integrate" this bmm template
in the designflow. (first you have to synthesis your design using XST,
Synplify or whatever)
3. just run map/par/bitgen as usual. bitgen will notice the
"bmm-marker attribute" and output automagic an annotated BMM file
"myfile_bd.bmm" with the correct BRAM location information
(PLACED = X?Y?). The add on part "_bm" in the filename is hard
coded in the xilinx tools (ugs!).
II. for the software design:
1. run your compiler/assembler/linker (whatever) as usual.
The output should be a standard intel-hex file (or a binary file).
2. use common tools like s_record (s_cat) to convert the intel
hex or binary file from the compiler to the mem data format, which can be
read by data2mem. data2mem can read elf files too, but i would not
suggest to do so. The "xilinx mem" file format is just a verilog mem
(vmem) format, very simple, take a look in the srecord docu. the
conversion could be a command like:
$ srec_cat rom.hex -Intel -o rom.mem -vmem 8
(remark: for picoblaze you don't need srecord, because the
picoblaze-3 assembler outputs a *.mem file)
III. The final step:
The final step is to use data2mem + the *.mem file from the
compiler + the *_bd.bmm file from the synthesis path to "inject" the
BRAM content in the final bitfile on the correct positions. data2mem
will split the datafile according to the BMM description and will do
all the bit level work. This could be done like:
$ data2mem -bm myfile_bd.bmm -bt design.bit -bd rom.mem -o b final.bit
the final.bit can now be loaded direct to the FPGA or could
be input to promgen/impact to generate a prom file.
for simulation you can use data2mem to generate a vhdl-package
with "-o h final.vhd" - see the xilinx documentation. (which is in
details not complete and not always very accurate. Ths commandline
switch --help or -h outputs very often more information than the PDF
documentation for the xilinx toolchain - ISE9.1.3 )
If you change your software you have only to do a recompile
(II.) and repeat the final step (III.) which is very fast.
[1] example myfile.bmm template, for ngdbuild input:
ADDRESS_MAP mymap PPC405 0 // PPC405 is just a dummy
ADDRESS_SPACE rom COMBINED [0x00000000:0x000007FF]
ADDRESS_RANGE RAMB16
BUS_BLOCK
my_softcore/my_rom_component/BRAM_01 [3:0];
my_softcore/my_rom_component/BRAM_02 [7:4];
END_BUS_BLOCK;
END_ADDRESS_RANGE;
END_ADDRESS_SPACE;
END_ADDRESS_MAP;
you have to modify the BRAM_layout and the BRAM component names
(path from the top of the HDL design) The address space must match the
correct BRAM length. The rest, like "mymap" is just a dummy. You can
choose any name.
bitgen will output a *_bm.bmm file with the location information
from the placing process. For example:
ADDRESS_MAP mymap PPC405 0
ADDRESS_SPACE rom COMBINED [0x00000000:0x000007FF]
ADDRESS_RANGE RAMB16
BUS_BLOCK
my_softcore/my_rom_component/BRAM_01 [3:0] PLACED = X0Y1;
my_softcore/my_rom_component/BRAM_02 [7:4] PLACED = X1Y2;
END_BUS_BLOCK;
END_ADDRESS_RANGE;
END_ADDRESS_SPACE;
END_ADDRESS_MAP;
Remark: for picoblaze you will have only one BRAM in your
*.bmm file. With a databus width of 18 bits [17:0] and a address range
from [0x00000000:0x000003FF]
hope this help's a little bit,
WD
--
Reply by Bart van Deenen●August 9, 20072007-08-09
I got it!!!!
xilinx answer database nr 21460 helped me. The correct bmm file is
ADDRESS_SPACE ram RAMB18 INDEX_ADDRESSING [0x00000000:0x000003FF]
BUS_BLOCK
top/ram/program_rom/ram_1024_x_18_1 [17:0] LOC = X0Y0;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
It's probably the INDEX_ADDRESSING tag, but I don't really care, I'm in
business now. I'll figure out the fine details later.
I'm a really experienced programmer and electronics designer, but this
journey into fpga land is steep!!! I love it :-)
Bart
Hi Sven
thanks for the great series. Unfortunately I only have the ISE
environment, and I don't (think I) have the simgen tool.
What surprises me most is the error message that the code segment
occupies from 0x0 to 0x9ff, whereas the mem file is really only 1024
lines of data, each being 5 nibbles,
line#
1 @00000000
2 00000
3 2E004
4 2C080
...
1025 340FD
That is funny, the 0xA00 is the number of bytes in the 1024 lines of 20
bits. So it doesn't realize those things are 18 bit words!
I hope someone comes up with the answer.
Thanks for thinking with me.
Bart
Reply by Bart van Deenen●August 9, 20072007-08-09
Hi
here is the start and end of the mem file
line#
1 @00000000
2 00000
3 2E004
4 2C080
...
1025 340FD
I presume the first nibble of the 5 is the 2 bit parity, at least it
only has values 0,1,2 and 3. So this is an 18 bit data file. So how come
the FPGA editor shows that it's a RAMB16BWE block?
Getting confused by now :-)
Bart (poster original question)
I'm a newbie in fpga design, and am really struggling to create a bmm
file that works. I am using an Spartan-3A starter kit, with ISE 9.2.0i
on Linux. I am working with the dna reader project, and am capable of
downloading the design, as well as modifying the assembly program
(dna_ctrl.psm), and updating it via the whole "implement design" route.
I'm really interested in the direct modification of the bit file via
data2mem because it promises much faster turnaround times when updating
the picoblaze program, but I'm stuck with the bmm file generation.
I've told ISE to Locate the bram at X0Y0, and from the FPGA Editor i can
see that this works. It has implemented a BRAMB16BWE at site
RAMB16_X0_Y0
I've created a file my.bmm with these contents:
ADDRESS_SPACE ram RAMB16 [0x0000:0x07FF]
BUS_BLOCK top/ram/program_rom/ ram_1024_x_18_1 [7:0] LOC = X0Y0;
END_BUS_BLOCK; END_ADDRESS_SPACE;
which seems to be syntactically correct and has the correct number of
bits (16kb)
When I try to merge the file with the mem file from kcpsm3.exe I get an
error
data2mem -bm my.bmm -bd dna_ctrl.mem -bt reading_dna.bit -o b new.bit
ERROR:Data2MEM:31 - Out of bounds code segment for ram space in
'my.bmm'.
Memory space 'ram' occupies [0x00000000:0x000007FF]
Code segment #0 occupies [0x00000000:0x000009FF]
This same assembly file is assembled into dna_ctrl.vhd which is
correctly built into the final bitfile.
So what am I doing wrong? Any help would be highly appreciated!
Bart