New Contributor
Frequent ContributorBefore using block synchronization, your original approach relied on sending a custom training word like 0x12345678 together with tx_control flags and then manually bit-slipping until the receiver matched that pattern. This method can work only if the word boundary remains stable after alignment, which is not true in your current configuration because the RX phase‑compensation FIFO can shift the data grouping internally. As a result, even if you successfully match 0x12345678 at one moment, the FIFO may later realign the data by bytes, breaking your alignment silently and causing rx_control to appear to rotate or change unpredictably. Moreover, 0x12345678 is not a strongly structured or repetitive pattern, so the receiver has no inherent way to verify long-term consistency of the alignment. Without block synchronization or a robust detection mechanism, this leads to a fragile system where alignment appears to work briefly but cannot be maintained.
Suggestion:
Enable the RX block synchronizer, and transmit a simple, highly repetitive training pattern such as 0xBCBCBCBC with tx_control held at zero (so all bytes are treated as normal data), allowing the receiver to observe a stable, structured bitstream; the RX block synchronizer continuously scans different bit offsets and monitors for consistent block delineation, and once it detects a stable boundary it asserts rx_enh_blk_lock, indicating that word alignment is achieved; only after this lock signal becomes stable should the transmitter switch from the training pattern to real payload data (for example, a counter), while the receiver begins accepting data, and during normal operation the design should continue to monitor rx_enh_blk_lock and revert to the training phase if lock is lost, ensuring robust and self-correcting alignment without relying on manual bitslip or tx_control markers.
At minimum, capture these signals on the RX side:
rx_parallel_data[31:0] → verify actual data pattern / counter
rx_control[19:0] → observe byte control movement (debug only)
rx_enh_blk_lock → MUST go high to indicate alignment achieved
rx_enh_data_valid → ensures data coming from FIFO is valid
rx_bitslip → confirm no unintended slipping (should stay low when using block sync)
rx_is_lockedtodata → confirms CDR has locked to incoming data
rx_ready → indicates RX path is initialized and stable
What to look for in SignalTap:
Suggest that if you see correct data but rx_enh_blk_lock = 0, you are NOT aligned yet, even if it “looks right” for a few cycles.
A little lengthy but hope it helps. :)
