Specifications

Silicon Updates
SPRZ293A—November 2009 TMS320C6457 Fixed-Point Digital Signal Processor Silicon Errata 17
www.ti.com
Submit Documentation Feedback Silicon Revisions 1.0, 1.1, 1.2, 1.3, 1.4 .
Advisory 7 DMA Corruption of External Data Buffer Issue
Revision(s) Affected: 1.3, 1.2, 1.1, 1.0
Details: Under a specific set of circumstances, an L1D snoop-write will update an unintended
L1D cache line. This leads to a corrupted line in L1D, and can lead directly to program
misbehavior. If the corrupted line is then modified by a CPU write accesses, a
subsequent victim writeback from L1D could commit the corrupted line to lower levels
of memory. Two key requirements for this bug are:
• DMA writes to buffers in UMAP1 only
– This must be cached and unmodified in L1D (read by CPU but not yet
written to)
– The L2 memory is typically shared across the two unified memory access
ports, UMAP0 and UMAP1. This bug occurs only if the buffer is located in
UMAP1. For the UMAP1 allocation on the C6457 device, see Table 6.
• CPU reads from external, cacheable address
– UMAP0 and UMAP1 are the two ports on the C64x+ Megamodule used to
connect the L2 Memory controller and the physical RAMs. For the UMAP1
allocation on the C6457 device, see ‘‘Appendix C—UMAP0 and UMAP1
Addresses Ranges’’.
– For information on L1D cache coherence protocol, see section 3.3.6, Cache
Coherence Protocol, in the C64x+ DSP Megamodule Reference Guide
(literature number SPRU871).
– 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 updates an L1D
cache line other than the one intended. This leads to a corrupted line in L1D.
Corruption happens only when the buffer in UMAP1 is cached in L1D while the CPU
is consuming external, cacheable data. The prerequisite before the window where the
bug occurs is:
• The CPU reads an L2 location in UMAP1 and has not modified (written) to the
same location before the window where the bug occurs.
– Because of this, a 64B cache line is allocated clean in L1D (referred to here as
Cache Line A).
The following steps must all occur concurrently to see the issue (note that the
concurrency is within the cache subsystem, so events visible at the CPU or the DMA
are not occurring during the same exact cycle):
1. The L1D is currently processing a snoop request or some other request that
prevents it from accepting new snoops. This could have been caused by any of the
following that is still being processed from previous actions:
– DMA read/write
– L1D read/invalidate
– L1D read + victim
2. The DMA writes to Cache Line A, mentioned in the prerequisite above. This
means that it is not necessarily the same exact address, but must be within the
same 64B cache line.
– As a result, a snoop-write request is generated but it is blocked because the
L1D is still busy with Step 1.