AR# 59435

|

Xilinx HSSIO Solution Center - Design Assistant Debugging Reset Problems

Description

GT RESETs are required under multiple conditions and circumstances. They are required in order to update, clear and reconfigure the GTs in a working manner.

Solution

7 Series

Reset issues can occur on 7 Series devices stemming from the powering on of the PLLs and also the settling of the refclk capacitor on initial power on.

If there are issues only on the initial power up of the device, check these three Answer Records to see if the issues discussed could be a problem:

(Xilinx Answer 59294)

(Xilinx Answer 61785)

(Xilinx Answer 65199)

If the reset sequence fails and the only way to recover is to reprogram see:

(Xilinx Answer 60489)

UltraScale

For UltraScale, under certain circumstances a problem on initial power up can sometimes be seen:

(Xilinx Answer 66472)

For a general debug check the following steps to ensure proper reset functionality:

  • Is GTRESETSEL set to the correct bit (sequential mode vs single mode)?
  • Is QPLL/CPLL RESET applied?
  • Is the associated PLL locked and stable? Is PLLLOCK high?
  • Are TX/RXUSRCLK and TXRXUSRCLK2 stable? Is TX/RXUSERRDY high?
  • Is the recovered clock stable? Many of the initialization functions such as buffer resets and phase alignment procedures are not recommended to be performed if the recovered clock is not stable.
  • Is the period of the "stable clock" used in the startup state machine correct?
  • If doing RX reset, is it single mode or sequential?
  • Is RX reset started after receiving valid incoming data?
  • If TX and RX (link partners) are not from the same CHANNEL, is TX reset completed first before starting RX reset?
  • If using DRP arbitration for reset, make sure the correct addresses and commands are used and performed.
  • In the example design, is the "rx_data_good_in" port of the initialization module connected to a valid "data good" checker? By default, it is connected to PRBS checker. If PRBS checker is not used, and rx_data_good_in is not asserted, the initialization module logic will constantly reset the RX.

The TX and RX RESET FSM table:




Additional checks to perform on when and what type of RESET is applied:

Completion of Configuration for 7 Series:

TX RESET:

  • Sequential Mode:
  • Resets asserted after 500ns post configuration completion.

RX RESET:

  • Sequential Mode:
    • Resets asserted after 500ns post configuration completion.
  • Single Mode:
    • Resets asserted after 800 to 1000ns after completion of completion of configuration.
      Note that the reset mode needs to be changed to sequential after 500ns of configuration completion.

    Soft Reset/GT

    • Must be in sequential mode
    • All component resets are constantly driven low during the entire reset process before RXRESETDONE is detected high.
    • For all 7 Series GTX and GTH (RXOUT_DIV = 1 & RX_DATA_WIDTH = 16,32 or 64), GTRXRESET pulse width should be about one period of the reference clock.
    • For 7 Series GTH (RXOUT_DIV != 1 & RX_DATA_WIDTH = 20,40 or 80) please refer to (UG476) to ensure proper procedure is followed for issuing a GTRXRESET and also for 7 Series GTP please refer to (UG482).

    Some useful debug ports to monitor:

    • PLLLOCK
    • PLLREFCLKLOST
    • RECCLK_STABLE
    • TX/RXUSERRDY
    • TXRESETDONE/RXRESETDONE

    Additional Tips:

    1. Follow recommendations made in the GT user guides (UG476, UG482, UG576, UG578) and the transceiver wizard product guides (PG168 and PG182).
    2. As with any GT issues, please make sure you are using the latest wizard version to get full benefits of the fixes provided. Using the latest version of the RESET FSM puts you in the best position to not encounter reset issues.
    3. Check the following helpful Answer Records for updates on attributes and settings.

    1. Use a ChipScope core such as IBERT to debug GT issues.
    2. Create a case with Xilinx support.
AR# 59435
Date 01/14/2020
Status Active
Type Solution Center
Devices More Less
People Also Viewed