TMS320C6472_16_技术文档

TMS320C6472

Digital Signal Processor

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Errata

Literature Number: SPRZ300

October 2009

2

SPRZ300–October 2009

Submit Documentation Feedback

1

2

Introduction ........................................................................................................................ 5

1.1

1.2

1.3

Device and Development Support Tool Nomenclature ............................................................. 5

Package Symbolization and Revision Identification ................................................................ 6

Silicon Updates .......................................................................................................... 8

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

.......................................................................................................................................... 9

2.1

Silicon Revision 2.0 Usage Notes ..................................................................................... 9

2.1.1

2.1.2

2.1.3

Device: Heatsink/Airflow Recommended to Lower Case Temperature .............................. 9

EMAC: Gigabit Mode Cannot Be Used With CPU Running at Speeds Lower Than 375 MHz .... 9

DDR2 EMIF: Delay Before CKE Goes High With Different Combinations of REFRESH_RATE and

DDR Clock .................................................................................................... 9

EMIF Read Incurs High Latency Under Certain Conditions .......................................... 10

2.1.4

2.2

Silicon Revision 2.0 Known Design Exceptions to Functional Specifications .................................. 11

3

4

5

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

........................................................................................................................................ 36

3.1

Silicon Revision 1.2 Usage Notes ................................................................................... 36

Silicon Revision 1.2 Known Design Exceptions to Functional Specifications .................................. 36

3.2

Silicon Revision 1.1 Usage Notes and Known Design Exceptions to Functional Specifications

........................................................................................................................................ 54

4.1

Silicon Revision 1.1 Usage Notes ................................................................................... 54

Silicon Revision 1.1 Known Design Exceptions to Functional Specifications .................................. 54

4.2

Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications

........................................................................................................................................ 56

5.1

Silicon Revision 1.0 Usage Notes ................................................................................... 56

Silicon Revision 1.0 Known Design Exceptions to Functional Specifications .................................. 56

5.2

3

SPRZ300–October 2009

Table of Contents

Submit Documentation Feedback

www.ti.com

List of Figures

1

Lot Trace Code Examples for TMS320C6472 (ZTZ Package) .......................................................

6

2

L1D Cache Address Mapping............................................................................................ 21

Cache Line Operations Flow............................................................................................. 22

L1D Cache Address Mapping............................................................................................ 29

Sequence of Events....................................................................................................... 30

Decision Tree .............................................................................................................. 31

IDMA, SDMA, and MDMA Paths ........................................................................................ 38

Data Pipelined SCR....................................................................................................... 40

Daisy-Chain Example ..................................................................................................... 57

Expected Customer Implementation .................................................................................... 59

Requested Implementation Change .................................................................................... 59

Interim Workaround for Silicon Revision 1.0........................................................................... 60

Bitmap Memory Address Translation ................................................................................... 63

Bitmap Memory Corruption Example ................................................................................... 63

3

4

5

6

7

8

9

10

11

12

13

14

List of Tables

1

Lot Trace Codes ............................................................................................................

Silicon Revision Registers .................................................................................................

Megamodule Revision Registers..........................................................................................

Silicon Revisions 2.0, 1.2, 1.1, and 1.0 Updates .......................................................................

200-μs Delay Calculated Values..........................................................................................

6

7

8

9

2

3

4

5

6

7.8125-μs Interval Calculated Values................................................................................... 10

Silicon Revision 2.0 Advisory List ....................................................................................... 11

C6472 Default Master Priorities ......................................................................................... 19

C6472 UMAP1 Allocation ................................................................................................ 20

Value of X for L1D Cache ................................................................................................ 21

Value of X for L1D Cache ................................................................................................ 29

Expected vs. Actual Data Values ....................................................................................... 30

Silicon Revision 1.2 Advisory List ....................................................................................... 36

C6472 Default Master Priorities ......................................................................................... 53

Silicon Revision 1.1 Advisory List ....................................................................................... 54

Silicon Revision 1.0 Advisory List ....................................................................................... 56

I2C Parameter Table for EMAC Boot................................................................................... 58

7

8

9

10

11

12

13

14

15

16

17

4

List of Figures

SPRZ300–October 2009

Submit Documentation Feedback

Silicon Errata

SPRZ300–October 2009

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

1

Introduction

This document describes the silicon updates to the functional specifications for the TMS320C6472 digital

signal processor; see the device-specific data manual, TMS320C6472 Fixed-Point Digital Signal

Processor (literature number SPRS612).

1.1 Device and Development Support Tool Nomenclature

To designate the stages in the product development cycle, TI assigns prefixes to the part numbers of all

DSP devices and support tools. Each DSP commercial family member has one of three prefixes: TMX,

TMP, or TMS (e.g., TMS320C6472ZTZ). Texas Instruments recommends one of two possible prefix

designators for its support tools: TMDX and TMDS. These prefixes represent evolutionary stages of

product development from engineering prototypes (TMX/TMDX) through fully qualified production

devices/tools (TMS/TMDS).

Device development evolutionary flow:

TMX

TMP

TMS

Experimental device that is not necessarily representative of the final device's electrical

specifications

Final silicon die that conforms to the device's electrical specifications but has not

completed quality and reliability verification

Fully-qualified production device

Support tool development evolutionary flow:

TMDX

Development-support product that has not yet completed Texas Instruments internal

qualification testing

TMDS

Fully-qualified development-support product

TMX and TMP devices and TMDX development-support tools are shipped against the following

disclaimer:

"Developmental product is intended for internal evaluation purposes."

TMS devices and TMDS development-support tools have been characterized fully, and the quality and

reliability of the device have been demonstrated fully. TI's standard warranty applies.

Predictions show that prototype devices (TMX or TMP) have a greater failure rate than the standard

production devices. Texas Instruments recommends that these devices not be used in any production

system because their expected end-use failure rate still is undefined. Only qualified production devices are

to be used.

5

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Introduction

www.ti.com

1.2 Package Symbolization and Revision Identification

The device revision can be determined by the lot trace code marked on the top of the package. The

location of the lot trace code for the ZTZ package is shown in Figure 1. Figure 1 also shows an example

of C6472 package symbolization.

DSP

TMS320C6472ZTZ

#xx−#######

Lot Trace Code

Figure 1. Lot Trace Code Examples for TMS320C6472 (ZTZ Package)

Silicon revision correlates to the lot trace code marked on the package. This code is of the format

#xx-#######. If xx is "10", then the silicon is revision 1.0. Table 1 lists the silicon revisions associated with

each lot trace code for the C6472 devices.

Table 1. Lot Trace Codes

LOT TRACE CODE (xx)

SILICON REVISION

COMMENTS

Silicon revison 2.0

20

12

11

10

2.0

1.2

1.1

1.0

Silicon revision 1.2

Silicon revision 1.1

Initial silicon revision

The C6472 device contains multiple read-only register fields that report revision values. The Silicon

Revision ID Register and the JTAG ID Register are chip-level revision registers. The Silicon Revision ID

Register provides the silicon revision in explicit fields. The silicon revision can be read directly from the

MAJOR REVISION and MINOR REVISION fields within this register. The Silicon Revision ID Register is at

address location 02A8 070Ch. Table 2 shows the contents of the Silicon Revision ID Register for each

silicon revision. More details on the Silicon Revision ID Register can be found in the TMS320C6472

Fixed-Point Digital Signal Processor (literature number SPRS612).

The JTAD ID Register provides a VARIANT field that is associated with the silicon revision. The JTAG ID

Register is at address location 02A8 0008h. Only the VARIANT field changes in this register. Table 2

shows the contents of the JTAG ID Register and the VARIANT field for each silicon revision. More details

on the JTAG ID Register can be found in the TMS320C6472 Fixed-Point Digital Signal Processor

(literature number SPRS612).

6

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Introduction

Table 2. Silicon Revision Registers

SILICON

REVISION

SILICON REVISION ID REGISTER

(02A8 070Ch)

JTAG ID REGISTER VALUE

(02A8 0008h)

2.0

1.2

1.1

1.0

0020 0091h

2009 102Fh

MAJOR REVISION (bits 23:20): 2h

MINOR REVISION (bits 19:16): 0h

0012 0091h

VARIANT (bits 31:28): 2h

1009 102Fh

MAJOR REVISION (bits 23:20): 1h

MINOR REVISION (bits 19:16): 2h

0011 0091h

VARIANT (bits 31:28): 1h

0009 102Fh

MAJOR REVISION (bits 23:20): 1h

MINOR REVISION (bits 19:16): 1h

0010 0091h

VARIANT (bits 31:28): 0h

0009 102Fh

MAJOR REVISION (bits 23:20): 1h

MINOR REVISION (bits 19:16): 0h

VARIANT (bits 31:28): 0h

The 64x+ Megamodule contains a revision register and the 64x+ CPU core within the Megamodule also

has a revision field in a status register. The Megamodule Revision ID Register provides the Megamodule

revision in explicit fields. The Megamodule revision information can be read directly from the VERSION

and REVISION fields within this register. The Megamodule Revision ID Register is at local address

location 0181 2000h. Table 3 shows the contents of the Megamodule Revision ID Register for each silicon

revision. More details on the Megamodule Revision ID Register can be found in the TMS320C6472

Fixed-Point Digital Signal Processor (literature number SPRS612).

The Control Status Register within the 64x+ CPU core provides CPU Revision fields that are associated

with the silicon revision. The Control Status Resister (CSR) is part of the CPU's control register file. Only

the CPU ID and REVISION ID fields in the CSR reflect CPU revision information. Table 3 shows the

contents of the CPU ID and the REVISION ID fields in the CSR register for each silicon revision. More

details on the CSR register can be found in the TMS320C64x/C64x+ DSP CPU and Instruction Set

Reference Guide (literature number SPRU732).

Table 3. Megamodule Revision Registers

SILICON

REVISION

MEGAMODULE REVISION ID

REGISTER (0181 2000h)

CPU REVISION

(CPU CSR Register)

2.0

1.2

1.1

1.0

0001 0004h

CPU ID (bits 31:24): 10h

VERSION (bits 31:16): 0001h

REVISION (bits 15:0): 0004h

0001 0003h

REVISION ID (bits 23:16): 00h

CPU ID (bits 31:24): 10h

VERSION (bits 31:16): 0001h

REVISION (bits 15:0): 0003h

0001 0003h

REVISION ID (bits 23:16): 00h

CPU ID (bits 31:24): 10h

VERSION (bits 31:16): 0001h

REVISION (bits 15:0): 0003h

0001 0003h

REVISION ID (bits 23:16): 00h

CPU ID (bits 31:24): 10h

VERSION (bits 31:16): 0001h

REVISION (bits 15:0): 0003h

REVISION ID (bits 23:16): 00h

7

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Introduction

www.ti.com

1.3 Silicon Updates

Table 4 lists the silicon updates applicable to each silicon revision. For details on each advisory, see

Section 2.2, Section 3.2, Section 4.2, and Section 5.2 or click on the link below.

Advisories are numbered in the order in which they were added to this document. If the design exceptions

are still applicable, the advisories move up to the latest silicon revision section. If the design exceptions

are no longer applicable or if the information has been documented elsewhere, those advisories are

removed. Therefore, advisory numbering may not be sequential.

Table 4. Silicon Revisions 2.0, 1.2, 1.1, and 1.0 Updates

APPLIES TO SILICON REVISON

SILICON UPDATE ADVISORY

SEE

2.0

1.2

1.1

1.0

SRIO: Packet-Forwarding NREAD Operations Larger

Than 16 Bytes Fail

X

Advisory 1

RGMII EMAC: Boot Start-Up Issue

X

Advisory 2

Advisory 3

Advisory 4

DDR2 EMIF: Clock Synchronization Issue

TSIP: Receive Channel 4 Bitmap Corruption Issue

Device Configuration: HOUT is Not Generated When HPI

is Disabled

X

Advisory 5

DSP SDMA/IDMA: Unexpected Stalling of SDMA/IDMA

Access to L2 SRAM

X

Advisory 6

Advisory 7

Advisory 8

Potential SerDes Clocking Issue

