AWR1843BOOST: Some questions about awr1843 demo in sdk 3.4.0.3

Hi Bryant,

This is actually a feature of the DPC. The scratch memory used by all DPUs is overlapped (starting at the same address). As only one DPU executes at a time, it has sole access to the scratch memory while it is executing. When executing, the DPU uses its scratch memory. The next DPU to execute overwrites this memory for its own computations.

DPC_ObjDet_MemPoolAlloc doesn't work like normal alloc functions. It doesn't reserve/allocate memory from the system heap, It just returns an address and advances MemPoolObj which is pointing to a memory that has already been allocated. In the case of mmwave demo, CoreLocalRamObj is allocated once in the dss_main.c as global variable (gDPC_ObjDetL2Heap) and passed to the DPC through DPM_init.

Have a look at the following diagram from the HWA DPC's doxygen document for a visual representation of the memory layout:

A little context for the image:

• If you want memory to persist across subframes, allocate it on the system heap with MemoryP_ctrlAlloc (eg: dcRangeSigMean) and later deallocate it with MemoryP_ctrlFree manually. 
• If you want memory to persist within a subframe across all DPU computations, "allocate" it with DPC_ObjDet_MemPoolAlloc before "allocating" the scratch buffers (eg: cfarRngDopSnrList)
• If you want memory to persist only when a DPU is being executed, "allocate" it  within DPC_ObjDet_<DPU>config and then rewind the memory pool to CoreLocalScratchStartPoolAddr so the next DPU can also "allocate" the same memory (eg: windowBuffer, scratchBuf, cfarDopplerDetOutBitMask, etc)

In cases 2 and 3, actual allocation happened in dss_main.c.  DPC_ObjDet_MemPoolSet, DPC_ObjDet_MemPoolGet and DPC_ObjDet_MemPoolAlloc are just accounting functions that don't do any actual allocation from the system.

To summarize,

Since only one DPU executes at a time, the scratch buffers used by these DPUs share the same physical memory which is allocated . This is why after every DPC_ObjDet_<DPU>config function, DPC_ObjDet_MemPoolSet is called to rewind and start allocation from CoreLocalScratchStartPoolAddr again.

Regards,

Aayush

Hello, Aayush

First of all, thank you very much for answering most of my questions.But i still have some Confuse.

In function DPC_ObjDet_preStartConfig, DPC_ObjDet_rangeConfig && DPC_ObjDet_staticClutterConfig && DPC_ObjDet_CFARCAconfig && DPC_ObjDet_dopplerConfig,these four functions are executed in turn.If DPC_ObjDet_rangeConfig called, this range DPU want use windowBuffer,and range  windowBuffer produced in DPC_ObjDet_rangeConfig.However DPC_ObjDet_staticClutterConfig is called,the range windowBuffer is overwriting.When execute the DPU_RangeProcHWA_process will can't find  range windowBuffer?Or it save in HWA in the DPC_ObjDet_rangeConfig ?

In your means,the order of execution of the functions is ：

1.DPC_ObjDet_rangeConfig -> DPU_RangeProcHWA_process

2.DPC_ObjDet_staticClutterConfig -> DPU_StaticClutterProc_process

3.DPC_ObjDet_CFARCAconfig -> DPU_DopplerProcHWA_process

4.DPC_ObjDet_dopplerConfig -> DPU_CFARCAProcHWA_process

Do I understand that correctly?

My understanding is that the order of execution of the functions is ：

DPC_ObjDet_rangeConfig -> DPC_ObjDet_staticClutterConfig -> DPC_ObjDet_CFARCAconfig -> DPC_ObjDet_dopplerConfig ->

DPU_RangeProcHWA_process -> DPU_StaticClutterProc_process-> DPU_DopplerProcHWA_process-> DPU_CFARCAProcHWA_process.

In function of DPC_ObjectDetection_execute,see follow picture:

if rewind and start allocation from CoreLocalScratchStartPoolAddr,when DPU_RangeProcHWA_process is called, we should DPC_ObjDet_GenRangeWindow,it do not execute it.However before DPU_DopplerProcHWA_process it called the DPC_ObjDet_GenDopplerWindow.

I hope to get your answer soon.

Thanks a lot!

Bryant

Hi Bryant,

Gy Bryant said:

My understanding is that the order of execution of the functions is ：

DPC_ObjDet_rangeConfig -> DPC_ObjDet_staticClutterConfig -> DPC_ObjDet_CFARCAconfig -> DPC_ObjDet_dopplerConfig ->

DPU_RangeProcHWA_process -> DPU_StaticClutterProc_process-> DPU_DopplerProcHWA_process-> DPU_CFARCAProcHWA_process.

Your understanding is correct for the most part. You can have a look at the doxygen document for an overview of the order of execution of these functions. Here is the execution flow diagram:

How the config functions are called (for HWA based DPC):

