LINUX的PHY抽象层——PAL

英文原文参考：
https://www.kernel.org/doc/html/latest/networking/phy.html

中文翻译参考：有关PHY抽象层的总结
https://blog.csdn.net/eydwyz/article/details/124753313

1 前言

(RG)MII/electrical interface considerations
简化的千兆位媒体独立接口（RGMII）是一个12引脚电信号接口(RXCLK、RXCTL、RXD[3:0]、TXCLK、TXCTL、TXD[3:0])，使用同步125MHz时钟信号和多条数据线。由于此设计决定，必须在时钟线（RXC或TXC）与数据线之间添加1.5ns至2ns的延迟，以使PHY（时钟接收器）具有足够的设置和保持时间来正确采样数据线。

2 PHY接口模式

PHY库提供不同类型的PHY_INTERFACE_MODE_RGMII *值，以使PHY驱动程序和可选的MAC驱动程序实现所需的延迟。必须从PHY设备本身的角度理解phy_interface_t的值，从而导致以下结果：

PHY_INTERFACE_MODE_RGMII：PHY不负责自己插入任何内部延迟，它假设以太网MAC（如果能够)或PCB走线插入正确的1.5-2ns延迟
PHY_INTERFACE_MODE_RGMII_TXID：PHY应为PHY设备处理的发送数据线（TXD [3：0]）插入内部延迟
PHY_INTERFACE_MODE_RGMII_RXID: the PHY should insert an internal delay for the receive data lines (RXD[3:0]) processed by the PHY device
PHY_INTERFACE_MODE_RGMII_ID：PHY应为PHY设备插入发送和接收数据线的内部延迟

3 尽量使用PHY端的延时而不是MAC或PCB

出于以下原因，尽可能使用PHY端RGMII延迟：

PHY设备可以提供亚纳秒的粒度，以确定它们如何允许指定接收器/发送器侧延迟（例如：0.5,1.0,1.5ns）. 可能需要这种精度来解决PCB走线长度的差异
PHY器件通常适用于大范围的应用（工业，医疗，汽车…），并且它们在温度/压力/电压范围内提供恒定且可靠的延迟
PHYLIB中的PHY设备驱动程序本质上是可重用的，能够正确配置指定的延迟，使具有类似延迟要求的更多设计能够正确运行
对于PHY无法提供此延迟但是以太网MAC驱动程序能够执行此操作的情况，正确的phy_interface_t值应为PHY_INTERFACE_MODE_RGMII，并且应正确配置以太网MAC驱动程序以提供所需的传输和/或或者从PHY设备的角度接收侧延迟. 相反，如果以太网MAC驱动程序查看phy_interface_t值，对于除PHY_INTERFACE_MODE_RGMII之外的任何其他模式，它应确保禁用MAC级延迟.

4 其他方式实现的延时

如果根据RGMII标准定义的以太网MAC和PHY都不能提供所需的延迟，则可以使用以下几个选项：

一些SoC可能提供一个引脚焊盘/多路复用器/控制器，能够配置一组给定的引脚强度，延迟和电压; 并且可能是插入预期的2ns RGMII延迟的合适选项.
修改PCB设计以包括固定延迟（例如：使用专门设计的蛇形），这可能根本不需要软件配置.

5 延时不匹配会怎样

Common problems with RGMII delay mismatch
当以太网MAC和PHY之间存在RGMII延迟不匹配时，当PHY或MAC对这些信号进行快照以将其转换为逻辑1或0状态时，这很可能导致时钟和数据线信号不稳定并重建正在传输/接收的数据. 典型症状包括：

发送/接收部分工作，并且观察到频繁或偶然的分组丢失
以太网MAC可能会报告一些或所有因FCS / CRC错误而进入的数据包，或者只丢弃它们
切换到较低的速度，例如10 / 100Mbits / sec会使问题消失（因为在这种情况下有足够的设置/保持时间）

6 ZYNQ的MAC可以调整延时吗

参考：
https://adaptivesupport.amd.com/s/question/0D52E00006lLh56SAC/can-the-mac-controller-of-zynq7000-adjust-the-clock-and-data-delay?language=en_US

Q: can the mac controller of zynq7000 adjust the clock and data delay?
Using the mac controler of zynq7000 to directly connect to the mac of another arm through the RGMII interface, but the mac of the opposite arm requires 1.5ns delay for clk and data. Is the zynq7000’s mac side required for data and clock latency? Or can the delay be adjusted?

A: There is not tap delay or clock delay structure wtih GEM. We just meet timing with setup/hold values in the datasheet. It’s expected to be added by PHY or PCB trace.

7 RGMII版本

参考：
UG933 (v1.7.1) August 5, 2014
Zynq-7000 PCB Design Guide, page 65

Ethernet GEM
Depending which RGMII specification the external PHY supports, the TX/RX clocks might
need to be delayed on the PCB relative to their respective data and control lines:

• PHYs that support RGMII v1.3
Requires clock to be delayed using longer PCB routes by 1.5 ns – 2.0 ns with respect
to average delay of DATA[3:0] and CTL
Delay skew for DATA[3:0] and CTL should be less than 100 ps including package
time

• PHYs that support RGMII v2.0 without internal delays
Requires clock to be delayed using longer PCB routes by 1.5 ns – 2.0 ns with respect
to average delay of DATA[3:0] and CTL
Delay skew for DATA[3:0] and CTL should be less than 100 ps including package
time

• PHYs that support RGMII v2.0 with internal delays (RGMII-ID)
Delay skew for DATA[3:0] and CTL to clock delay should be less than ±50 ps
including package time
When using EMIO to connect to the PL, ensure that all clocks (TX and RX) route using
clock-capable I/Os.