TMDX654IDKEVM: Clarification of frame transmission and receive paths with regard to latency and jitter on industrial Ethernet ports of the board

Jan

Here is some guidance from Thomas Leyrer  on your queries 

Assumption 1:
Both transmit and receive timestamping is implemented in PRU according to IEEE 802.3 Clause 90.
(I. e. timestamping plane is enter/exit generic reconciliation sublayer of the MAC and message timestamping point is SFD.)

[tley] While IEEE 802.3 is not an implementation specification on Ethernet MAC, it is correct that time stamps are taken with SFD reference point. In addition you have to understand various time domains on Ethernet. IEEE Ethernet does not specify time domain for MAC, bridge and Ethernet PHY. On ICSS_G there are various options to configure clock source for PRU (MAC, bridge), IEP timer (time stamp unit) and MII/RGMII (phy interface). In an ideal case all these clocks including the clock source for Ethernet PHY are one time domain. The IDK has hardware stuffing options to accomplish single time domain.

Assumption 2:
Timestamping implementation in PRU uses free running clock counter that is independent on TX_CLK and RX_CLK signals of the xMII interface.

[tley] In case IEP timer is tuned to follow clock master then time stamp unit is not free-running. This should be marginal as IEP clock is typically tuned to compensate offsets of oscillators/cristal used on different boards. Typically < 50 ppm deviation.   

Assumption 3:
When crossing clock domains in PHY, resulting jitter can never be greater than one period of the target clock.

[tley] As mentioned on TX direction PHY can be clocked with same source as MAC/bridge. We also have customers using denoising PLL with RX_CLK (25MHz fallback OSC on link loss) and provide network wide jitter in sub 10 ns range. This is similar to SYNC Ethernet from telecom standard. Not sure I understand what a period of the target clock is? (25 MHz, 125 MHz)

Assumption 4:
Processing in PHY, both sending and receiving, on 10Base-T, 100Base-TX and 1000Base-T (all Full Duplex) have zero jitter (excluding crossing of the clock domains).

[tley] Correct for processing internal to ICSS_G. However TX_CLK direction is different on 100M vs Gig.

Assumption 5:
PCB wiring and magnetics have zero jitter.

[tley] No, capacitive and inductive loads on high speed signals shape the edge of a signal which contributes to jitter. Maybe true, for your 0 jitter definition of < 4ns.

Assumption 6:
When transmitting MAC and transmitting PHY share clock signal source, crossing the MAC-PHY clock domain interface has constant latency (zero jitter).

[tley] True in general. Phy may also have power-up/reset jitter in term of TX_CLK. DP83826 is optimized to have only 2 ns variation of TX_CLK with reset.

Assumption 7:
When RX_CLK is driven by the line clock (from received data), there is zero added jitter in the PHY processing (thanks to no clock-domain crossing).

[tley] Yes, this mode will get you to < 10 ns jitter in a network.

Question 1:
Can the PHY, during transmission driven by RGMII (driven by GTX_CLK from PRU) use this clock source for transmission on the medium for 10Base-T Full Duplex, resp. 100Base-TX Full Duplex operation?
(This seems theoretically very well possible at least for 10Base-T, as line clock is not continuous there and receiver clock is always synchronized at the start of the frame, during preamble.)

[tley] This is a phy question and would need to be addressed by Ethernet team in TI.

Please consider creating a separate post for their product for the subject matter experts on that team to address 

Question 2:
Can the PHY, during receiving, use link clock to drive the (RG)MII RX_CLK (and the whole decoding process)?  If not at all times, what are the conditions when this is/can be done?

[tley] I do not understand the question. RX_CLK is a recovered clock from previous network node when link is established. RX_CLK is a phy output going into MII interface of ICSS_G.

Jan,

  I see here three options.

Default setting is RGMII interface with phy and SOC with own clock source. 

DP83867 has also MII mode which I would recommend for 100 Mbit testing. Description how to change to MII mode is in chapter 7 of EVM users guide.  https://www.ti.com/lit/ug/spruim6a/spruim6a.pdf 

Figure 3-4 of same document shows the clock tree for SoC and Ethernet Phy.

Default option is that EPHYs and SOC run from different sources. There are 2 options.

1. Use SOC clock source and route MCU_CLKOUT to clock buffer. Switch selection on clock buffer to MCU_CLKOUT.

2. Use EPHY clock buffer source and route WKUP_OSC0_XIN from clock buffer to SoC. This option does not require any software change but only hardware mods with different resistor settings.

We talk about clock synchronization in nano second range.  Linux OS is not sensitive to ns clock jitter. 

I recommend to start with clock modification option 2 first - only hardware changes. 

BR,

  Thomas