AM6422: AM6422 + DP83869 RGMII Tuning

Tool/software:

Hey everyone,

I am an electronics engineer working on fine-tuning the CPU board of our design, where we are integrating a SoC AM6422 and two TI DP83869 Ethernet PHYs, following the configuration below:

We are aiming to optimize the RGMII timings between the AM64 and our Ethernet PHYs, and we are relying on the TI application note SNLA243 to guide our adjustments.

We have conducted a series of tests to understand and adjust the transmission and reception delays, and we would like to validate our analysis with you before finalizing our configuration.

The goal of this fine-tuning is to correctly adjust the RX and TX delays in RGMII to ensure robust communication and proper clock edge positioning relative to the data signals.

We have observed that:

• On the RX side, we successfully centered the RXC edges within the data eye, ensuring robust timing.
• On the TX side, the adjustments appear to have no visible effect, and we are trying to understand why.

We have conducted several detailed tests (outlined below) to analyze these phenomena.

️ Tests and Observations

RX Adjustment and Validation

By adjusting the rx-internal-delay-ps in the Device Tree, we were able to center the RXC edges within the data eye.

Below is the measurement of RXC and RX_Dx, where the least dense curve represents no delay (0x00) and the densest curve represents a delay (0x77):

This measurement allowed us to observe in real time that we can indeed influence RX timing.

After adjusting the delay via register settings, we obtained the following curves:

The communication is stable, with edges positioned slightly more within the open part of the eye (white dashed lines), and the setup/hold margins appear to be correct.
From our perspective, this configuration is functional and validated.

️ Tests and Anomalies in TX

The initial configuration in the Device Tree was:

tx-internal-delay-ps = <250>;

rx-internal-delay-ps = <2000>;

As it stands, communication works well, and iperf (a network performance measurement tool that tests bandwidth, throughput, and latency between two hosts) runs correctly.

We modified the TX_DELAY values via the Device Tree and PHY registers (e.g., register 0x86), but observed no visible effect on the TX signals.

From the TX eye diagram, the situation seems borderline:

The clock edges align with the most open part of the eye, but they are too close to the TX_D transitions, approaching setup/hold constraint limits. Ideally, we would like to shift these edges to the left to recenter the timing (which would be like “moving back in time” by adjusting TXC).

Degraded Tests: How We “Broke” the Communication

To better understand the impact of the settings, we intentionally attempted to disrupt communication by modifying certain parameters:

• By applying an explicit 2 ns shift on TX, we observed a complete loss of communication.
• The communication became unstable, and iperf no longer functioned.
• We attempted to find an intermediate state (between normal operation and complete failure) but did not observe any gradual degradation—only either functional or completely failed communication.

This leads us to question whether some settings are effectively considered and what the exact cause of this communication loss might be.

What We Believe We Have Understood

• RX tuning works, and we have control over it.
• TX tuning does not appear to have a visible effect, despite modifications to the Device Tree and PHY registers.
• An explicit 2 ns shift in TX causes total communication loss, with no intermediate degradation state.

EDIT: Based on the first feedback we had from TI FAE, we understand that TX delay is an internal delay block that does not manifest physically in measurements. Instead, it impacts the internal timing relationship between the PHY die and its pins.

 Updated Questions for TI

1. Given our measurements, do you confirm that our TX timing margins are acceptable?
2. Since TX delays do not physically manifest in measurements, is there an alternative way to validate that we meet setup/hold requirements correctly?
3. Should we rely only on theoretical calculations based on the known internal TX delay values, or is there a practical method to confirm proper TX timing?
4. We observed that applying a 2 ns TX shift leads to a total loss of communication with no intermediate degradation. Is this expected behavior in RGMII?
5. Are there additional best practices to ensure robust TX timing, given that the TX delay cannot be directly observed in measurements?

Thank you in advance for your help and insights!

Jamel