User application->DPM_ioctl(DPC_OBJDET_IOCTL__STATIC_PRE_START_CFG) (for each subframe)-> DPC_ObjectDetection_ioctl->DPC_ObjDet_preStartConfig->(calls all DPC_ObjDet_<DPU>Config)

Once this is complete, user application starts the sensor by calling DPM_start and then MMWave_start.

After this the frames start coming in.

When a frame starts, DPM gets a frameStartSysInterrupt interrupt from RF. DPM notifies this to DPC by calling DPC_ObjectDetection_frameStart, which was registered with the DPM. 

DPC_ObjectDetection_frameStart checks if last subframe's processing has finished, and if so, calls DPM_notifyExecute to notify the DPM that the DPC is ready to be executed. DPM_notifyExecute posts a semaphore ptrDPM->semaphoreHandle.

Then, the DPM_execute function which was pending on the semaphore (which is being called in the user application in a loop) starts and calls DPC_ObjectDetection_execute.

Hello, Aayush

you say right,but i think you do not get my point.

DPC_ObjDet_MemPoolAlloc function does not modify the underlying memory. It just returns a pointer to a memory location that can be used later by the DPU process functions. That's right. But the memory that this pointer is pointing to and the memory that follows is all the data that we need(etc windowbuffer...) DPC_ObjDet_rangeConfig and DPC_ObjDet_staticClutterConfig and other two configs both have the same address pointer to begining of the scratch buffer.When DPU_RangeProcHWA_process called,it will find the begenning address of the scratch buffer,and the address pointer to range windowbuffer,this memory is overwriting due to followed DPC_ObjDet_DPU_Config(etc DPC_ObjDet_staticClutterConfig ) .

Is there a problem with my understanding, or do i not understand your answer?

thanks

Bryant

Hi Bryant,

Let me know if I'm wrong, but I think you might be under the impression that the successive DPU config calls overwrite the previous DPU scratch memories. If I am correct in the understanding your question,

Yes, the scratch memory objects (rangeproc windowBuffer etc) will get overwritten, but not by the DPU config functions (DPC_ObjDet_staticClutterConfig and the rest).

The rangeproc windowBuffer allocated during DPC_ObjDet_rangeConfig is not overwritten by DPC_ObjDet_staticClutterConfig.

It will be used for the first and only time in DPU_RangeProcHWA_process and then get overwritten by DPU_StaticClutterProc_process when it writes to its scratchBuf array.

Since rangeproc windowBuffer is only used during the execution of DPU_RangeProcHWA_process and at no other time, it doesn't matter if the data in it gets overwritten by other process functions later.

I hope that answers your question. If not, please let me know.

Regards,

Aayush

Hello, Aayush

Since rangeproc windowBuffer is only used during the execution of DPU_RangeProcHWA_process and at no other time, it doesn't matter if the data in it gets overwritten by other process functions later.That is right.

When you execution DPU_RangeProcHWA_process,you should get rangeproc windowBuffer data,then you can do ID-FFT.However,the data is overwriting when execute a series of initializations(etc DPC_ObjDet_rangeConfig -> DPC_ObjDet_staticClutterConfig -> DPC_ObjDet_CFARCAconfig -> DPC_ObjDet_dopplerConfig).

I wonder if it's necessary to DPC_ObjDet_GenRangeWindow before DPU_RangeProcHWA_process?Or it save rangeproc windowBuffer in HWA when execute DPC_ObjDet_rangeConfig ?

Thanks.

Bryant

Hi Bryant, 

Thanks for your patience, I fully understand your question now.

After windowBuffer is allocated, it is populated by DPC_ObjDet_GenRangeWindow in DPC_ObjDet_rangeConfig. Then, the rest of the config functions are called. These config functions do not modify the contents of memory. Hence, after DPC_ObjDet_preStartConfig is complete, the start of scratch memory stores the valid range windowBuffer. You can check the code for yourself and confirm that this is indeed the case.

So, when DPU_RangeProcHWA_process is called, it receives valid value for windowBuffer. Once DPU_StaticClutterProc_process writes to its scratchBuf, the rangeproc windowBuffer is overwritten. It is reconfigured again before the arrival of the next frame in this manner:

DPM_ioctl(DPC_OBJDET_IOCTL__DYNAMIC_EXECUTE_RESULT_EXPORTED) -> DPC_ObjectDetection_ioctl -> DPC_ObjDet_reconfigSubFrame -> DPC_ObjDet_GenRangeWindow.

Regards,

Aayush

Hello, Aayush

I check the code.The flow as follow:

DPC_ObjDet_rangeConfig->DPC_ObjDet_MemPoolAlloc->DPC_ObjDet_GenRangeWindow

DPC_ObjDet_GenRangeWindow :valid range window data is generated;

 DPC_ObjDet_staticClutterConfig &&  DPC_ObjDet_CFARCAconfig alloc the begining scratchBuf address,not generate data;

