Distributed Ram with Initial Values (Virtex)

[Travis]

Hi all,

I'm trying to implement a distributed RAM with initial values in VHDL. I'm targeting a Virtex-5 (that part doesn't matter on comp.lang.vhdl...) - is there an example somewhere? I know that some of the Virtex components do have an initial value that can be passed in using generics - should I tie thisto a global reset or something in order to get the behavior I want?

Thanks!

 

[Gabor]

Hi all,

I'm trying to implement a distributed RAM with initial values in VHDL. I'm targeting a Virtex-5 (that part doesn't matter on comp.lang.vhdl...) - is there an example somewhere? I know that some of the Virtex components do have an initial value that can be passed in using generics - should I tie this to a global reset or something in order to get the behavior I want?

Thanks!

I assume by "with initial values" you mean some values other than
all zeroes as in your last thread. Have you looked in the XST
user guide for inferring ROM? I know it's possible to load the
initial values from a file, as well as to list them explicitly
in the declaration (gets messy for larger memories).

 

[goouse99]

Am Mittwoch, 19. Juni 2013 02:21:30 UTC+2 schrieb Travis:

Hi all,



I'm trying to implement a distributed RAM with initial values in VHDL. I'm targeting a Virtex-5 (that part doesn't matter on comp.lang.vhdl...) - isthere an example somewhere? I know that some of the Virtex components do have an initial value that can be passed in using generics - should I tie this to a global reset or something in order to get the behavior I want?



Thanks!

Hi,
whatever way you choose to get the initial data into your RAM/ROM (INIT or file, actually XST also supports the use of file_io functions but this is not standard VHDL compliant) this has nothing to do with the reset.

The data comes from the configuration bitstream and is only loaded once during configuration. Any kind of reset (if possible at all for a RAM) will not reload that initial data.

Have a nice synthesis
Eilert

 

[Andy]

Travis,

Distributed RAM can be inferred from arrays just like block ram, except you can do combinatorial (non-registered) reads with distributed RAMs.

Just initialize the array in its declaration, and those values will be stored in the ram(s) during configuration.

You cannot reset ram contents on any FPGA that I know of. You can re-configure the FPGA though...

Flash based FPGAs from MicroSemi do not support initial values on RAMs. There is no "configuration" phase in which to perform the initialization.

Andy

 

[Travis]

Hi Gabor,

Yes, this would be a RAM with initial values, but I was going to try to fitit into distributed ram. Its 512x32 bits, so I was going to make it distributed. I will check the XST user guide, but I really wanted to make sure myVHDL was synthesizable

Thanks!

 

[Travis]

Hi Andy,

Thank you, I will initialize the array in its declaration (that's what I did now, but I wanted to make sure it made sense for synthesis).

I'm primarily targeting Xilinx devices; hopefully I'll get a chance to work with some other FPGAs at some point.

-Travis

 

[rickman]

Hi Gabor,

Yes, this would be a RAM with initial values, but I was going to try to fit it into distributed ram. Its 512x32 bits, so I was going to make it distributed. I will check the XST user guide, but I really wanted to make sure my VHDL was synthesizable

I can't say I can see why you want to use distributed RAM rather than
block RAM. I think 512 x 32 bits would use a lot of LUTs but would only
use 2 block RAMs depending on the device family. Are you saving the
block RAMs for something else?

 

[kevin.neilson]

I'd agree. It would only be 1 16-kbit BRAM and it would be much faster. Putting this in distributed RAM would eat up a ton of CLBs and make a routing/placement mess.

 

[Travis]

I'd agree. It would only be 1 16-kbit BRAM and it would be much faster. Putting this in distributed RAM would eat up a ton of CLBs and make a routing/placement mess.

Ah; I will put it into block ram if it would be more sensible, which it looks like it is! Thank you both!

 

[rickman]

Ah; I will put it into block ram if it would be more sensible, which it looks like it is! Thank you both!

I think for the most part, as long as your coding allows it to be
implemented in block RAM, the tool will automatically put it in block
RAM. I'm not sure where they draw the line between using block RAM and
using distributed RAM, but I'm sure it is a RAM that is smaller than 1
block which yours is not.

 

[kevin.neilson]

If you want to target BRAM, you have to have at least one cycle of latency,since the BRAM address is registered. (Distributed RAM can be fully combinatorial.) The tools will then target BRAM if it's over a certain (small) depth. You can add synthesis directives, but you probably don't need them.

 

[Andy]

If you want to target BRAM, you have to have at least one cycle of latency, since the BRAM address is registered. (Distributed RAM can be fully combinatorial.) The tools will then target BRAM if it's over a certain (small) depth. You can add synthesis directives, but you probably don't need them.

Depending on the target device, block RAM read data may be registered instead of (or in addition to) the address being registered. Most synthesis tools don't care, as long as there is one cycle of latency between address and read data.

I have not tried this on a device that had both distributed and block rams,but if you describe RAM accesses with 1 cycle latency on reads, then it should use block rams first, then it should switch to distributed rams plus registers.

You can also use an attribute on the array to direct the ram style. See your synthesis tool documentation for details.

Andy