Before discussing how the coding style can impact the implementation of arrays after synthesis, it is worthwhile discussing a situation where arrays can introduce issues even before synthesis is performed, for example, during C/C++ simulation.
If you specify a very large array, it might cause C/C++ simulation to run out of memory and fail, as shown in the following example:
#include "ap_int.h"
int i, acc;
// Use an arbitrary precision type
ap_int<32> la0[10000000], la1[10000000];
for (i=0 ; i < 10000000; i++) {
acc = acc + la0[i] + la1[i];
}
The simulation might fail by running out of memory, because the array is placed on the stack that exists in memory rather than the heap that is managed by the OS and can use local disk space to grow.
This might mean the design runs out of memory when running and certain issues might make this issue more likely:
- On PCs, the available memory is often less than large Linux boxes and there might be less memory available.
- Using arbitrary precision types, as shown above, could make this issue worse as they require more memory than standard C/C++ types.
- Using the more complex fixed-point arbitrary precision types found in C++ might make the issue of designs running out of memory even more likely as types require even more memory.
The standard way to improve memory resources in C/C++ code development is
to increase the size of the stack using the linker options such as the following option
which explicitly sets the stack size -z
stack-size=10485760
. This can be applied in Vitis HLS by going to , or it can also be provided as options to the Tcl commands:
csim_design -ldflags {-z stack-size=10485760}
cosim_design -ldflags {-z stack-size=10485760}
In some cases, the machine may not have enough available memory and increasing the stack size does not help.
A solution is to use dynamic memory allocation for simulation but a fixed sized array for synthesis, as shown in the next example. This means that the memory required for this is allocated on the heap, managed by the OS, and which can use local disk space to grow.
A change such as this to the code is not ideal, because the code simulated
and the code synthesized are now different, but this might sometimes be the only way to move
the design process forward. If this is done, be sure that the C/C++ test bench covers all
aspects of accessing the array. The RTL simulation performed by cosim_design
will verify that the memory accesses are correct.
#include "ap_int.h"
int i, acc;
#ifdef __SYNTHESIS__
// Use an arbitrary precision type & array for synthesis
ap_int<32> la0[10000000], la1[10000000];
#else
// Use an arbitrary precision type & dynamic memory for simulation
ap_int<int32> *la0 = malloc(10000000 * sizeof(ap_int<32>));
ap_int<int32> *la1 = malloc(10000000 * sizeof(ap_int<32>));
#endif
for (i=0 ; i < 10000000; i++) {
acc = acc + la0[i] + la1[i];
}
__SYNTHESIS__
macro in the code to be synthesized. Do not use this macro in the test bench, because it is not obeyed
by C/C++ simulation or C/C++ RTL co-simulation.Arrays are typically implemented as a memory (RAM, ROM or FIFO) after synthesis. Arrays on the top-level function interface are synthesized as RTL ports that access a memory outside. Internal to the design, arrays sized less than 1024 will be synthesized as FIFO. Arrays sized greater than 1024 will be synthesized into block RAM, LUTRAM, and UltraRAM depending on the optimization settings.
Like loops, arrays are an intuitive coding construct and so they are often found in C/C++ programs. Also like loops, Vitis HLS includes optimizations and directives that can be applied to optimize their implementation in RTL without any need to modify the code.
Cases in which arrays can create issues in the RTL include:
- Array accesses can often create bottlenecks to performance. When implemented as a memory, the number of memory ports limits access to the data.
- Some care must be taken to ensure arrays that only require read accesses are implemented as ROMs in the RTL.
Array[10];
. However, unsized arrays are not supported, for
example: Array[];
.