Potential Insertion or Deletion of 2 Bits in SerDes Data

Stream

I2C Slave Boot Does Not Work

X

Advisory 9

Advisory 10

Advisory 11

Atomic Operations Fail to Complete

X

EMU: Emulation Access Can Corrupt CPU Operation

X

PMC: Local Reset (lreset) Followed By Block Invalidate

Hangs

X

Advisory 12

Advisory 13

Advisory 14

PMC: L1P Cache Not Invalidated During lreset

UMC: L2MPFAR Fails to Log CPU Protection Faults

Under Certain Conditions

CPU: Back-to-Back SPLOOPs With Interrupts Can

Cause Incorrect Operation on C64x+ CPU

X

Advisory 16

Advisory 17

CPU: C64x+ CPU Incorrectly Generates False

Exceptions for Multiple Writes

PrivID For Non-CPU Masters Is Same as GEM0 CPU

UTOPIA Lock-Up Issue

X

Advisory 18

Advisory 19

Advisory 20

Advisory 21

Advisory 22

DDR2 EMIF Buffers Not Totally Compensated by Default

SRIO Port 0 Reset Affects Other Ports

X

SRIO OUTBOUND_ACKID Field Not Read Correctly

DMA Access to L2 SRAM May Stall When the DMA Has

Lower Priority Than the CPU

X

Advisory 23

Advisory 24

DMA Access to L2 SRAM May Stall When the DMA and

the CPU Command Priority is Equal

X

DMA Corruption of External Data Buffer

DMA Corruption of L2 RAM Data

X

Advisory 25

Advisory 26

8

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

2

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional

Specifications

2.1 Silicon Revision 2.0 Usage Notes

Usage Notes highlight and describe particular situations where the device's behavior may not match

presumed or documented behavior. This may include behaviors that affect device performance or

functional correctness. These notes will be incorporated into future documentation updates for the device

(such as the device-specific data sheet), and the behaviors they describe will not be altered in future

silicon revisions.

2.1.1

Device: Heatsink/Airflow Recommended to Lower Case Temperature

It is strongly recommended that users complete system-level thermal analysis to account for details of

heatsink requirements, airflow, and other factors in order to achieve the case temperature specification of

85°C. The latest power data for the TMS320C6472 device indicates that static power is a significant

contributor to overall power. Since static power varies with case temperature and voltage, a lower case

temperature can greatly impact the overall power consumption. Therefore, the use of a heatsink to lower

the case temperature is an effective way to lower power consumption and help maintain the device at an

operating temperature within datasheet specifications.

2.1.2

EMAC: Gigabit Mode Cannot Be Used With CPU Running at Speeds Lower Than 375 MHz

The EMAC internal bus frequency must be greater than or equal to the I/O bus frequency. The EMAC

internal bus is clocked by SYSCLK7 of the PLL1 controller, which has a frequency equal to the CPU

frequency divided by 3. The I/O bus frequency of the EMAC is determined by the bit rate being used: 1.25

MHz for 10 Mbps, 12.5 MHz for 100 Mbps, and 125 MHz for 1000 Mbps. This restriction applies whether

RGMII or GMII mode is being used.

Note that if the CPU speed is less than 375 MHz, the gigabit mode of the EMAC (1000 Mbps) cannot be

used since the SYSCLK7 frequency will be less than 125 MHz.

2.1.3

DDR2 EMIF: Delay Before CKE Goes High With Different Combinations of REFRESH_RATE and

DDR Clock

The SDRAM refresh control register (SDRFC) contains a count value that is used for two purposes. At

power up, it is used to control the delay before CKE goes high. Later, it is used to control the time

between refreshes. The DDR2 JEDEC specification requires a 200 μs delay before CKE goes high during

initialization. The calculation of the delay before CKE goes high involves the following: The default value

for REFRESH_RATE is 0x1388 at POR.

If the DDR clock period is set at 3.75 ns, the delay would be 16 * (0x1388) / 266.666 = 300 μs. Users

have to make sure that any time when the DDR2 is enabled, the delay before CKE goes high with

different combinations of REFRESH_RATE and DDR clock is always longer than 200 μs. Table 5 lists a

few typical calculated values (200-μs delay).

Table 5. 200-μs Delay Calculated Values

CLOCK PERIOD

3.75 ns

REFRESH_RATE

0xD04

5 ns

0x9C4

8 ns

0x61A

During normal operation, the DDR memories require a refresh cycle at an average interval of 7.8125 μs

(MAX). The calculation of RERESH_RATE involves the following:

REFRESH_RATE = DDR2CLKOUT frequency × memory refresh period

If the DDR clock period is set at 3.75 ns, the RERESH_RATE would be:

REFRESH_RATE = 266.666 MHz × 7.8125 μs = 2082 = 0x822.

9

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Table 6 lists a few typical calculated values (an average interval of 7.8125 μs).

Table 6. 7.8125-μs Interval Calculated Values

CLOCK PERIOD

3.75 ns

REFRESH_RATE

0x822

5 ns

0x61A

8 ns

0x3D0

If the DDR2 needs to be put into self-refresh mode or power-down mode, users need to write a new value

to the REFRESH_RATE field of the SDRFC register to guarantee the 200-μs delay of CKE during

power-up or self-refresh mode exit.

2.1.4

EMIF Read Incurs High Latency Under Certain Conditions

Reads can incur higher than expected latency under certain conditions even though they are higher

priority than writes if there are continuous sequences of back-to-back single writes.

A DDR2 EMIF read with high priority could incur high latency under the following conditions:

•

Continuous back-to-back single writes are issued to the DDR2 EMIF at an interval of t_RP+ t_RCD+ t_WR.

While the high-priority read is waiting for t_WTRto expire, the t_RASexpires first, this causes the low-priority

request to precharge the bank. The proper operation is that the low-priority request should not have

issued a precharge if a high-priority request is still pending for that bank.

•

A few other read requests from different masters arrive for the same bank at a particular timing offset.

t_RASis smaller than t_WTR+ 4 + CasLatency - 1.

The above conditions result in the following behaviors:

•

Since t_RASexpires before t_WTR, the low-priority request to precharge the bank is performed before a

read can be fired.

•

After t_RPexpires, the bank is re-activated due to the high-priority read.

If a write comes in on the cycle just after the t_RCDexpires, it will go through this loop again. If more

single-word writes arrive just after the t_RCDexpires, this keeps the high-priority read from happening

until the pr_old_count expires.

•

Since only single word writes are executed, the expiration of the pr_old_count for the high-priority read

could be delayed by a factor of (t_RP+ t_RCD+ t_WR) / 2, in clock cycles. Normally, the pr_old_count of 255

impacts latency by (pr_old_count * clk_period * 2), worst case.

This issue has only been observed through an internal test, it appears to have a very low probability of

affecting existing designs.

Increasing the programmed t_RASvalue by a couple of clock cycles and programming a lower value of

pr_old_count could eliminate or reduce the latency. The pr_old_count should not be reduced to an

extreme value since it could dramatically impact system performance. For example, pr_old_count = 0 can

reduce throughput by about 20%.

10

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

2.2 Silicon Revision 2.0 Known Design Exceptions to Functional Specifications

lists the silicon revision 1.2 known design exceptions to functional specifications. Advisories are numbered

in the order in which they were added to this document. If the design exceptions are still applicable, the

advisories move up to the latest silicon revision section. If the design exceptions are no longer applicable

or if the information has been documented elsewhere, those advisories are removed. Therefore, advisory

numbering may not be sequential.

Table 7. Silicon Revision 2.0 Advisory List

Title

Advisory

Advisory 11

Advisory 16

Advisory 17

Advisory 20

Advisory 21

Advisory 22

Advisory 24

Advisory 25

Advisory 26

EMU: Emulation Access Can Corrupt CPU Operation

CPU: Back-to-Back SPLOOPs With Interrupts Can Cause Incorrect Operation on C64x+ CPU

CPU: C64x+ CPU Incorrectly Generates False Exceptions for Multiple Writes

DDR2 EMIF Buffers Not Totally Compensated by Default

SRIO Port 0 Reset Affects Other Ports

SRIO OUTBOUND_ACKID Field Not Read Correctly

DMA Access to L2 SRAM May Stall When the DMA and the CPU Command Priority is Equal

DMA Corruption of External Data Buffer

DMA Corruption of L2 RAM Data

11

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 11

EMU: Emulation Access Can Corrupt CPU Operation

Revision(s) Affected:

Details:

2.0, 1.2, 1.1, 1.0

When debug software issues a low-priority emulation data interface (EDI) access to

control register file registers concurrently with the CPU executing the compact instruction

MVC R, ILC, there is a 1-cycle window that can cause the EMU access to take place

and the assembly code MVC R, ILC to get dropped. The non-compact form of the MVC

R, ILC instruction does not have the problem.

Workaround:

There is no workaround for this advisory.

Debug software generally performs low-priority accesses only when you first start up

CCStudio or run in real-time mode.

Since the MVC R, ILC instruction is not a common instruction and there is only a 1-clock

cycle window, the likelihood of encountering this bug is small.

12

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

Advisory 16

CPU: Back-to-Back SPLOOPs With Interrupts Can Cause Incorrect Operation on

C64x+ CPU

Revision(s) Affected:

Details:

2.0, 1.2, 1.1, 1.0

Back-to-back software pipeline loops (SPLOOPs) with interrupts can cause incorrect

operation on the C64x+ CPU. This bug occurs when the first SPLOOP is interrupted and

there are less than two execute packets between the SPKERNEL of the first SPLOOP

block (SPKERNEL instruction marks the end of the first SPLOOP block) and the

SPLOOP instruction of the second SPLOOP block (SPLOOP instruction marks the

beginning of the second SPLOOP block). The first SPLOOP block terminates abruptly

(i.e., without completing the loop, even though the termination condition is false). The

failure mechanism can be seen as a hang or by the first SPLOOP block draining for the

interrupt and starting the second SPLOOP block without taking the interrupt or returning

to complete the first SPLOOP block.

Workaround:

The C6000 compiler release v6.0.6, and above, detects this problem. If there are fewer

than two execute packets between the SPKERNEL and SPLOOP instructions, the

compiler adds the appropriate number of NOP instructions following the SPKERNEL

instruction. For example:

SPKERNEL 0, 0

NOP 1 ; SDSCM00012367 HW bug workaround

MVK .L1 0x1,A0

[ A0] SPLOOPW 3 ;12

NOP 1

The assembler detects sequences that could potentially trigger this bug and issues a

remark. For example:

"neg_test.asm", REMARK at line 21 [R5001] SDSCM00012367 potentially triggered by

this execute packet sequence. SLOOP must be at least 2 EPs away from previous

SPKERNEL for safe interrupt behavior.

Note: The assembler tool, asm6x.exe, can be used to determine if a previous version of

the compiler generated code that could potentially be affected by this silicon issue. The

assembler can also be used on assembly source code to see if the source could be

affected by this issue. Replace the old version of asm6x.exe with the v6.0.6 asm6x.exe

in your current build setup and recompile or reassemble.

13

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 17

CPU: C64x+ CPU Incorrectly Generates False Exceptions for Multiple Writes

2.0, 1.2, 1.1, 1.0

Revision(s) Affected:

Details:

The C64x+ CPU may generate an incorrect resource conflict exception when taking an

interrupt. This only affects applications that run with exceptions enabled. Applications

enable exceptions by writing 1 to the GEE bit in the task state register (TSR).

Applications that do not enable exceptions are not affected by this errata. The CPU

generates this incorrect exception in the following scenario:

1. The CPU begins draining the pipeline as part of an interrupt context switch. During

this time, the CPU annuls instructions in the pipeline that have not yet reached the

E1 pipeline phase while it drains the pipeline.

2. The first annulled execute packet (resident in the DC pipeline stage at the time

draining begins) writes to one or more predicate registers. Because it is annulled, the

writes do not occur.

3. The second annulled execute packet (resident in the DP pipeline stage at the time

draining begins) has a predicated single cycle instruction that uses a predicate

written by the execute packet described in item 2. Because it is annulled, the write

does not occur.

