Specifications

32 TMS320C6457 Fixed-Point Digital Signal Processor Silicon Errata SPRZ293A—November 2009
Silicon Updates
www.ti.com
Silicon Revisions 1.0, 1.1, 1.2, 1.3, 1.4 Submit Documentation Feedback
SDMA/IDMA stalling and any system impact is most likely in systems with excessive
context switching, L1/L2 cache miss/victim traffic, and heavily loaded EMIF.
Use the following steps to determine if SDMA/IDMA stalling is the cause of real-time
deadline misses for existing applications. Situations where real-time deadlines may be
missed include loss of McBSP samples and low peripheral throughput.
1. Determine if the transfer missing the real-time deadline is accessing L2 or L1D
memory. If not, then SDMA/IDMA stalling is not the source of the real-time
deadline miss.
2. Identify all SDMA transfers to/from L2 memory (e.g., EDMA transfer to/from L2
from/to a McBSP or from/to TCP). If there are no SDMA transfers going to L2,
then SDMA/IDMA stalling is not the source of the problem.
3. Redirect all SDMA transfers to L2 memory to other memories using one of the
following methods:
– Temporarily transfer all the L2 SDMA transfers to L1D SRAM.
– If not all L2 SDMA transfers can be moved to L1D memory, temporarily
direct some of the transfers to DDR memory and keep the rest in L1D
memory. There should be no L2 SDMA transfers.
– If neither of the above approaches are possible, move the transfer with the
real-time deadline to the EMAC CPPI RAM. If the EMAC CPPI RAM is not
big enough, a two-step mechanism can be used to page a small working buffer
defined in the EMAC CPPI RAM into a bigger buffer in L2 SRAM. The
EDMA module can be setup to automate this double buffering scheme
without CPU intervention for moving data from the EMAC CPPI RAM.
Some throughput degradation is expected when the buffers are moved to the
EMAC CPPI RAM.
Note—The EMAC CPPI RAM memory is word-addressable only, and,
therefore, must be accessed using an EDMA index of 4 bytes.
If real-time deadlines are still missed after implementing any of the options in Step 3,
then SDMA/IDMA stalling is likely not the cause of the problem. If real-time deadline
misses are solved using any of the options in Step 3, then SDMA/IDMA stalling is likely
the source of the problem.
An extreme manifestation of the IDMA/SDMA stall bug is the C64x+ MDMA-SDMA
deadlock that requires a device reset or power-on reset in order for the system to
recover. The following summarizes the deadlock conditions:
• Master(s) on a single main MSCR port write to the C64x+'s SDMA followed by a
write to slaveX.
• The C64x+ issues victim traffic or a non-cacheable write to slaveX.
• Any one of the following:
– A write data path pipelined in main MSCR between master(s) and a C64x+
– SDMA
– A bridge exists between master(s) and the main MSCR
– Master(s) are able to issue a command to slaveX concurrent with the write to
the C64x+'s SDMA.