DPC_ObjDet_dopplerConfig->DPC_ObjDet_MemPoolAlloc->DPC_ObjDet_GenDopplerWindow;

DPC_ObjDet_GenDopplerWindow:valid Doppler window data is generated,so the range window data is overwriting.

Is this a bug?

Please check it.

Thanks.

Bryany

Hi Bryant,

Please give me some time to discuss this with the wider team and get back to you. Since the HWA DPC works, it means this doesn't lead to a fault, but there must be some reasoning to reconcile this.

Regards,

Aayush

Hello, Aayush

I think  that the rangeproc windowBuffer is saved in HWA when execute DPC_ObjDet_rangeConfig .

Wait for the outcome of your discussion to see if my idea is correct.

Thanks.

Bryant

Hi Bryant,

You're right. DPC_ObjDet_rangeConfig->DPU_RangeProcHWA_config->HWA_configRam is the chain of calls used to copy the windowBuffer in scratch memory to HWA memory at appropriate locations to ensure both windows can be stored. Range windowBuffer gets copied to HWA RAM before it is overwritten in scratch by doppler windowBuffer.

Regards,

Aayush

Hello, Aayush:

In function DPC_ObjDet_rangeConfig,see as follow picture:

I think line 1405 should be : hwaCfg->hwaWinRamOffset += winGenLen;Becuse the var of  *windowOffset do not use anymore.

Please check it.

Thanks.

Bryant

Hi Bryant,

This is fine. In DPC_ObjDet_preStartConfig, &hwaWindowOffset pointer is passed to DPC_ObjDet_rangeConfig as windowOffset. hwaWindowOffset is being added to by the statement:

*windowOffset += winGenLen;

This modified value is later used in DPC_ObjDet_dopplerConfig to copy its windowBuffer to the appropriate HWA RAM location.

Regards,

Aayush

Hello, Aayush:

In HWA DPC, i can not find the variable of Twiddle.But it exists in the DSP DPC.

Does this variable also preexist in HWA? 

Thanks.

Bryant

Hi Bryant,

There is a twiddle factor look-up table in HWA in twiddle factor ROM.

From the HWA user guide:

"...twiddle factor look-up table(LUT). This LUT contains the (compressed) equivalent of the cos, sin values corresponding to the 16384 long sequence exp(j*2*pi*(0:16383)/16384)."

Regards,

Aayush

Hello, Aayush:

I find that every edma chanel will follow a shadow edma chanel,What does it do？

And when edma use in HWA will follow a HotSignature chanel,What does it do？

Thanks.

Bryant

What does it do

Hi Bryant,

The shadow link EDMA parameter set is used to reload the original EDMA parameter set for a particular channel once the transfer is complete. This is called linking, and is an EDMA specific detail. Please refer to the EDMA user guide to see how this is implemented and its use cases.

The hot signature channel is used to trigger the HWA. The signature channel copies a one-hot signature word to the DMA2ACCTRIG register to trigger a HWA parameter set. This is a way to trigger the HWA, and is a HWA specific implementation detail. Please refer to the HWA user guide for more details. 

The signature channel is configured to run after some other channel which copies data in/out of HWA RAM. This is accomplished by chaining of the EDMA channels, which is an EDMA specific feature. 

Regards,

Aayush

Hello, Aayush:

The hot signature channel and  signature channel are not the same things?

Second question:The loop is range->staticclutering->doppler->cafr->AoA,when first loop end,range is running again.Will the RANGE CONFIG be initialized again?Due to AoA set the HWA paramset,once range dpu runs again,whether to reset it?TWhat is the sequence of detailed initialization and execution loops?

Thanks.

Bryant

Hello, Aayush:

Immediately after the last question, I also have a question to add.

In file:///C:/ti/mmwave_sdk_03_04_00_03_1/packages/ti/datapath/dpc/dpu/aoaproc/docs/doxygen/html/index.html,as this picture as follow(Blue box marking):

Why doppler chirps are not 1,2,3,...,N but 1,4,..,N-2?

I think 2D-FFT should be done N chirps.This makes me confused.Can you explain it?

Thanks.

Bryant

Hi Bryant,

The hot signature channel is just called the signature channel. It copies a one-hot encoded vector.

Reconfiguration after the chain has run for a frame is done when the DPC_OBJDET_IOCTL__DYNAMIC_EXECUTE_RESULT_EXPORTED is received. 

In the last diagram, all chirps are involved in the 2D FFT. 2nd chirp is available in the TX2.

Regards,

Aayush 

Hello, Aayush:

In file:///C:/ti/mmwave_sdk_03_04_00_03_1/docs/mmwave_sdk_module_documentation.html,

Why the follow four DPU's radarcube is

• CFAR
• Doppler
• Range
• Static Clutter Removal

But 

• AoA 

radarcube will be as followed picture:

Where's the lost chirp?

Thanks.

Bryant