Queries on 46.6944 Gbps PAM4 F-Tile Configuration and Loopback Testing using Agilex7

Team,

Please find design example and toolkit test results.

Part: AGIB027R31B1E1VC

Quartus Pro 26.1

Regards

amol

Hi,

As I understand it, you have several inquiries related to BER performance on the F-Tile Transceiver. Let me address them one by one.

Regarding your observation that the external loopback shows a non-zero BER while the internal loopback reports zero BER, this is expected behavior. In internal loopback mode, the transmitted data is looped back to the receiver within the transceiver itself, bypassing the external channel. As a result, the signal is not exposed to any external signal integrity impairments such as channel loss, noise, crosstalk, or reflections.

In contrast, external loopback exercises the complete signal path, including the PCB traces, connectors, cables, and other channel components. Therefore, any signal integrity degradation along the external path may contribute to bit errors and result in a non-zero BER.

By the way, I was unable to locate the test design and Transceiver Toolkit results that you referenced. It is possible that I may have missed them. Could you please point me to the relevant files or share them again for review?

Please let me know if you have any concerns or additional questions. Thank you.

Hi,

Regarding the 2D eye diagram inquiry, for your information, the Agilex 7 F-Tile Transceiver Toolkit does not support a 2D eye plot. It provides scalar measurements ie eye heights and widths. You might need to use oscilloscope for 2D eye diagram measurement as a workaround. Sorry for the inconvenience.

Hi,

Regarding your inquiry on the gray coding control, yes. For FGT, Gray coding is forced On in the PAM4 GUI but is explicitly disableable through register writes. Use read-modify-write access:

TX: 0x47808[3] = 0

RX: 0x47810[2] = 0

You may refer to the F-Tile PMA and FEC Direct PHY IP Register Map for further details (https://docs.altera.com/v/u/resources/647401/f-tile-pma-and-fec-direct-phy-ip-register-map). Thank you.

Hi,

Regarding the external loopback BER results, I apologize, but I was unable to locate the specific test results and configuration details that you are referring to.

In general, the target BER requirement depends on your system design and the protocol specifications being used. Therefore, we recommend reviewing your system-level and protocol-level BER requirements to determine the appropriate target value.

If additional link optimization is required, you may consider performing manual PMA tuning using the Transceiver Toolkit (XCVR Toolkit). For more information, please refer to the F-Tile Architecture and PMA and FEC Direct PHY IP User Guide, specifically the "Debugging F-Tile Transceiver Links" section, which provides guidance on transceiver link debugging and tuning.

Please let us know if you have any further questions or require additional assistance.

Thank you.

Hi,

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:

1. Faster CDR recovery/lock to data when a new short burst arrives after a long idle period, or
2. 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

Hello,

Please find the below snap shot from the user guide of F-Tile PMA/FEC Direct PHY IP user guide.

The support of fgt_rx_signal_detect_lfps_port has been removed in the 25.1.1 release. Previously it was supported by Altera.

The issue we are facing is that we are required to use this signal for our use case to detect the low frequency periodic signalling. Is there any way to enable this port in the latest version of Quartus F tile IP?