See the clocking and reset sections (Clocking and Resets in Chapter 4) of this product guide for these requirements.
Ensure that the clock frequencies for both the Interlaken IP core as well as the AMD transceiver reference clock match the configuration requested when the IP core was ordered. The core clock has a minimum frequency associated with it. The maximum core clock frequency is determined by timing constraints. The minimum core clock frequency is derived from the required Interlaken bandwidth plus some margin reserved for clock tolerance, wander, and jitter.
The first thing to verify during debugging is to ensure that resets remain asserted until the clock is stable. It must be frequency-stable as well as free from glitches before the Interlaken IP core is taken out of reset. This applies to both the SerDes clock as well as the IP core clock.
If any subsequent instability is detected in a clock, the Interlaken IP core must be reset. One example of such instability is a loss of CDR lock. The user logic should determine all external conditions that would require a reset (for example, clock glitches, loss of CDR lock, power supply glitches, etc.).
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.