UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor schirice
Visitor
7,787 Views
Registered: ‎08-22-2013

XST and BRAMs

Jump to solution

Hello all,

 

I have a design that contains a large-ish 32k x 128 memory which consumes a fair amount of BRAM resources; the xst reports that the design needs 327 RAMB36E1 and 8 RAMB18E1 elements. Since I am targeting a xc6vlx240T part which contains 416 BRAMs, I have a few BRAMs to "spare". So far so good, the design is being synthesized and it works correctly. The utilization of the other resources (except for BRAMs) is around 50-60%, there is a lot of "room" left on the device.

 

At this point, I want to increase the amout of memory to say 33Kx128 - so I am adding only one extra k to the design; However, this increase in memorty capacity by one extra k (1k x 128) results in xst reporting that it requires 455 RAMB36E1 and 8 RAMB18E1 elements. This puzzels me since a 1kx128 memory requires only 4 BRAMs. Am I missing something here?

 

So I have tried a couple of other  experiments and increased the memory to 37kx128, 40kx128 and xst reports that it requires the same number of RAMB36E1 elements : 455.

 

The xst script that I am using indicates that the bram_utilization_ration, slice_utilization_ratio and dsp_utilization_ratio  should all be 100.

 

Any idea why xst reports such a large increase in BRAM resources?

 

Thanks,

-silviu

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Teacher rcingham
Teacher
10,294 Views
Registered: ‎09-09-2010

Re: XST and BRAMs

Jump to solution
The address space has to be a power-of-2. Therefore the next step up from 32K is 64K. The only other way is to design a block so that it includes 32Kx128 and 1Kx128 BRAMs and ignores out-of-range addresses.

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
10 Replies
Scholar austin
Scholar
7,779 Views
Registered: ‎02-27-2008

Re: XST and BRAMs

Jump to solution

s,

 

How is the memory arranged?  The synthesis tool is only so clever (not really very clever at all), and using memory that does not fit he intrinsic 36K BRAM (9 bits by 4192, 18 by 2048, 36 by 1024 etc.) will result in inefficient use of the resource.

 

Is it just one memory?  Is it just one port?  All of these will affect implementation.  It may be better to instantiate them manually, and 'wrap' them in logic to make efficient use of their features (extra address decoding, or data multiplexing).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Instructor
Instructor
7,776 Views
Registered: ‎08-14-2007

Re: XST and BRAMs

Jump to solution

I'm confused.  In 32K x 1 mode you should only need 128 RAMB36E1's to do the original memory.  Does your memory have more than two address ports?  Did you use one of the templates from the XST user guide?

-- Gabor
0 Kudos
Visitor schirice
Visitor
7,767 Views
Registered: ‎08-22-2013

Re: XST and BRAMs

Jump to solution

Gabor,

 

Thank you for your reply. The memory is 32k x 128 bits. It is a simple dual port mode memory. I have not used any xst templates, instead the memory is initialized as a Bluespec module (mkBRAM2Server). I have looked at the verilog code produced by the bluespec compiler and it looks "fine".  What I wonder is why is xst reporting such a sharp increase in BRAM needs when the size of the memory is only "marginally " increased ...

 

Thanks,

-silviu

0 Kudos
Visitor schirice
Visitor
7,765 Views
Registered: ‎08-22-2013

Re: XST and BRAMs

Jump to solution
Gabor,

