Hardware Debug - 12.0 English

Most fields in the AMD Vivado™ Integrated Design Environment (IDE) have tool tips serving as guidelines to properly configure and generate the core.

Observe and follow all RECOMMENDED and IMPORTANT notes in product guides.

As the transceiver is the critical building block in the Aurora 64B/66B core, debugging and ensuring proper operation of the transceiver is extremely important. The following figure shows the steps involved in debugging transceiver-related issues.

This section provides a debug flow diagram for resolving some of the most common issues. See GT_Debug_Flowchart for transceiver debugging mentioned in the following Answer Record:

Answer Record: 57237

The Transceiver Debug ports mentioned in Table 1 are operational when you enable the Additional Transceiver Control and Status Ports option in Aurora 64B/66B interface. Refer to Aurora 64B/66B IP Example design for recommended connections for additional transceiver control and status ports in the following guides:

• 7 Series FPGAs GTX/GTH Transceivers User Guide (UG476)
• UltraScale Architecture GTH Transceivers User Guide (UG576)
• UltraScale Architecture GTY Transceivers User Guide (UG578)
• Versal Adaptive SoC GTY and GTYP Transceivers Architecture Manual (AM002)
• Versal Adaptive SoC GTM Transceivers Architecture Manual (AM017)

Figure 1. Transceiver Debug Flow Chart

Transceiver Attribute Check

Transceiver attributes must match with the silicon version of the device being used on the board. Apply all the applicable workarounds and Answer Records given for the relevant silicon version.

GT REFCLK and GT PLL LOCK Check

A low-jitter differential clock must be provided as the transceiver reference clock. Ensure that REFCLK location constraints are correct with respect to the board schematics. REFCLK should be active and should meet the phase noise requirements of the transceiver. Ensure that the transceiver locks into the incoming GT REFCLK and asserts the gt_pll_lock signal. This signal is available in the Aurora 64B/66B example design. If the gt_pll_lock signal is toggling periodically, check if FSM_RESETDONE is also toggling. Ensure that the GT PLL attributes are set correctly and that the transceiver generates txoutclk with the expected frequency for the given line rate and datapath width options. The Aurora 64B/66B core uses channel PLL/Quad PLL (CPLL/QPLL) in the generated core for GTX or GTH transceivers.

GT TX/RX RESETDONE Check

The transceiver generates txoutclk based on the line rate parameter. The user_clk signal is generated from txoutclk and the Aurora 64B/66B core uses it as an FPGA logic clock. Check that user_clk is generated properly with the expected frequency from txoutclk. If the user_clk frequency is not in the expected range, check the frequency of the transceiver reference clock and PLL attributes.

MMCM Lock Check

Aurora 64B/66B cores expect all clocks to be stable. If clocks are generated using an MMCM, ensure the reset inputs are held High until the generated clock is stable. It is recommended to stop the output clock from the MMCM until it is locked. This can be accomplished by using a BUFGCE with the output clock where clock enable (CE) is driven by the MMCM lock output. If the MMCM_LOCK signal is toggling periodically, check if the TX_STARTUP_FSM is restarting and probe the signals and states of the FSM.

BLOCK SYNC Check

See the block sync algorithm described in the Aurora 64B/66B Protocol Specification (SP011) for block sync done.

LANE_UP Assertion Check

Assertion of the lane_up signal indicates the communication between the transceiver and its channel partner is established and link training is successful. Enable loopback mode and check for lane_up assertions. Bring the LANE_INIT_SM module FSM state signals to debug if lane_up is not asserted. See the Lane Initialization Procedure in the Aurora 64B/66B Protocol Specification (SP011) for lane_up assertion details.

Single Lane

CHANNEL_UP Assertion Check

The criteria for channel_up signal assertion are the verification sequence (defined in the Aurora 64B/66B protocol) being transferred between channel partners, and the successful reception of four verification sequences. Enable loopback mode and check for lane_up assertions. Bring the CHANNEL_INIT_SM module FSM state signals to debug if channel_up is not asserted. For a simplex link, the simplex TX partner might have already achieved channel_up status. See the Channel Verification Procedure in the Aurora 64B/66B Protocol Specification (SP011) for channel_up assertion details.

Periodic Channel Failures Check

If the Aurora 64B/66B core asserts and deasserts the channel_up signal, enable internal loopback and check for a stable channel up condition. Probe RXBUFSTATUS of the transceiver.

Multiple Lane

Channel Bonding Assertion Check

Channel bonding is necessary for a multi-lane Aurora 64B/66B design. Channel bonding is performed by the transceiver and the required logic is present in the transceiver_wrapper module. Ensure that the channel bonding level, master and slave connections are correct. See the channel bonding procedure in the Aurora 64B/66B Protocol Specification (SP011) for channel_up assertion details.

CHANNEL_UP Assertion Check

The criteria for channel_up signal assertion are the verification sequence (defined in the Aurora 64B/66B protocol) being transferred between channel partners, and the successful reception of four verification sequences. Enable loopback mode and check for lane_up assertions. Bring the CHANNEL_INIT_SM module FSM state signals to debug if channel_up is not asserted. For a simplex link, the simplex TX partner might have already achieved channel_up status. See the Channel Verification Procedure in the Aurora 64B/66B Protocol Specification (SP011) for channel_up assertion details.

Periodic Channel Failures Check

If the Aurora 64B/66B core asserts and deasserts the channel_up signal, enable internal loopback and check for a stable channel up condition. Probe RXBUFSTATUS of the transceiver.

Data Transfer Check

After channel_up is asserted, the Aurora 64B/66B core is ready to transfer data (wait for tready assertion). Data errors can be monitored with VIO. The tx_d and rx_d signals are connected to monitor the data transfer. Also, soft_err and hard_err are connected to VIO. If data_err_count is incrementing, perform a loopback test as described in See LOOPBACK Testing Check. If the loopback test passes, check the transmitted data and cable for channel integrity. Run the integrated bit error ratio test (IBERT) to confirm link connectivity and signal integrity (SI) on the channel. If IBERT runs are unsuccessful, monitor the power supplies and termination circuit, then run SI simulations on the transceiver.

LOOPBACK Testing Check

Loopback modes are specialized configurations of the transceiver datapath. The loopback port of the Aurora 64B/66B example design controls the loopback modes. Four loopback modes are available. The following figure illustrates a loopback test configuration with four different loopback modes. Refer to the respective transceiver user guide for guidelines and additional information.

Figure 2. Loopback Testing Overview