Forum Discussion
Occasional ContributorQueries on 46.6944 Gbps PAM4 F-Tile Configuration and Loopback Testing using Agilex7
New ContributorHi,
I would like to add a few points to this query. Amol and I are both working on this issue and would appreciate your guidance.
I was able to achieve a clear BER result using an external loopback when the AC Coupling option was enabled in the F-Tile PMA IP.
However, during testing with custom RTL-generated data patterns, I encountered an issue related to the Locked to Data status. My test consists of short bursts of data with the following sequence:
IDLE → PREPARE → LEVEL1 → PRBS Data → IDLE
IDLE: No data transmission for approximately 10 seconds.
PREPARE: FFFF pattern transmitted continuously for a few cycles.
LEVEL1: 3333CCCC3333CCCC pattern transmitted for a few cycles.
PRBS Data: PRBS pattern transmitted for a longer duration. In this state, I am able to achieve Locked to Data.
IDLE: Transmission stops, and the Locked to Data status is lost again.
The main issue is that, after returning from the IDLE state, the receiver takes too long to achieve Locked to Data. Because of this, I am unable to reliably receive the short FFFF and 3333CCCC patterns at the beginning of the next burst.
I have also tried transmitting the patterns for 65,536 cycles at 364.8 MHz using a 128-bit parallel interface, but the CDR still does not lock to data early enough for my application.
Since the current configuration uses Auto Adaptation, I considered freezing the CDR/adaptation state after the PRBS Data phase. However, this appears to require Manual Adaptation, and my understanding is that FGT PAM4 does not support Manual Adaptation.
I also tried enabling lock_to_ref, but it does not appear to resolve the issue in this configuration.
Could you please advise if there is any supported mechanism in FGT PAM4 / BASIC mode to achieve either of the following:
- Faster CDR recovery/lock to data when a new short burst arrives after a long idle period, or
- Freezing/holding the CDR state after it has successfully locked to data, and keeping it frozen until explicitly deasserted.
I noticed that the CDR Freeze functionality described in the documentation appears to be applicable only to GPON mode, whereas my configuration is BASIC mode with FGT PAM4 at approximately 46.7 Gbps.
Our main objective is to reliably receive these short bursts of data, which is important for the implementation we are currently working on.
Any guidance on the supported CDR configuration, registers, or other mechanisms that could help achieve this behavior would be greatly appreciated.
Regards,
Himanshu
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.
- Himanshu_Varia
Hello,
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
