The UHD-SDI wrapper contains control logic for the GTX. This control logic initializes the GTX after FPGA configuration, resets the GTX in response to reset inputs to the UHD-SDI wrapper, and dynamically changes the operating mode of the GTX in response to changing SDI modes of the RX and TX sections.
The control logic for the RX and TX portions of the GTX are separate so that the RX and TX and controlled independently. Both GTX RX and TX control logic modules are based on AMD PicoBlaze microcontrollers. These microcontrollers are programmed to implement the GTX initialization, reset, and dynamic mode change sequences. During these sequences, the microcontroller might encounter abnormal conditions. The abnormal conditions often manifest themselves by a signal not being asserted within the expected period of time. For example, after asserting the gttxreset, the microcontroller expects the GTX to negate its txresetdone and then assert it again within a certain period of time. Such timeouts cause the microcontroller to retry certain phases of the sequence some number of times. If the sequence still fails after repeated attempts, the microcontroller indicates that a failure has occurred.
Both the RX and TX microcontrollers have three ports used to monitor their status. These ports are listed in the following table.
| Port Name | Description | |
|---|---|---|
| RX | rx_change_done_out | High when the most recent RX sequence completed successfully. |
| rx_change_fail_out | High when the most recent RX sequence failed. | |
| rx_change_fail_code_out | When rx_change_fail_out is High, this port indicates the nature of the failure. | |
| TX | tx_change_done_out | High when the most recent TX sequence completed successfully. |
| tx_change_fail_out | High when the most recent TX sequence failed. | |
| tx_change_fail_code_out | When tx_change_fail_out is High, this port indicates the nature of the failure. |
Under normal conditions, the rx/tx_change_done_out port is High. When a change sequence is underway, the rx/tx_change_done_out port goes Low as soon as the microcontroller begins a reset or change sequence and it remains Low throughout the duration of the sequence. At the end of the sequence, the rx/tx_change_done_out port goes High if the sequence completed successfully. If there was a failure, the rx/tx_change_done_out port remains Low and the rx/tx_change_fail_outport goes High. The rx/tx_change_fail_out code changes values during the sequence, even to values not listed in the failure code table, but this does not indicate failures unless the rx/tx_change_fail_out port is High. The failure codes for both the RX and TX microcontrollers are the same and are listed in the following table.
| Failure Code | Description |
|---|---|
| 0 | Reset timeout: This code indicates that the microcontroller timed out waiting for a reset done signal from the GTX after a reset was initiated. |
| 1 | DRP request timeout: The RX and TX microcontrollers share the GTX DRP. There is an arbiter that controls which one has access to the DRP. If a microcontroller requests the DRP from the arbiter, but doesn’t receive a grant within a certain period of time, the sequence terminates with this error code. |
| 2 | DRP cycle timeout: When the microcontroller does a read or write cycle on the GTX DRP, it must see a DRPRDY signal from the GTX indicating completion of the DRP cycle. If the microcontroller times out waiting for the DRPRDY, it retries the DRP cycle several times. If the microcontroller continues to timeout waiting for DRPRDY on the retries, it eventually fails to generate this error code. |
| 3 | Illegal PLL output divider: This error code indicates that the microcontroller was commanded to change the PLL output divider to an unsupported value. |
If one of the microcontrollers asserts its change_fail_out port, the associated portion of the GTX must be considered to be in an invalid state. It could still be in a working condition, but any further changes to the SDI mode of that portion of the GTX is ignored by the failed microcontroller. When in the failure state, the only request that the microcontroller responds to is a full reset request. So, for example, if the RX microcontroller experiences a sequence failure and asserts its rx_change_fail_out port, the application must assert the rx_gtx_full_reset_in port High to attempt to restore proper operation of the GTX RX. The microcontroller, in response to assertion of the rx_gtx_full_reset_in port, attempts to do a full reset of the GTX RX. If that reset is successful, the rx_change_done_out port is asserted High and the GTX RX is functional. If the reset sequence fails, the rx_change_fail_out port is asserted High and the GTX RX is still not operational.