Not power of two BRAM size problem

Hi Everybody,

I'm using a xc2vp4 FPGA from Xilinx which has 28 blocks of 18Kb (= 504
Kb = 63 KB) of BRAM.

The problem is:
using EDK is only possible to allocate a power of two size (in KB) for
the BRAM !!!
This means that I can only address 32KB of the 63KB available on
FPGA...

One possible (bad) solution to use all BRAM can be to create more BRAM
controllers each one with a different size (32 + 16 + 8 + 4 + 2 + 1).
The drawbacks of this approach in my opinion are:
1) Lot of logic used for all the controllers
2) Each code segment has to fit fine (to exploit the memory) in each
bram.
3) If I have a code segment greater than 32KB there's no way to
complete the design even if the FPGA has 63KB available...

Nevertheless, EDK minimum BRAM size is 16KB !!!! So I can, at best, to
use only 32 + 16 KB   :(

Any ideas to workaround this problem?

Thanks!

Andrea

You should recalculate your BRAM needs. As some cores and microblaze 
itself may consume a few of the BRAM for fifos or cache. If you use
chipscope, you'll need a bram for onchip debugging.

Nonetheless, I wouldn't worry so much about the LUT logic consumed for 
controllers unless you running out of resources.

The approach of combining controllers (32 + 16) in a contiguous memory 
space is correct. The BMM generated will recognize that memory regions 
are contiguous thus allowing data2mem to populate code segments that are 
larger than 32kB. Ofcourse, this requires atleast EDK 8.2

Andrea05 wrote:
> Hi Everybody,
> 
> I'm using a xc2vp4 FPGA from Xilinx which has 28 blocks of 18Kb (= 504
> Kb = 63 KB) of BRAM.
> 
> The problem is:
> using EDK is only possible to allocate a power of two size (in KB) for
> the BRAM !!!
> This means that I can only address 32KB of the 63KB available on
> FPGA...
> 
> One possible (bad) solution to use all BRAM can be to create more BRAM
> controllers each one with a different size (32 + 16 + 8 + 4 + 2 + 1).
> The drawbacks of this approach in my opinion are:
> 1) Lot of logic used for all the controllers
> 2) Each code segment has to fit fine (to exploit the memory) in each
> bram.
> 3) If I have a code segment greater than 32KB there's no way to
> complete the design even if the FPGA has 63KB available...
> 
> Nevertheless, EDK minimum BRAM size is 16KB !!!! So I can, at best, to
> use only 32 + 16 KB   :(
> 
> Any ideas to workaround this problem?
> 
> Thanks!
> 
> Andrea
> 

On 23 Feb, 18:08, Paulo Dutra <paulo.du...@NOSPAM.com> wrote:
Hi Paulo,

> You should recalculate your BRAM needs. As some cores and microblaze
> itself may consume a few of the BRAM for fifos or cache. If you use
> chipscope, you'll need a bram for onchip debugging.

What do you exactly mean by that?
I have a quite big program which use several 4x4 matrix. I would like
to mantain Program and Data in BRAM to speed up the execution.


> Nonetheless, I wouldn't worry so much about the LUT logic consumed for
> controllers unless you running out of resources.

You're right, this is only a minor issue.



> The approach of combining controllers (32 + 16) in a contiguous memory
> space is correct.

Yes correct but (63 - (32 + 16)) KB still remain unsued!



> The BMM generated will recognize that memory regions
> are contiguous thus allowing data2mem to populate code segments that are
> larger than 32kB. Ofcourse, this requires atleast EDK 8.2

Unfortunately I have EDK 7.1 :(

Thanks for your hints,

Andrea

Hi Andrea,

Let me add some more things to this:

1. The "opb_bram" core allows for smaller memory blocks. It lets you
add controllers for the smaller sizes and thus make available more
memory.

2. For me, the EDK 8.2 SP3 "data2mem" functionality does not work
correctly with contiguous segments.  I can assign different linker
segments to different bram (controllers), but a linker segment cannot
cross a bram border.  Unfortunately all C code is compiled to a single
TEXT segment, so the maximum code size for your project would be
32KB.  Only the data, bss, stack, init, boot, etc segments can be
moved to the additional bram controllers.

3. You can always implement your own bram controller, with only 63K
used.

Regards,
Marc