The 64B/66B and 64B/67B protocols depend on block synchronization to determine
their block boundaries. Block synchronization is required because all incoming data is
unaligned before block lock is achieved. The goal is to search for the valid synchronization
header by changing the data alignment. The CH*_RXGEARBOXSLIP input port is used to change
the gearbox data alignment so that all possible alignments can be checked in normal mode
(MODE[2] = 1'b0). The CH*_RXGEARBOXSLIP signal feeds back
from the block synchronization state machine to the RX gearbox and tells it to slip the data
alignment. This process of slipping and testing the synchronization header repeats until
block lock is achieved. When using the RX gearbox, a block synchronization state machine is
required in the interconnect logic. The following figure shows the operation of a block
synchronization state machine.
The state machine works by keeping track of valid and invalid synchronization headers. Upon reset, block lock is deasserted, and the state is LOCK_INIT. The next state is RESET_CNT where all counters are zeroed out. The synchronization header is analyzed in the TEST_SH state. If the header is valid, sh_cnt is incremented in the VALID_SH state, otherwise sh_count and sh_invalid_count are incremented in the INVALID_SH state.
For the block synchronization state machine shown in Figure 1, sh_cnt_max and sh_invalid_cnt_max are both constants that are set to 64 and 16, respectively. From the VALID_SH state, if sh_cnt is less than the value sh_cnt_max and test_sh is High, the next state is TEST_SH. If sh_cnt is equal to sh_cnt_max and sh_invalid_cnt equals 0, the next state is GOOD_64 and from there block_lock is asserted. Then the process repeats again and the counters are cleared to zeros. To achieve block lock, the state machine must receive sh_cnt_max number of valid synchronization headers in a row without getting an invalid synchronization header. However, when block lock is achieved sh_invalid_cnt_max – 1, the number of invalid synchronization headers can be received within sh_cnt_max number of valid synchronization headers. Thus, once locked, it is harder to break lock.
The following figure shows a waveform of the block synchronization state machine asserting RXGEARBOXSLIP numerous times because of invalid synchronization headers before achieving data alignment. After the RXGEARBOXSLIP is issued, the state machine waits 32 RXUSRCLK cycles before checking for valid synchronization headers.
1'b0)
