Using combined In-Out-Buffer on EVE/VCOP

Hi Tobias,

    As you are using one of our example so I am assuming you are using alias memory view? So in this case  you will have 16KB of IBUFH and 16KB of IBUFL (Total of 32KB for input and ouput). From the error it is looking like inside your kernel you are going beyond these two buffers and accessing the restricted region. We will have to look into the kernel and to comment more on this.

Regards,

Anshu

Hey Anshu,

Yes, I am using alias memory view. The kernel is meant to process two 10 bit input values (which are stored in a 16 bit buffer)  and merge them to one 20 bit value (stored in a 32 bit buffer). That means we have two times as much inputs as outputs. This is the equivalent C-Code:

	UINT16 *pFrameAdd16 = (UINT16*)ipcMsg->frameAddr;
	UINT32 *pFrameAdd32 = (UINT32*)ipcMsg->frameAddr;
	UINT32 numPixel = ipcMsg->vPixel * ipcMsg->hPixel;

	for( UINT32 i = 0; i < numPixel; i++ )
	{
		pFrameAdd32[i] = (UINT32)pFrameAdd16[i * 2] << 10 | (UINT32)pFrameAdd16[i * 2 + 1]  ;
	}

The kernel code I came up with looks like this:

#define ELEMSZ           sizeof(*in1_ptr)
#define VECTORSZ        (VCOP_SIMD_WIDTH*ELEMSZ)
#define SHIFT (10)

void buffer_merge
(
   __vptr_uint16  in1_ptr,
   __vptr_uint32  optr, 
   unsigned short width,
   unsigned short height
)
{
   __vector Vin1;
   __vector Vin2; 
   __vector Vout; 
   __vector Vshift;
   __vector Vin1s;

   Vshift = SHIFT;

   for (int I1 = 0; I1 < height; I1++)
   {
       for (int I2 = 0; I2 < width/VCOP_SIMD_WIDTH; I2++)
       {
           __agen Addr_out;
      
           Addr_out = I1*width*ELEMSZ*2 + I2*VECTORSZ*2;

           (Vin1,Vin2) = in1_ptr[Addr_out].deinterleave();
           Vin1s	= (Vin1 << Vshift);
           Vout     = Vin1s | Vin2;
           optr[Addr_out] = Vout;
       }
   }
}

In Simulatior error messages appear, but the overall output values are OK. As mentioned before, on actual hardware the app gets stuck in a loop.
The Screenshot below shows end of combined memory IBUFL/IBUFH after VCOP has processed one 32kB block.
It writes to addresses 0x40050000 to 0x40057FFD.

Regards,
Tobias

Hi Pramod,


 __vptr_uint16  in1_ptr: pointer to VCOP buf, in this case (uint16_t*) 0x40050000

__vptr_uint32 optr: pointer to same VCOP buff, since I want to use whole VCOP memory as one single In/Out buffer, so here it is (uint32_t*) 0x40050000

unsigned short width: number of input pixels in a row, here 16384

unsigned short height: in this case 1 since I want to process subsequent data, not data in a 2D way

Regards,

Tobias

Hey Anshu,

thank you a lot for your tipps on my kernel. You were right regarding the width I used with my initial kernel code. It was too large, so that on the last VCOP cycle the memory boundaries were exceeded. I fixed that and now my application doesnt get stuck in a loop or throws errors anymore.

I also tried your improvement to my kernel and with a few changes (e.g. changing VCOP_SIMD_WIDTH to 16) it worked nicely.

As mentioned my application now always finishes without code related errors, however I encountered another problem: Whenever I choose an VCOP buffer size bigger or equal than 16kB at some point my output buffer contains wrong values. These values always appear from a changing positiion everytime I restart the app and aren't even close to the expected values.

The strange thing is that these errors/wrong values only appear when I start my app without any breakpoints (directly on EVE/TDA3x). If I run it with breakpoints and debug through it, all values are ok. In EVE simulator the output also seems fine (with and without breakpoints in the code). Are there any runtime problems I have to  pay attention to? Or could this be an EDMA error?

The attached image shows the wrong values. Expected values should always be one higher than the previous one, like they are until [2098039].

Again, thanks a lot and Regards!

Tobias

Hi Tobias,

    This is looking like  your DMA is overwriting some portion of the output data. As mentioned earlier in this case as you must be writing the output data at the same time as you are reading new data to the same memory location, which might be causing this issue. Have you made sure in your code that you are first finishing the writing of output data before you read the new data? Can you explicitly put wait after each EDMA and see if you are still seeing the issue?

Regards,

Anshu