I totally agree; the 32k128bits uses indeed 128 BRAMs (the other ones - up to the 327 + 8/2 - are taken by other smaller memories and some logic. I have synthesized the design without the large 32k x 128 (just to confirm that the large meory takes only 128 BRAMs) and the math adds up correctly.

-silviu
0 Kudos
Highlighted
Teacher rcingham
Teacher
10,295 Views
Registered: ‎09-09-2010

Re: XST and BRAMs

Jump to solution
The address space has to be a power-of-2. Therefore the next step up from 32K is 64K. The only other way is to design a block so that it includes 32Kx128 and 1Kx128 BRAMs and ignores out-of-range addresses.

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Visitor schirice
Visitor
7,751 Views
Registered: ‎08-22-2013

Re: XST and BRAMs

Jump to solution
 
Thank you for the information. I was not aware of that. Will try separating that into two blocks of memory as per your suggestion.
 
Thank you,
-silviu
 
 
0 Kudos
Visitor schirice
Visitor
7,735 Views
Registered: ‎08-22-2013

Re: XST and BRAMs

Jump to solution

Austin,

 

It is a single (simple) dual port memory. The code is written in bluespec and verilog is generated for it.

Since hte memory is 32k x 128 I have assumed that the tool would need 2 BRAMs to construct a 512x128 memory and thus

a 1k x 128 needs 4 BRAMs. One of the replies to my post indicate that XST creates memories of power of two sizes ... - I was not aware of that; Thus, I would have to create at least two memory blocks. Is the aboev mentioned constraint mentioned in any user/ref guide?

 

 

Thank you,

-silviu

0 Kudos
Historian
Historian
7,723 Views
Registered: ‎02-25-2008

Re: XST and BRAMs

Jump to solution

@schirice wrote:

Austin,

 

It is a single (simple) dual port memory. The code is written in bluespec and verilog is generated for it.

Since hte memory is 32k x 128 I have assumed that the tool would need 2 BRAMs to construct a 512x128 memory and thus

a 1k x 128 needs 4 BRAMs. One of the replies to my post indicate that XST creates memories of power of two sizes ... - I was not aware of that; Thus, I would have to create at least two memory blocks. Is the aboev mentioned constraint mentioned in any user/ref guide?


The easiest way to figure out how to build a memory block (I always infer) is to realize that the BRAM aspect ratio can vary from being a 32k x 1 to a 512 x 36. (V6 can be a 64k x 1 using its built-in cascade mechanism.) See the V6 FPGA Memory Resources Guide, UG363, for details.

 

When inferring memory, XST will build a memory block by noticing the required depth, up to 64k, and then parallelling as many memories of that depth as necessary to meet the required width. This ensures that no "banking" is required. 

 

Using the RAMB36 with depth = 512 locations, the width of each BRAM is 72 bits. A memory that's 128 bits wide needs two of them (and the parity bits which are bits 65 to 71 in each BRAM are not used). 

 

If the memory needs to be 1k deep, the BRAM width is 36 bits, so you need four BRAMs to get 128 bits wide.

 

Where you get into trouble is if you need memory deeper than 64 k words, since you'll have to build two banks and use a mux to select the bank you're reading, and also you need to create some logic to manage write enables. But it seems unlikely that most users need memory deeper than 64 k words in an FPGA,  and at that point, one might seriously start thinking about using external memory.

 

 

----------------------------Yes, I do this for a living.
0 Kudos
Scholar markcurry
Scholar
7,718 Views
Registered: ‎09-16-2009

Re: XST and BRAMs

Jump to solution

bassman59 wrote: 

Where you get into trouble is if you need memory deeper than 64 k words, since you'll have to build two banks and use a mux to select the bank you're reading, and also you need to create some logic to manage write enables. But it seems unlikely that most users need memory deeper than 64 k words in an FPGA,  and at that point, one might seriously start thinking about using external memory.


 

Bassman,

 

Ever try to infer a memory > 64K deep?  Was always curious what XST would do.  (Error out?  Barf?  Build the banking?) Wouldn't be hard to come up with a quick testcase... I'm just lazy.

 

--Mark

 

0 Kudos
Historian
Historian
2,334 Views
Registered: ‎02-25-2008

Re: XST and BRAMs

Jump to solution

@markcurry wrote:
Ever try to infer a memory > 64K deep?  Was always curious what XST would do.  (Error out?  Barf?  Build the banking?) Wouldn't be hard to come up with a quick testcase... I'm just lazy.

No, because I never use FPGAs with that much BRAM!

 

But yes, it would be an interesting case, and my hope is that it would either barf out or build the correct write gating/output muxing logic.

 

The write gating would be simple, just use appropriate high-order address bits to gate the write enable.

 

The read mux would need to be combinatorial so that the tools don't build something with an extra clock of latency. But I bet that would impact performance.

 

I'm not lazy. Just busy.

----------------------------Yes, I do this for a living.
0 Kudos