cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
1,130 Views
Registered: ‎02-23-2017

bit file doesn't contain BRAM supposed load

Hi,

Can somebody help me, please.

I am using from Kintex-7, the chip xc7k410tfbg676-1. Please see attached the implementation report. According to the report there are 744.5 BRAM used (I mean RAMB36E1) what should be consistent with the design. After my bitstream generation and programming the chip if I connect the scope and unloading the RAM I see only ones coming from RAM's which is not what I expect. My simulation shows everything all right so I am looking where the mistake is.

My bit file is 12.7 MB. Can be the size an indication of the BRAM load?

Looking after implementation into Netlist tab -> Leaf Cells -> Properties of BRAM I see the content of BRAM exactly what binary patterns are supposed to be. However, if I look into the bitstream with a hex Editor I don't find the binary strings that I would supposed to find. I am not sure if this is the right way to check if the bit file includes the wanted binary patterns that reached the BRAM. If you have a better solution please help.

I see in the bit file blocks of FFs which are not in my binary patterns but should maybe related how the bitstream is written.

Should be a special option/condition when I build the bit file to ensure the BRAM content correctly?

Thank you very much for help,

andrei

0 Kudos
4 Replies
Highlighted
Instructor
Instructor
1,078 Views
Registered: ‎10-23-2018

@andreid

Did you 'set' the ram via logic or via a COE file prior to reading? Or did you 'set' the default pattern for the to initialize the ram or did you just let it use the default?

Are you really needing ram or would ROM work for you?

0 Kudos
Highlighted
Visitor
Visitor
1,069 Views
Registered: ‎02-23-2017

Hi,

I need half of BRAM, more exactly 371 blocks, as RAM and other half as ROM. I mean it is ROM but I asked Vivado with an attribute to be a block. It is vhdl coding.

If I don't ask for ROM to be BRAM, wouldn't use to much logic? That was my concern.

I initialized each 371 BRAMs with a file. It should be a different file for each BRAM. Please see attached Vivado_screen.png. It is Vivado with a BRAM 367, a randomly target for exemple. Then you have vivado_cell_367.png, Cell properties of BRAM number 367. It is exactly what I supposed to see as per initialization file, shown in data_in_BrAM_367.png. To make life easier I have an converted hex file of the data initialization file, converted_Hex_367.png.

Thank you very much for help,

andrei

 

vivado_cell_367.png
data_in_BRAM_367.png
Vivado_screen.png
converted_Hex_367.png
0 Kudos
Highlighted
Instructor
Instructor
1,051 Views
Registered: ‎10-23-2018

@andreid

I am guessing you have a Virtex FPGA… I have an UltraScale, so I can’t say for sure, but the way I would do it, it to use the IP catalog.. Use the Block Memory generator (not distributed memory) if you want to use BRAM instead if LUTs.

You can specific specifically for RAM or ROM. You ‘could’ use the ram like rom by not enabling writes, it you want to keep the RAM and psuedo-ROM together.

On the ‘other options’ tab in the memory generator, you can specify a COE file with you initial values. You can also specify the default value to ‘fill’ the rest of the values not specified in the COE.

The memory generator should customize itself to your specific hardware. (and be more portable)

Hope that helps

0 Kudos
Highlighted
Visitor
Visitor
1,040 Views
Registered: ‎02-23-2017

Hello,

As I said in the first post, I am using Kintex-7, the chip xc7k410tfbg676-1. Also at that post, I attached the report from Vivado implementation. I am doing here copy and paste from that report.(you can see all the report attached at the first post)

--------------------------------------------------------------------

3. Memory
---------

+-------------------+-------+-------+-----------+-------+
| Site Type | Used | Fixed | Available | Util% |
+-------------------+-------+-------+-----------+-------+
| Block RAM Tile | 744.5 | 0 | 795 | 93.65 |
| RAMB36/FIFO* | 744 | 0 | 795 | 93.58 |
| RAMB36E1 only | 744 | | | |
| RAMB18 | 1 | 0 | 1590 | 0.06 |
| RAMB18E1 only | 1 | | | |
+-------------------+-------+-------+-----------+-------+
* Note: Each Block RAM Tile only has one FIFO logic available and therefore can accommodate only one FIFO36E1 or one FIFO18E1. However, if a FIFO18E1 occupies a Block RAM Tile, that tile can still accommodate a RAMB18E1

--------------------------------------------------------------------

It is clearly stating that 744.5  BRAM from 795 are used so is not a problem of  Vivado implementing BRAM. And clearly said that all BRAM are implemented. Also I mentioned my ROM is using BRAM and of course for that, I am not enabling writings. According to all reports of Vivado is clearly understanding what it was told to do. Tell me what report of Vivado you want to check because to me implementation is correct. I used a Xilinx template for BRAM so I don't complain about implementation.  Vivado doesn't accept array of two dimensions and also I didn't see a documentation for BRAM generator generating such big RAM memory. 

My question is about bitstream. The moment when I pass at bitstream the things get wrong. As I said in the first post, the size in the bitstream is 12.7 MB. If I am thinking of only  744 BRAM shouldn't be about 27 MB only from BRAM. Somehow the BRAM bits are lost?

Thank you for your time.

 

0 Kudos