Hardware Developers Community - NI sbRIO & SOM

cancel
Showing results for 
Search instead for 
Did you mean: 

Who is claiming my Block RAM!?

Solved!
Go to solution

Dear colleagues,

I am programming a sbrio-9606, whose LX45 FPGA has, as you surely know, 116 BRAMs (short for Block RAM), sizeable as Length*Width = 16k*1b = 8k*2b = ... = 1k*16b = 1/2k*32b.

As a result, because I need to implement 10 tables of 10,000 16-bit words each, my design consumes 100 BRAMs. This would leave 16 BRAMs available, right? ... wrong!: only 13 are shown as available!

I wonder who is eating the remaining 3 BRAMs!

And, generally speaking, is there any way to know who in your design is claiming the FPGA's BRAMs?

Regards,

Biscay.

0 Kudos
Message 1 of 7
(5,799 Views)

Try to compile an empty VI and see how much BRAM it consumes. I think there are some logic underneath used for LabVIEW to communicate with the FPGA.

Message 2 of 7
(5,780 Views)

Hi Biscay,

 

Besides trying a blank bitfile, another interesting check would be to verify the usage in the compilation log. That may show whether or not there is a discrepancy with how the resource utilization is being reported.

 

Will

National Instruments

Message 3 of 7
(5,759 Views)

Dear colleagues,
Thank you for your replies. I've done both things:
1) Compiling a blank vi: Final device utilization is = 120/6822 total slices, 306/54576 slice registers, 246/27288 slice LUTs... but 0/116 Block RAMs (and 0/58 DSP48s).
2) Reading through the xilinx log, I find these lines:

INFO: [Designutils 20-277] Completed resource estimation on toplevel_gen - Slices: 4163, LUTs: 11324, Flops: 8185, BRAMs: 4, DSP48s: 6

...

Design Summary:

..

Specific Feature Utilization:
  Number of RAMB16BWERs:                         2 out of     116    1%
  Number of RAMB8BWERs:                          2 out of     232    1%

...

Device Utilization Summary:

..

  Number of RAMB16BWERs:                         2 out of     116    1%
  Number of RAMB8BWERs:                          2 out of     232    1%

 

These figures match the gross total of 3 given by the "Display Compilation Results" window, as long as two 8-kb blocks count as one 16-kb block, as seems to be the case.

***

Having said all that... I may have found an answer. I forgot to mention that I also have three "Look-up Table 1D" items in the FPGA diagram. In their config menus they confess that they will take 4kB=1k*16b; 128B; 128B.

Do you know how such "Look-up Table 1D" items are implemented? I assumed they were implemented as fabric LUTs, but perhaps the name has misled me, and are actually implemented as BRAMs instead? This could unveil the mystery!

Regards,

Biscay.

0 Kudos
Message 4 of 7
(5,745 Views)

Sorry, when I said 4kB=1k*16b I obviously meant 4kB=1k*32b. Biscay.

0 Kudos
Message 5 of 7
(5,742 Views)
Solution
Accepted by topic author biscay

Hi biscay,

I'm assuming you're referring to the Look-Up Table 1D Express VI. If that's correct, that VI does typically get implemented using BlockRAM resources. From the Help for that VI:


@biscay The main FPGA resources used for implementation of the Look-Up Table 1D are block memories, which Xilinx literature describes as block RAMs or BRAMs.

If you explicitly are looking for an implementation that uses LUTs in LabVIEW, I would recommend one of the following:

  1. Use a Memory Item with the Implementation set explicitly to LUTs.
  2. Use one of the array constant patterns for optimizing array constant memory usage that will resolve to a LUT implementation.

 

I believe the Express VI is referring to Look-Up Table in terms of the data structure rather than the physical FPGA resource type. 

Charlie J.
National Instruments
Message 6 of 7
(5,734 Views)

Charlie, good point! Definitely, it makes much sense. And sorry for having missed the "Look-Up Table 1D Express VI" help entry, which is crystal clear.

Biscay.

0 Kudos
Message 7 of 7
(5,728 Views)