4. The value held in the predicate register would cause the instruction in the second

annulled execute packet to write to some register in the same cycle as another

instruction if it were not annulled. The conflicting writes would not happen if the first

execute packet had not been annulled. The exception is not a valid exception. If the

CPU executed instructions, described in items 2 and 3 above, rather than annulling

them while draining the pipeline for an interrupt, the execute packet in item 2 would

set the predicate(s) such that the writes in the subsequent execute packet do not

conflict.

Examples of sequences that generate the incorrect exception are:

ZERO A0

ZERO B0

---------------------> interrupt occurs

MVK 1, A0 ;(1st annulled EPKT)

[!A0] MVK 2, A1 ;(2nd annulled EPKT) \_ Appears both MVKs write A1,

||[!B0] MVK 3, A1 ;(2nd annulled EPKT) / triggers invalid exception.

...

ZERO A0

[!A0] LDW *A4, A5

NOP

--------------------> interrupt occurs

MVK 1, A0 ;(1st annulled EPKT)

[!A0] MVK 2, A5 ;(2nd annulled EPKT) LDW writes A5 this cycle

...

ZERO A0

[!A0] DOTP2 A3, A4, A5

NOP

-------------------> interrupt occurs

MVK 1, A0 ;(1st annulled EPKT)

[!A0] MVK 2, A5 ;(2nd annulled EPKT) DOTP2 writes A5 this cycle

Workaround:

The CPU only recognizes the incorrect exception while it drains the pipeline for an

interrupt. As a result, the CPU begins exception processing upon reaching the interrupt

handler. The NMI return pointer register (NRP) and the NMI task state register (NTSR)

reflect the state of the machine upon arriving at the interrupt handler. Therefore, to

identify the incorrect resource conflict exception in the software, verify the following

conditions at the beginning of the exception handler prior to normal exception

processing:

1. The exception occurred during an interrupt context switch.

(a) In the NTSR register, verify that INT=1, SPLX=0, IB=0, CXM=00.

(b) Verify that the NRP register points to an interrupt service fetch packet. That is,

(NRP & 0xFFFF FE1F) == (ISTP & 0xFFFF FE1F).

14

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

2. The exception is a resource conflict exception. In IERR, verify that RCX == 1 and all

other IERR bits == 0.

3. The exception is an internal exception. In EFR, verify that IXF == 1 and all other EFR

bits == 0.

Upon matching the above conditions, suppress the exception as follows:

1. Clear the EFR.IXF bit by writing 2 to the ECR bit.

2. Resume the interrupt handler by branching to the NRP register. The above

workaround identifies and suppresses all cases of the incorrect resource conflict

exception. It resumes normal program execution when the incorrect exception

occurs, and has minimal impact on the execution time of program code. The

interrupted code sequence runs as expected when the interrupt handler returns. The

workaround also suppresses a particular valid exception case that is indistinguishable

from the incorrect case. Specifically, the code suppresses the exception generated by

two instructions with different delay slots (e.g., LDW and DOTP2) writing to the same

register in the same cycle, where the conflicting writes occur during the interrupt

context switch.

An example of a sequence with incorrectly suppressed exception is:

LDW *A0, A1

DOTP2 A3, A2, A1

NOP

-----------------> interrupt occurs

NOP

NOP ; Both LDW and DOTP2 write to A1 this cycle

The workaround will not suppress these valid resource conflict exceptions if the

multiple writes occur outside an interrupt context switch. That is, the workaround will

not suppress the exception generated by the code above when it executes without an

interfering interrupt.

For more details, see the following sections in the TMS320C64x/C64x+ DSP CPU and

Instruction Set Reference Guide (literature number SPRU732):

•

Interrupt Service Table Pointer Register (ISTP) describes the ISTP control register.

Nonmaskable Interrupt (NMI) Return Pointer Register (NRP) describes the NRP

control register.

•

TMS320C64x+ DSP Control Register File Extensions describes the ECR, EFR,

IERR, TSR, and NTSR control registers.

Pipeline describes the overall operation of the C64x+ pipeline, including the behavior

of the E1, DC and DP pipeline phases.

Actions Taken During Nonreset Interrupt Processing describes the operation of the

C64x+ pipeline during interrupt processing, including how it annuls instructions.

C64x+ CPU Exceptions describes exception processing.

15

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 20

DDR2 EMIF Buffers Not Totally Compensated by Default

Revision(s) Affected:

Details:

2.0, 1.2, 1.1, 1.0

The output buffers on the DDR2 EMIF contain dynamic impedance compensation

circuitry to maintain a constant output impedance across temperature, voltage, and

silicon process variation. This impedance compensation circuitry must configure each

individual output buffer. The output buffer compensation for each DDR2 output buffer is

not complete until both a 1-to-0 and 0-to-1 transition has occurred on that output.

Until this compensation occurs, the output drive strength is probably less than ideal. The

DDR2 EMIF cycles that occur before dynamic compensation is complete may fail. Since

the mode register (MR) write cycles are the first cycles initiated by the DDR2 EMIF after

a reset, these cycles are at risk. Similarly, after EMIF configuration, the first writes to

DDR2 memory are also at risk.

This issue has not been seen in the field. It has only been observed on test fixtures at TI.

Therefore, it appears to have a very low probability of affecting existing designs. The

recommended topologies that only have one or two loads per DDR2 EMIF without VTT

termination appear to be resilient to this condition. The possibility of failure can only be

eliminated if the software workaround described below is implemented.

Some system start-up sequences improve the probability of robust operation, such as:

•

Incomplete compensation may cause mode register (MR) writes to fail. This could

result in DDR2 performance lower than expected or complete failure. The risk of this

occurring is reduced through multiple MR write operations since compensation of

most address and control output buffers and both clock output buffers are completed

before the final MR write. Most DDR2 EMIF configuration sequences, including the

one implemented in the CSL, result in multiple MR write operations. MR write cycles

are also designed to complete on the slowest possible DDR2 memory devices. This

is another reason these cycles have a high probability of success.

•

Incomplete compensation may cause initial DDR2 memory writes to fail. This could

cause the DSP to execute incorrectly if these initial writes are code or critical data.

Many system implementations use a secondary bootloader to load the full binary

image. The secondary bootloader is then discarded after boot completion. Therefore,

any invalid writes would occur in the bootloader and the full application code is

loaded after the DDR2 EMIF output buffers have been activated many times. (This is

not a full guarantee of complete compensation but the probability is high that all of

the output buffers are fully compensated by the time the secondary bootloader is

written.)

•

A better guarantee that this compensation has no latent impact is validation of the full

binary image through some type of code checksum at the end of the boot process. If

the code is verified in this way, the system is guaranteed to be robust.

Workaround:

This workaround has to be executed every time the DDR2 EMIF is initialized. Since it

should occur before valid mode register writes can be completed, the EMIF configuration

has to be repeated after the output buffers are fully compensated. The sequence of

steps listed below completes the dynamic compensation for all of the DDR2 EMIF output

buffers. The CSL API function CSL_ddr2HwSetup is called during the normal bring-up

process to trigger MR writes. Therefore, the workaround code can be put before the API

function call.

16

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

Sample code:

/* Define the following variables. */

Uint32 tempData0, tempData1;

/* Define the following pointers to compensate the address buffers. */

Uint32

*pDdr2Data_temp0 = (Uint32 *) 0xEAAAAAA8;

*pDdr2Data_temp1 = (Uint32 *) 0xE5555554;

/* Use 0xF5555554 on systems using 512MB of memory. */

/*************************************************************

The following code needs to be executed at the beginning of every DDR2 EMIF

initialization.

*************************************************************/

/* Enable self-refresh mode and set an appropriate REFRESH_RATE to guarantee

200us delay before CKE goes high. REFRESH_RATE value has to be calculated based

on DDR2 clock being used. */

hDdr2->regs->SDRFC = 0x80001388;

/* Disable self-refresh mode and set an appropriate REFRESH_RATE to have a

correct refresh cycle. REFRESH_RATE value has to be calculated based on DDR2

clock being used. */

hDdr2->regs->SDRFC = 0x00000753;

/*Write and read the first location with a 0xAAAAAAAA pattern.*/

tempData0 = 0xAAAAAAAA;

*pDdr2Data_temp0 = tempData0;

tempData1 = *pDdr2Data_temp0;

/* DDR2 memory write */

/* DDR2 memory read */

/* Perform two more writes with a 0x55555555 and 0xAAAAAAAA pattern to complete

the compensation cycle. */

tempData0 = 0x55555555;

*pDdr2Data_temp1 = tempData0;

tempData0 = 0xAAAAAAAA;

/* DDR2 memory write */

*pDdr2Data_temp0=tempData0;

17

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 21

SRIO Port 0 Reset Affects Other Ports

Revision(s) Affected:

Details:

2.0, 1.2, 1.1, 1.0

The SerDes for SRIO should allow the reset of individual 1X ports without affecting the

state of the other operational ports. There are dedicated MMR bits to reset 1X ports,

which are the BLKn_EN (n=5..8) at offsets 0x60 and 0x68. However, the BLK5_EN that

controls reset for port 0 also resets all other ports. Therefore, it is impossible to reset

port 0 without affecting all other ports.

Workaround:

There is no workaround for this advisory.

Advisory 22

SRIO OUTBOUND_ACKID Field Not Read Correctly

Revision(s) Affected:

Details:

2.0, 1.2, 1.1, 1.0

The OUTBOUND_ACKID field of the RIO_SP(n)_ACKID_STAT register should be

updated by hardware each time a packet is sent out. The value should reflect the ACKID

value to be used on the next transmit packet. This field is being updated by the hardware

as expected. The field can also be written by the software and these writes also

succeed. However, a hardware error prevents this field from being read. The

OUTBOUND_ACKID always reads as zero. This problem does not cause any impact to

link operation.

Workaround:

There is no workaround for this advisory.

18

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

Advisory 24

DMA Access to L2 SRAM May Stall When the DMA and the CPU Command Priority

is Equal

Revision(s) Affected:

Details:

2.0, 1.2, 1.1, 1.0

The L2 memory controller in the GEM has programmable bandwidth management

features that are used to control bandwidth allocation for all requestors. There are two

parameters to control this, command priority and arbitration counter MAXWAIT values.

Each requestor has a command priority and the requestor with the higher priority wins.

However, there are also counters associated with each requestor that track the number

of cycles each requestor loses arbitration. When this counter reaches a threshold

(MAXWAIT), which is programmed by the user (or default value), the losing requestor

gets an arbitration slot and wins for that cycle. There are four such requestors: CPU,

DMA (SDMA and IDMA), user cache coherency operation, and global cache coherence.

Global-coherence operations are highest priority, while user-coherence operations are

lowest priority. However, there is active arbitration done for the CPU and the DMA

(SDMA/IDMA) commands. The priority for DMA commands comes from an external

master as part of the SDMA command or a programmable register, IDMA1_COUNT, in

the GEM for IDMA commands. The priority for CPU accesses to L2 is in a

programmable register, CPUARBU, in the GEM. For the default priority values, see

Table 8.

More details on the bandwidth management feature can be found in the C64x+ DSP

Megamodule Reference Guide (SPRU871).

Table 8. C6472 Default Master Priorities

DEFAULT MASTER PRIORITIES

MASTER

(0 = Highest priority,

7 = Lowest priority)

PRIORITY CONTROL

EDMA3TCx

0

QUEPRI.PRIQx (EDMA3 register)

SRIO (Data Access)

PER_SET_CNTL.CBA_TRANS_PRI

(SRIO register)

EMAC

7

1

7

PRI_ALLOC.EMAC

HPI

PRI_ALLOC.HOST

UTOPIA - PDMA

TSIP

PRI_ALLOC.UTOPIAPDMA

DMACTL (TSIP register)

C64x+ Megamodule (MDMA port)

MDMAARBE.PRI (C64x+ Megamodule

register)

C64x+ Megamodule (CPU Arbitration

control to L2)

1

0

CPUARBU (C64x+ Megamodule register)

C64x+ Megamodule (IDMA channel 1)

IDMA1_COUNT (C64x+ Megamodule

register)

