The Aurora 64B/66B core example design for duplex mode incorporates a hardware reset FSM to perform repeated resets and monitoring robustness of the link. This FSM also contains an option to set different time periods between reset assertions. Also continuous channel_up and link_reset transition counters are monitored and the test status is reported through VIO.
The following signals are added in to the default ILA and VIOs for probing the link:
• tx_d_i[0:15] : TX Data from the LocalLink Frame Gen module
• rx_d_i[0:15] : RX Data to the LocalLink Frame check module
• data_err_count_o : 8-bit Data error count value, it is expected to be 'd0 in normal operations
• lane_up_vio_usrclk : lane_up signal
• channel_up_i : channel_up signal
• soft_err_i : Soft error monitor
• hard_err_i : Hard error monitor
• sysreset_from_vio_i : Reset input to example design
• gtreset_from_vio_i : pma_init to example design
• vio_probe_in2 : Quality counters for Link status
• rx_cdrovrden_i : Used while enabling loopback mode
• loopback_i : Used while enabling loopback mode
• reset_quality_cntrs : Used to reset all the quality counters in the example design
• reset_test_fsm_from_vio : Used to reset the hardware reset test FSM
• reset_test_enable_from_vio : Used to enable/start the repeat reset test from the vio ports on the hardware.
• iteraion_cnt_sel_from_vio : Number of repeat reset iterations to be initiated. This is a 4-bit encoded value for a fixed number of iterations that can be seen in the example design when Vivado lab tools is enabled.
• lnk_reset_in_initclk : Input probe to monitor the assertion of link_reset
• soft_err_in_initclk : Input probe to monitor the soft_err status
• chan_up_transcnt_20bit_i [15:8] : Number of channel_up transaction counts; this can be used to monitor the number of reset iterations that have been completed.
a. chan_up_transcnt_20bit_i is probed only [15:8] bits; hence, this probe takes some time to update the status.
b. To change the number of reset iterations, modify the respective value for iteration_cnt_sel_from_vio and correspondingly select chan_up_transcnt_20bit_i to probe the status.
• test_passed_r : Test pass status is asserted after the respective iteration count if resets are done successfully.
• test_failed_r : Test fail status is asserted if there is either a lack of channel_up or some data errors have occurred.
• lnkrst_cnt_20bit_vio_i : Probe to monitor the number of times the link_reset is asserted.
• reset_test_fsm_chk_time_sel : 3-bit encoded value probe to select the hardware reset_fsm check time for channel_up assertions after reset is deasserted.
Hardware FSM Operation:
In the example design ( <user_component_name>_exdes.v ), a hardware initiated repeat reset FSM has been added to test the robustness of the link when subject to repeat reset. The FSM consists of IDLE, ASSERT_RST, DASSERT_RST, WAIT, WAIT1, CHECK, FAIL and DONE states.
1. In IDLE state, test_passed_r indicates reset test passed, test_failed_r indicates reset test fail, and timer_r provides an iteration count of resets. Defaults to 0.
2. When the reset_test_enable_from_vio signal is asserted, the hardware FSM traverses to the ASSERT_RST state where pma_init is asserted for a pre-determined time (28-bit count time).
3. This pma_init assertion ensures that a hot plug sequence is detected by the link partner. The hardware FSM then traverses to the DEASSERT_RST state where the pma_init is deasserted and the timer is loaded with a default value that can be configured using the reset_test_fsm_chk_time_sel vio signal.
4. The FSM then moves to the WAIT state until the selected time has expired. In this state, all checks such as for data errors and soft error occurrences are performed and the channel_up signal is verified to be asserted High and not toggled more than once for this iteration of pma_init .
5. If this condition is not met, the FSM moves to FAIL state and the repeat reset run is stopped. Otherwise, the FSM moves to WAIT1 state where a few data packets are transmitted and received.
6. The FSM then moves to the CHECK state, in which the channel_up transitions are checked again. If there is not more than one transition, the FSM returns to the IDLE state until the requested iterations are completed. This ensures that the link is robust and recovers reliably across multiple repeat resets of the link.