AWR1843: Why doing HWA re-config at the start of every frame processing?

Wesley He

Part Number: AWR1843

Hello team,

Here's question from customer. Why the HWA need to be re-config at the start of every frame processing?

Suppose if using one subframe, we don't need to re-config the HWA all the time because the range FFT and dopper FFT are using different hwaParamCfg[paramsetIdx]

Please let me know if I have any mis-understanding here.

Thanks.

The reference code is copy from

"C:\ti\mmwave_automotive_toolbox_3_3_0\labs\lab0011_mrr_beamsteering\src\dss\dss_data_path.c"

void MmwDemo_interFrameProcessing(MmwDemo_DSS_DataPathObj *obj, uint8_t subframeIndx)
{
uint32_t rangeIdx, detIdx1, numDetObjPerCfar, numDetDopplerLine1D, numDetObj1D, numDetObj2D;
uint32_t dmOff;
uint32_t slowChirpOff;
volatile uint32_t startTime;
volatile uint32_t startTimeWait;
uint32_t waitingTime = 0;
uint32_t pingPongIdx = 0;
uint32_t dopplerLine, dopplerLineNext;

startTime = Cycleprofiler_getTimeStamp();

//only used for MRR:
slowChirpOff = obj->numDopplerBins * obj->numVirtualAntennas;

//Configure the EDMA for 2D HWA usage, either subframe type
MmwDemo_config2D_EDMA(obj);

//This HWA program fills obj->detMatrix. For MRR, it does an FFT on
//the first 128 "fast" chirps per virtual antenna per all range bins.
MmwDemo_config2D_HWA(obj, subframeIndx);
MmwDemo_dataPathTrigger2D(obj);
MmwDemo_waitEndOf2D_HWA();

if (obj->processingPath == MAX_VEL_ENH_PROCESSING)
{
//setup the first virtual antenna's data to be transferred.
//This needs to start with chirp 128 - the "slow" chirps.
Config_2d_and_Azm_Edma(obj, 0,
(uint8_t *)&obj->radarCube[slowChirpOff]);

//Kick the first transfer for secondDimFFTandLog2Computation().
MmwDemo_startDmaTransfer(obj->edmaHandle[EDMA_INSTANCE_DSS],
MRR_SF0_EDMA_CH_2D_IN_PING,
NULL,
0);
}

Regards,

Wesley

over 4 years ago

0 Aniket Mahajan over 4 years ago

TI__Genius 15046 points

Hi Wesley,

The customer's statement about range and doppler processing using different paramsets is correct (within a subframe), but there are two reasons that a HWA reconfiguration is needed nonetheless:

1. MRR and USRR subframes use different HWA paramset configurations. As the lab stands currently, these different configurations are stored in the same paramset index by means of reconfiguring the paramsets every subframe. It should be possible to avoid reconfiguration here if different paramsets are used for the MRR, USRR subframe as well.

2. HWA common configs need to change between different subframes and for that matter, even within a subframe when switching from range to doppler processing. This includes configurations like number of HWA loops, paramset start and end index, et cetera. (have a look at HWA_CommonConfig structure). It is not possible to avoid this reconfiguration.

Reconfiguring just the common configs would definitely be cheaper than reconfiguring the paramsets (though the cost of reconfiguring paramsets as well is pretty insignificant for this case to begin with).

Regards,

Aayush

0 Wesley He over 4 years ago in reply to Aniket Mahajan

TI__Expert 6205 points

Hi Aayush,

For question 1, MRR and USRR use different parameter index. And we still need to do the re-config.

Is it means that we need to pass which index should be used information to HWA hardware everytime?

#define MMW_HWA_WINDOWRAM_1D_OFFSET 0 //In samples
#define MMW_HWA_START_PARAMSET_SF0_1D 0
#define MMW_HWA_START_PARAMSET_SF1_1D 4
#define MMW_HWA_START_PARAMSET_SF0_2D 8

Question 2, understand.

Thanks.

Regards,

Wesley

0 Aniket Mahajan over 4 years ago in reply to Wesley He

TI__Genius 15046 points

Hi Wesley,

Thanks for this catch! It seems that the paramsets for 1D FFT for MRR and USRR subframes are indeed different. However, this is not the case for the 2D paramset. From the MmwDemo_config2D_HWA function:

if (subframe == 0) //MRR
      dopplerBinsPerRangeBin = obj->numDopplerBins * 2; //for MRR, there are two chirp types
    else
      dopplerBinsPerRangeBin = obj->numDopplerBins;     //for MRR, there is one chirp type

Further down in the same function:

HWAutil_configDopplerFFT(obj->hwaHandle,
        MMW_HWA_START_PARAMSET_SF0_2D,     // paramSetStartIdx,
        obj->numDopplerBins,               // dopplerFftSize,
        dopplerBinsPerRangeBin,            // doppler bins (chirps) per range bin,
        obj->numVirtualAntennas,           // numVirtualAnt,
        MMW_NUM_RANGE_BINS_PER_TRANSFER,   // numRangeBinsPerIter,
        obj->hwa_2DwinOff,

        MMW_HWA_DMA_TRIGGER_SOURCE_2D_PING,
        MMW_HWA_DMA_TRIGGER_SOURCE_2D_PONG,
        MMW_HWA_DMA_DEST_CHANNEL_2D_PING,
        MMW_HWA_DMA_DEST_CHANNEL_2D_PONG,

        ADDR_TRANSLATE_CPU_TO_HWA(MMW_HWA_2D_INP_PING), //hwaMemSourcePingOffset
        ADDR_TRANSLATE_CPU_TO_HWA(MMW_HWA_2D_INP_PONG), //hwaMemSourcePongOffset
        ADDR_TRANSLATE_CPU_TO_HWA(MMW_HWA_2D_OUT_PING), //hwaMemDestPingOffset
        ADDR_TRANSLATE_CPU_TO_HWA(MMW_HWA_2D_OUT_PONG), //hwaMemDestPongOffset
        DATA_PATH_CHAIN_COMBINED_LOGMAG);

The same paramset index is supporting two different configs.

There can be a total of 16 paramsets, and it looks like the lab was designed with some consideration in mind for possible future inclusion of CFAR and AoA processing with HWA. Maybe that is why this is the case.

Regards,

Aayush

Sensors

Sensors forum

AWR1843: Why doing HWA re-config at the start of every frame processing?