Forum Discussion
Occasional ContributorQueries on 46.6944 Gbps PAM4 F-Tile Configuration and Loopback Testing using Agilex7
Regular ContributorHi,
Thank you for the additional details. Your observation that PRBS eventually achieves Locked to Data, while the short FFFF and 3333CCCC... patterns are not reliably captured after a long idle interval, is consistent with the CDR needing sufficient data transitions to reacquire lock. During the long idle interval, I believe the CDR has lost LTD mode. Thus, when the burst come, it is expected that the short FFFF and 3333CCCC patterns cannot be captured because the CDR is not in LTD yet.
For FGT PAM4 in BASIC mode, we do not recommend treating lock_to_ref or fgt_rx_cdr_freeze as a supported way to preserve the previous lock-to-data/adaptation state:
- lock_to_ref changes the CDR reference behavior and lock to the refclk; it is not a “hold the last lock-to-data state” function.
- fgt_rx_cdr_freeze is documented for the GPON inactive-timeslot use case. We do not have a documented general-purpose BASIC-mode PAM4 mechanism that freezes the CDR state.
The recommended workaround is to add a transition-rich preamble after every long idle period. For example:
- Keep the lane electrically active if the application permits.
- Transmit a known PRBS or other transition-rich training pattern first.
- Wait for rx_is_lockedtodata to assert, or discard the RX data until it asserts.
- Transmit the FFFF and 3333CCCC... patterns and then the payload
Please let me know if there is any inquiry. Thank you.
New ContributorHello,
Thanks for providing your guidance.
I truly understand that first transmitting a rich training pattern followed by FFFF and 3333CCCC would work as the locked to data state would be there due to the PRBS transmitted first. But in our application, the first intended packets to be received are FFFF and 3333CCCC patterns and later on the training sequence is intended to be received. As the FFFF and 3333CCCC patterns are not enough for locking the data, we were planning to either hold the CDR state during lock state when PRBS is received or either use the lock to reference mode so that we can receive the data on the rx clock.
However, none of the two options seems to work for FGT PAM4, am i correct ?
Because in real time application, we are required to receive the FFFF and 3333CCCC pattern first for the initial training.
Can i get to know how much time does it take to get the locked to data status? This would help us to know the number of FFFF and 3333CCCC pattern to be transmitted enough which could help us to observe that if we increase the number of times FFFF and 3333CCCC patterns, we are able to get the locked to data status or not.
Regards,
Himanshu
- CheepinC_altera
Hi,
Please see my responses below:
However, none of the two options seems to work for FGT PAM4. Am I correct?
[CP] Yes, your understanding is correct.
Can I know how much time it takes to achieve Lock-to-Data status?
[CP] There is currently no published deterministic lock-time specification for FGT PAM4 operating in BASIC mode from which a guaranteed pattern count can be derived. Based on my understanding, the transition density of the incoming data pattern plays a significant role in achieving Lock-to-Data status. The FFFF and 3333CCCC patterns you are targeting may contain fewer transitions compared to transition-rich training patterns, which can impact the locking process.
As a workaround, I would recommend evaluating this on your hardware platform to determine the minimum or optimal number of FFFF and 3333CCCC pattern occurrences required to reliably achieve Lock-to-Data under your specific operating conditions.
Please let me know if you have any further questions. Thank you.
Best regards,
Chee Pin
amolkumarHi Team,
I am writing to inquire about PAM3 signaling support in Altera FPGAs.
Could you please clarify whether any current Altera FPGA families or transceiver architectures natively support PAM3 modulation?
Please provide guidance on possible approaches to implement or achieve PAM3 signaling using available FPGA transceiver resources. Specifically, we would like to know if this can be accomplished through specific PMA/PCS configurations, transceiver modes, or custom logic.
Additionally, please let us know if there are any relevant devices, IPs, application notes, or reference designs available for this type of implementation.
Additional question regarding the current Agilex 7 series we are currently using:
1. Has rx_lfps_detect been officially removed from the latest F-Tile PMA/Direct PHY IP, or is it simply no longer exposed in the IP parameter interface?
2. If yes to point 1, is the functionality of rx_lfps_detect still supported internally by the F-Tile PMA, is there any QSF assignment, Tcl command, IP parameter, register configuration, or other supported method to enable or expose rx_lfps_detect?
Team, I can able to find below, please advise
PAM3 modulation : Altera FPGA do not natively support PAM3 (3-level Pulse Amplitude Modulation) via built-in transceiver hardware.
Agilex7 supports below:
NRZ (Non-Return-to-Zero / PAM2): For legacy and lower-speed serial protocols.
PAM4 (4-level Pulse Amplitude Modulation): Used in high-performance tiles (like E-Tile, F-Tile, and FHT)
Regards
amol
- amolkumar
Hi Team,
Moreover, our priority right now is rx_lfps_detect port feature in the F Tile IP. For our application, we must detect the LFPS signalling of the incoming protocol traffic. If you could find a way to enable it in the latest version of Quartus (26.1), that would be a great help.
Regards
amol
