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.