Specifications

Silicon Updates
SPRZ293A—November 2009 TMS320C6457 Fixed-Point Digital Signal Processor Silicon Errata 23
www.ti.com
Submit Documentation Feedback Silicon Revisions 1.0, 1.1, 1.2, 1.3, 1.4 .
Advisory 8 DMA Corruption of L2 Ram Data
Revision(s) Affected: 1.2, 1.1, 1.0
Details: Under a specific set of circumstances, a snoop-write updates an unintended L2 RAM
location. This is a result of a corrupted L1D cache writeback, and can lead directly to
program misbehavior. If that line is then modified by CPU accesses, a subsequent
victim writeback from L1D could commit this corrupted line to lower levels of
memory. Three key requirements for this bug are:
•The DMA reads or writes to buffers in L2 SRAM.
– This must be cached and modified in L1D (read and written by the CPU).
• The CPU reads from any L2 or external, cacheable address.
• A second DMA write to the same cache line address (within 64B) in L2 RAM that
the CPU is reading from.
Note—For Information on L1D cache coherence protocol, see section 3.3.6,
Cache Coherence Protocol, in the C64x+ DSP Megamodule Reference Guide
(SPRU871).
Note—The DMA in the following description refers to all non-CPU
requestors. This includes IDMA, EDMA, and any other master in the system.
Under the specific set of circumstances listed below, a snoop-write results in a data
corruption in L2 RAM. This bug exists only when L1D evicts a dirty line from its cache
while allocating a new line to the same set/way. Both lines must be from L2 SRAM in
either UMAP0 or UMAP1 (For the UMAP0 and UMAP1 allocation on the C6457
device, see ‘‘Appendix C—UMAP0 and UMAP1 Addresses Ranges’’). The bug occurs
when there is a DMA to L2 for the allocated (clean) line and a DMA to or from the
victim (dirty) line. The L2 sends the DMA request as a snoop-read or -write to the L1D
cache after it allocates the new line. When the bug occurs, the snoop-write to the
allocated line corrupts the line being evicted instead. The L2 writes this corrupted
victim back to L2 SRAM.
The prerequisite before the window where the bug occurs is:
• The CPU reads an L2 location and has modified (written to) the same cache line
location before the window where the bug occurs. That means that it is not
necessarily the same exact address that is written to, but within the same 64B
cache line.
– Because of this, a 64B cache line is allocated and dirty in L1D (referred to here
as Cache Line A).