describe

GT RESET is required in a number of situations and situations. In order to update in an efficient way,

Clear and reconfigure GT, they are required.

Reset issues can occur on 7 series devices due to the power-up of the PLL and the build-up of the refclk capacitor on initial power-up.

If the problem only occurs when the device first starts up, check the following three answer records to see if the problem in question might 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) Hyperscale

For UltraScale, I sometimes see power-on problems in some cases:

(Xilinx Answer 66472)

For general debugging, check the following steps to ensure proper reset functionality:

Is GTRESETSEL set to the correct bit (sequential mode or single mode)?

Apply QPLL/CPLL RESET?

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 initialization functions, such as buffer reset and phase alignment procedures, are not recommended if the recovered clock is not stable.

Is the "stable clock" period used in the startup state machine correct?

If RX reset is performed, is it single mode or sequential mode?

Does RX reset start after receiving valid input data?

If TX and RX (link partner) are not from the same channel, is the TX reset done before starting the RX reset?

If using DRP quorum for reset, make sure the correct address and command are used and executed.

In the example design, is the "rx_data_good_in" port of the initialization block connected to a valid "data good" checker? By default it is connected to the PRBS inspector. If the PRBS checker is not used, and rx_data_good_in is not declared, the initialization block logic will constantly reset RX.

TX and RX RESET FSM table:

,