From: de4 on
>http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf
>
>Read that. Then come back and ask questions.
>HTH, Syms.
>

I read that before but It didn't give me much... I was thinking CoreGen
generating RAM so probably map of this RAM can be generated also automatic.
I see it can't. .mem file is not a problem I've got my assembler program so
I will generate code in mem format but those .bmm are stupidness... Why it
cant be generated by software ? I don't know what constarin placement is ?

I have got something like that generated from CoreGen :

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
-- synthesis translate_off
Library XilinxCoreLib;
-- synthesis translate_on
ENTITY BlockRAM4 IS
port (
clka: IN std_logic;
wea: IN std_logic_VECTOR(0 downto 0);
addra: IN std_logic_VECTOR(10 downto 0);
dina: IN std_logic_VECTOR(15 downto 0);
douta: OUT std_logic_VECTOR(15 downto 0);
clkb: IN std_logic;
web: IN std_logic_VECTOR(0 downto 0);
addrb: IN std_logic_VECTOR(10 downto 0);
dinb: IN std_logic_VECTOR(15 downto 0);
doutb: OUT std_logic_VECTOR(15 downto 0));
END BlockRAM4;

ARCHITECTURE BlockRAM4_a OF BlockRAM4 IS
-- synthesis translate_off
component wrapped_BlockRAM4
port (
clka: IN std_logic;
wea: IN std_logic_VECTOR(0 downto 0);
addra: IN std_logic_VECTOR(10 downto 0);
dina: IN std_logic_VECTOR(15 downto 0);
douta: OUT std_logic_VECTOR(15 downto 0);
clkb: IN std_logic;
web: IN std_logic_VECTOR(0 downto 0);
addrb: IN std_logic_VECTOR(10 downto 0);
dinb: IN std_logic_VECTOR(15 downto 0);
doutb: OUT std_logic_VECTOR(15 downto 0));
end component;

-- Configuration specification
for all : wrapped_BlockRAM4 use entity
XilinxCoreLib.blk_mem_gen_v3_2(behavioral)
generic map(
c_has_regceb => 0,
c_has_regcea => 0,
c_mem_type => 2,
c_rstram_b => 0,
c_rstram_a => 0,
c_has_injecterr => 0,
c_rst_type => "SYNC",
c_prim_type => 1,
c_read_width_b => 16,
c_initb_val => "0",
c_family => "spartan3",
c_read_width_a => 16,
c_disable_warn_bhv_coll => 0,
c_write_mode_b => "WRITE_FIRST",
c_init_file_name => "no_coe_file_loaded",
c_write_mode_a => "WRITE_FIRST",
c_mux_pipeline_stages => 0,
c_has_mem_output_regs_b => 0,
c_has_mem_output_regs_a => 0,
c_load_init_file => 0,
c_xdevicefamily => "spartan3a",
c_write_depth_b => 2048,
c_write_depth_a => 2048,
c_has_rstb => 0,
c_has_rsta => 0,
c_has_mux_output_regs_b => 0,
c_inita_val => "0",
c_has_mux_output_regs_a => 0,
c_addra_width => 11,
c_addrb_width => 11,
c_default_data => "0",
c_use_ecc => 0,
c_algorithm => 1,
c_disable_warn_bhv_range => 0,
c_write_width_b => 16,
c_write_width_a => 16,
c_read_depth_b => 2048,
c_read_depth_a => 2048,
c_byte_size => 9,
c_sim_collision_check => "ALL",
c_common_clk => 0,
c_wea_width => 1,
c_has_enb => 0,
c_web_width => 1,
c_has_ena => 0,
c_use_byte_web => 0,
c_use_byte_wea => 0,
c_rst_priority_b => "CE",
c_rst_priority_a => "CE",
c_use_default_data => 0);
-- synthesis translate_on
BEGIN
-- synthesis translate_off
U0 : wrapped_BlockRAM4
port map (
clka => clka,
wea => wea,
addra => addra,
dina => dina,
douta => douta,
clkb => clkb,
web => web,
addrb => addrb,
dinb => dinb,
doutb => doutb);
-- synthesis translate_on

