xilinx bmm file problem

hello, Has anybody experience with xilinx bitfile merging using a bmm file? I've a small processor core running in a spartan 3A using romcode which I install into a generated vhdl file. like entity ROM is port( Clk : in std_logic; A : in std_logic_vector(12 downto 0); D : out std_logic_vector(7 downto 0) ); end ROM;

architecture rtl of ROM is signal A_r : std_logic_vector(12 downto 0); type rom_type is array(0 to 1951) of std_logic_vector(7 downto 0); signal ROM:rom_type := ( X"02", X"00", X"08", etc. This works fine (programming running), but I would like to replace this with a generic rom file without any initialization or just zero's and merge the romhexfile into the bitfile using a bmm. For the situation above the following bmm file doesn't give any errors: ADDRESS_MAP TV51MAP PPC405 0 ADDRESS_BLOCK CPU_INST_ROM RAMB16 [0X0000:0X7ff] BUS_BLOCK cpu_inst/rom/Mrom_D1 [15:0]; END_BUS_BLOCK; END_ADDRESS_BLOCK; END_ADDRESS_MAP; It's possible to force a location etc. and a _bd.bmm is generated like the documentation describes. I call ngdbuild with: if ngdbuild -bm cpu_rom.bmm -intstyle ise -dd _ngo -uc $(CONSTRAINTFILE) -p $(DEVICE) $(DESIGN).ngc $(DESIGN).ngd and bitgen with bitgen -bd src/test.mem -w -g UnusedPin:PullNone $< $@ $(DESIGN).pcf (so only the -bm and -bd arguments are added into the Makefile.) The mem file looks like: @00 02 @01 00 @02 08 @03 12 @04 00 @05 95 @06 80 The new bitfile is generated, but no luck. Program not running. Anybody an idea how to tackle this? Taco walstra

Reply to
taco
Loading thread data ...

eh the bmm approuch works. after some months-years ;)

is your memory 8 or 16 bits? if 8 then make the bram block 8 not 16 as in your bmm

connect chipscope to the ram add and data and let it run and look

Antti

Reply to
Antti

[...]

I once summarized my experience with bmm files in

formatting link

Maybe you find some answers there.

Cheers

Arnim

Reply to
Arnim

Just to record the solution which I found last week: Indeed 8 bits. The bmm file only needed to changed into cpu_inst/rom/Mrom_D1 [7:0];

The problem occurred because the declaration of the romsize was bigger than actually initialized which is corrected in the xilinx software, but during the ngdbuild phase the reduced romsize should be taken into account. Very logical actually, but that's with many things... taco

Reply to
taco

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.