The L2 memory controller is supposed to give equal bandwidth to the DMA and the

CPU, by alternating between the two for arbitration. Instead, the L2 memory controller

gives larger bandwidth allocation to the CPU accesses when the DMA and the CPU

priorities are same. The CPU commands keep winning arbitration over the DMA as long

as there are no other internal conditions (stalls, etc.) that force the DMA to win

arbitration. This typically happens when CPU accesses keep the L2 memory controller

busy every cycle, hence, the DMAs stall until the stream of CPU accesses completes.

For example, if a continuous stream of L1D write misses to L2 keep the L2 memory

controller busy every cycle, the DMAs stall for the entire duration of the write miss

stream.

Workaround:

Set the CPU and the DMA commands to L2 on different priorities.

19

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 25

DMA Corruption of External Data Buffer

Revision(s) Affected:

Details:

2.0, 1.2, 1.1, 1.0

Under a specific set of circumstances, an L1D snoop-write updates 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 access, a subsequent

victim writeback from L1D could commit the corrupted line to lower levels of memory.

Two key requirements for this bug are:

•

The DMA writes to buffers in UMAP1 only (see below).

–

This must be cached and unmodified in L1D (read by the CPU but not yet written

to it).

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 C6472 device, see Table 9.

Table 9. C6472 UMAP1 Allocation

UMAP1

ADDRESS RANGE

AFFECTED

N/SMC

0x00200000 - 0x002BFFFF

Yes

•

The CPU reads from an 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 C6472 device, see Table 9.

For information on L1D cache coherence protocol, see section 3.3.6, Cache

Coherence Protocol, in the C64x+ DSP Megamodule Reference Guide

(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

only happens 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.

3. The CPU reads from a cacheable, external memory (e.g., DDR) that is a set match to

Cache Line A (referred to here as Cache Line B).

Determining if two addresses are a set match can be done by comparing certain bits

20

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

of two addresses. The mapping of an address to a location in L1D cache is shown in

Figure 2.

31

X+1

X

6

5

4

2 1

0

Offset

Sub-line Bank Byte

Tag

Set

The value X is determined by how large the L1D cache is in the particular application (see Table 10).

Figure 2. L1D Cache Address Mapping

Table 10. Value of X for L1D Cache

AMOUNT OF L1D CACHE

X BIT POSITION

0KB

4KB

N/A

10

11

12

13

8KB

16KB

32KB

If you use the default configuration, 32KB, as an example, bits [13:6] are a set match

if they are identical in two different addresses. Some examples of set matches are

shown below:

•

0x0080 2A80 00000000100000000010101010000000

0x8000 2A80 10000000100000000010101010000000

0x0080 2A8A 00000000100000000010101010001010

This results in a cache miss from the CPU for an external address and sends a

read request to L2 cache for the line (and possibly to the external source on an L2

cache miss or if no L2 cache is present).

The results of the above cause the following:

L2 sends both the return data for the L1D read miss request (response of Step 3 above)

and the data for the snoop-write (response of Step 2 above). The L1D commits the

snoop-write data after the L2 return data.

As a result, L1D now holds the wrong data for the external address (Cache Line B) and

commits the data to cache. Cache Line B remains marked "clean." If the program does

not write to the uncorrupted portion of the line and does not read the corrupted portion of

the line, the corruption goes unnoticed. If the program writes to the uncorrupted portion

of the line, the corrupted data gets written back to L2 cache and/or external memory.

Otherwise, the corruption disappears when L1D discards the line.

Cache lines holding external addresses are the only cache lines that exhibit corruption.

Corruption only happens when DMA buffers in UMAP1 get cached in L1D. Additionally,

corruption only happens when the DMA buffer is clean, meaning that it gets discarded

without generating a victim. Thus, this affects buffers where the DMA writes and the

CPU reads. It does not affect buffers that the CPU only writes and/or DMA only reads.

One can identify this bug unambiguously by examining the corrupted memory range in

CCStudio using the cache tag viewer. The corrupted data shows up in the include L1D

view in a memory window, but not in the exclude L1D view. The cache tag viewer should

indicate that the line is also "clean" and the corrupt data should also be visible in its

intended destination, which must be in UMAP1 and map to the same L1D set as the

corrupted line.

Figure 3 shows the flow of these operations, the incorrect order that causes the bug, and

the correct order. The blue line is Cache Line A and the yellow line is Cache line B.

21

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

UMAP0

UMAP1

External

Buffer

L1D

t2

Clean

t3

t0

t1

DMA Write

(Snoop Write)

CPU Read

(L2 Cache)

Corruption

t0: DMA Write

t1: CPU Allocate

t2: Snoop Write

t1: CPU Allocate

t2: Allocation Data

t3: Snoop Write

Incorrect Order

t3: Allocation Data

Correct Order

Figure 3. Cache Line Operations Flow

Workarounds:

In the bug description above, all of the conditions must be true for the bug to occur. Our

workarounds essentially focus on picking one of the conditions and removing it so that

you do not need to worry about the other conditions.

We propose starting with workaround 1 as an immediate fix. The other workarounds that

follow may provide a solution with reduced overhead and/or simplified implementation,

depending on the customer's system.

22

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

Workaround 1: Write Back and Invalidate DMA Buffers

L1D corruption occurs when the DMA writes to a buffer in UMAP1 that is also cached in

L1D at the same time the L1D is discarding the buffer. Thus, this affects buffers where

the DMA writes and the CPU reads. It does not affect buffers that the CPU only writes

and/or the DMA only reads.

To prevent this sort of race condition, programs should discard inbound DMA buffers in

UMAP1 immediately after use and keep a strict policy of "buffer ownership" such that a

given buffer is owned only by the CPU or the DMA at any given time.

This model assumes the following:

1. The DMA fills the buffer during a period when the CPU does not access it.

2. The DMA engine or other mechanism signals to the CPU that it has finished filling the

buffer.

3. The CPU operates on the buffer, reading and writing to it, as necessary. The DMA

does not access the buffer at this time.

4. The CPU relinquishes control of the buffer so that DMA may refill it. (This may be an

implicit step in many implementations if the period between refills is much longer than

the time it takes the CPU to process the refilled buffer.)

To implement this workaround, programmers must write back and invalidate the buffer

from L1D cache after Step 3 and before Step 4. This eliminates the prerequisite for the

bug to occur should another DMA, in the future, be a set match to the reads that the

CPU just performed.

There are multiple mechanisms for doing this, but the most straightforward is to use the

L1D block cache writeback-invalidate mechanism via L1DWIBAR/L1DWIWC.

The recommended implementation of this workaround requires calling the

l1d_block_wbinv.asm function (see the L1D Block Writeback-Invalidate Routine below).

It can be invoked as follows:

void l1d_block_wbinv(void *base, size_t byte_count);

To writeback-invalidate a C array, one could then do:

/* ... */

l1d_block_wbinv(&array[0], sizeof(array));

Programmers should insert such a call whenever the code is done with a particular DMA

buffer in UMAP1, before the DMA controller can refill it. The l1d_block_wbinv() function

is non-interruptible. Its overhead is proportional to the size of the buffer.

NOTE:

1. To ensure complete effectiveness, DMA buffers must always start on

an L1D cache-line boundary (64-byte boundary) and occupy a

multiple of 64 bytes. This may require increasing the size of some

DMA buffers slightly. This is necessary to prevent accesses to an

unrelated buffer or variable from bringing a portion of the DMA buffer

back into the L1D cache.

2. If the buffer under consideration is a small number of read-only flags

to the CPU, then Workaround 4 may be more applicable.

L1D Block Writeback-Invalidate Routine

;; ======================================================================== ;;

.asg 0x01844030, L1DWI

.global _l1d_block_wbinv

.text

; L1D Block Wb-Inv; BAR at 0, WC at 1

.asmfunc

_l1d_block_wbinv:

MVC DNUM, B0

ADDK 0x10, B0

; \_ Get global alias prefix

; /

23

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

SHRU A4, 24, B2

CMPEQ B0, B2, B0

[ B0] EXTU A4, 8, 8, A4

MVKL L1DWI, B6

; Get prefix from address

; Check if address prefix is global

; Remove global prefix from address

;

CLR A4, 0, 5, A1

|| ADD A4, B4, B1

; Align to L1D cache line boundary

; Compute end of buffer

ADDK 63, B1

CLR B1, 0, 5, B1

; \_ Round to next L1D cache line

; /

SUB B1, A1, B1

|| MVKH L1DWI, B6

; Count cache-line span in bytes

;

SHR B1, 2, B1

|| DINT

; Convert to "word count"

; Disable interrupts

STW A1, *B6[0]

STW B1, *B6[1]

; Store base address

; Store word count

; Note: The following loop is intentionally low-rate to avoid

; interfering with the block writeback operation.

loop: LDW *B6[1], B1

NOP 4

[ B1] BNOP loop, 5

; Read remaining word-count

; Loop until done

RINT

RETNOP B3, 5

; Reenable interrupts

; Return to caller

.endasmfunc

;; ======================================================================== ;;

;; End of file: l1d_block_wbinv.asm ;;

;; ======================================================================== ;;

Workaround 2: Make DMA Buffers Dirty After Use

The errant snoop-write occurs only when the DMA buffer in L1D has not been modified.

This is due to the additional snoop-checking mechanisms associated with tracking

victims as they leave L1D.

Therefore, another workaround is to mark DMA buffers as "dirty" before releasing them.

This generates additional victims whenever the buffer gets pushed out of L1D. It also

blocks the errant snoop-write.

This workaround assumes a similar model to Workaround 1, but uses the make_dirty()

function (see the Mark Buffer Dirty Routine below). The make_dirty() function reads one

byte from each cache line of the buffer and writes the same value back to it immediately.

The function is called as follows:

void make_dirty(void *base, size_t byte_count);

Mark Buffer Dirty Routine

;; ======================================================================== ;;

;; Make a block of data "dirty" in L1D

;;

;; make_dirty(void *base, size_t byte_count);

;;

;; ======================================================================== ;;

.global _make_dirty

.text

.asmfunc

_make_dirty:

ADDK 63, B4

SHR B4, 6, B4

MVC B4, ILC

MVK 64, A5

MVK 64, B5

MV A4, B4

NOP SPLOOP 1

LDBU *A4++[A5], A1

24

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

NOP 4 MV.L A1, B1

STB B1, *B4++[B5]

SPKERNEL

RETNOP B3, 5

.endasmfunc

;; ======================================================================== ;;

;; End of file: make_dirty.asm

;;

;; ======================================================================== ;;

NOTE:

1. This workaround is not acceptable if the DMA could be writing to the

buffer at the same time make_dirty() function gets called. The

process of making the cache line dirty requires reading and writing

within the buffer and, so, the CPU's writes could overwrite the

inbound data from the DMA.

2. This workaround may cause the application to be affected by the

issue described in Advisory 26, DMA Corruption of L2 RAM Data.

Workaround 3: Do Not Cache Data From External Memory in L1D

If your program only makes a small number of data accesses to external memory,

consider marking the data portions of external memory as non-cacheable. This prevents

caching copies of external memory in L1D cache.

Alternately, to prevent the line from allocating in L1D, freeze the L1D cache around each

access to an external address. The long_dist_load_word function (see the Long Distance

Load Word Routine below) is suitable for isolated accesses. For larger accesses, such

as reading a block, other techniques may be more appropriate.

The incorrect snoop-write only occurs when the L1D read miss involved is to an external

address. The snoop-write corrupts the newly cached copy in L1D. If all accesses to

external data memory are non-cacheable or occur while L1D is frozen, this prevents

copies from being stored in L1D.

Long Distance Load Word Routine

;; ======================================================================== ;;

;; Long Distance Load Word

;;

int long_dist_load_word(volatile int *addr)

;; This function reads a single word from a remote location with the L1D

;; cache frozen. This prevents L1D from sending victims in response to

;; these reads, thus preventing the L1D victim lock from engaging for the

;; corresponding L1D set.

;;

;; The code below does the following:

;;

1. Disable interrupts

2. Freeze L1D

3. Load the requested word

4. Unfreeze L1D

5. Restore interrupts

;; Interrupts are disabled while the cache is frozen to prevent affecting

;; the performance of interrupt handlers. Disabling interrupts during

;; the long distance load does not greatly impact interrupt latency,

;; because the CPU already cannot service interrupts when it's stalled by

;; the cache. This function adds a small amount of overhead (~20 cycles)

;; to that operation.

;;

;; ======================================================================== ;;

.asg 0x01840044, L1DCC ; L1D Cache Control

.global _long_dist_load_word

.text

.asmfunc

25

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

; int long_dist_load_word(volatile int *addr)

_long_dist_load_word:

MVKL L1DCC, B4

MVKH L1DCC, B4

||

DINT

; Disable interrupts

MVK 1,

B5

STW B5, *B4

LDW *B4, B5

NOP 4

SHR B5, 16, B5

LDW *A4, A4

NOP 4

; \_ Freeze cache

; /

; POPER -> OPER

; read value remotely

||

STW B5, *B4

RET B3

LDW *B4, B5

NOP 4

; \_ Restore cache

; /

RINT

; Restore interrupts

.endasmfunc

;; ======================================================================== ;;

;; End of file: ldld.asm ;;

;; ======================================================================== ;;

Workaround 4: Allocate DMA buffers in L1D RAM or UMAP0

If possible, move DMA buffers that the CPU reads directly out of UMAP1 to either

UMAP0 or L1D RAM. DMA buffers that the CPU does not access directly can remain in

UMAP1 safely, as these do not generate snoops.

If your set of in-bound DMA buffers does not fit in L1D RAM and UMAP0 statically,

consider paging buffers from UMAP1 to either UMAP0 or L1D RAM. That is, allow the

DMA to write to buffers in UMAP1 freely, but never read them directly from the CPU.

Instead, use the IDMA to copy a buffer from UMAP 1 to either UMAP0 or L1D RAM

before using it.

The IDMA1 utility functions (see the IDMA Channel 1 Block Copy Routine below) can be

used for copying data with the IDMA controller.

IDMA Channel 1 Block Copy Routine

;; ======================================================================== ;;

;; TEXAS INSTRUMENTS INC.

;;

;; Block Copy with IDMA Channel 1

;;

;; REVISION HISTORY

;;

13-Feb-2009 Initial version . . . . . . . . . . . J. Zbiciak

;; DESCRIPTION

;;

The following macro functions are defined in this file:

idma1_copy(void *dst, void *src, int word_count)

idma1_wait(IDMA_PEND or IDMA_ACTV)

;; NOTE: The last arg is WORD count, not byte count. 1 word = 4 bytes.

;;

;; ------------------------------------------------------------------------ ;;

;;

;; ======================================================================== ;;

.asg 0x01820100,

.asg 0x01820108,

.asg 0x0182010C,

.asg 0x01820110,

.asg 0x01820100,

IDMA1_STATUS

IDMA1_SOURCE

IDMA1_DEST

IDMA1_COUNT

IDMA1_BASE

.asg (IDMA1_STATUS - IDMA1_BASE), OFS_IDMA1_STATUS

.asg (IDMA1_SOURCE - IDMA1_BASE), OFS_IDMA1_SOURCE

.asg (IDMA1_DEST - IDMA1_BASE),

OFS_IDMA1_DEST

.asg (IDMA1_COUNT - IDMA1_BASE), OFS_IDMA1_COUNT

;; ------------------------------------------------------------------------ ;;

;; IDMA1_COPY: Copy a block of words to dst from src with IDMA channel 1

;;

26

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

;;

;; USAGE

;;

idma1_copy( <dest address>, <source address>, <word count>)

Both source and destination addresses must be word aligned.

The IDMA gets issued at top priority. Only bits 13:0 of the word

count are significant.

;; ------------------------------------------------------------------------ ;;

.global _idma1_copy

.asmfunc

_idma1_copy:

;

Point to IDMA channel 1's base

RET B3

; return; also protect from interrupts

||

MVKL IDMA1_SOURCE, A7

MVKH IDMA1_SOURCE, A7

;

Write second argument to "source" register

STW B4, *A7++(IDMA1_DEST - IDMA1_SOURCE)

Write first argument to "destination" register

STW A4, *A7++(IDMA1_COUNT - IDMA1_DEST)

Write last argument to "count" register.

EXTU A6, 18, 16, A6

STW A6, *A7

; truncate word count to 14 bits

.endasmfunc

;; ------------------------------------------------------------------------ ;;

;; IDMA1_WAIT: Wait for IDMA "pend" or "actv" slot to free up.

;;

;; USAGE

;;

idma1_wait(IDMA_PEND) Waits for just PEND to be 0

idma1_wait(IDMA_ACTV) Waits for ACTV (and PEND) to be 0

;; NOTE

;;

IDMA_PEND = 2

IDMA_ACTV = 3

;; ------------------------------------------------------------------------ ;;

.global _idma1_wait

.asmfunc

_idma1_wait:

MVKL IDMA1_STATUS, A6

MVKH IDMA1_STATUS, A6

||

loop?:

[ A0] LDW *A6, A0

||[ A0] BNOP.1 loop?, 4

MVK 1, A0

;

The 'AND' below is safe because IDMA never returns 10b in 2 LSBs

AND.L A4, A0, A0

RETNOP B3, 5

.endasmfunc

;; ======================================================================== ;;

;; End of file: idma1_util.asm ;;

;; ======================================================================== ;;

27

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 26

DMA Corruption of L2 RAM Data

Revision(s) Affected:

Details:

2.0

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:

1. For information on L1D cache coherence protocol, see section 3.3.6,

Cache Coherence Protocol, in the C64x+ DSP Megamodule

Reference Guide (SPRU871).

2. 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. 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).

