Code Group Sync is the first stage of the JESD204 protocol link up.
In this stage, each lane in the link must see a stream of K28.5 K-characters transmitted across the lanes. These lanes must be aligned and comma alignment is used to ensure this is the case.
The optional transceiver debug port gt_rxcommadet[(LANES-1):0] will be set high showing that the comma alignment block has detected a valid comma.
Once this deasserts and goes low, comma alignment is complete. Once this is complete, Debug Status register bit 0 will assert in the JESD204 core.
The next step is to complete code group sync by having four consecutive K28.5 characters transmitted within each lane.
Once this is seen, Sync will go high as well as Debug Status register bit 1 (in a JESD204B RX core).
The transmitter will send data until the beginning of the next frame.
Each subclass will treat this next step in a different way:
Potential Errors / Debugging Code Group Sync failures:
Check if the device GTs are locked. Check QPLL / CPLL LOCK in particular. This is the most likely signal to fail.
Follow standard GT debug if this occurs:
|(Xilinx Answer 37181)||Xilinx High-Speed Serial I/O Solution Center|
If a lane is missing data, ensure the other side of the link is set up for the same number of lanes.
Potential reasons could be:
If lanes have skew, getting past CGS might not be possible without fixing this skew.
Check power on the board - this must be within the specification of the datasheet. Check power for both the FPGA and the ADC / DAC.
K-characters can be incorrect. Check for signal integrity of failing lanes. View GT data and char_is_k signals to verify which lanes are failing.
encommaalign is driven by the core so that comma alignment is limited to when the core is out of sync.
This is because there is the possibility that a single errored byte could become a comma spanning a byte boundary, which in turn could result in the GT re-aligning and sticking with the bad alignment.
The result would be that all subsequent data bytes would become errors.
2 bytes with 10 bit codes: 1100110000 and 1110100010
If the first byte had a couple of bit errors then the data could become: 1100110011 and 1110100010
Taking the last 4 bits of the first word and first 6 bits of the second word gives: 0011111010, which would appear as a mis-aligned comma as the 10-bit code for K28.5 is also 0011111010
Disabling comma alignment means this cannot happen - comma alignment is only required to be performed during synchronization.
Alignment character replacement should only occur in the last byte of a multiframe and only if the data matches the data in the last byte of the previous multiframe - this should always fall on multiframe boundaries.
If this occurs at other positions in the data, the RX will drop synchronization.