See Clocking and Resets for these requirements.
Ensure that the clock frequencies for both the 100G Ethernet subsystem as well as the AMD transceiver reference clock match the configuration requested when the subsystem 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 Ethernet bandwidth plus the 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 100G Ethernet subsystem is taken out of reset. This applies to both the SerDes clock as well as the subsystem clock.
If any subsequent instability is detected in a clock, the 100G Ethernet subsystem 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, or power supply glitches).
The GT requires a GTRXRESET after
the serial data becomes valid to insure correct CDR lock to the
data. This is required after a cable pull and re-plug, or after
powering on or resetting 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
. If available, signal detect or inversion of loss of signal from
the optics can be used to trigger the reset. If signal detect or
loss of signal is not available, timeout logic can be added to
monitor if alignment has not completed and to issue the gtwiz_reset_rx_datapath
reset.
Configuration changes cannot be made unless the subsystem is reset. An example of a configuration change would be setting a different maximum packet length. Check the description for the particular signal on the port list to determine if this requirement applies to the parameter that is being changed ( Table 1).