The following steps must all occur concurrently to see the issue:

1. The CPU reads from any address in L2 SRAM that is a set match to Cache Line A.

(To determine if you have a set match, see below.)

•

The set match to Cache Line A is referred to here as Cache Line B.

This results in a cache miss from the CPU and sends a read request to L2 cache

for the line (and possibly an external source if it was through L2 cache or if no L2

cache is present).

•

Since Cache Line A is dirty, a victim is prepared to be sent after Cache Line B is

allocated and is held in a temporary victim data buffer.

Determining if two addresses are a set match can be done by comparing certain bits

of two addresses. The mapping of an address to a location in L1D cache is shown in

Figure 4.

28

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

31

X+1

X

6

5

4

2 1

0

Offset

Sub-line Bank Byte

Tag

Set

The value X is determined by how large the L1D cache is in the particular application (see Table 11).

Figure 4. L1D Cache Address Mapping

Table 11. Value of X for L1D Cache

AMOUNT OF L1D CACHE

X BIT POSITION

0KB

4KB

N/A

10

11

12

13

8KB

16KB

32KB

If you use the default configuration, 32KB, as an example, bits [13:6] are a set match

if they are identical in two different addresses. Some examples of set matches are

shown below:

•

0x0080 2A80 00000000100000000010101010000000

0x8000 2A80 10000000100000000010101010000000

0x0080 2A8A 00000000100000000010101010001010

2. The DMA read or writes from/to Cache Line A, mentioned in the prerequisite above.

This means that it is not necessarily the same exact address, but within the same

64B cache line.

•

As a result, a snoop-read/-write request is generated.

3. The DMA writes to Cache Line B, mentioned in Step 1. This means that it is not

necessarily the same exact address, but within the same 64B cache line as Step 1.

•

As a result, a snoop-write request is generated but not immediately issued, as it

is blocked by the snoop-read/-write issued in Step 2.

The results of the above cause the following:

(A) The L1D controller receives the new line (B) back from the L2 Controller.

(B) If Step 2 above was a write, the snoop-write to Cache Line A updates the victim

buffer correctly. If it was a read, the snoop-read returned the correct data to the DMA.

(C) The snoop-write to Cache Line B (Step 3 above) incorrectly updates the victim buffer

instead of the newly allocated line that was returned in Step A.

As a result, the following is true:

1. Cache Line A now holds data that was corrupted by Steps 3 and C above.

•

A subsequent read of this data returns a corrupted value.

2. Cache Line B now holds stale data, as it was never updated with the data it was

supposed to get from Steps 3 and C.

•

The CPU gets stale data (not updated).

Corruption only happens when the DMA accesses an L1D cache line that the CPU also

writes to. This results in DMAs that may match victim lines leaving L1D. Thus, it can

affect buffers that the CPU fills with writes and the DMA reads, as well as buffers where

both the DMA and CPU write. It does not affect DMA buffers that the CPU only reads.

Figure 5 shows the sequence of events.

29

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

UMAPx

SRAM

L1D

t2

t1

Dirty

t3

t0

t3¢

CPU Read

(L2 Cache)

DMA Write

(Snoop Write)

Corruption

t4

t0: CPU Allocate

t1: Victim Start

t2: Allocation Data

t4: Victim Done

t2: Allocation Data

t3: DMA Write (SNPW)

t4: Victim Done

Incorrect Order

t3: DMA Write (SNPW)

Correct Order

Figure 5. Sequence of Events

Table 12 shows the expected data values after this sequence completes and the actual

values that are now present because of this issue.

Table 12. Expected vs. Actual Data Values⁽¹⁾

EXPECTED

ACTUAL

Buffer A

Buffer B

A′′′

B′′

B

(1)

Key:

A, B = Original data

A′ = CPU-written data

A′′, B′′ = DMA-written data

A′′′ = CPU- and DMA-written data, properly merged

30

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

With all the steps above, it is fairly painful to determine if a particular buffer has the

potential to see this issue. Figure 6 is a simple decision tree to help make a

determination for a particular buffer.

N

Is the CPU reading

Is CPU reading

from this buffer?

OK

Y

N

Is the CPU writing

Is CPU reading

to this buffer?

from this buffer?

OK

Y

Is CPU reading

Does the DMA access

from this buffer?

the same buffer

N

OK

(read or write)

?

Y

Is CPU reading

Is there a software

from this buffer?

control mechanism to

Y

force buffer ownership between

the CPU and the DMA

through WB/invalidate

?

OK

N

Potential Problem

Figure 6. Decision Tree

If you approach one of the "OK" fields, then the buffer should not have a potential of

being affected. If you arrive at "Potential Problem," see the workarounds below.

NOTE: Figure 6 assumes that each buffer is aligned to a 64B boundary and

spans a multiple of 64B. This is because the cache line size of our L1D is

64B. If that is not the case, there is a chance that you might still see this

issue even if you get to an OK state in the diagram (see the Workaround

for "False-sharing" section below).

Workarounds:

The bug occurs when the CPU writes within the same L1D cache line that the DMA

reads or writes. This can happen for multiple reasons. The following sections detail

workarounds for three scenarios:

1. The CPU writes to a buffer that the DMA then reads. This could either be due to an

"in-place" algorithm that operates on data brought to it by DMA or an "out-of-place"

algorithm where the CPU fills a buffer that the DMA then reads. In either case, the

31

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

CPU and DMA explicitly synchronize.

2. The CPU and DMA are updating distinct or unrelated objects that happen to share a

cache line. (This is sometimes called "false sharing.") Because the objects are

unrelated, the DMA and CPU are not synchronized.

3. The CPU and DMA are both writing to the same structure without external

synchronization. This pattern often underlies software synchronization

implementations and lockless multiprocessing algorithms.

Workaround for Synchronizing DMA and CPU Access to Buffers

The CPU potentially triggers this bug when it reads and later writes to a buffer that the

DMA also accesses (read or write). The bug can happen when the DMA accesses the

affected line when the L1D cache writes it back to L2. To avoid this bug, programmers

can explicitly manage coherence on the buffer so that the buffer is not present and dirty

in L1D when the DMA accesses it.

To explicitly manage coherence on the buffer, programmers should adhere to the

programming model described earlier: Programs should write back or discard in-bound

DMA buffers immediately after use and keep a strict policy of buffer ownership such that

a given buffer is owned only by the CPU or the DMA at any given time.

This model assumes the following:

1. The DMA fills the buffer during a period when the CPU does not access it.