END BlockRAM4_a;


how I can create some .bmm from this ? I know that those things are simple
for exprets but I not an expert...

Thanks for aswers...

---------------------------------------
Posted through http://www.FPGARelated.com
From: he on
> I read that before but It didn't give me much... I was thinking CoreGen
> generating RAM so probably map of this RAM can be generated also automatic.
> I see it can't. .mem file is not a problem I've got my assembler program so
> I will generate code in mem format but those .bmm are stupidness... Why it
> cant be generated by software ? I don't know what constarin placement is ?

Look up the number and names of your BRAMs in your routed design, for
example with fpga_editor or Planahead.
You can pin these BRAMs to fixed locations with the approprate entries
in your ucf file.
This is an example ucf entry for 4 BRAMs used in 8 bit mode in parallel:

---8<----
## BRAM location constraints
INST
"BRAM/blockram/BU2/U0/blk_mem_generator/valid.cstr/ramloop[3].ram.r/v4_init.ram/SP.SINGLE_PRIM.SP"
LOC = "RAMB16_X3Y1";
INST
"BRAM/blockram/BU2/U0/blk_mem_generator/valid.cstr/ramloop[2].ram.r/v4_init.ram/SP.SINGLE_PRIM.SP"
LOC = "RAMB16_X3Y0";
INST
"BRAM/blockram/BU2/U0/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v4_init.ram/SP.SINGLE_PRIM.SP"
LOC = "RAMB16_X4Y1";
INST
"BRAM/blockram/BU2/U0/blk_mem_generator/valid.cstr/ramloop[0].ram.r/v4_init.ram/SP.SINGLE_PRIM.SP"
LOC = "RAMB16_X4Y0";
---8<----

you have to insert the approprate names/paths for your design...


> how I can create some .bmm from this ?

write it by hand, the commands are described in the data2mem user guide.
This is an example for the four BRAMs shown above:

---8<----
ADDRESS_MAP mymap PPC405 0
ADDRESS_SPACE BRAM COMBINED INDEX_ADDRESSING[0x00000000:0x00001FFF]
ADDRESS_RANGE RAMB16
BUS_BLOCK
wb_arbiter/BRAM/BU2/U0/blk_mem_generator/valid.cstr/ramloop[3].ram.r/v4_init.ram/SP.SINGLE_PRIM.SP
[31:24] PLACED=X5Y1;
wb_arbiter/BRAM/BU2/U0/blk_mem_generator/valid.cstr/ramloop[2].ram.r/v4_init.ram/SP.SINGLE_PRIM.SP
[23:16] PLACED=X5Y0;
wb_arbiter/BRAM/BU2/U0/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v4_init.ram/SP.SINGLE_PRIM.SP
[15:8] PLACED=X4Y1;
wb_arbiter/BRAM/BU2/U0/blk_mem_generator/valid.cstr/ramloop[0].ram.r/v4_init.ram/SP.SINGLE_PRIM.SP
[7:0] PLACED=X4Y0;
END_BUS_BLOCK;
END_ADDRESS_RANGE;
END_ADDRESS_SPACE;
END_ADDRESS_MAP;
---8<----

now you can use data2mem to show or change the BRAM contents via
$ data2mem -bm brams.bmm -bt yourbitfile.bit > log.txt
$ data2mem -bm brams.bmm -bt yourbitfile.bit -bd ram_content.mem -o -b
bitfile_with_new_contents.bit

hth
HE
From: Brian Drummond on
On Tue, 16 Feb 2010 13:50:02 +0000, Symon <symon_brewer(a)hotmail.com> wrote:

