See Clocking and Resets for these requirements.
Ensure that the clock frequencies for both theIntegrated Interlaken IP core and the AMD transceiver reference clock are set correctly according to the configured mode of the core. Typical frequencies for each Interlaken configuration mode are listed in Table 1.
The first thing to verify during debugging is to ensure that resets remain asserted until the clock is stable. It must be frequency-stable and free from glitches before the integrated IP core for Interlaken is taken out of reset. This applies to both the SerDes clock and the IP core clock.
If any subsequent instability is detected in a clock, the Integrated Interlaken IP core must reset. One example of such instability is a loss of CDR lock. The user logic
should determine all external conditions which would require a reset, for example, clock
glitches, loss of CDR lock, power supply glitches, etc. The GT requires a GTRXRESET
after the serial data becomes valid to ensure correct CDR lock to the data. This is
required after powering on, resetting or reconnecting the link partner. At the core
level to avoid interruption on the TX side of the link, the reset can be triggered using
gtwiz_reset_rx_datapath.
Configuration changes cannot be made unless the IP core is reset. An example of a configuration change is a change in BurstMax. Check the description for the particular signal on the port list to determine if this requirement applies to the parameter that is being changed.