Design Tools - Others

[eteam00]

see this thread.  I found it by using search.  I searched for "block ram initial".

Also, for Spartan 6, check the Libraries guide UG615.  For any/all of the block rams (e.g. RAMB16BWER), in the attributes table, it is clearly written that memory block contents are (by default) initialised to "0".  Example:

           |           |Allowed
Attribute  |Type       |Values   |Default  |Description
===========+===========+=========+=========+=================================
INIT_00 to |Hexadecimal|Any 256  |All zeros|Specifies the initial contents
INIT_3F    |           |bit value|         |of the 16kb data memory array.
-----------+-----------+---------+---------+---------------------------------
INITP_01 to|Hexadecimal|Any 256  |All zeros|Specifies the initial contents of
INITP_07   |           |bit value|         |the 2kb parity data memory array.

- Bob Elkind

[mowomo]

The thread and solution you point to is a simplistic approach to small, uncomplicated rams that are inferred from simple HDL. Our needs are much more complex, that's why we instantiate IP and not have the tools infer them. Using a $readmemh or a initial block in the Verilog HDL is a solution only when the memory is written as a local variable, i.e. reg [31:0 ] myram [0:2047] because the name of the memory is at the same heirarchy. With instantated block rams, the actual name of the memory array is down a few levels, and usually it is called memory, or mem, but may not be. If the tool changes the heirarchy OR the name of the memory array then locally written initial blocks or $readmemh statements become useless. 

[eteam00]

If you think you can design FPGAs at an abstract level with no references or concessions to the underying hardware, with device-independent code, you'll get no sympathy from me.  And you'll need no sympathy from me, because you'll learn this all on your own, sooner or later.

Hardware is your friend, not your enemy.  Being able to instantiate primitives is a powerful tool, not a burden.

For some reason I thought you started this thread to learn how to initialise a block memory.  Sigh....

- Bob Elkind

[mowomo]

I started this thread to inquire if anybody else has seen what I think is a bug where the option to initialize all remaining memory locations check box on the Block Ram Memory Generator Tool V4.3 is always greyed out.

Surely, I am not the first to run across this?

[mowomo · Accepted solution]

Anyway, I've started an official Webcase....

[mowomo]

Good idea on looking at the Spartan6 Libraries Guide and the UG384, Spartan-6 FPGA Block RAM Resources User Guide. Yup, the RAMB16BWER and RAMB8BWER are initialized to zeros in the bit stream. My bad. That solves this. BUT the original question remains on the greyed-out option on Block Ram Generator GUI. What if I wanted to init the RAM to all ONES? I shouldn't have to go the hassle of making a .coe file for constants.

[eteam00]

Why would you want to see Xilinx spending manpower and time on something that works well enough, is well enough documented, and isn't broken?  Life must be very good indeed if this is worth your time and energy.

- Bob Elkind

[nathan_clarke]

Mowomo,

If it's any consolation to you, I see the same problem (in ISE 12.3) and it does indeed appear to be a bug in the block memory generator software.  Any luck with your bug report?

I also need to rely on my block memory being initialized to zero, which of course happens naturally within the device, but simulations will return X from block memory locations that have not first been written to, or initialized (actually, I could be wrong on this point, but I have no way of verifying this statement at this time).  So, for simulation purposes, I wanted to ensure that my memory is indeed initialized to zero by setting the default values to 0.  As you've rightly pointed out, the default data option is greyed out for some unexplained reason, contrary to what's described in the user guide.

It seems our "expert contributor" won't, or can't help us, so I guess we have to live with using the .coe files to initialize.

Cheers,

Nathan

[eteam00]

I also need to rely on my block memory being initialized to zero, which of course happens naturally within the device,

So far, so good it seems.  This is a settled question.

but simulations will return X from block memory locations that have not first been written to, or initialized (actually, I could be wrong on this point, but I have no way of verifying this statement at this time).

So you have a problem which really isn't a problem, perhaps.  Running a simulation should verify or disprove the issue with excellent clarity...  so yes, you do have a way of 'verifying this statement'.

So, for simulation purposes, I wanted to ensure that my memory is indeed initialized to zero by setting the default values to 0.

It seems our "expert contributor" won't, or can't help us

You have all the insight and tools you need to answer your own question.  You don't need my contributions, expert or otherwise.

so I guess we have to live with using the .coe files to initialize.

If I read your post correctly, you have no basis for making this assertion.  This is a problem which you can quickly and easily solve by running a simulation.

-- Bob Elkind