Spartan3 Block RAM from WebPACK

Is it possible to use the Block RAMs in the Spartan3
with the (free) WebPACK software?  If so, how?

I'm playing with the Spartan3 starter kit and trying to make
a ROM.  I'd expect to find something in the library package.
I can't find anything there other than tiny ones using CLBs.

Looks like the normal path is to use Coregen, but that's not
part of WebPACK.  I could use a machine with Coregen installed
on it to do the "gen" part, but that makes something that's
tangled up with the Coregen libraries.  (Maybe that tangle is
only the simulation libraries. But everybody would snicker if
I didn't simulate.)

Am I just overlooking something simple?  (If so, what's the
magic word.)

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

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

"Hal Murray" <hmurray@suespammers.org> wrote in message
news:RuednZqh6-LY5QjcRVn-hQ@megapath.net...
> Is it possible to use the Block RAMs in the Spartan3
> with the (free) WebPACK software?  If so, how?
>
> I'm playing with the Spartan3 starter kit and trying to make
> a ROM.  I'd expect to find something in the library package.
> I can't find anything there other than tiny ones using CLBs.
>
> Looks like the normal path is to use Coregen, but that's not
> part of WebPACK.  I could use a machine with Coregen installed
> on it to do the "gen" part, but that makes something that's
> tangled up with the Coregen libraries.  (Maybe that tangle is
> only the simulation libraries. But everybody would snicker if
> I didn't simulate.)
>
> Am I just overlooking something simple?  (If so, what's the
> magic word.)
>
> -- 
> 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.
>

Hal Murray wrote:
> Is it possible to use the Block RAMs in the Spartan3
> with the (free) WebPACK software?  If so, how?
> 
> I'm playing with the Spartan3 starter kit and trying to make
> a ROM.  I'd expect to find something in the library package.
> I can't find anything there other than tiny ones using CLBs.
> 
> Looks like the normal path is to use Coregen, but that's not
> part of WebPACK.  I could use a machine with Coregen installed
> on it to do the "gen" part, but that makes something that's
> tangled up with the Coregen libraries.  (Maybe that tangle is
> only the simulation libraries. But everybody would snicker if
> I didn't simulate.)
> 
> Am I just overlooking something simple?  (If so, what's the
> magic word.)
> 

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

Elder Costa wrote:
> Hal Murray wrote:
> 
>> Is it possible to use the Block RAMs in the Spartan3
>> with the (free) WebPACK software?  If so, how?
>>
>> I'm playing with the Spartan3 starter kit and trying to make
>> a ROM.  I'd expect to find something in the library package.
>> I can't find anything there other than tiny ones using CLBs.
>>
>> Looks like the normal path is to use Coregen, but that's not
>> part of WebPACK.  I could use a machine with Coregen installed
>> on it to do the "gen" part, but that makes something that's
>> tangled up with the Coregen libraries.  (Maybe that tangle is
>> only the simulation libraries. But everybody would snicker if
>> I didn't simulate.)
>>
>> Am I just overlooking something simple?  (If so, what's the
>> magic word.)
>>
> 
> 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.

The online documentation at

http://toolbox.xilinx.com/docsan/xilinx6/books/manuals.htm

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

http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0026_5.html#wp325264

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

hmurray@suespammers.org (Hal Murray) wrote in message news:<RuednZqh6-LY5QjcRVn-hQ@megapath.net>...
> Is it possible to use the Block RAMs in the Spartan3
> with the (free) WebPACK software?  If so, how?
> 

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.

Hal Murray wrote:

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

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.

hmurray@suespammers.org (Hal Murray) wrote in message 

> The suggestion of using data2mem is one of the ways I was looking for.
> (It doesn't support the parity bit.) 

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.

> 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

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