Alignment Status Signals

Versal Adaptive SoC GTY and GTYP Transceivers Architecture Manual (AM002)

Document ID
Release Date
1.3 English

While MCOMMA or PCOMMA alignment is active, any matching comma pattern causes the block to realign to a symbol boundary. After successful alignment, the block holds CH*_RXBYTEISALIGNED High. At this time, RX_MCOMMA_ALIGNEN and RX_PCOMMA_ALIGNEN can be set to 1'b0 to turn off alignment and keep the current alignment position. RX_PCOMMA_ALIGNEN must be 1'b1 for PCOMMAs to cause CH*_RXBYTEISALIGNED to go High. Similarly, RX_MCOMMA_ALIGNEN must be 1'b1 for MCOMMAs to cause CH*_RXBYTEISALIGNED to go High. Commas can arrive while CH*_RXBYTEISALIGNED is High. If the commas arrive aligned to boundaries, there is no change. If the commas arrive out of position, the block deasserts CH*_RXBYTEISALIGNED until the commas are aligned again. If alignment is still activated for the comma that arrives, the block automatically aligns the new comma to the closest boundary and drives CH*_RXBYTEREALIGN High for one RXUSRCLK cycle.

In applications that operate at a line rate greater than 5 Gb/s and have excessive noise in the system, the byte align block might falsely align to a wrong byte boundary and falsely assert the CH*_RXBYTEISALIGNED signal when no valid data is present. In such applications, a system-level check should be in place for checking the validity of the CH*_RXBYTEISALIGNED indicator and data.

In systems that use the RX OOB block, such as PCIe and SATA, after locking to a valid byte boundary and asserting the CH*_ RXBYTEISALIGNED signal, the byte align block might occasionally deassert the CH*_RXBYTEISALIGNED signal even when there is no change in the byte boundary. In such applications, CH*_RXBYTEISALIGNED should not be used as a valid indicator of the change in byte boundary after the first assertion.