Forum Discussion
New ContributorUnable to Generate Valid PAM4 Eye Diagram and BER Measurements on Stratix 10 SI E-Tile Native PHY
Regular ContributorHi,
Here are my recommendations:
Step 1 — Upgrade Quartus Prime Pro (Critical)
Quartus 18.1 is 8 years old. PAM4 E-Tile support has received extensive fixes since then. Recommend upgrading to at least Quartus 24.x (or latest). Many PAM4 adaptation, eye viewer, and toolkit fixes were delivered in 19.x–24.x releases.
Step 2 — Use Proper PRBS Pattern for PAM4
The user-defined pattern does NOT exercise all 4 PAM4 voltage levels. This alone can cause "eye could not be detected."
Use PRBS31Q (quaternary/PAM4-aware PRBS) from the Transceiver Toolkit's built-in pattern generator, not a custom pattern. This ensures all 4 symbol levels (0, 1, 2, 3) are properly exercised.
Step 3 — Signal Integrity Check (SMA Cable)
A 50 cm Pasternack PE3CA1035 SMA cable may have excessive insertion loss at 25.5 GHz (PAM4 Nyquist for 51 Gbps). Recommend:
Use the shortest possible cable (< 15 cm) or a calibrated test fixture
Alternatively, test with serial internal loopback (SILB) first to eliminate the cable as a variable
Step 4 — Adaptation Sequence
Run continuous adaptation (not one-time) for PAM4. The adaptation FSM needs to converge VGA/AGC, CTLE, DFE, and IQ timing for all 3 PAM4 eyes.
After enabling continuous adaptation, wait for it to fully converge (observe stable CTLE/DFE tap values in Toolkit) before running Eye Viewer.
Step 5 — TX Pre-emphasis / FIR Settings
For a short SMA loopback, start with:
Pre-tap = 0, Main tap = max (e.g., 55), Post-tap = 0
Adjust only if needed after confirming basic link with SILB
Step 6 — Eye Viewer Configuration
Ensure Eye Viewer is set to PAM4 mode (measures top, middle, and bottom eyes)
Let the tool accumulate sufficient bits at each BER point (~10⁸ bits minimum at 51 Gbps before starting eye scan)
Verify CDR lock-to-data is asserted before running Eye Viewer
Step 7 — Verify lock status registers
Before running Eye Viewer, confirm: rx_is_lockedtodata = 1 and rx_pll_locked = 1
If CDR is locked to reference (not data), the eye measurement will fail
Recommended Debug Sequence (Short form for response)
First: Try internal serial loopback with PRBS31Q → confirms transceiver PMA works
If SILB passes: try external loopback with shortest cable available
If short cable passes: troubleshoot with original 50 cm cable (likely too lossy)
Regards
New ContributorAs suggested, we installed Quartus Prime Pro 24.1. However, we could not find the Transceiver Toolkit (TTK) in the System Console.
Could you please recommend the exact Quartus Prime Pro version that includes both the Transceiver Toolkit and the board example designs for PAM4 operation over the SMA connectors?
Previously, we used Quartus Prime Pro 18.1, which included board example files for PAM4 programming through the SMA interface. However, we were unable to successfully complete the Eye Viewer test, as described in our earlier correspondence.
It's Urgent, kindly respond.
Kind regards.
- Ash_R_Altera
Hi,
I suspect that probably the design is not properly configured to enable the TTK. Please refer the section 10.3 and make sure that the E-tile IP has correct settings enabled.
The latest version of the Quartus is 26.1. Recommend you to choose the latest one.
For the design example, unfortunately there is none for PAM4 native PHY IP.
Regards
- Ash_R_Altera
Hi,
Just wanted to follow-up. Do you have any further queries on the topic?
Regards
- pryngshu
Hi, that issue has been resolved. We are now able to generate PAM4 and NRZ signals and control them through TTK.
However, we observed that when no data is being transmitted on Tx, i.e., when the generator is turned off, a clock-like signal is still present on the Tx output. Could you please let us know what might be causing this?
Additionally, the measured data rate or clock rate are significantly different than the configured/set data rate. Could you please advise on the possible reasons for this discrepancy as well?
- Ash_R_Altera
Hi,
Here is my theory on the observation you made:
This behavior is expected and does not indicate a fault. On Stratix 10 E-tile channels, the transmitter must keep its high-speed lines toggling whenever the channel is operational, even during idle periods when no user data is being sent. Extended transmission of static levels (all 0's or all 1's) can cause Bias Temperature Instability (BTI) degradation, so the device is designed to maintain a toggling pattern to protect the channel.
For a channel that is used but temporarily idle, the recommended and common approach is to drive the TX with a DC-balanced toggling pattern such as PRBS or a clock pattern (or enable the built-in TX PMA PRBS generator). The clock-like waveform you are observing is most likely this low-rate keep-alive activity — which also helps a downstream/loopback receiver CDR retain lock, since the CDR relies on signal transitions to recover timing.
This also explains the rate discrepancy: the keep-alive/idle pattern runs at a low rate that is unrelated to your configured NRZ/PAM4 line rate, so the measured toggle frequency should be compared against the idle keep-alive pattern rather than the mission-mode data rate.
Recommended checks:
- Confirm whether your firmware/RTL (or the transceiver IP) drives a PRBS/clock pattern, or enables the TX PMA PRBS generator, when user data stops.
- Compare the measured toggle rate to that idle pattern rate, not the configured line rate.
- If you genuinely need the TX line quiet, tri-state the TX buffer (e.g., via tx_pma_elecidle or the corresponding PMA register), rather than only stopping the generator.
- Ensure the reference clock is present; if it is lost, the channel must be held in reset.
In summary, the toggling TX output on an idle channel is intended device behavior to avoid channel degradation and maintain link/CDR stability, and its rate is not expected to match your configured data rate.
Regards,
Altera Tech Support