>On 2/16/2010 12:45 PM, he wrote:
>> First you should constrain the used BRAMs to fixed locations, so you
>> don't have to recreate a new bmm file after each P&R run.
>> Most probably, you will have to write the BMM file "by hand" (see the
>> link posted by Symon, tell me if theres an automated way ;)
>
>I dimly recall analysing the RBT format, and then writing a perl script
>that searched through the RBT file for a BRAM with contents beginning
>"DEADBEEF", or whatever I'd tagged the BRAM with, to automatically
>update the BMM after a PAR. However, as you point out, constraining the
>placement was much easier.

Bitgen (at least I think it's Bitgen and not PAR) will update a BMM file for
you, with the latest placements - IF you sing the right incantations first.

The first step is to write a myfile.bmm file without the placements - using one
generated by EDK as an example is a good idea.

The second step is to feed it into "Translate" (if using the GUI) or ngdbuild
(command line) with the right options ... -bd myfile.bmm if I remember
correctly.

Check the ".bld" report file to see if the BMM file was read correctly; if not,
it's not going to report an error via the GUI or console!

Then the BMM magic disappears into the tool flow without trace.

But if the myfile.bmm is still there when Bitgen runs, the earlier magic
reappears and you might see a new myfile_bd.bmm file, annotated with the correct
BRAM placements.

There is documentation on this. But it's so well hidden that the Webcase tech
support team submitted a change request to get some written when I complained I
couldn't find any, even though it was apparently already in existence by then...

- Brian
From: Brian Davis on
Symon wrote:
>
> I dimly recall analysing the RBT format, and then writing a perl script
> that searched through the RBT file for a BRAM with contents beginning
>

I've noticed a more recent ncd -> bmm generation perl script
in the OpenFire distribution that might be useful:

http://www.ccm.ece.vt.edu/~scraven/openfire.html#Download

OpenFire_release/utils/openfire_bram.pl
"
"This program creates a BMM file from an NCD and uses this to read
and
"write initial BRAM contents from a bitstream.
"
"NOTE: XDL and DATA2MEM must be installed and in the user's path.
"
"usage: $0 [-h] [-n NCD_FILE -o BMM_FILE] [-r ROM_FILE -b BITSTREAM]
"
" -h : this (help) message
" -n NCD_FILE : NCD_FILE containing placed BRAMs (default =
implementation/system.ncd)
" -o BMM_FILE : BMM_FILE to create (default = implementation/
openfire.bmm)
" -t top-level module : name of the top-level OpenFire module
(default = openfire)
" -f ELF_FILE : ELF file to place in OpenFire memory
(optional)
" -b BITSTREAM : bitstream to update with BRAM contents
" (default = "implementation/download.bit)
" -x XDL_FILE : use specified XDL file (w/o flag, generates
own from NCD_FILE)
" -p # : number of processors in design; named top-
level_module0, top-level_module1, etc.
" (default = 1)
"
"example: $0 -n system.ncd -o system.bmm -f openfire.elf -b
download.bit
"example: $0 -o system.bmm -p 4 -t vtmb_
"

Brian

From: saar drimer on
On Feb 17, 3:01 am, Brian Davis <brimda...(a)aol.com> wrote:
> I've noticed a more recent ncd -> bmm generation perl script
> in the OpenFire distribution that might be useful:
>
> http://www.ccm.ece.vt.edu/~scraven/openfire.html#Download
>
> OpenFire_release/utils/openfire_bram.pl

I've recently ran into this problem, trying to avoid hard placement so
the tools are less constrained.

Brian Drummond has the right way to do it, I think -- I wish proper
documentation on how to make this happen in commandline existed. The
tools, as they do, do not tell you what's wrong on fail, so it's
mostly guesswork ("right incantations" indeed). The user guide Symon
points to doesn't deal with that type of usage directly. I ran into
trouble particularly when trying to make map accept multiple BRAM
definitions (when/if I iron all the kinks, I'll post a how-to).

Before seeing the above OpenFire script, I've also written a similar
script to do the same...

NCD -> XDL
Extract coordinates(s) of BRAMs by name from XDL
Use data2mem to insert BRAM data into bitstream

....but I consider it a hack.

saar.