spartan3 picoblaze how to make .bmm file work

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

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 don't know if this helps but I used Simgen to generate the bmm file
for MicroBlaze.
See my blog: http://svenand.blogdrive.com/archive/68.html

Sven

svenand <svenand@comhem.se> wrote:
> See my blog: http://svenand.blogdrive.com/archive/68.html

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

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

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