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 Copyright © 2009, Texas Instruments Incorporated 1 1.1 1.2 1.3 2 ........................................................................................................................ 5 Device and Development Support Tool Nomenclature ............................................................. 5 Package Symbolization and Revision Identification ................................................................ 6 Silicon Updates .......................................................................................................... 8 Introduction 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 Device: Heatsink/Airflow Recommended to Lower Case Temperature .............................. 9 2.1.2 EMAC: Gigabit Mode Cannot Be Used With CPU Running at Speeds Lower Than 375 MHz .... 9 2.1.3 2.1.4 2.2 3 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 Silicon Revision 2.0 Known Design Exceptions to Functional Specifications .................................. 11 Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications ........................................................................................................................................ 36 3.1 Silicon Revision 1.2 Usage Notes ................................................................................... 36 3.2 Silicon Revision 1.2 Known Design Exceptions to Functional Specifications .................................. 36 4 Silicon Revision 1.1 Usage Notes and Known Design Exceptions to Functional Specifications ........................................................................................................................................ 54 4.1 Silicon Revision 1.1 Usage Notes ................................................................................... 54 4.2 Silicon Revision 1.1 Known Design Exceptions to Functional Specifications .................................. 54 5 Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications ........................................................................................................................................ 56 5.1 Silicon Revision 1.0 Usage Notes ................................................................................... 56 5.2 Silicon Revision 1.0 Known Design Exceptions to Functional Specifications .................................. 56 SPRZ300 – October 2009 Submit Documentation Feedback Table of Contents Copyright © 2009, Texas Instruments Incorporated 3 www.ti.com List of Figures ....................................................... 1 Lot Trace Code Examples for TMS320C6472 (ZTZ Package) 2 L1D Cache Address Mapping............................................................................................ 21 3 Cache Line Operations Flow ............................................................................................. 22 4 L1D Cache Address Mapping............................................................................................ 29 5 Sequence of Events ....................................................................................................... 30 6 Decision Tree .............................................................................................................. 31 7 IDMA, SDMA, and MDMA Paths ........................................................................................ 38 8 Data Pipelined SCR ....................................................................................................... 40 9 Daisy-Chain Example ..................................................................................................... 57 10 Expected Customer Implementation .................................................................................... 59 11 Requested Implementation Change 12 Interim Workaround for Silicon Revision 1.0 ........................................................................... 60 13 Bitmap Memory Address Translation ................................................................................... 63 14 Bitmap Memory Corruption Example ................................................................................... 63 .................................................................................... 6 59 List of Tables Lot Trace Codes 2 Silicon Revision Registers ................................................................................................. 7 3 Megamodule Revision Registers.......................................................................................... 7 4 Silicon Revisions 2.0, 1.2, 1.1, and 1.0 Updates 5 6 7 8 9 10 11 12 13 14 15 16 17 4 ............................................................................................................ 1 ....................................................................... 200-μs Delay Calculated Values .......................................................................................... 7.8125-μs Interval Calculated Values ................................................................................... Silicon Revision 2.0 Advisory List ....................................................................................... C6472 Default Master Priorities ......................................................................................... C6472 UMAP1 Allocation ................................................................................................ Value of X for L1D Cache ................................................................................................ Value of X for L1D Cache ................................................................................................ Expected vs. Actual Data Values ....................................................................................... Silicon Revision 1.2 Advisory List ....................................................................................... C6472 Default Master Priorities ......................................................................................... Silicon Revision 1.1 Advisory List ....................................................................................... Silicon Revision 1.0 Advisory List ....................................................................................... I2C Parameter Table for EMAC Boot ................................................................................... List of Figures 6 8 9 10 11 19 20 21 29 30 36 53 54 56 58 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated 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 Experimental device that is not necessarily representative of the final device's electrical specifications TMP Final silicon die that conforms to the device's electrical specifications but has not completed quality and reliability verification TMS 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 5 Introduction 1.2 www.ti.com 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 20 2.0 Silicon revison 2.0 12 1.2 Silicon revision 1.2 11 1.1 Silicon revision 1.1 10 1.0 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 Copyright © 2009, Texas Instruments Incorporated Introduction www.ti.com Table 2. Silicon Revision Registers SILICON REVISION SILICON REVISION ID REGISTER (02A8 070Ch) JTAG ID REGISTER VALUE (02A8 0008h) 2.0 0020 0091h 2009 102Fh MAJOR REVISION (bits 23:20): 2h VARIANT (bits 31:28): 2h MINOR REVISION (bits 19:16): 0h 1.2 0012 0091h 1009 102Fh MAJOR REVISION (bits 23:20): 1h VARIANT (bits 31:28): 1h MINOR REVISION (bits 19:16): 2h 1.1 0011 0091h 0009 102Fh MAJOR REVISION (bits 23:20): 1h VARIANT (bits 31:28): 0h MINOR REVISION (bits 19:16): 1h 1.0 0010 0091h 0009 102Fh MAJOR REVISION (bits 23:20): 1h VARIANT (bits 31:28): 0h MINOR REVISION (bits 19:16): 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 2.0 MEGAMODULE REVISION ID REGISTER (0181 2000h) CPU REVISION (CPU CSR Register) 0001 0004h CPU ID (bits 31:24): 10h VERSION (bits 31:16): 0001h REVISION ID (bits 23:16): 00h REVISION (bits 15:0): 0004h 1.2 0001 0003h CPU ID (bits 31:24): 10h VERSION (bits 31:16): 0001h REVISION ID (bits 23:16): 00h REVISION (bits 15:0): 0003h 1.1 0001 0003h CPU ID (bits 31:24): 10h VERSION (bits 31:16): 0001h REVISION ID (bits 23:16): 00h REVISION (bits 15:0): 0003h 1.0 0001 0003h CPU ID (bits 31:24): 10h VERSION (bits 31:16): 0001h REVISION ID (bits 23:16): 00h REVISION (bits 15:0): 0003h SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 7 Introduction 1.3 www.ti.com 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 SILICON UPDATE ADVISORY APPLIES TO SILICON REVISON 2.0 1.2 1.0 SEE SRIO: Packet-Forwarding NREAD Operations Larger Than 16 Bytes Fail X Advisory 1 RGMII EMAC: Boot Start-Up Issue X Advisory 2 DDR2 EMIF: Clock Synchronization Issue X Advisory 3 TSIP: Receive Channel 4 Bitmap Corruption Issue X Advisory 4 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 X X Advisory 6 Potential SerDes Clocking Issue X X X Advisory 7 Potential Insertion or Deletion of 2 Bits in SerDes Data Stream X X X Advisory 8 I2C Slave Boot Does Not Work Atomic Operations Fail to Complete EMU: Emulation Access Can Corrupt CPU Operation X X X Advisory 9 X X X Advisory 10 X X X Advisory 11 PMC: Local Reset (lreset) Followed By Block Invalidate Hangs X X X Advisory 12 PMC: L1P Cache Not Invalidated During lreset X X X Advisory 13 UMC: L2MPFAR Fails to Log CPU Protection Faults Under Certain Conditions X X X Advisory 14 CPU: Back-to-Back SPLOOPs With Interrupts Can Cause Incorrect Operation on C64x+ CPU X X X X Advisory 16 CPU: C64x+ CPU Incorrectly Generates False Exceptions for Multiple Writes X X X X Advisory 17 X X X Advisory 18 PrivID For Non-CPU Masters Is Same as GEM0 CPU UTOPIA Lock-Up Issue X X X Advisory 19 DDR2 EMIF Buffers Not Totally Compensated by Default X X X X Advisory 20 SRIO Port 0 Reset Affects Other Ports X X X X Advisory 21 SRIO OUTBOUND_ACKID Field Not Read Correctly X X X X Advisory 22 X X X Advisory 23 DMA Access to L2 SRAM May Stall When the DMA Has Lower Priority Than the CPU 8 1.1 DMA Access to L2 SRAM May Stall When the DMA and the CPU Command Priority is Equal X X X X Advisory 24 DMA Corruption of External Data Buffer X X X X Advisory 25 DMA Corruption of L2 RAM Data X TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Advisory 26 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated 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 REFRESH_RATE 3.75 ns 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 9 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 REFRESH_RATE 3.75 ns 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 tRP + tRCD + tWR. • While the high-priority read is waiting for tWTR to expire, the tRAS expires 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. • tRAS is smaller than tWTR + 4 + CasLatency - 1. The above conditions result in the following behaviors: • Since tRAS expires before tWTR, the low-priority request to precharge the bank is performed before a read can be fired. • After tRP expires, the bank is re-activated due to the high-priority read. • If a write comes in on the cycle just after the tRCD expires, it will go through this loop again. If more single-word writes arrive just after the tRCD expires, 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 (tRP + tRCD + tWR) / 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 tRAS value 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 Copyright © 2009, Texas Instruments Incorporated www.ti.com 2.2 Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications 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 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 Advisory Advisory 11 Advisory 16 Advisory 17 Advisory 20 Advisory 21 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 Advisory 22 Advisory 24 Advisory 25 Advisory 26 SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 11 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: 2.0, 1.2, 1.1, 1.0 Details: 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 16 CPU: Back-to-Back SPLOOPs With Interrupts Can Cause Incorrect Operation on C64x+ CPU Revision(s) Affected: 2.0, 1.2, 1.1, 1.0 Details: 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 13 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 Revision(s) Affected: 2.0, 1.2, 1.1, 1.0 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 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: 14 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). TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 15 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: 2.0, 1.2, 1.1, 1.0 Details: 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: 16 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. TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Sample code: /* Define the following variables. */ Uint32 tempData0, tempData1; /* Define the following pointers to compensate the address buffers. */ Uint32 *pDdr2Data_temp0 = (Uint32 *) 0xEAAAAAA8; Uint32 *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; /* DDR2 memory write */ tempData1 = *pDdr2Data_temp0; /* DDR2 memory read */ /* Perform two more writes with a 0x55555555 and 0xAAAAAAAA pattern to complete the compensation cycle. */ tempData0 = 0x55555555; *pDdr2Data_temp1 = tempData0; /* DDR2 memory write */ tempData0 = 0xAAAAAAAA; *pDdr2Data_temp0=tempData0; /* DDR2 memory write */ SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 17 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: 2.0, 1.2, 1.1, 1.0 Details: 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: 2.0, 1.2, 1.1, 1.0 Details: 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 24 DMA Access to L2 SRAM May Stall When the DMA and the CPU Command Priority is Equal Revision(s) Affected: 2.0, 1.2, 1.1, 1.0 Details: 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 MASTER DEFAULT MASTER PRIORITIES (0 = Highest priority, 7 = Lowest priority) PRIORITY CONTROL EDMA3TCx 0 QUEPRI.PRIQx (EDMA3 register) SRIO (Data Access) 0 PER_SET_CNTL.CBA_TRANS_PRI (SRIO register) EMAC 7 PRI_ALLOC.EMAC HPI 7 PRI_ALLOC.HOST UTOPIA - PDMA 1 PRI_ALLOC.UTOPIAPDMA TSIP 7 DMACTL (TSIP register) C64x+ Megamodule (MDMA port) 7 MDMAARBE.PRI (C64x+ Megamodule register) C64x+ Megamodule (CPU Arbitration control to L2) 1 CPUARBU (C64x+ Megamodule register) C64x+ Megamodule (IDMA channel 1) 0 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 19 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: 2.0, 1.2, 1.1, 1.0 Details: 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com of two addresses. The mapping of an address to a location in L1D cache is shown in Figure 2. 31 X+1 Tag X 6 Set 4 2 1 0 Offset Sub-line Bank Byte 5 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 N/A 4KB 10 8KB 11 16KB 12 32KB 13 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 21 Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications UMAP0 www.ti.com UMAP1 External Buffer L1D t2 Clean t3 CPU Read (L2 Cache) Corruption t0 DMA Write (Snoop Write) t1 t0: DMA Write t0: DMA Write t1: CPU Allocate t1: CPU Allocate t2: Allocation Data t2: Snoop Write t3: Snoop Write t3: Allocation Data Incorrect Order 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 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. 2. 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. 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 .asmfunc _l1d_block_wbinv: MVC DNUM, B0 ADDK 0x10, B0 ; L1D Block Wb-Inv; BAR at 0, WC at 1 ; \_ Get global alias prefix ; / SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 23 Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications SHRU A4, 24, B2 CMPEQ B0, B2, B0 [ B0] EXTU A4, 8, 8, A4 MVKL L1DWI, B6 CLR A4, 0, 5, A1 || ADD A4, B4, B1 ADDK 63, B1 CLR B1, 0, 5, B1 www.ti.com ; Get prefix from address ; Check if address prefix is global ; Remove global prefix from address ; ; Align to L1D cache line boundary ; Compute end of buffer ; \_ 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 ; Read remaining word-count NOP 4 [ B1] BNOP loop, 5 ; 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com NOP 4 MV.L A1, B1 STB B1, *B4++[B5] SPKERNEL RETNOP B3, 5 .endasmfunc ;; ======================================================================== ;; ;; End of file: make_dirty.asm ;; ;; ======================================================================== ;; NOTE: 1. 2. 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. 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 SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 25 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 ; \_ Freeze cache LDW *B4, B5 ; / NOP 4 SHR B5, 16, B5 ; POPER -> OPER || LDW *A4, A4 ; read value remotely NOP 4 STW B5, *B4 ; \_ Restore cache RET B3 || LDW *B4, B5 ; / NOP 4 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. ;; ;; ------------------------------------------------------------------------ ;; Copyright (c) 2009 Texas Instruments, Incorporated. ;; All Rights Reserved. ;; ======================================================================== ;; .asg .asg .asg .asg .asg .asg .asg .asg .asg 0x01820100, 0x01820108, 0x0182010C, 0x01820110, 0x01820100, (IDMA1_STATUS - IDMA1_BASE), (IDMA1_SOURCE - IDMA1_BASE), (IDMA1_DEST - IDMA1_BASE), (IDMA1_COUNT - IDMA1_BASE), IDMA1_STATUS IDMA1_SOURCE IDMA1_DEST IDMA1_COUNT IDMA1_BASE OFS_IDMA1_STATUS OFS_IDMA1_SOURCE OFS_IDMA1_DEST 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com ;; ;; 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 ; truncate word count to 14 bits STW A6, *A7 .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 || MVK 1, A0 loop?: [ A0] LDW *A6, A0 ||[ A0] BNOP.1 loop?, 4 ; 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 ;; ;; ======================================================================== ;; SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 27 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: 2.0 Details: Under a specific set of circumstances, a snoop-write updates an unintended L2 RAM location. This is a result of a corrupted L1D cache writeback, and can lead directly to program misbehavior. If that line is then modified by CPU accesses, a subsequent victim writeback from L1D could commit this corrupted line to lower levels of memory. Three key requirements for this bug are: • The DMA reads or writes to buffers in L2 SRAM. – This must be cached and modified in L1D (read and written by the CPU). • The CPU reads from any L2 or external, cacheable address. • A second DMA write to the same cache line address (within 64B) in L2 RAM that the CPU is reading from. NOTE: 1. 2. For information on L1D cache coherence protocol, see section 3.3.6, Cache Coherence Protocol, in the C64x+ DSP Megamodule Reference Guide (SPRU871). 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 31 X+1 X Tag 6 Set 4 2 1 0 Offset Sub-line Bank Byte 5 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 N/A 4KB 10 8KB 11 16KB 12 32KB 13 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 29 Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com UMAPx SRAM L1D t2 t1 Dirty t3 Corruption t0 CPU Read (L2 Cache) t3¢ DMA Write (Snoop Write) t4 t0: CPU Allocate t0: CPU Allocate t1: Victim Start t1: Victim Start t2: Allocation Data t2: Allocation Data t3: DMA Write (SNPW) t4: Victim Done t4: Victim Done t3: DMA Write (SNPW) Incorrect Order 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 (1) EXPECTED ACTUAL Buffer A A′′′ B′′ Buffer B B′′ B (1) 30 Key: A, B = Original data A′ = CPU-written data A′′, B′′ = DMA-written data A′′′ = CPU- and DMA-written data, properly merged TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated SPRZ300 – October 2009 Submit Documentation Feedback Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 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 OK IsIsthe CPU reading CPU reading fromthis thisbuffer? buffer? from Y N OK Is CPU writing Is the CPU reading to this from this buffer? buffer? Y N OK Is CPU reading Does the DMA access from this buffer? the same buffer (read or write) ? Y OK Y CPU reading IsIsthere a software from this buffer? to control mechanism force buffer ownership between the CPU and the DMA through WB/invalidate ? 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: Workarounds: 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). 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 SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 31 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 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 ADDK 0x10, B0 SHRU A4, 24, B2 CMPEQ B0, B2, B0 [ B0] EXTU A4, 8, 8, A4 MVKL L1DW, 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 L1DW, B6 ; ; Count cache-line span in bytes || || SHR B1, 2, B1 ; Convert to "word count" DINT ; 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 ; Read remaining word-count NOP 4 [ B1] BNOP loop, 5 ; Loop until done RINT RETNOP B3, 5 ; Reenable interrupts ; Return to caller .endasmfunc ;; ======================================================================== ;; ;; End of file: l1d_block_wb.asm ;; ;; ======================================================================== ;; SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 33 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 ; L1D Block Wb-Inv; BAR at 0, WC at 1 .global _l1d_block_wbinv .text .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 ; Read remaining word-count NOP 4 [ B1] BNOP loop, 5 ; 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 2.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 35 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 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 Advisory Advisory 6 Advisory 7 Advisory 8 Advisory 10 Advisory 12 Advisory 13 Advisory 14 Advisory 18 Advisory 19 Advisory 23 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 6 DSP SDMA/IDMA: Unexpected Stalling of SDMA/IDMA Access to L2 SRAM Revision(s) Affected: 1.2, 1.1, 1.0 Details: 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 37 Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications RAM/ Cache RAM/ Cache 256 ROM 256 Cache Control Memory Protect L1P 256 256 Cache Control 256 Memory Protect Bandwidth Mgmt www.ti.com L2 Bandwidth Mgmt 256 128 256 256 Power Down Instruction Fetch Interrupt Controller Register File A IDMA C64x + CPU Register File B 64 64 Bandwidth Mgmt CFG 256 Memory Protect L1D Cache Control MDMA 8 x 32 32 Peripherals EMC SDMA 128 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 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 SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 39 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. VBUS# Master A # . . * Bridge B2 (M/P) : (M) SCR* VBUS# Master B # . . * * . . M GEM SDMA 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 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. • SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 41 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 .global _long_dist_load_word .text .asmfunc ; int long_dist_load_word(volatile int *addr) _long_dist_load_word: MVKL L1DCC, B4 MVKH L1DCC, B4 || DINT || MVK 1, B5 STW B5, *B4 LDW *B4, B5 NOP 4 SHR B5, 16, B5 || LDW *A4, A4 NOP 4 STW B5, *B4 RET B3 || LDW *B4, B5 NOP 4 RINT .endasmfunc ; L1D Cache Control ; Disable interrupts ; \_ Freeze cache ; / ; POPER -> OPER ; read value remotely ; \_ Restore cache ; / ; Restore interrupts ;; ======================================================================== ;; ;; 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 43 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: 1.2, 1.1, 1.0 Details: 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: 44 The TCK pin should be externally pulled down with a 1-kΩ resistor. TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 8 Potential Insertion or Deletion of 2 Bits in SerDes Data Stream Revision(s) Affected: 1.2, 1.1, 1.0 Details: 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 45 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: 1.2, 1.1, 1.0 Details: 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 ; MVKL L1DCC, MVKH L1DCC, MVK 1, A0 ; Copy value to exchange to B side. A5 ; \_ L1D cache control for freezing A5 ; / and unfreezing L1D. 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com ; ; int atomic_exhange(int value, volatile int *sema) ; .asg 0x01840044, L1DCC .global _atomic_exchange _atomic_exchange: || || MV A4, B5 ; MVKL L1DCC, MVKH L1DCC, MVK 1, A0 ; Copy value to exchange to B side. A5 ; \_ L1D cache control for freezing A5 ; / and unfreezing L1D. 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 47 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: 1.2, 1.1, 1.0 Details: 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 13 PMC: L1P Cache Not Invalidated During lreset Revision(s) Affected: 1.2, 1.1, 1.0 Details: 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 49 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 Revision(s) Affected: 1.2, 1.1, 1.0 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 18 PrivID For Non-CPU Masters Is Same as GEM0 CPU Revision(s) Affected: 1.2, 1.1, 1.0 Details: 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. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 51 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: 1.2, 1.1, 1.0 Details: 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 Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.2 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 23 DMA Access to L2 SRAM May Stall When the DMA Has Lower Priority Than the CPU Revision(s) Affected: 1.2, 1.1, 1.0 Details: 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 14. More details on the bandwidth management feature can be found in the C64x+ Megamodule Reference Guide (SPRU871). Table 14. C6472 Default Master Priorities DEFAULT MASTER PRIORITIES (0 = Highest priority, 7 = Lowest priority) MASTER PRIORITY CONTROL EDMA3TCx 0 QUEPRI.PRIQx (EDMA3 register) SRIO (Data Access) 0 PER_SET_CNTL.CBA_TRANS_PRI (SRIO register) EMAC 7 PRI_ALLOC.EMAC HPI 7 PRI_ALLOC.HOST UTOPIA - PDMA 1 PRI_ALLOC.UTOPIAPDMA TSIP 7 DMACTL (TSIP register) C64x+ Megamodule (MDMA port) 7 MDMAARBE.PRI (C64x+ Megamodule register) C64x+ Megamodule (CPU Arbitration control to L2) 1 CPUARBU (C64x+ Megamodule register) C64x+ Megamodule (IDMA channel 1) 0 IDMA1_COUNT (C64x+ Megamodule register) To enable bandwidth management, the L2 memory controller has an internal (non-user visible) counter that counts MAXWAIT every cycle that a DMA command is blocked because of a CPU access. When the internal counter reaches the MAXWAIT threshold, it is supposed to stay saturated at that value and force the DMA access to win arbitration over the CPU. In the case where DMA priority is less than CPU priority, the internal counter does not saturate at the MAXWAIT threshold value. Instead, it wraps around and keeps counting, thereby, giving more bandwidth to the CPU than intended by the MAXWAIT threshold value. The result is that the DMA may lose to the CPU over multiple arbitration cycles. This typically happens when CPU accesses keep the L2 memory controller busy every cycle; for example, a continuous stream of L1D write misses to L2. Workaround: Set the CPU at a lower priority than the DMA commands to L2. The priority for CPU accesses to L2 is in a programmable register, CPUARBU, in the GEM. However, lowering the CPU priority may impact the performance since CPU accesses to L2 may stall due to DMA accesses, in case of contention. This bug has been fixed on silicon revision 2.0. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 53 Silicon Revision 1.1 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 4 Silicon Revision 1.1 Usage Notes and Known Design Exceptions to Functional Specifications 4.1 Silicon Revision 1.1 Usage Notes Silicon revision 1.1 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. 4.2 Silicon Revision 1.1 Known Design Exceptions to Functional Specifications lists the silicon revision 1.1 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.1 still apply and have been moved up to Section 3.2, Silicon Revision 1.2 Known Design Exceptions to Functional Specifications, or Section 2.2, Silicon Revision 2.0 Known Design Exceptions to Functional Specifications, of this document. Table 15. Silicon Revision 1.1 Advisory List Title I2C Slave Boot Does Not Work 54 Advisory Advisory 9 TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.1 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 9 I2C Slave Boot Does Not Work Revision(s) Affected: 1.1, 1.0 Details: I2C Slave Boot is intended to speed the boot process for a system with more than two devices by allowing a single master read of the I2C EEPROM followed by a broadcast by that master to all remaining devices on the I2C bus. However, during the I2C slave boot process an internal exception is encountered causing the boot sequence to abort on the slave device(s). Consequently, I2C slave boot does not complete. Workaround: Use I2C master boot for all devices in the system. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 55 Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com 5 Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications 5.1 Silicon Revision 1.0 Usage Notes Silicon revision 1.0 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. 5.2 Silicon Revision 1.0 Known Design Exceptions to Functional Specifications lists the silicon revision 1.0 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.0 still apply and have been moved up to Section 4.2, Silicon Revision 1.1 Known Design Exceptions to Functional Specifications, Section 3.2, Silicon Revision 1.2 Known Design Exceptions to Functional Specifications, or Section 2.2, Silicon Revision 2.0 Known Design Exceptions to Functional Specifications, of this document. Table 16. Silicon Revision 1.0 Advisory List Title SRIO: Packet-Forwarding NREAD Operations Larger Than 16 Bytes Fail RGMII EMAC: Boot Start-Up Issue DDR2 EMIF: Clock Synchronization Issue TSIP: Receive Channel 4 Bitmap Corruption Issue Device Configuration: HOUT is Not Generated When HPI is Disabled 56 TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Advisory Advisory 1 Advisory 2 Advisory 3 Advisory 4 Advisory 5 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 1 SRIO: Packet-Forwarding NREAD Operations Larger Than 16 Bytes Fail Revision(s) Affected: 1.0 Details: Packet forwarding uses programmable look-up tables to direct incoming packets to an outbound port when the packets do not belong to the local device. Packet forwarding is carried out at the logical layer of the serial RapidIO (SRIO) without the interaction of the CPU. The SRIO logical layer copies incoming packets from an inbound buffer to an outbound buffer. When used for packet forwarding, it forwards all types of packets, including response, maintenance, DOORBELL, and message packets. The current SRIO design fails to correctly copy response packets with a payload greater than 16 bytes from the inbound to the outbound buffer. The first 16 bytes are correctly copied, but the remainder of the payload is discarded. This issue affects only NREAD response packets since their payloads can be up to 256 bytes. Packet types with small responses, such as NWRITE_R, maintenance, message, and DOORBELL packets are not affected by this issue. Workaround: 1: Use a data push model, where each device in the daisy chain only submits write requests. Using this approach will avoid the issue and provide the lowest latency solution. Workaround: 2: Two options exist if NREAD response packets cannot be avoided; for example, when reading core dump information from an unresponsive processor which is unable to initiate traffic by itself. The first option is to use software to segment read requests into 16-byte NREADs. Note that this option will work functionally, but may take too much time. The second option is illustrated in Figure 9. Network/ System Host Port 0 Port 1 DSP 1 Port 0 Port 1 DSP 2 Port 0 DSP 3 Figure 9. Daisy-Chain Example In this example, assume that DSP3 is down and the system host wants to do a large NREAD of DSP3 to examine the core dump. The issue discussed above prohibits the NREAD from completing correctly because, as the response packets from DSP3 are sent back, they are corrupted by DSP2 and DSP1 packet forwarding. Instead, the system host needs to request that the adjacent DSP (DSP2) generates the NREAD request to DSP3. The NREAD responses are sent to DSP2 and temporarily stored in memory. Then, DSP2 can generate NWRITE/NWRITE_R/SWRITE packets to the system host with the needed payload. These packets are correctly forwarded by DSP1 to the system host since they are request packets and not responses. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 57 Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 2 RGMII EMAC: Boot Start-Up Issue Revision(s) Affected: 1.0 Details: The RGMII EMAC boot mode in the C6472 will fail to transmit an Ethernet-ready frame when that boot mode is selected by the BOOTMODE[3:0] pins at device reset. In most systems, the host that is responsible for sending the boot table will not send the table until it sees the Ethernet-ready frame. Workarounds: Three workarounds could be used to address this issue: 1. Select one of the I2C master boots. Program the selected parameter table in the I2C device to select EMAC boot as the extended boot mode type. Table 17 is a parameter table that selects the EMAC boot mode. The minimum set of parameters also includes the chip PLL multiplier, which allows this mode to automatically set the multiplier value as required by the DDR clock issue alert for use of external memory. More detailed information on programming the I2C parameter tables for additional boot configuration requirements can be found in the TMS320C6472 Bootloader User’s Guide (literature number SPRUTBD). Table 17. I2C Parameter Table for EMAC Boot OFFSET VALUE 0x00 0x000A Parameter table is 10 bytes 0x02 0xFED2 1's complement checksum 0x04 0x0105 EMAC boot 0x06 0x0000 Port 0 0x001E PLL multiplier is x30 (Assumes CLKIN1=16.667MHz and PG1.0 silicon) 0x08 COMMENTS 2. Have the host that is responsible for sending the boot table broadcast a small boot table with the program that is shown in the example below. This causes any C6472 devices that have not sent an Ethernet-ready frame and have not begun to receive boot table packets to restart the EMAC boot procedure and transmit the Ethernet-ready frame. Boot Restart Code warm_restart .equ mvkl mvkh bnop nop 0x00100110 #warm_restart, b0 #warm_restart, b0 b0, 5 3. If the host responsible for sending the boot table already knows the identity of all devices it is responsible to boot, then the host can begin sending the boot table packets after some customer TBD delay following a device reset. Under typical conditions, the device will be ready to receive EMAC boot packets within 2 ms following the deassertion of reset. 58 TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 3 DDR2 EMIF: Clock Synchronization Issue Revision(s) Affected: 1.0 Details: The DDR2 EMIF in the C6472 device requires that specific consideration be given to the DDR2 clock with respect to the CPU clock, in order to successfully complete all writes to external memory. When independent clock sources are used for CLKIN1 (CHIP clock) and CLKIN3 (DDR2 clock), writes to the DDR2 external memory may be corrupted in certain situations. Workaround: Provide a single clock source to both CLKIN1 and CLKIN3 and set the PLL1 multiplier to multiply CLKIN1 by x30. The selected frequency should be 16.67 MHz and the PLL1 multiplier should be set to multiply CLKIN1 by x30. This will create a 500-MHz clock to each CPU. The DDR2 data rate, which has a fixed multiply by x20 of CLKIN3, will be 333 MHz. The following three figures help illustrate the likely hardware changes. Figure 10 shows the clock source diagram that TI expects most customers have implemented. Figure 11 shows the requested implementation change. Figure 12 shows the workaround implementation requirement. C6472 25-MHz clock oscillator CLKIN1 (CHIP PLL) PLL multiply: x20 CLKIN2 (EMAC PLL) PLL multiply: x20 (fixed) 26.67-MHz clock oscillator CLKIN3 (DDR PLL) PLL multiply: x20 (fixed) Figure 10. Expected Customer Implementation 25-MHz clock oscillator C6472 0W CLKIN1 (CHIP PLL) PLL multiply: x20 CLKIN2 (EMAC PLL) PLL multiply: x20 (fixed) 26.67-MHz clock oscillator CLKIN3 (DDR PLL) PLL multiply: x20 (fixed) Figure 11. Requested Implementation Change SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 59 Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com C6472 25-MHz clock oscillator CLKIN1 (CHIP PLL) PLL multiply: x30 0W CLKIN2 (EMAC PLL) PLL multiply: x20 (fixed) 16.67-MHz clock oscillator CLKIN3 (DDR PLL) PLL multiply: x20 (fixed) Figure 12. Interim Workaround for Silicon Revision 1.0 60 TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 4 TSIP: Receive Channel 4 Bitmap Corruption Issue Revision(s) Affected: 1.0 Details: The bitmap memory for receive channel 4 will be corrupted if an error occurs on any TSIP channel. This results in the receive data for channel 4 (associated with GEM4) being lost for frame intervals beginning with the first error until the issue is addressed and the receive channel 4 bitmap has been reinitialized and activated. Corruption is due to a double translation of the address going to the memory used for bitmaps and error queues (see Figure 13). Figure 14 shows a bitmap memory snapshot where the TSIP receive channel 4 bitmap has been corrupted. If an error occurs during execution of the normal application, then a TSIP error interrupt is asserted for every channel that experiences an error. This error interrupt is asserted to the corresponding DSP subsystem. The DSP subsystem that receives the error interrupt must correct the error condition to avoid prolonged loss of data on its own channel as well as on channel 4. When DSP subsystem 4 receives an error it must determine whether the error is due to its own failure and, if it is, that error must be corrected first. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 61 Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications Un-optimized Solution TX0 Intended Single Translation TX0 A 512B A www.ti.com Incorrect Double Translation TX0 A B B TX1 TX1 TX1 TX2 TX2 TX2 TX3 TX3 TX3 TX4 TX4 TX4 TX5 TX5 TX5 Not Used RX4 RX4 + Eq Not Used RX5 RX5 RX0 RX0 RX0 RX1 RX1 RX1 RX2 RX2 RX2 RX3 RX3 RX3 RX4 Eq Not Used B 1024B RX5 Eq Not Used Figure 13. Bitmap Memory Address Translation 62 TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Errors logged in channel 0 error queue. Errors (code=0x10) are due to bitmap CID mismatch in the transmit channel. Errors logged in channel 4 error queue. Errors (code=0x03) are due to bitmap and buffer size mismatch in the receive channel. Figure 14. Bitmap Memory Corruption Example Workaround: The following describes the two-part Workaround 1. Fix the application code or use condition that is responsible for generating the TSIP error. This requires examination of the TSIP error registers for all the channels. 2. Re-initialize the receive channel 4 bitmap after the error condition is rectified. Regardless of the cause of the failure, DSP subsystem 4 must re-initialize the content of its bitmap memory. The re-initialization of its bitmap memory must start with the A set. SPRZ300 – October 2009 Submit Documentation Feedback TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 Copyright © 2009, Texas Instruments Incorporated 63 Silicon Revision 1.0 Usage Notes and Known Design Exceptions to Functional Specifications www.ti.com Advisory 5 Device Configuration: HOUT is Not Generated When HPI is Disabled Revision(s) Affected: 1.0 Details: HOUT is a host output signal that is pulsed by a write to IPCGR15, which is a register in the CRLF. HOUT is placed in a high-impendence state when HPI is disabled in the system. This occurs even though HOUT is functionally independent of HPI. Workaround: HPI must remain enabled if HOUT is used, even if there is no plan to use HPI. Since the I/O buffers for HPI are on when HPI is enabled, board resistors should be used to pull all HPI I/O buffers to the 3.3-V supply rail or to ground. The preferred direction of the resistors is the same as the internal pull resistors that are present when HPI is disabled. 64 TMS320C6472 DSP Silicon Revisions 2.0, 1.2, 1.1, 1.0 SPRZ300 – October 2009 Submit Documentation Feedback Copyright © 2009, Texas Instruments Incorporated IMPORTANT NOTICE Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements, and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders and should verify that such information is current and complete. All products are sold subject to TI’s terms and conditions of sale supplied at the time of order acknowledgment. TI warrants performance of its hardware products to the specifications applicable at the time of sale in accordance with TI’s standard warranty. Testing and other quality control techniques are used to the extent TI deems necessary to support this warranty. Except where mandated by government requirements, testing of all parameters of each product is not necessarily performed. TI assumes no liability for applications assistance or customer product design. Customers are responsible for their products and applications using TI components. To minimize the risks associated with customer products and applications, customers should provide adequate design and operating safeguards. TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right, copyright, mask work right, or other TI intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information published by TI regarding third-party products or services does not constitute a license from TI to use such products or services or a warranty or endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of the third party, or a license from TI under the patents or other intellectual property of TI. Reproduction of TI information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations, and notices. Reproduction of this information with alteration is an unfair and deceptive business practice. TI is not responsible or liable for such altered documentation. Information of third parties may be subject to additional restrictions. Resale of TI products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service and is an unfair and deceptive business practice. TI is not responsible or liable for any such statements. TI products are not authorized for use in safety-critical applications (such as life support) where a failure of the TI product would reasonably be expected to cause severe personal injury or death, unless officers of the parties have executed an agreement specifically governing such use. Buyers represent that they have all necessary expertise in the safety and regulatory ramifications of their applications, and acknowledge and agree that they are solely responsible for all legal, regulatory and safety-related requirements concerning their products and any use of TI products in such safety-critical applications, notwithstanding any applications-related information or support that may be provided by TI. Further, Buyers must fully indemnify TI and its representatives against any damages arising out of the use of TI products in such safety-critical applications. TI products are neither designed nor intended for use in military/aerospace applications or environments unless the TI products are specifically designated by TI as military-grade or "enhanced plastic." Only products designated by TI as military-grade meet military specifications. Buyers acknowledge and agree that any such use of TI products which TI has not designated as military-grade is solely at the Buyer's risk, and that they are solely responsible for compliance with all legal and regulatory requirements in connection with such use. TI products are neither designed nor intended for use in automotive applications or environments unless the specific TI products are designated by TI as compliant with ISO/TS 16949 requirements. Buyers acknowledge and agree that, if they use any non-designated products in automotive applications, TI will not be responsible for any failure to meet such requirements. Following are URLs where you can obtain information on other Texas Instruments products and application solutions: Products Amplifiers Data Converters DLP® Products DSP Clocks and Timers Interface Logic Power Mgmt Microcontrollers RFID RF/IF and ZigBee® Solutions amplifier.ti.com dataconverter.ti.com www.dlp.com dsp.ti.com www.ti.com/clocks interface.ti.com logic.ti.com power.ti.com microcontroller.ti.com www.ti-rfid.com www.ti.com/lprf Applications Audio Automotive Broadband Digital Control Medical Military Optical Networking Security Telephony Video & Imaging Wireless www.ti.com/audio www.ti.com/automotive www.ti.com/broadband www.ti.com/digitalcontrol www.ti.com/medical www.ti.com/military www.ti.com/opticalnetwork www.ti.com/security www.ti.com/telephony www.ti.com/video www.ti.com/wireless Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265 Copyright © 2009, Texas Instruments Incorporated