C6424 - McBsp problem

Hi Eran

It does look like the customer is getting impacted with the EDMA latency issues documented in the errata, given they see the failure go away at lower McBSP speed or higher CPU frequency (which means higher DMA frequency).

Does the failure happen in stand alone McBSP only operation or is there more concurrent traffic.

I am not sure if there is any other work around for this. The only other thing would be to transfer more bytes per sync event i.e. instead of 1 byte per sync event, do 4 bytes per sync event (32 bit word), but not sure if that is acceptable in this customer scenario.

Other typical recommendations still apply (which perhaps the customer is following , if this is seen in a system context)

1) Move out other competing buffers/accessess from internal memory to other memory like external memory

2) Make sure that the EDMA Q/TC servicing the McBSP traffic is programmed to higher master priority

3) If the issue is being caused by both McBSPs being put on the same Queue/TC, see if the issue is less severe if the events from 2 McBSPs were place on different Queue/TCs.

To address these type of issues next gen platforms like OMAPL138 incorporated a FIFO for McBSP.

Hope this helps.

Regards

Mukul

Note: I moved your question from the DM643x forum to c64x forum as DM6437 and C6424 is supported out of our team (SCDSP apps) and invariably this device family questions will get routed to us. Our team monitors the c64x single core forums.

Hello,

The steps suggested above didn't help in solving the issues.

The first suggestion isn't applicable for us, since the access time to these buffers by the core is crucial for our application and that's why they're located in the internal memory.

The second suggestion is what we're doing in our application.

The third suggestion didn't make any difference and we could still see the problem.

I have an update to my original problem: we DID see the problem also happening at 700 MHz CPU speed.

It seems that the problem is less severe if we use only a single McBSP.

We have to provide accurate answers to our customers as to the limitations depending on the CPU speed (400 MHz, 600 MHz, 625 MHz, 700 MHz), the BUS speed (2 MHz, 4 MHz, 8 MHz) and the number of used McBSPs. They MUST know how many TDM slots are available for usage and how they should spread them across the TDM interface.

Please see how we can get these limitations by your experts ASAP.

Thanks in advance,

Elad.

Elad,

I expect your issue is related to Advisory 1.3.11 DSP SDMA/IDMA: Unexpected Stalling and Potential Deadlock Condition When L2 Memory Configured as Non-cache (RAM).  The easiest workaround is to configure all of your L2 as cache. 

If you provide a bit more info on the usage of your internal RAM then I can tell you whether you're potentially affected by Advisory 1.3.11.  In particular, what are your L1D and L2 cache configurations?  What buffers do you have in L1 SRAM?  What buffers do you have in L2 SRAM?  Any Ethernet descriptors?

Brad

Hi Brad,

I'm sorry it took me so long to respond, but finally I got to it.

Our application uses L2 for cache and RAM. It's not possible for me to allocate all of L2 as cache as the outcome will be fatal to our application.

We use all of L1 as cache and as I said, L2 is partially used as cache.

We use the EDMA to copy the samples from the McBSP to buffers allocated in the L1D RAM only section (start address: 0x10f04000). We use Ethernet descriptors, but they're not in the L1 or L2 memory.

Regards,

Elad.

Hi Brad,

As much as I could see we have no memory movement using EDMA to L2 RAM.

We are using EDMA / QDMA to move data from / to L1D, but not from / to to L2 RAM.

In addition, as I wrote before:

"We have to provide accurate answers to our customers as to the limitations depending on the CPU speed (400 MHz, 600 MHz, 625 MHz, 700 MHz), the BUS speed (2 MHz, 4 MHz, 8 MHz) and the number of used McBSPs. They MUST know how many TDM slots are available for usage and how they should spread them across the TDM interface."

Regards,

Elad.

In my opinion there are two possible scenarios that could cause this issue:

1. Advisory 1.3.11 DSP SDMA/IDMA: Unexpected Stalling and Potential Deadlock Condition When L2 Memory Configured as Non-cache (RAM).
2. Usage Note 2.1.13 McBSP: Maximum Frame Frequency May Not Be Possible When Word Length is 8-Bits.

So it sounds like you've done some investigation into #1.  Did you investigate ALL master peripherals?  It's not sufficient only to look at EDMA.  You would need to look at EMAC, HPI, PCI too.  If any of those masters access L2 RAM (such as EMAC writing the packet payload into L2 RAM) then you would run into the issue.

For #2 this looks like a latency/bottleneck issue.  In order to better understand the scenario I recommend looking in the c6424 data manual at Figure 4-1 "System Interconnect Block Diagram".  In particular you can see the McBSPs down in the lower right corner of the diagram.  In order to write to the McBSP the EDMA TC has to go through SCR1, SCR3, and SCR8.  There's also latency from the time that McBSP signals for the EDMA to transfer data until the time where the EDMA channel controller submits the request to the Transfer Controller.

My intent here was to help you understand the underlying issue behind the usage note.  There's not a simple number that I can put down as the answer because there are many variables.

There's one other distinction that I think should be made with respect to the SCRs on c6424.  Referring back to Figure 4-1, only SCR 1 allows for multiple transactions to occur simultaneously so long as different targets are being accessed.  The other SCRs allow only one master/initiator to transfer to one slave/target at any given time. 

Example 1: EDMA3TC0 could write to the L1D memory of the DSP while simultaneously the DSP writes to DDR2.  This is possible because both accesses only go through SCR 1 and because there is no conflict with regard to the target (i.e. they're not competing for DDR2).

Example 2: DSP (MDMA) could write to EMIFA.  However, if EDMA3TC0 attempts to access McBSP0 there will be arbitration at SCR3 because only one access at a time is allowed through SCR3 (and all interconnects except SCR1).