C6747 Silicon Errata: Advisory 2.1.21

The first part of method 2 states "In cases where buffer access will not be shared between CPU and SDMA".  That's a critical part of Method 2, i.e. you must ensure that the buffer is not being accessed by both the CPU and the SDMA at the same time.  Let me give a concrete example.  Let's say we're collecting audio samples from the McBSP and storing them in buffers in L2 SRAM.  We setup EDMA to write them into L2 SRAM (this goes through the SDMA port of the megamodule).  Once the samples are collected then we get an EDMA interrupt and the CPU processes the data.  Furthermore we are double buffered.  This means the EDMA can be collecting samples in one buffer while the CPU is processing samples from the buffer.  The EDMA and CPU then swap ownership of their respective buffers each time the EDMA interrupt fires.  In this scenario we have met the requirement of buffer access not shared between CPU and SDMA because at any given time ONLY the CPU or ONLY the SDMA will access the buffer.

Now let's take it a step further.  There is a possibility that you might ACCIDENTALLY share the line in this scenario in the case where the cache lines have not been carefully aligned.  If for example each buffer was 50 bytes long and they were contiguous, then you would end up sharing a cache line between the buffers.  In this case you would be violating the first part about the buffer access not being shared between CPU and SDMA.  So in order to prevent that from happening it is required to align the buffers on 64 byte boundaries.

Thank you for your reply.

I can understand about your concrete example.

But , I'm afraid I still can't agree with this workaround for Advisory 2.1.21.

If this workaround is for Advisory 1.1.5, I can agree with you and this workaround.

                   #Advisory 1.1.5 is "Under Specific Conditions, SDMA Activity Can Corrupt the L1D Cache and L2 RAM"

I think the Advisory 2.1.21 is as follows.

First, precondition is

- L1D cache line 2 is associated with Line B on L2 SRAM.

- L 2D cache line is associated with Line E (on L3/External)

(- Line E and Line B is mapped to same "L1D Cache line 2.")

and then

When "Snoop write operation (line B)" and " Load operation from L2cache (line E)" is processed at the same time to the same L1D cache line(line2),

L1D cache line(line2) corruption event occurs.

So ,I don't think workaround has anything to do with Advisory 2.1.21.

If I perform to align CPU(L2SRAM)/SDMA(L3/External) buffer to 64byte boundaries,

there will be a risk to use on the same line in L1D cache because of different memory space (L2 and L3/Extenral).

Is my understanding wrong?

Excuse me for my bad English.

-Takao

I think you are right that my example was applicable to Advisory 1.1.5 and not to Advisory 2.1.21.  I apologize for the confusion.

I just read through this errata once more and I've come to a different understanding of what workaround 2 means.  In particular I was looking at this pseudo-code:

/** Pseudo code only **/
Uint8 *SDMA_BUFF, *CPU_BUFF;

/* 64-byte aligned allocation Option 1 */
SDMA_BUFF = malloc( (Int32) (( SDMA_BUFF_SIZE + 63)/64) * 64 );
CPU_BUFF = malloc( (Int32) ((CPU_BUFF_SIZE + 63)/64) * 64 );

Based on the pseudo-code it appears that 2 independent buffers have been assigned.  So I think this is actually saying that SDMA_BUFF would only be accessed by the SDMA and the CPU_BUFF would only be accessed by the CPU.  In other words, we're going further than simply having "ownership" of a buffer at any given time, i.e. ownership does not ping-pong but rather is permanent.  This would avoid the errata because if the CPU never reads from SDMA_BUFF (ever!) then lines A and B would never be cached in L1D.

That said, this doesn't seem like a very practical workaround for most cases since typically the buffer needs to be shared between CPU and SDMA at some point.  If you want to actually share the buffer (which is more typical) then you would look at Method 3 where a writeback-invalidate is initiated by the CPU prior to any EDMA/SDMA access of the buffer, or you can use method 1 for a simple change of compiler options.

Hi

Thank you for the reply. That means a lot to me.

Excuse me, please tell me more.

In the first place, The condition of this problem isn't shared between CPU and SDMA memory.

I understand

it is only the following condition that this problem occurs.

- CPU Access buffer is allocated in L3/External (=> read Line in L1D cache)

- SDMA Access buffer is allocated in L2RAM (=>snoop write in L1D cache)

Therefore, I think this Method 2 and 3 have nothing to do with Advisory 2.1.21 and these shouldn't be described in workaround for Advisory 2.1.21.

What do you think about my opinion?

-Takao

7840.adivisory2-1-21.pptx

Takao said:

- SDMA Access buffer is allocated in L2RAM (=>snoop write in L1D cache)

Let me expand a little bit on the meaning of "snoop write" just to make sure we are both on the same page.  A snoop write is a mechanism built into the cache architecture for maintaining cache coherence between L1D and L2 SRAM.  Let me give an example of how it works.  Let's say we have a buffer in L2 SRAM.  The CPU reads from that buffer which causes a cache line to be allocated in L1D.  Now let's say an external master such as EDMA writes to that buffer in L2 SRAM.  A snoop write will occur such that the data gets updated in L1D which avoids any cache coherence issues.

Takao said:

Therefore, I think this Method 2 and 3 have nothing to do with Advisory 2.1.21 and these shouldn't be described in workaround for Advisory 2.1.21.

What do you think about my opinion?

Notice the line that I put in red font above, i.e. the CPU must read from a buffer for it to be cached in order for a snoop write to occur.  Both methods are proper workarounds.  Method 2 works by completely avoiding any CPU reads to the buffer being written by EDMA.  Therefore a snoop write will never occur and the errata is avoided.  Method 3 works in a similar manner.  By performing a writeback-invalidate the buffer is no longer cached in L1D and so a snoop write will not occur.