Spartan3 Block RAM from WebPACK

there is lots missing from the webpack. but you can still use memory in vhdl or verilog by just describing it :-) just infer it. there are a few examples in webpack of this

Simon

unsolicited

addresses.

Doesn't Webpack include a language template help? (It is marked with a lit lamp on the tool bar). If it does you may find some templates. However I would suggest you to look for application note XAPP463 at Xillinx' page. There are zip files with vhdl/verilog code you may simply copy and paste and adapt to your needs.

HTH

The online documentation at

has it as well. I drilled down through XST User guide -> HDL Coding techniques -> RAMs/ROMs. This lead me here:

which shows how to infer the ROM. I'm sure you could also instantiate it, but to me, that actually seems harder than inferring.

Marc

Sure - you might be able to infer it, but you can also just instantiate it with the appropriate verilog of vhdl library component. The block ram's function as a fixed number of bits, which you can access with varying widths and lengths, and are optionally dual port. Do a directory of everything starting with RAMB in your xilinx/src/verilog/unisims directory to get an idea of the options. For example RAMB16_S9 is an 8bit+parity memory, and RAMB16_S9_S9 is the same thing in dual port configuration.

One thing to remember is that this is SYNCHRONOUS memory - there's a clock delay in getting anything out of it.

Initializing them as rom's is a bit of a pain, as you need to do it seperately for the simulation and for synthesis. For example, in verilog you would have:

//synthesis translate_off defparam my_mem.INIT_00 =

256'h7B98606064C364C364C364C364C364C300006FC360646080F060607C64C30077; //synthesis translate_on

To get the simulation values in there. For synthesis, you specify the value like this:

//synthesis attribute init_00 of my_mem is "7B98606064C364C364C364C364C364C300006FC360646080F060607C64C30077"

(synthesis directives are all formally verilog comments, hence the //)

If you have processor code in the ROM, you can also use a .bmm file and the data2mem tool to let you change the code without recompiling the whole design.

For example:

my_mem.bmm: ADDRESS_BLOCK rom RAMB16 [0x00000000:0x00007FF] BUS_BLOCK my__mem3 [7:0] OUTPUT = my_dump.mem; END_BUS_BLOCK; END_ADDRESS_BLOCK;

If you put my_mem.bmm in your project, XST will further process it and give you a my_mem_bd.bmm which you can then use along with a .mem file of data:

data2bram -bm my_mem_bd.bmm -bt project.bit -bd my_mem.mem -o bv updated

This will create an 'updated.bit' as well as an 'updated.v' with defparam's that you can `include (from within a //synthesis translate_off block!) in your design to subsequently have the same values in simulation.

It's a pain to set up, but once it works it's really nice.

Chris

Thanks for all the replies.

What I was looking for is actually in the library guide. It's RAMB16, two entries of about 25 different flavors of RAM. There doesn't seem to be a wrapper that turns it into a ROM. (But I can turn off WE.) I just didn't find either when searching...

I think I was googling for BLKRAM which is probably why I didn't find much that way.

The software generates a ROM (like I wanted) if I feed it either a big case statement or use a constant array. (I fat fingered one attempt and left out the clock. That made a blizzard of LUTs, but it all ran at 100 MHz. :)

I also got it working instantiating a RAMB16_S9 with a bunch of INIT_xx ...

The suggestion of using data2mem is one of the ways I was looking for. (It doesn't support the parity bit.) The normal tool flow doesn't really support this approach. You can add a .mem file as a source, but you have to add a couple of magic command line options to make it do anything. (Or at least that's what I did.)

data2mem needs a .bmm file to tell it where to put the bits. It seems as though the tools should generate that automagically, or at least semi-automatically. I couldn't figure out how to do that. The doc for data2mem describes the -mf option. I couldn't get it to work. I'm not sure it even makes sense - that info isn't in the bit file. But if you make a .bmm file by hand, the LOC info does get used by the tool chain.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

I am a novice on this area but... IIRC data2mem allows one to reconfigure the tables. Do you need this feature? I have followed the link provided by Marc Randolph (XST user guide) and implemented a ROM using a constant. To make the vhdl module small I created a package to encapsulate the rom table. The data width is 18 bits as my design requirements. I had previously implemented this table following the app note guidelines and created the INIT_xx entries with a C program. Another simple C program to create the table and, at least in the simulation, it worked as expected.

Regards.

Elder.

I knew there must be some good reason why I didn't surrender to the temptation to stretch my 32 bit processor to a 36 bit instruction word...

Quick and dirty suggestion: disable parity checking in the development version and use data2mem to shorten the process of developoing preliminary code. Then at some point as the project approaches finalization, re-enable parity and put the code in there in synthesis with the INITP's to set the parity bits.

Could one figure out how to write a data2mem replacement that would load them? Is sythesis repeatable enough that you could map the parity bit locations by changing one parity bit location in the HDL code's INITP's and diff'ing the bitstreams?

Chris

Hello,

I also want to use Block RAM with data2mem tool without success. I uses Spartran-3 Development Kit with ISE webPack.

Would you please instruct more detail?

I made a .bmm file as:

ADDRESS_BLOCK mainmem MEMORY [0x000:0x7ff] BUS_BLOCK mainMem_Mram_mcell_inst_ramb_0 [7:0] OUTPUT=mcell.mem; END_BUS_BLOCK; END_ADDRESS_BLOCK;

I made 2kb of mcell.mem start with @00 c3 3d 00 00 00 00 00 00 ed 4d 00 00 00 00 00 00 ed 4d 00 00 00 00 00 00 ed 4d 00 00 00 00 00 00 ...

After then, I invoked data2bram with:

data2bram -bm mcell.bmm -bt swsystem.bit -bd mcell.mem -o b new

It generate new.bit without any error messages but new.bit is just the same as swsystem.bit. Then it may not updated at all but just copied, I think. The name in the BUS_BLOCK is extracted from floorplan editor, and I generated the name in ADDRESS_BLOCK.

Would anybody give me any suggestion?

Regards, Naohiko

I resolved by myself.

Regards,

Naohiko