Clock Correction Sequences in Device-Specific Transceivers - 16.2 English

1G/2.5G Ethernet PCS/PMA or SGMII LogiCORE IP Product Guide (PG047)

Document ID
PG047
Release Date
2023-11-01
Version
16.2 English

The device-specific transceivers are configured by the appropriate transceiver wizard to perform clock correction. The output of the transceiver wizard is provided as part of the example design. Two different clock correction sequences can be employed:

  1. The mandatory clock correction sequence is the /I2/ ordered set; this is a two byte code-group sequence formed from /K28.5/ and /D16.2/ characters. The /I2/ ordered-set is present in the inter-frame-gap. These sequences can therefore be removed or inserted by the transceiver receive elastic buffer without causing frame corruption.
  2. The default transceiver wizard configuration for the device-specific transceivers varies across device families. Some of the transceiver wizards enable the CLK_COR_SEQ_2_USE attribute. When this is the case, the transceiver is also configured to perform clock correction on the /K28.5/D21.5/ sequence; this is the first two code-groups from the /C1/ ordered set (the /C1/ ordered-set is four code-groups in length).

    Because there are no /I2/ ordered-sets present during much of the auto-negotiation cycle, this provides a method of allowing clock correction to be performed during auto-negotiation.

    Because this form of clock correction inserts or removes two-code groups into or from a four-code group sequence, this causes ordered-set fragments to be seen by the cores auto-negotiation state machine. It is therefore important that the transceivers rxclkcorcnt[2:0] port is correctly wired up to the core netlist; this indicates a clock correction event (and type) to the core. Using this signal, the cores state machine can interpret the clock-correction fragments and the auto-negotiation function can complete cleanly.

When the device-specific transceivers CLK_COR_SEQ_2_USE attribute is not enabled, no clock correction can be performed during much of the auto-negotiation cycle. When this is the case, it is possible that the transceivers receive elastic buffer could underflow or overflow as asynchronous clock tolerances accumulate. This results in an elastic buffer error. It is therefore important that the transceivers rxbufstatus[2:0] port is correctly wired up to the core netlist; this indicates a buffer error event to the core. Using this signal, the cores state machine can interpret the buffer error and the auto-negotiation function can complete cleanly.