AN5295
AN5295
SRIO A-004034 SRIO downtrains to 2x or 1x, or may Perform software re-training P2040/P2041
fail to complete link initialization sequence P4080
P3041
P5020
SRIO A-004042 An SRIO port enabled for 2x Perform software re-training P2040/P2041
operation may fail to train when sequence P3041
connected to a device which supports P5020
2x, but is operating in 1x mode
SRIO-A006 SRIO 1x and 2x operation may see Set the platform frequency to the P2040/P2041
excess errors on Rx with low platform minimum safe platform frequency P4080 Rev 2.0
frequencies of operation P3041
P5020 Rev 1.0
SerDes SerDes Ring VCO does not maintain For SRIO 2.5 Gbaud or 5 Gbaud T4240
A-007186 lock throughout specified protocols that use the Ring VCO, T2080
temperature range use the alternate protocols that B4860
use the LC VCO instead.
SerDes SerDes 2 LC VCO does not work for Override LC VCO in SerDes PLL T2080
A-007809 SRDS_PRTCL_S2=0x29 (SRIO1 and register
SRIO2 3.125 Gbaud)
SerDes 8 Interfering SerDes PLLs can result in Use only SerDes protocol P4080
jitter increase combinations supported on P4080
(see AN4065)
SerDes 9 Intermittent SerDes lane training Override SerDes bank register P4080
failure when a differential signal from and perform software re-training
a connected device is not received sequence
on SD_RXn/SD_RXn pins
SerDes Internal tracking loop can falsely lock Override default settings in P2040/P2041
A-004580 causing unrecoverable bit errors SerDes bank registers P3041
P4080
P5020
SerDes A-006 SerDes 3.125 Gbaud is not supported Use the higher voltage alternate P2040/P2041 Rev 1.0
device part number to operate at P3041 Rev 1.0
3.125 Gbaud P5020 rev 1.0
2 Hardware issues
2.1 Clocking
SerDes clocking restrictions allow each SRIO protocol a set of valid SerDes reference clocks that depend
on the protocol speed. For the T- and B-series devices, reference clock selection is made in the RCW field
SRDS_PLL_REF_CLK_SEL_Sn. Additionally, selection between 5 Gbaud and 2.5 Gbaud is made in the
SRDS_DIV_SRIO_Sn field. For the P-series devices, the desired SRIO speed is based on the
SRDS_RATIO_Bn and SRDS_DIV_Bn fields, which determine the SerDes clock ratio and divider.
SerDes clocking restriction examples for the T4240 and P4080 are shown in Figure 1 and Figure 2.
To ensure proper SerDes clocking, the user must:
1. Provide a valid SerDes clock input for the selected SRIO speed.
2. Program the RCW fields for the selected SRIO speed.
3. Ensure the actual SerDes clock input frequency is the same as selected SerDes clock frequency.
The SerDes PLL supply provides power to the analog portions of the SerDes PLL. To ensure stability of
the internal clock, the power supplied to the SerDes PLL must be filtered. In general, T-series devices
require the AVDD_SDn_PLLn to be a filtered version of XnVDD, while P-series devices require the
SerDes PLL supply voltage (AVDD_SRDSn) to be a filtered version of SnVDD. Figure 4 shows an
example PLL filtering scheme.
In the example below, an IO error response will be generated on an outbound NREAD request with the
following settings:
Example 1. Misaligned ATMU window
• SRIO outbound window base address 0xAC000000
• SRIO outbound translation address 0x10800000
• SRIO outbound window size 16 MB
In this example, the ATMU translation address is not properly aligned to the window size. The address
0x10800000 is not evenly divisible by 16 MB. An example of a properly aligned translation address is
0x14000000.
To avoid memory mapping issues, the user must:
1. Ensure the TLB effective and real addresses are aligned to the window size.
2. Ensure the LAW addresses are aligned to the window size.
3. Ensure the ATMU base and translation starting addresses are aligned to the window size.
4. Ensure there is no overlap between the TLB/LAW/ATMU windows.
5. Ensure each ATMU and TLB space is covered by a LAW entry.
4 Software issues
4.1 Errors during initial training sequence
During initialization, both sides of the link send the idle sequences to align the recovered sampling clock.
Once a sufficient number of error-free characters is received, the inbound link becomes operational. The
port is allowed to transmit after a number of status control symbols have been received from the connected
device. When both sides can reliably receive error-free characters, the link is considered operational.
During the initial training sequence when a device powers up or is reset, it is quite common for some errors
to occur. These errors are expected while the SerDes clock and data recovery loop locks on the incoming
data stream. After the ports are initialized, link training errors should be cleared before beginning normal
operation.
After initial link training completes, the user should:
1. Confirm the Error and Status Command and Status Register ESCSR[PO] = 1 and ESCSR[PU] = 0
to indicate the input and output ports have been initialized and are exchanging error-free control
symbols with the connected device.
2. Clear the errors in the registers shown in Table 3:
Table 3. Registers to clear after link initialization
Register Action
ESCSR Write to clear all port error bits. Only PO should be set to
indicate input and output ports are OK.
Register Action
information locked in the capture registers ECACSR, PCSECCSR0, and PECCSR1:3. After the error is
detected and reported, software can then determine the source of the error, make the appropriate
adjustments or fixes to remedy the issue, and recover from the error so normal operation can resume.
Error rate counters and threshold registers are also available to report errors when the error count reaches
a level that the system considers to be unacceptable. For example, if poor performance is observed, the
counting of the number of packet-not-accepted control symbols can be enabled in the ERECSR[PNA].
This would allow software to determine if there is a high rate of packet-not-accepted returned by the
connected device.
To enable error detection/reporting, the user should configure the registers with suggested settings shown
in Table 4.
Table 4. Registers to enable error detection and reporting
ERECSR Enable all port errors to be detected and Check EDCSR for the reported errors.
reported. Check ECACSR, PCSECCSR0, PECCSR1:3 for
the captured error information.
ERCSR Set the ERR field to 0b11 to not limit Check the ERCSR[ERC] field for the error count
incrementing the port error rate count. of transmission errors.
ERTCSR Set the ERFTT and ERDTT fields to 0x01 to When the ERFTT is exceeded, the ESCSR[OFE]
set the failed threshold trigger and degraded bit is set to indicate output port encountered a
threshold triggers, respectively, to 1. failed condition.
PRETCR Set the RET field to 0xF to generate an error When the RET is exceeded, the ECSR[RETE] bit
interrupt when the number of consecutive is set.
physical retry errors exceed this threshold.
LTLEECSR Enable all logical layer errors to be detected Check LTLEDCSR for the reported errors.
and reported. Check LTLACCSR, LTLDIDCCSR, LTLCCCSR
for the captured error information.
LRETCR Set the RET field to 0xF to generate an error When RET is exceeded, the LTLEDCSR[RETE]
interrupt when the number of consecutive bit is set.
logical retry errors exceed this threshold.
2. Request is ACK’d
For proper usage of the time-out counters for detection of lost packets, the user should follow these
guidelines:
1. Enable error reporting of port link time-out errors in the Error Rate Enable Command and Status
Register (ERECSR[LTO]). This allows detection of an acknowledge or link-response control
symbol that is not received within the time-out interval in PLTOCCSR. The link time-out event is
indicated in the Error Detect Command and Status Register (EDCSR).
a) Read the first four bytes of the captured control character and control symbol information in
the Packet/Control Symbol Error Capture Command and Status Register (PCSECCSR0).
b) Read bytes 4-15 in the Packet Error Capture Command and Status Registers (PECCSR[1:3]).
2. Enable error reporting of packet response time-out errors in the Logical/Transport Layer Error
Enable Command and Status Register (LTLEECSR[PRT]). This allows detection of a response
packet that is not received within the time-out interval in PRTOCCSR. The packet response
time-out event is indicated in the Logical/Transport Layer Error Detect Command and Status
Register (LTLEDCSR[PRT]).
a) Read the captured address associated with the error in the Logical/Transport Layer Address
Capture Command and Status Register (LTLACCSR).
b) Read the captured source and destination IDs associated with the error in the
Logical/Transport Layer Device ID Capture Command and Status Register (LTLDIDCCSR).
c) Read the captured format and transaction type in the Logical/Transport Layer Control
Command and Status Register (LTLCCCSR).
3. Enable error reporting of packet time-to-live errors in LTLEECSR[PTTL]. This allows detection
of a packet that is not received within the time-out interval in LOPTTLCR. The packet
time-to-live time-out event is indicated in LTLEDCSR[PTTL].
a) Read the captured error information in LTLACCSR, LTLDIDCCSR, and LTLCCCSR.
4. Set the time-out intervals long enough to prevent false time-out errors to be signaled.
5. Ensure the LOPTTLCR value is larger than the PLTOCCSR value.
6. Do not change the time-out counters while there are transmit packets in the SRIO pipeline.
7. Clear the PCR[OBDEN] output buffer drain bit after the LOPTTLCR expires. The OBDEN is
automatically set when the packet time-to-live timer expires, causing the packets from the
outbound buffer to be drained and not be transmitted. Packets will not be sent out until software
clears the OBDEN.
5 Revision history
This table provides a revision history for this document.
Table 6. Document revision history
Rev.
Date Substantive change(s)
number
Web Support: information in this document. NXP reserves the right to make changes without further
nxp.com/support notice to any products herein.
NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD,
COOLFLUX, EMBRACE, GREENCHIP, HITAG, I2C BUS, ICODE,
JCOP, LIFE VIBES, MIFARE, MIFARE CLASSIC, MIFARE DESFire, MIFARE PLUS,
MIFARE FLEX, MANTIS, MIFARE ULTRALIGHT, MIFARE4MOBILE, MIGLO, NTAG,
ROADLINK, SMARTLX, SMARTMX, STARPLUG, TOPFET, TRENCHMOS, UCODE,
Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire,
ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV,
mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, Ready Play,
SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit,
BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine, SMARTMOS,
Tower, TurboLink, and UMEMS are trademarks of NXP B.V. All other product or service
names are the property of their respective owners. . Oracle and
Java are registered trademarks of Oracle and/or its affiliates. The Power Architecture
and Power.org word marks and the Power and Power.org logos and related marks are
trademarks and service marks licensed by Power.org.