Axi Lite总线为何占用两个BRAM_18K？技术咨询

Let’s break down what’s happening with your code and why you’re seeing two BRAM_18K resources being consumed. First, here’s your code for reference:

void MyFunc(float input[10], float output[10]) {
#pragma HLS INTERFACE s_axilite port=input bundle=BUS_INPUT
const float temp[10]={ 0.0f,0.1f,0.2f,0.3f,0.4f,0.5f,0.6f,0.7f,0.8f,0.9f };
for(int i=0;i<10;i++) {
output[i]=input[i]+temp[i];
}
}

First off, AXI-Lite itself doesn’t inherently require BRAM resources—it’s a lightweight, memory-mapped bus designed for control registers, not bulk data. The BRAMs you’re seeing are almost certainly tied to how HLS implements your array interfaces and internal constant array. Here are the most likely reasons:

1. AXI-Lite Array Interfaces Are Mapped to BRAM #

When you declare arrays (input[10], output[10]) as AXI-Lite ports, HLS needs to provide a memory-mapped way for the host to read/write these values. Even though your arrays are small (10 floats = 40 bytes), HLS might default to using BRAM as the storage backend for these interface arrays instead of discrete registers.

AXI-Lite slaves typically expose a register space, but for arrays larger than a few elements, HLS often maps the entire array to a single BRAM block to simplify address decoding logic. So input could be using one BRAM, and output another—adding up to two total.

2. The Constant Array temp Is Stored in BRAM #

Your temp array is a constant, but HLS doesn’t always optimize small constants into combinational logic (like hardcoding values directly into adders). Depending on your HLS configuration, it might be inferring a BRAM-based ROM to store these values. Even though 10 floats are tiny, HLS’s default resource allocation might prioritize BRAM for any array, regardless of size, unless you explicitly guide it otherwise.

3. HLS Default Storage Optimization Settings #

Check your HLS project’s configuration: if you haven’t enabled aggressive array optimization (like ARRAY_PARTITION or ARRAY_MAP), HLS will stick to its default behavior of using BRAM for array storage. Small arrays can sometimes fit in LUTRAM or flip-flops, but HLS won’t make that switch automatically unless you tell it to.

How to Verify & Adjust This #

• Check the HLS Resource Report: Look for the "Memory Resources" section—it will explicitly map each BRAM block to a specific variable (e.g., input, output, or temp). This is the fastest way to pinpoint which array is using which BRAM.
• Force the Constant Array to Use LUTRAM/ROM: Add a pragma to tell HLS to implement temp as a ROM using LUTs instead of BRAM:

  const float temp[10]={ 0.0f,0.1f,0.2f,0.3f,0.4f,0.5f,0.6f,0.7f,0.8f,0.9f };
  #pragma HLS ARRAY_MAP variable=temp instance=temp_rom type=rom
  

• Optimize Interface Arrays: If you don’t need the entire array accessible via AXI-Lite at once, modify the code to transfer elements one by one (using a loop with single input/output registers), which would eliminate BRAM usage for interfaces. Alternatively, use #pragma HLS ARRAY_PARTITION to split the array into individual registers, though this increases the number of exposed AXI-Lite registers.

内容的提问来源于stack exchange，提问作者Yunlong Wang