Forum Discussion
Occasional ContributorTranceiver Enhanced PCS Basic mode questions
Hi MinzhiWang,
1) There is a Word Aligner block in Cyclone 10 GX, instead of Byte Ordering. Refer Table 29 in https://docs.altera.com/r/docs/683054/20.1/cyclone-10-gx-transceiver-phy-user-guide/standard-pcs-parameters.
2) Typically both Tx and Rx and connected to other side Rx and Tx respectively. Then, you send a know response. Else, use general purpose IOs to communicate the Rx readiness. This will be your own custom logic.
Hoep this clarifies.
Regards,
Altera Tech Support
Occasional ContributorHello Ash，
Thanks for your patience. Actually, I met several this similar issues, as following image
The hex value of "55555555" will be received as "aaaaaaaa", and "33333333" will be x"66666666" or "cccccccc". And "ff00ff00" will be "01fe01fe".
For enhanced PCS seems can't open rx_control ports to user, so we went to use standard PCS. In this cae, we can test with counter value. The only thing we need to note is byte mis-ordering issue. BTW, in this case, PHY open tx/rx_datak to user, we use it as our old devices' tx/rx_control signals.
Regular ContributorHi MinzhiWang,
Thank you for the update. Switching to Standard PCS with 8b/10b encoding is the correct approach for your point-to-point application on Cyclone 10 GX — it gives you explicit access to the tx_datak/rx_datak ports, which function the same way as the tx_control/rx_control signals you used on Arria GX and Stratix IV GX. This is a well-supported path for custom, protocol-free transceiver links.
Regarding the bit-shift patterns you saw with Enhanced PCS (0x55→0xAA, 0x33→0x66/0xCC, 0xFF00→0x01FE):
These are consistent with a 1-bit boundary misalignment at the 64b/66b block level in the Enhanced PCS. Because the Enhanced PCS Basic mode does not send 64b/66b header bits in IEEE 802.3ae-compliant LSB-first order, the block synchronizer can lock to an incorrect bit offset, causing systematic bit shifts in the decoded data.
This is a known behavior documented in the Knowledge Base article: Are the 64b/66b header bits compliant to the IEEE802.3ae standard when using Enhanced PCS with Basic Mode?
Since you don't require a specific protocol and need per-byte control signaling, Standard PCS with 8b/10b is the cleaner solution — you have made the right decision.
Regarding the byte mis-ordering issue in Standard PCS:
When using Standard PCS with a parallel data width wider than 10 bits (e.g., 16-bit or 32-bit FPGA fabric interface), the byte ordering block is needed to ensure the correct byte position within the wider word. Here's what to check:
Enable the Byte Ordering block in the Native PHY IP parameter editor. The byte ordering block uses a K28.5 (0xBC) comma character on a designated byte lane to establish the correct byte order. See: Byte Ordering — Cyclone 10 GX Transceiver PHY User Guide
Transmit a K28.5 comma on byte lane 0 periodically (e.g., during idle or initialization) with tx_datak asserted for that byte. The receiver byte ordering block uses this pattern to determine which received byte corresponds to the LSByte of the wider word.
Monitor rx_byteorderalignstatus — this signal asserts when the byte ordering block has successfully aligned the byte lanes. Only treat rx_parallel_data as valid after this signal is asserted.
Verify the Word Aligner settings — ensure the word alignment pattern is set to K28.5 (the comma pattern) and that rx_syncstatus is asserted, indicating successful word alignment at the 10-bit boundary level. See: Word Aligner — Cyclone 10 GX Transceiver PHY User Guide
Check Byte Serializer/Deserializer ordering — if you enabled the byte serializer (TX) and byte deserializer (RX) to widen the datapath, be aware that the byte serializer forwards LSByte first. Make sure the TX and RX byte serializer/deserializer configuration matches. See:
RX Byte Reversal — if you see a consistent MSByte/LSByte swap after addressing the above, you may toggle the "Enable RX byte reversal" option. This feature reverses the LSByte with the MSByte of the received data. See: Word Aligner RX Byte Reversal Feature
Recommended initialization sequence:
TX continuously sends K28.5 (0xBC) with tx_datak = 1 on all byte lanes
Wait for RX rx_syncstatus = 1 (word alignment achieved)
Wait for RX rx_byteorderalignstatus = 1 (byte ordering achieved)
Begin sending user data with tx_datak = 0
The full Cyclone 10 GX Transceiver PHY User Guide is available here for additional reference: Cyclone 10 GX Transceiver PHY User Guide (683054)
Please let us know if you need further assistance with the Standard PCS configuration.
Best regards,
Altera Technical Support
- MinzhiWang
Hello Ash,
Thanks for you reply.
After switching from Ehanced PCS to standard PCS, I know how to practice tranceiver on C10GX devices. I only have several simple questions need to discuss with you.
- I know and remember that Stratix II GX and Arrai GX devices has byte ordering block, however, I can't find this block on C10GX. How to find and enable this block on C10GX devices?
2. We didn't enable Byte Ordering Block in our Arria GX devices. So we can refer this function when use C10GX devices now. The only issue is that 32-bit wide parallel data width is used for our current project. In our previous project, it's 16-bit wide. In 16-bit case, there is only one possibility for re-alignment, which high byte swaps with lower byte. Now in 32-bit case, there are 3 possibilities, as following image
Because we don't use Byte Ordering Block, so we can use user code to correct this byte mis-ordering issue. Actually above diagram is not correct real case for byte ordering before we use SignalTap II to detect it. According to previous signaltap II image, we got the following correct byte re-ordering method:
3. You gave "Recommended initialization sequence:" above. I have one question about TX side. In our case, RX and TX are on different hardware boards. RX can't notice TX when RX is ready. So our issue is how to guarantee both sides are ready before TX sends user data?
Best Regard
- Ash_R_Altera
Hi Minzhi,
For Cyclone 10 GX Enhanced PCS Basic mode, word alignment is typically achieved using the RX Synchronizer (word aligner) or the RX bitslip interface. A common approach is to transmit a known training/alignment pattern from the remote TX and allow the local RX to search for that pattern and adjust the word boundary until it is detected correctly. This is generally how serial links establish alignment before normal payload traffic begins.
Regarding the initialization sequence, a typical flow is:
- Wait for TX/RX PLL lock and RX ready/calibration completion.
- Remote TX continuously sends a known alignment pattern.
- Local RX uses the RX Synchronizer or RX bitslip to achieve word alignment.
- Once the alignment pattern is detected consistently, switch to normal data transmission.
Since your design uses a custom point-to-point link without a standard protocol, defining a unique training pattern during link bring-up is the recommended method for reliable synchronization and word-boundary alignment.
The TX normally has no visibility into the RX word-alignment status. A common approach is for the TX to continuously transmit a known training pattern after link initialization, while the RX performs word alignment using the RX Synchronizer or RX bitslip. Once the RX reliably detects the training pattern, it can either:
- Signal alignment completion through a separate sideband/control channel, or
- Begin transmitting a known response pattern back to the far-end TX.
After the TX receives the expected indication, both sides can transition to normal payload traffic.
Regards,
Altera Tech Support
- MinzhiWang
Hi Ash,
We are focus on Standard PCS now, instead of Enhanced PCS. So my questions are
- How to open/enable "Byte Ordering Block"?
- I just want to know how RX notice for-end TX after RX is ready?
Regard
- Ash_R_Altera
Hi MinzhiWang,
1) There is a Word Aligner block in Cyclone 10 GX, instead of Byte Ordering. Refer Table 29 in https://docs.altera.com/r/docs/683054/20.1/cyclone-10-gx-transceiver-phy-user-guide/standard-pcs-parameters.
2) Typically both Tx and Rx and connected to other side Rx and Tx respectively. Then, you send a know response. Else, use general purpose IOs to communicate the Rx readiness. This will be your own custom logic.
Hoep this clarifies.
Regards,
Altera Tech Support
