Actions
Forum Thread Details
  • State Not Answered
  • Replies 1 reply
  • Subscribers 323 subscribers
  • Views 2584 views
  • Users 0 members are here
Related

ZedBoard BRAM Size confusion

100chakal

Hi,

 

I am confused about the size of the BRAM memory. The training video published on the Training and Videos link,section SoC Hardware, video Zynq overview,minute 8 http://zedboard.org/course/developing-zynq%C2%AE-7000-all-programmable-soc-hardware-vivado-20133-201441-20152-and-20162

says that the Z-7020 SoC has 560KB of Block RAM. 

This link - https://lauri.xn--vsandi-pxa.com/2014/05/zynq-soc.html  also states that the ZedBoard has 560KB of Block RAM.

 

I've added a BRAM module and a BRAM Controller to my design and when I look in the system.hdf file in the SDK my BRAM(the axi_bram_ctrl_0 more precisely) is in the range 0x4000 0000  –0x4000 1FFF. This means I have only 8KB of BRAM and I don't understand why. Why do I have only 8KB of BRAM? How can I have acces to the 560KB of BRAM that are mentioned in the ZedBoard Training Video?

Thank you!
Chakal

  • 0

    Hi there,

    From the sounds of it, you are using the Block Memory Generator IP in the Block Design.  The reason you are seeing 8192 instead of the "full" 560kB is probably some confusion due to the representation of a BRAM.  Also, notice the kB not KB.  8kB = 1KB.  In the PL, typically you operate at a BIT level.

    If you open the block design block memory generator, under the basic tab, select stand alone mode instead of BRAM Controller, you can now choose to have deeper writes.  The controller part is causing your limitation.  This is due to the ease addressing using AXI and a processor.  In the PL, we are typically free to do things at the BIT level (non-multiples of 8).  When working with a processor we need to do things on a level that is most efficient to the hardened interfaces provided.

    Notice I specifically stated "deeper writes", not 8KB of data?  Take into account that this is a 32bit wide interface.  32x8192 = 256kB, which is 32KB, not the 8KB you mentioned.  As a side note, the AXI_BRAM_CTRL IP can access TWO BRAMS, giving you access to 64KB of BRAM with one interface.  You are then free to drop in more than 1 controller, although I cannot speak to how this will affect the design, as I have not done this.

    I would not recommend accessing all 560kB from one point in the fabric.  It is distributed around inside the various slices of the chip.  As you wire them in, you will eventually begin to use up LUTS and routing fabric, which will be detrimental to meeting timing as well as having resources available for your PL design.  This also chews up the internal memory that the FPGA will use for FIFOS as well as any other register type of interface.  The tool will attempt to compensate by creating BRAM from LUTS and other logic.  This is not a recomended practice.  You can see this in the UltraFast Design methodology UG1231, where it gives recomendations to how "full" a design should be.  In this case, you want to use 100% of a resource, which is well above the recomendations provided.
    You can find this document here:
    https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_3/ug1231-ultrafast-design-methodology-quick-reference.pdf

    Instead, I suggest that the snoop controller within the Zynq allows the processor access to many types of memory using a scatter gather interface.  As such, I would suggest using DDR for accessing that much memory from the PS.  If you are looking for just a way to pass information back and forth, might I suggest a FIFO or one of the many other AXI interfaces (both streaming or quasi-static).  These are designed for this type of interface.

    If you really need to access this particular memory, you can certainly change the BRAM mode type to stand alone and wire in your own controller, or as mentioned, the tools seems to allow you to drop in multiple AXI_BRAM controllers.  The IP is there and with some effort on your part, you might be able do this, although again, I recomend you NOT do this.

    --Dan