2. The DMA engine or other mechanism signals to the CPU that it has finished filling the

buffer.

3. The CPU operates on the buffer, reading and writing to it, as necessary. The DMA

does not access the buffer at this time.

4. The CPU relinquishes control of the buffer so that DMA may refill it. (This may be an

implicit step in many implementations if the period between refills is much longer than

the time it takes the CPU to process the refilled buffer.)

To implement this workaround, programmers must write back (and optionally invalidate)

the buffer from L1D cache after Step 3 and before Step 4. There are multiple

mechanisms for doing this, but the most straightforward is to use the L1D block cache

writeback mechanism via L1DWBAR/L1DWWC or the L1D block cache

writeback-invalidate mechanism via L1DWIBAR/L1DWIWC.

The recommended implementation of this workaround requires calling the

l1d_block_wb.asm and l1d_block_wbinv.asm functions (see the L1D Block Writeback

and L1D Writeback-Invalidate Routines below). The functions can be invoked as follows:

void l1d_block_wb(void *base, size_t byte_count);

or

void l1d_block_wbinv(void *base, size_t byte_count);

To writeback a C array, one could then do:

char array[SIZE];

/* ... */

l1d_block_wb(&array[0], sizeof(array));

The above example could be used to writeback-invalidate as well by calling the other

function.

Programmers should insert such a call whenever the CPU code is done with a particular

DMA buffer, before the DMA controller can refill it. The l1d_block_wb() and

l1d_block_wbinv() functions are non-interruptible. The overhead is proportional to the

size of the buffer.

32

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

NOTE: To ensure complete effectiveness, ensure that the DMA buffers always

start on an L1D cache-line boundary (64-byte boundary) and occupy a

multiple of 64 bytes. This may require increasing the size of some DMA

buffers slightly. This is necessary to prevent accesses to an unrelated

buffer or variable from bringing a portion of the DMA buffer back into the

L1D cache.

L1D Block Writeback Routine

;; ======================================================================== ;;

;; L1D Block Writeback

;;

l1d_block_wb(void *base, size_t byte_count);

;; Performs a block writeback from L1D to L2. It can be used

;; on any address range (L2 or external), but it only operates on L1D

;; cache.

;;

;; Maximum block size is 256K. Exact maximum byte count depends on the

;; alignment of the block.

;;

;; Interrupts are disabled during the block writeback operation.

;; ======================================================================== ;;

.asg 0x01844040, L1DW ; L1D Block Wb; BAR at 0, WC at 1

.global _l1d_block_wb

.text

.asmfunc

_l1d_block_wb:

MVC DNUM, B0

; \_ Get global alias prefix

; /

; Get prefix from address

; Check if address prefix is global

ADDK 0x10, B0

SHRU A4, 24, B2

CMPEQ B0, B2, B0

[ B0] EXTU A4, 8, 8, A4 ; Remove global prefix from address

MVKL L1DW, B6 ;

CLR A4, 0, 5, A1

ADD A4, B4, B1

; Align to L1D cache line boundary

; Compute end of buffer

||

ADDK 63, B1

CLR B1, 0, 5, B1

; \_ Round to next L1D cache line

; /

SUB B1, A1, B1

MVKH L1DW, B6 ;

; Count cache-line span in bytes

||

SHR B1, 2, B1

DINT ; Disable interrupts

; Convert to "word count"

STW A1, *B6[0]

STW B1, *B6[1]

; Store base address

; Store word count

; Note: The following loop is intentionally low-rate to avoid

; interfering with the block writeback operation.

loop: LDW *B6[1], B1

NOP 4

[ B1] BNOP loop, 5

; Read remaining word-count

; Loop until done

RINT

RETNOP B3, 5

; Reenable interrupts

; Return to caller

.endasmfunc

;; ======================================================================== ;;

;; End of file: l1d_block_wb.asm ;;

;; ======================================================================== ;;

33

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

L1D Block Writeback-Invalidate Routine

;; ======================================================================== ;;

;; L1D Block Writeback-Invalidate

;;

l1d_block_wbinv(void *base, size_t byte_count);

;; Performs a block writeback-invalidate from L1D to L2. It can be used

;; on any address range (L2 or external), but it only operates on L1D

;; cache.

;;

;; Maximum block size is 256K. Exact maximum byte count depends on the

;; alignment of the block.

;;

;; Interrupts are disabled during the block writeback operation.

;; ======================================================================== ;;

.asg 0x01844030, L1DWI

.global _l1d_block_wbinv

.text

; L1D Block Wb-Inv; BAR at 0, WC at 1

.asmfunc

_l1d_block_wbinv:

MVC DNUM, B0

ADDK 0x10, B0

SHRU A4, 24, B2

CMPEQ B0, B2, B0

[ B0] EXTU A4, 8, 8, A4

MVKL L1DWI, B6 ;

; \_ Get global alias prefix

; /

; Get prefix from address

; Check if address prefix is global

; Remove global prefix from address

CLR A4, 0, 5, A1

ADD A4, B4, B1

; Align to L1D cache line boundary

; Compute end of buffer

||

ADDK 63, B1

CLR B1, 0, 5, B1

; \_ Round to next L1D cache line

; /

SUB B1, A1, B1

MVKH L1DWI, B6 ;

; Count cache-line span in bytes

||

SHR B1, 2, B1

DINT

; Convert to "word count"

; Disable interrupts

STW A1, *B6[0]

STW B1, *B6[1]

; Store base address

; Store word count

; Note: The following loop is intentionally low-rate to avoid

; interfering with the block writeback operation.

loop: LDW *B6[1], B1

NOP 4

[ B1] BNOP loop, 5

; Read remaining word-count

; Loop until done

RINT

RETNOP B3, 5

; Reenable interrupts

; Return to caller

.endasmfunc

;; ======================================================================== ;;

;; End of file: l1d_block_wbinv.asm ;;

;; ======================================================================== ;;

Workaround for "False Sharing"

This bug can occur when the CPU and the DMA both access distinct objects that share

a single L1D cache line. This is often referred to as "false sharing."

To avoid false sharing, ensure that the DMA buffers begin on 64-byte boundaries and

occupy a multiple of 64 bytes. This may require increasing the size of some DMA

buffers. If an application has many small DMA buffers, consider packing these together

to limit the overall growth in DMA buffer space implied by this workaround.

Workaround for Buffers that the CPU and DMA Access Asynchronously

While this situation is rare in most programs, there are some cases where both the CPU

and the DMA both access the same structure without explicit synchronization. In some

34

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications

cases, this is due to the fact that said accesses are part of an algorithm that implements

a synchronization primitive. Regardless of the purpose, these accesses potentially

trigger this bug.

The easiest way to avoid the bug with this case is to freeze the L1D whenever the CPU

reads this buffer. This prevents the buffer from allocating in the L1D cache so that the

DMA never sends a snoop (read or write) to the DMC on behalf of this buffer.

Alternately, programs can always invalidate the line in L1D after reading it so that all

writes to the line miss L1D and the line is never present and dirty in L1D cache.

Programs can use the L1D block invalidate (L1DIBAR/L1DIWC) or L1D block

writeback-invalidate (L1DWIBAR/L1DWIWC) to perform these explicit coherence

operations.

35

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

3

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional

Specifications

3.1 Silicon Revision 1.2 Usage Notes

Silicon revision 1.2 applicable usage notes have been found on a later silicon revision; for more detail, see

Section 2.1, Silicon Revision 2.0 Usage Notes, of this document.

3.2 Silicon Revision 1.2 Known Design Exceptions to Functional Specifications

lists the silicon revision 1.2 known design exceptions to functional specifications. Advisories are numbered

in the order in which they were added to this document. If the design exceptions are still applicable, the

advisories move up to the latest silicon revision section. If the design exceptions are no longer applicable

or if the information has been documented elsewhere, those advisories are removed. Therefore, advisory

numbering may not be sequential.

All other known design exceptions to functional specifications for silicon revision 1.2 still apply and have

been moved up to Section 2.2, Silicon Revision 2.0 Known Design Exceptions to Functional

Specifications, of this document.

Table 13. Silicon Revision 1.2 Advisory List

Title

Advisory

Advisory 6

Advisory 7

Advisory 8

Advisory 10

Advisory 12

Advisory 13

Advisory 14

Advisory 18

Advisory 19

Advisory 23

DSP SDMA/IDMA: Unexpected Stalling of SDMA/IDMA Access to L2 SRAM

Potential SerDes Clocking Issue

Potential Insertion or Deletion of 2 Bits in SerDes Data Stream

Atomic Operations Fail to Complete

PMC: Local Reset (lreset) Followed By Block Invalidate Hangs

PMC: L1P Cache Not Invalidated During lreset

UMC: L2MPFAR Fails to Log CPU Protection Faults Under Certain Conditions

PrivID For Non-CPU Masters Is Same as GEM0 CPU

UTOPIA Lock-Up Issue

DMA Access to L2 SRAM May Stall When the DMA Has Lower Priority Than the CPU

36

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

Advisory 6

DSP SDMA/IDMA: Unexpected Stalling of SDMA/IDMA Access to L2 SRAM

Revision(s) Affected:

Details:

1.2, 1.1, 1.0

NOTE: Only when DSP level 2 (L2) memory is configured as non-cache (RAM),

unexpected stalling may occur on DSP SDMA/IDMA accesses. If DSP L2

memory is used only as cache or if L2 RAM is not accessed by IDMA or

via the SDMA interface during run-time, then this exception does not

apply.

The C64x+ megamodule has a Master Direct Memory Access (MDMA) bus interface and

a Slave Direct Memory Access (SDMA) bus interface. The MDMA interface provides

DSP access to resources outside the C64x+ megamodule (i.e., DDR2 memory). The

MDMA interface is used for CPU/cache accesses to memory beyond the level 2 (L2)

memory level. These accesses include cache line allocates, write-backs, and

non-cacheable loads and stores to/from system memories. The SDMA interface allows

other master peripherals in the system to access level 1 data (L1D), level 1 program

(L1P), and L2 RAM DSP memories. The masters that are allowed to access these

memories are GEM megamodules, DMA controllers, TSIPs, EMAC, UTOPIA, HPI,

SRIO, and SRIO wrapper. The DSP Internal Direct Memory Access (IDMA) is a C64x+

megamodule DMA engine used to move data between internal DSP memories (L1, L2)

and/or the DSP peripheral configuration bus. The IDMA engine shares resources with

the SDMA interface.

The C64x+ megamodule has an L1D cache and an L2 cache, both of which implement

write-back data caches. The C64x+ megamodule holds updated values for external

memory as long as possible. It writes these updated values, called victims, to external

memory when it needs to make room for new data or when requested to do so by the

application or when a load is performed from a non-cacheable memory for which there is

a set match in the cache (i.e., the non-cacheable line would replace a dirty line if

cached). The L1D sends its victims to L2. The caching architecture has pipelining,

meaning multiple requests could be pending between L1, L2, and MDMA. For more

details on the C64x+ megamodule and its MDMA and SDMA ports, see the

TMS320C64x+ Megamodule Reference Guide (literature number SPRU871).

Ideally, the MDMA (the blue lines in Figure 7) and SDMA/IDMA paths (the orange lines

in Figure 7) operate independently with minimal interference. Normally, MDMA accesses

may stall for extended periods of time (clock cycles) due to expected system level delays

(e.g., bandwidth limitations, DDR2 memory refreshes). However, when using L2 as

RAM, SDMA and/or IDMA accesses to L2/L1 may experience unexpected stalling in

addition to the normal stalls seen by the MDMA interface. For latency-sensitive traffic,

the SDMA stall can result in missing real-time deadlines.

NOTE: SDMA/IDMA accesses to L1P/D will not experience an unexpected stall

if there are no SDMA/IDMA accesses to L2. Unexpected SDMA/IDMA

stalls to L1 happen only when they are pipelined behind L2 accesses.

Figure 7 is a simplified view for illustrative purposes only. The IDMA/SDMA path (orange

lines) can also go to L1D/L1P memories and IDMA can go to the DSP CFG peripherals.

