Original question:
Tool/software: TI C/C++ Compiler
My client want to have a higher angle resolution.
So I try to change the size of azimuth FFT in aoaprochwa.h(C:\ti\mmwave_sdk_03_02_00_04\packages\ti\datapath\dpc\dpu\aoaproc).
I adjusted DPU_AOAPROCHWA_LOG2_NUM_ANGLE_BINS to 7. Then, the Size of azimuth FFT will be 128.
Bug it will be crashed when I start the project.
Are there any settings that need to be modified?
For example : L2 RAM, HSRAM or L3 RAM.
What do I need to set up?
Regards,
JuiYang
Hi JuiYang,
Sorry for the delayed response. Please see below the response from our algorithm expert.
Documentation may not be mentioning all limits [generally I don’t prefer specifying limits related to memory in documentation] but code will enforce. HWA limits are not the only limits, there are also scratch/persistent buffers usage which is allocated by DPC to the DPU so this depends on what total scratch is allocated in the application code which may also run out as DPC allocates one by one the DPUs and DPU demands increases. So the obvious thing to do is to ask the customer to look at the exception information and see in the source code, unless this was an uncontrolled crash [e.g CPU exception]. The DPU API documentation [you can refer to doxygen or directly look up the API header] shows scratch buffer dependency on angle fft size:
/*! @brief Local scratch buffer size. The size maximum of the two buffers that are overlayed:
* Buffer 1 (azimElevLocalBuf and azimElevLocalHypothesesBuf) size:
* (NTxAnt + 1) * NTxAnt * NRxAnt * sizeof(uint32_t)
* Buffer 2 (azimuthFftOutMagBuf) size:
* NTxAnt * @ref DPU_AOAPROCHWA_NUM_ANGLE_BINS * sizeof(uint16_t)
* The size of the second buffer is greater than the first one as long as
* (NTxAnt + 1) * NRxAnt < 32, which is true, therefore the size of the
* second buffer is defined below. */
#define DPU_AOAPROCHWA_NUM_LOCAL_SCRATCH_BUFFER_SIZE_BYTES(numTxAntennas) \
((numTxAntennas) * DPU_AOAPROCHWA_NUM_ANGLE_BINS * sizeof(uint16_t))
……..
/*! @brief Local scratch buffer */
uint8_t *localScratchBuffer[DPU_AOAPROCHWA_NUM_LOCAL_SCRATCH_BUFFERS];
/*! @brief Local scratch buffer size = numTxAntennas * DPU_AOAPROCHWA_NUM_ANGLE_BINS * sizeof(uint16_t).
A convenient macro @ref DPU_AOAPROCHWA_NUM_LOCAL_SCRATCH_BUFFER_SIZE_BYTES has
been provided for calculating this size */
uint32_t localScratchBufferSizeBytes;
} DPU_AoAProcHWA_HW_Resources;
The FFT on HWA itself will be limited to 1 K FFT size. We may have missed one check though in the DPU API which seems related to the Mx memory usage that depends on the angle FFT size, this can be seen in the sub-picture below taken from the doxygen, although in principle we don’t have to do this check because code is compiled for size of 64 [i.e it is not a variable coming indirectly from application e.g through CLI]:
However for FFT size of 256, the total amounts to 6 (2*3 hypothesis, related to extended max vel) * 256 (instead of 64) * 4 (bytes per complex sample) = 6144 bytes < 16 KB, so 256 should be o.k. If someone increased FFT size to 1K, this would be 24576 > 16 KB and this would not be reported as exception currently [it may cause a hang].
BR,
Raghu