MDMA transactions (blue lines) can also originate from L1P or L1D through the L2

controller or directly from the DSP.

37

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

RAM/

Cache

RAM/

Cache

ROM

256

Cache Control

Memory Protect

Bandwidth Mgmt

Cache Control

Memory Protect

Bandwidth Mgmt

L1P

L2

256

128

256

Power Down

Instruction Fetch

C64x + CPU

Interrupt

Controller

Register

File A

Register

File B

64

Bandwidth Mgmt

Memory Protect

Cache Control

32

CFG

256

Peripherals

EMC

L1D

MDMA

SDMA

128

8 x 32

128

EDMA Master

Peripherals

RAM/

Cache

CPU/Cache Access Origination

Master Peripheral Origination

Figure 7. IDMA, SDMA, and MDMA Paths

38

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

SDMA/IDMA stalls may occur during the following scenarios. Each of these scenarios

describes expected normal DSP functionality, but the SDMA/IDMA access potentially

exhibits additional unexpected stalling.

1. Bursts of writes to non-cacheable MDMA space (i.e., DDR2). The DSP buffers up to

4 non-cacheable writes. When this buffer fills, SDMA/IDMA is blocked until the buffer

is no longer full. Therefore, bursts of non-cacheable writes longer than three writes

can stall SDMA/IDMA traffic.

2. Various combinations of L1 and L2 cache activity:

(a) L1D read miss generating victim traffic to L2 (cache or SRAM) or external

memory. The SDMA/MDMA may be stalled while servicing the read miss and the

victim. If the read miss also misses L2 cache, the SDMA/IDMA may be stalled

until data is fetched from external memory to service the read miss. If the read

access is to non-cacheable memory, there will still potentially be an L1D victim

generated even though the read data will not replace the line in the L1D cache.

(b) L1D read request missing L2 (going external) while another L1D request is

pending. The SDMA/IDMA may be stalled until the external memory access is

complete.

(c) L2 victim traffic to external memory during any pending L1D request. The

SDMA/IDMA may be stalled until external memory access and the pending L1D

request are complete.

The duration of the SDMA/IDMA stalls depends on the quantity/characteristics of the

L1/L2 cache and the MDMA traffic in the system. In cases 2a, 2b, and 2c, stalling may or

may not occur depending on the state of the cache request pipelines and the traffic

target locations. These stalling mechanisms may also interact in various ways, causing

longer stalls. Therefore, it is difficult to predict if stalling will occur and for how long.

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

occurring include lower-than-expected peripheral throughput or loss of I/O data.

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 external memory or non-local L2, TSIP Tx/Rx data transfer or an EMAC

Tx/Rx/CPPI transfer or UTOPIA Tx/Rx transfers, SRIO Tx/RX/CPPI message

transfers, SRIO direct IO accesses, or HPI accesses). 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 writing 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: 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

39

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

the source of the problem.

An extreme consequence of the IDMA/SDMA stall bug is the C64x+ MDMA-SDMA

deadlock that requires a device reset or power cycle in order for the system to recover.

The following summarizes the deadlock conditions:

•

Master(s) on a single main MSCR port write to the GEM's SDMA followed by a write

to slaveX

•

The GEM issues victim traffic to slaveX

Any one of the following (see Figure 8):

–

A write data path pipelined in main MSCR between master(s) and the GEM's

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

GEM's SDMA.

A load (either cacheable or non-cacheable) from another core's L1D or L2 memory can

additionally create a deadlock condition. When the load is issued, the read command is

propagated to the SDMA port of the other core through a shared cross-connect bridge

that is shared with either TC0 or TC1 and GEM MDMA traffic from two other GEMs.

When the load is issued, if a victim is generated in L1D cache, then the SDMA may stall

until the load completes. If other masters are issuing commands through the shared

cross-connect bridge, then the bridge may fill due to the stalled SDMA before the read

command can propagate through the bridge and complete. The C6472 device has two

cross-connect bridges (Xconn1 and Xconn2). GEMs 0, 1, 2, and TC0 use cross-connect

bridge 1. GEMs 3, 4, 5, and TC1 use cross-connect bridge 2. In summary, a deadlock

can occur if the following is true:

•

GEMx issues a read to any of other GEM's L1D or L2 SRAM through cross-connect

bridge 1 or 2.

•

Any of the other GEMs or TCx on the same cross-connect bridge issue commands to

GEMx L2.

#

.

Bridge B2

(M/P) : (M)

VBUS#

Master A

*

.

M

SCR*

GEM -

SDMA

#

.

VBUS#

Master B

*

Satellite SCR

Main

MSCR

SlaveX

VBUSM

Master C

GEM -

MDMA

* denotes M or P.

Figure 8. Data Pipelined SCR

40

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

Workarounds:

Method 1

To reduce the SDMA/IDMA stalling system impact, perform any of the following:

1. Improve system tolerance on DMA side (SDMA/IDMA/MDMA):

•

Understand and minimize latency-critical SDMA/IDMA accesses to L2 or L1P/D.

Directly reduce critical real-time deadlines, if possible, at peripheral/IO level (e.g.,

increase word size and/or reduce bit rates on serial ports).

To reduce DSP MDMA latency:

•

–

Increase the priority of the DSP access to DDR2 such that MDMA latency of

MDMA accesses causing stalls is minimized.

Note: Other masters may have real-time deadlines that dictate higher priority

than the DSP.

–

Lower the PRIO_RAISE field setting in the DDR2 memory controller's burst

priority register. Values ranging between 0x10 and 0x20 should give decent

performance and minimize latency; lower values may cause excessive

SDRAM row thrashing.

2. Minimize offending scenarios on DSP/caching side:

•

If the DSP performing non-cacheable writes is causing the issue, insert protected

non-cacheable reads (as shown in the last list item below) every few writes to

allow the write buffer to empty.

Use explicit cache commands to trigger cache writebacks during appropriate

times (L1D Writeback All, L2 Writeback All). Do not use these commands when

real-time deadlines must be met.

Restructure program data and data flow to minimize the offending cache activity.

–

Define the read-only data as const. The const C keyword tells the compiler

not to write to the array. By default, such arrays are allocated to the .const

section as opposed to BSS. With a suitable linker command file, the

developer can link the .const section off chip, while linking .bss on chip.

Because programs initialize .bss at run time, this reduces the program's

initialization time and total memory image.

–

Explicitly allocate lookup tables and writeable buffers to their own sections.

The #pragma DATA_SECTION (label, section) directive tells the compiler to

place a particular variable in the specified COFF section. The developer can

explicitly control the layout of the program with this directive and an

appropriate linker command file.

Avoid directly accessing data in slow memories (e.g., flash); copy at

initialization time to faster memories.

•

Modify troublesome code.

–

Rewrite using DMAs to minimize data cache writebacks. If the code accesses

a large quantity of data externally, consider using DMAs to bring in the data,

using double buffering and related techniques. This will minimize cache

write-back traffic and the likelihood of SDMA/IDMA stalling.

–

Re-block the loops. In some cases, restructuring loops can increase reuse in

the cache and reduce the total traffic to external memory.

Throttle the loops. If restructuring the code is impractical, then it is reasonable

to slow it down. This reduces the likelihood that consecutive SDMA/IDMA

blocks stack up in the cache request pipelines, resulting in a long stall.

•

41

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Protect non-cacheable reads from generating an SDMA stall by freezing the L1D

cache during the non-cacheable read access(es). The following example code

contains a function that protects non-cacheable reads, avoids blocking during the

reads, and, therefore, avoids the deadlock state.

;; ======================================================================== ;;

;; Long Distance Load Word

;;

int long_dist_load_word(volatile int *addr)

;;

;; This function reads a single word from a remote location with the L1D

;; cache frozen. This prevents L1D from sending victims in response to

;; these reads, thus preventing the L1D victim lock from engaging for the ;;

;; corresponding L1D set.

;;

;; The code below does the following:

;;

1. Disable interrupts

2. Freeze L1D

3. Load the requested word

4. Unfreeze L1D

5. Restore interrupts

;; Interrupts are disabled while the cache is frozen to prevent affecting ;;

;; the performance of interrupt handlers. Disabling interrupts during

;; the long distance load does not greatly impact interrupt latency,

;;

;; because the CPU already cannot service interrupts when it's stalled by ;;

;; the cache. This function adds a small amount of overhead (~20 cycles) ;;

;; to that operation.

;;

;; ======================================================================== ;;

.asg 0x01840044, L1DCC ; L1D Cache Control

.global _long_dist_load_word

.text

.asmfunc

; int long_dist_load_word(volatile int *addr)

_long_dist_load_word:

MVKL

MVKH

DINT

MVK

STW

LDW

NOP

SHR

LDW

NOP

STW

RET

LDW

NOP

RINT

L1DCC,

B4

||

; Disable interrupts

1,

B5

*B4

B5

B5,

*B4,

4

B5,

*A4,

4

B5,

B3

*B4,

4

; \_ Freeze cache

; /

16,

B5

A4

; POPER -> OPER

; read value remotely

||

*B4

B5

; \_ Restore cache

; /

; Restore interrupts

.endasmfunc

;; ======================================================================== ;;

;; End of file: ldld.asm ;;

;; ======================================================================== ;;

In the C6472 multi-core device, when one GEM is accessing another GEM's L1 or L2

memory it is an MDMA access, so the potential SDMA/IDMA stall can occur. The stall

can be avoided by using the EDMA to transfer data from one GEM's memory to another.

42

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

Method 2

Entirely eliminate the exception by removing all SDMA/IDMA accesses to L2 SRAM. For

example, EMAC descriptors and EMAC payload cannot reside in L2. Master peripherals

like the EDMA/QDMA, IDMA, and SRIO cannot access L2. There are no issues with the

CPU itself accessing code/data in L2. This issue only pertains to SDMA/IDMA accesses

to L2.

Dataflow Requirements

To avoid the issue due to a C64x+ deadlock, workarounds depend on the

CPU/peripheral bus master that is accessing the GEM internal or external memory:

CPU/PERIPHERAL BUS

MASTER

WORKAROUND

GEM

GEMs should not write to the memory of any other GEM. GEMs must not directly read from the

memory of any other GEMs without providing the L1D cache disable workaround, mentioned in

Method 1, to ensure that the load will not stall itself indefinitely and hang the system.

EDMA3TCx

Inbound and outbound traffic should be programmed on different TC ports(i.e., two different

EDMA queues, since a given queue maps to a given TC). Any TC used to write to DDR should

not be used to write to a GEM even when the TC writing to the DDR is also reading from the

DDR.

TSIP0,1,2

All TSIPs (0, 1, 2) should either write to the GEM's memory or the DDR, but not both.

SRIO, SRIO CPPI

SRIO should transfer payload data to only the GEM memories or to the DDR2 SDRAM, but not

both. This includes any direct I/O writes as well as any inbound receive messaging transfers.

SRIO CPPI descriptors should be placed wholly in the local wrapper memory, any combination of

wrapper and L2 memory, or any combination of wrapper and DDR2 SDRAM. Buffer descriptors

should not be placed in any combination of L2 and DDR2 SDRAM.

EMAC0, EMAC1, UTOPIA, HPI All four masters should write to the GEM's memory or the DDR, but not both. This includes

buffers and buffer descriptors of EMAC and any writes issued by the host. EMAC CPPI

descriptors should be placed wholly in local wrapper memory, any combination of wrapper and L2

memory, or any combination of wrapper and DDR2 SDRAM.

43

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 7

Potential SerDes Clocking Issue

Revision(s) Affected:

Details:

1.2, 1.1, 1.0

A bug has been found in the SerDes interfaces that causes a SerDes clocking problem

in normal functional operation. This problem will not occur when external pull-down is

applied on the TCK pin (JTAG controller clock).

The TCK pin (JTAG controller clock) is internally assigned to an internal signal that is

used by the SerDes macro. For the SerDes macro to get proper clocking in the normal

functional operation, it needs the internal signal to be held low. However, there is an

internal pull-up on the TCK, creating problems for SerDes operation.

Workaround:

The TCK pin should be externally pulled down with a 1-kΩ resistor.

44

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

Advisory 8

Potential Insertion or Deletion of 2 Bits in SerDes Data Stream

Revision(s) Affected:

Details:

1.2, 1.1, 1.0

For arbitrary phase mode, a FIFO function is integrated into the SerDes TX serializer.

This FIFO has three states (minus1, center, plus1) and is supposed to be reset to the

center state at startup. From this position, the SerDes is then tolerant to variations of

phase between the input clock (TXBCLKIN) and the SerDes internal clock, caused by

temperature and voltage variations. However, as a result of a logic bug, the possibility

exists that under some circumstances, the FIFO may not start in the center state. When

this happens, there is a risk that the FIFO may subsequently overflow or underflow.

Whether the FIFO fails to initialize to the center state depends on the timing

relationships between several signals, including the SerDes internal clock. Even if the

FIFO initializes to the center state, the FIFO will only underflow or overflow if the phase

relationship between the TXBCLKIN input and the internal SerDes clock vary (due to

temperature or voltage changes) in such a way as to cause their edges to cross in one

particular direction. Overflow results in two bits being added to the data stream.

Underflow results in two bits being deleted. If overflow or underflow occurs at all, it only

happens once per TX lane because after it has occurred the FIFO is configured exactly

as if it had initialized to the center state at startup.

The precise silicon process of the device will also be a factor in whether the overflow or

underflow occurs. Some devices may exhibit this behavior at some particular PVT

combinations, others may never exhibit it. It is not possible to predict whether, or under

what conditions, a device is susceptible. If overflow or underflow occur, it could be at any

time ranging from immediately after startup to weeks, months, or years later.

Workaround:

SRIO has an auto-recovery in silicon rev. 1.0 and 1.1. Auto-recovery resets the link and

re-exposes the issue. TI is working to understand the likelihood of repeated recovery and

whether there could be performance impacts due to repeated recovery.

45

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 10

Atomic Operations Fail to Complete

Revision(s) Affected:

Details:

1.2, 1.1, 1.0

In the C6472 device atomic access monitors are located only in the shared-memory

controller. These monitors assure that only the correct sequence of accesses are

successful. Successful completion of atomic operations requires the successful

completion of a sequence of load-linked (LL), store-linked (SL), and commit-linked

(CMTL) instructions to a single address by a single CPU. The atomic operation

instructions were intended to temporarily freeze the cache for execution of those

instructions, in all respects. However, the implicit cache freezing functionality is

incomplete due to an internal exception. Therefore, for the accesses to be successful,

the L1D cache must be explicitly temporarily frozen around the execution of these

instructions to ensure that the accesses generated by these instructions are made all the

way to the shared-memory controller. Since the L1D memory controller (DMC) does not

completely disable the cache functionality for these instructions resulting in a failure to

complete, explicit disables and, possibly, re-enables of the L1D cache around these

instructions must be provided by the software.

Workaround:

Reference implementations of atomic add and atomic exchange that incorporate

workarounds for atomic operations and L1D freeze mode are provided below. Since the

L1D cache lines must be explicitly frozen, the memory objects of the atomic access

instructions should be the only thing stored in a 64B L1D cache line (i.e., normal reads

and writes should not be performed to the remaining locations in the same L1D cache

line).

;Atomically add A4 to the value pointed to by B4. Returns the sum.

;This is a C-callable function as written.

; int atomic_add(int value, volatile int *sema)

;

.asg 0x01840044, L1DCC

.global _atomic_add

_atomic_add:

MV A4, B5 ; Copy value to exchange to B side.

MVKL L1DCC, A5 ; \_ L1D cache control for freezing

MVKH L1DCC, A5 ; / and unfreezing L1D.

||

MVK 1, A0 ; Value to put into L1DCC.OPER for freeze.

loop:

||

STW .D1T1 A0, *A5 ; Freeze L1D.

DINT ; Disable interrupts.

LDW .D1T1 *A5, A2 ; Get previous freeze. Stall until frozen.

[!A0] MVK .D2 0, B1 ; (block EDI)

LL .D2 *B4, B6 ; Establish monitor and get old value.

[!A0] MVK .D2 0, B1 ; (block EDI)

NOP 3 ; wait for LL to complete.

ADD .D2 B5, B6, B7 ; Add new value to old *and* block EDI.

SL .D2 B7, *B4 ; Store new value to monitor.

[!A0] MVK .D2 0, B1 ; (block EDI)

CMTL.D2 *B4, B0 ; Attempt to commit.

[!A0] MVK .D2 0, B1 ; (block EDI)

SHRU A2, 16, A2 ; Shift L1DCC.POPER down to L1DCC.OPER.

STW .D1T1 A2, *A5 ; Restore previous frozen/non-frozen state.

RINT ; Restore interrupts

;; ==== Interrupt may occur here prior to issuing branch.

[!B0] BNOP.S2 loop, 0 ; Loop if it didn't commit.

||

MV B7, A4 ; Copy sum to return register.

[ B0] BNOP.S2 B3, 5 ; Return if it did commit.

;; ==== Interrupt may occur here prior to reaching branch target.

;; ==== Branch occurs.

; Atomically exchange the value pointed to by B4 with the value in A4.

; This is a C-callable function as written.

46

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

;

; int atomic_exhange(int value, volatile int *sema)

;

.asg 0x01840044, L1DCC

.global _atomic_exchange

_atomic_exchange:

MV A4, B5 ; Copy value to exchange to B side.

MVKL L1DCC, A5 ; \_ L1D cache control for freezing

MVKH L1DCC, A5 ; / and unfreezing L1D.

||

MVK 1, A0 ; Value to put into L1DCC.OPER for freeze.

loop:

||

STW .D1T1 A0, *A5 ; Freeze L1D.

DINT ; Disable interrupts.

LDW .D1T1 *A5, A2 ; Get previous freeze. Stall until frozen.

[!A0] MVK .D2 0, B1 ; (block EDI)

LL .D2 *B4, B6 ; Establish monitor and get old value.

[!A0] MVK .D2 0, B1 ; (block EDI)

SL .D2 B5, *B4 ; Store new value to monitor.

[!A0] MVK .D2 0, B1 ; (block EDI)

CMTL.D2 *B4, B0 ; Attempt to commit.

[!A0] MVK .D2 0, B1 ; (block EDI)

SHRU A2, 16, A2 ; Shift L1DCC.POPER down to L1DCC.OPER.

STW .D1T1 A2, *A5 ; Restore previous frozen/non-frozen state.

RINT ; Restore interrupts.

;; ==== Interrupt may occur here prior to issuing branch.

[!B0] BNOP.S2 loop, 0 ; Loop if it didn't commit.

||

MV B6, A4 ; Copy exchanged value to return register.

[ B0] BNOP.S2 B3, 5 ; Return if it did commit.

;; ==== Interrupt may occur here prior to reaching branch target.

;; ==== Branch occurs.

47

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 12

PMC: Local Reset (lreset) Followed By Block Invalidate Hangs

Revision(s) Affected:

Details:

1.2, 1.1, 1.0

The PMC never goes into idle when lreset is followed by a programmed block invalidate

without sufficient delay. The L1PINV command issued to the PMC is not acknowledged

until the CFG request is read in. When combined with an lreset, the PMC treats it as a

new L1PINV command every cycle and the invalidation counter never increments. The

result is a deadlock.

Workaround:

Ensure that 2Kb CPU cycles have elapsed after beginning execution at the reset vector

before an L1PINV is issued. The minimum number of CPU cycles is decided by the time

duration for the global cache invalidation to finish before a new L1PINV starts.

Note: Advisories 12 and 13 must be used together.

48

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

Advisory 13

PMC: L1P Cache Not Invalidated During lreset

Revision(s) Affected:

Details:

1.2, 1.1, 1.0

The PMC is supposed to perform cache invalidation on lreset. However, due to an

internal exception, the PMC may drop cache invalidate on lreset and the remaining

addresses are skipped from invalidation.

Workaround:

The code that is located at the lreset start address, beginning of the local L2 memory by

default, must perform a complete invalidation of the L1P before proceeding.

Note: Advisories 12 and 13 must be used together.

49

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 14

UMC: L2MPFAR Fails to Log CPU Protection Faults Under Certain Conditions

1.2, 1.1, 1.0

Revision(s) Affected:

Details:

When a CPU memory protection fault on a UMAP0 access occurs in the same cycle as

a DMA memory protection fault on a UMAP1 access, the DMA fault information, rather

than the CPU fault information, is logged in L2MPFAR and L2MPFSR.

Workaround:

There is no workaround for this advisory.

50

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

Advisory 18

PrivID For Non-CPU Masters Is Same as GEM0 CPU

Revision(s) Affected:

Details:

1.2, 1.1, 1.0

The GEM0 CPU and all non-EDMA system masters on the device are assigned the

same privilege ID. (The EDMA inherits the privilege ID from the programming GEM.)

This requires the software to take corrective actions to differentiate memory accesses

from the GEM0 CPU and the non-CPU peripheral masters when a memory access

violation occurs. Note: Within GEM0, the CPU generated accesses are identified as

local, although IDMA accesses are recognized as PrivID=0 accesses. This provides

some distinction between true CPU accesses and non-EDMA system masters for GEM0.

Workaround:

A partial workaround is to keep the non-GEM traffic always as user access and the

GEM0 traffic always as supervisor access. In that case, AID0 supervisor transactions are

known to be GEM0 CPU and AID0 user transactions are known to be non-CPU and

non-EDMA peripheral masters. Note: If the HPI/SRIO are configured as supervisors for

host accesses to on-chip memory and certain MMRs, then it is not possible to

distinguish between GEM0 supervisor traffic and HPI/SRIO traffic.

51

SPRZ300–October 2009

Submit Documentation Feedback

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

www.ti.com

Advisory 19

UTOPIA Lock-Up Issue

Revision(s) Affected:

Details:

1.2, 1.1, 1.0

A PDMA issue could cause the UTOPIA receive cell buffer in memory to become

corrupted and UTOPIA and PDMA to stop transmitting and receiving cells. UTOPIA and

PDMA must be reset through the PSC and reconfigured to restart operation.

Workaround(s):

A partial workaround is to perform a software recovery. A lock-up detection and UTOPIA

reset routine on the C6472 device can recover the lockup. Lock-up detection can be

performed by a polling routine running at 1-kHz frequency. When the lockup occurs, no

calls are lost; no calls must be torn down and setup again. The detection and recovery

procedure is:

1. Core y detects a cell with a bad header and signals Core A through the IPC.

2. Core A disables the UTOPIA, closes all DMA channels (on all cores), and executes a

reset of UTOPIA through the PSC.

3. Core A signals all other cores to perform a local UTOPIA restart through the IPC.

4. Core A waits for all other cores to acknowledge the restart.

5. Core A performs a global UTOPIA enable.

In addition to the software recovery, the following three optional workarounds could

reduce the risk of UTOPIA lock-up occurrence.

1. One cell per block for transmits.

(a) One transmit block with multi-cells could block a PDMA receive channel from

winning arbitration to copy data from the UTOPIA receive FIFO to the PDMA

receive channel buffer in time to avoid a super-sized cell. The maximum block

time depends on the number of cells in the block due to the PDMA arbitration

mechanism.

(b) One-cell transmit reduces the time until the PDMA re-arbitrates between the

receive and transmit channels. The re-arbitration enables the blocked receive

channel to win the grant.

(c) The implementation of one-cell transmit is purely software based and has minimal

impact on UTOPIA throughput.

2. Any two cells that arrive in the UTOPIA are sent to different PDMA channels. This

cuts the available bandwidth in half, but it prevents the problem.

3. Set the UCLK at the lowest possible speed without impacting the system

performance. The lower the UCLK speed, the higher the tolerance for stalls. The

chance for lockup is significantly reduced.

52

TMS320C6472 DSP

Silicon Revisions 2.0, 1.2, 1.1, 1.0

SPRZ300–October 2009

Submit Documentation Feedback

www.ti.com

Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications

Advisory 23

DMA Access to L2 SRAM May Stall When the DMA Has Lower Priority Than the

CPU