MII模式下CRS信号处理实战：以LAT1595为例的完整指南-平芜编程栈

1. 为什么MII模式下的CRS信号成了“烫手山芋”

做嵌入式网络开发的朋友应该都有过这种经历：硬件原理图上明明把PHY的CRS、COL引脚连到了MAC，软件里配的也是标准的MII模式，可跑起来就是不对——要么收包错乱，要么系统偶尔卡死，最头疼的是问题还不好复现。我刚开始调LAT1595这颗芯片的Ethernet接口时，就在这个坑里蹲了差不多一周，最后翻到datasheet里一句不起眼的注释才恍然大悟：MII模式下CRS信号的处理，并不是“按照标准连上就行”那么简单。

先说清楚一个基本事实：MII（Media Independent Interface）是IEEE 802.3定义的一种MAC与PHY之间的标准接口，数据通路是4位宽，时钟25MHz，整体速率100Mbps。它区别于RMII（Reduced MII）的地方在于，MII保留了完整的信号集合，包括TX_ER、RX_ER、CRS和COL，而RMII为了省引脚，把这些状态信号砍掉了大半，只留了一个CRS_DV复用信号。正因如此，很多从RMII转过来做MII的工程师，会对CRS这种“在RMII里根本没单独出现过”的信号感到陌生，不知道它到底该怎么接、怎么配、怎么用。

MII信号组里，CRS（Carrier Sense，载波侦听）的作用是告诉MAC介质上有载波活动，也就是线路正处于“忙”的状态。只要TX或RX方向上有活动，CRS就会被PHY拉高。在10Mbps模式下，CRS在帧传输期间保持有效，在100Mbps模式下CRS在帧前导码和帧数据期间有效。从协议层面看，CRS是CSMA/CD（载波侦听多路访问/冲突检测）机制的一部分，用于避免冲突；但在全双工模式下，这条信号的作用就很微妙了——因为全双工本身不依赖载波侦听来判断能否发送，它只关心对端是否在发数据。所以问题来了：在全双工MII模式下，CRS到底怎么处理？是忽略、是拉高、还是照常接？这恰恰是LAT1595这类芯片手册里说得最含糊、而实际工程中最容易出错的地方。

这篇文章我就以LAT1595的Ethernet接口为例，把我调MII模式时摸出来的CRS信号处理思路、Kconfig/设备树配置方式、以及那些“手册没写但实测会翻车”的细节，一起整理出来。适合正在调LAT1595、或者用其他带MII接口的MAC芯片且被CRS/COL信号困扰的开发者参考。

2. 先弄懂CRS在MII里的角色：全双工与半双工的天壤之别

2.1 从CSMA/CD机制说起

要理解CRS为什么重要，得先回到Ethernet最原始的机制。早期的Ethernet是共享介质网络，所有节点挂在同一条同轴电缆上，谁想发数据，得先“听”一下线路上有没有人在发。这个“听”的动作，就是载波侦听。CRS就是PHY把这个“听到的结果”上报给MAC的物理信号。

在100Mbps半双工模式下，MAC发送前必须确认CRS为低，才认为线路空闲，可以开始发送；如果发送过程中CRS突然变高（对端也在发），就说明发生了冲突，这时COL信号会被拉高，MAC需要执行退避算法，等待随机时间后重发。这套流程就是CSMA/CD。

而在全双工模式下，链路两端使用独立的收发通道，MAC发送数据时不需要管线路上有没有其他节点在发送，因为对端的发送走的是另外一对线。这样CRS就没有存在的必要了。IEEE 802.3规范里也说明了：在全双工模式下，PHY可以不产生CRS，或者MAC不需要响应CRS。

但问题在于，很多PHY芯片并不清楚自己连接的上游MAC到底工作在什么模式。CRS是PHY根据物理线路状态主动拉高/拉低的，它不知道MAC是全双工还是半双工。所以MAC一侧必须在逻辑上正确处理这个信号：要么根据双工模式主动忽略它，要么在硬件上把它处理成不造成影响的状态。

2.2 为什么CRS处理不当会“卡死”系统

如果MAC内部逻辑没有正确屏蔽CRS，在配置为全双工时仍然把CRS当作“忙”信号来阻塞发送队列，就会出现一个很隐蔽的现象：PHY在收到远端数据时拉高CRS，MAC看到CRS高就推迟自己的发送，于是发送延迟变得不稳定，时延抖动很大；极端情况下，如果PHY在链路空闲时因为噪声或者其他原因误触发CRS（这在某些PHY上是存在的），MAC就会被“锁死”在等待状态，表现就是整个网络接口看起来瘫了，但寄存器和中断都是正常的。

这还不是最糟的。更常见的一个问题是：CRS和COL信号在MAC芯片内部如果被送到中断控制器或者DMA引擎，一旦PHY在上电初始化或link down/up切换瞬间产生毛刺，就可能触发MAC的异常中断，干扰驱动的正常运行。LAT1595这类集成MAC的FPGA芯片，如果信号没有在FPGA内部做同步和过滤，毛刺很容易被采集到，进而影响状态机的正常工作。

2.3 半双工场景下CRS是真的要用的

与全双工相反，半双工模式下CRS是必须使用的。虽然现在绝大多数网络设备默认跑全双工，但在一些工业现场，老旧的集线器（Hub）仍然存在，此时链路协商结果会是半双工。如果MAC在硬件层面直接把CRS屏蔽掉，半双工模式下的冲突检测就彻底失效了，两个节点同时发送时不会退避，数据大量冲突，网络退化到几乎不可用。

所以在设计阶段就要想清楚：产品是只支持全双工，还是需要兼容半双工？如果需要兼容，那CRS必须被正确引入MAC逻辑，而不能简单地“接个下拉电阻了事”。

3. LAT1595的MII接口信号全览：除了CRS还有哪些容易忽略的引脚

3.1 标准MII信号分组

先列出完整的MII接口信号，方便对照检查硬件连接。MII总共需要16根信号线（不包含管理接口MDIO/MDC），分为发送、接收、状态和管理四类：

信号组	信号名	方向（MAC视角）	说明
发送数据	TXD[3:0]	输出	4位并行发送数据
发送控制	TX_EN	输出	发送使能，高有效
发送错误	TX_ER	输出	发送错误指示
发送时钟	TX_CLK	输入	25MHz（100M）/ 2.5MHz（10M）
接收数据	RXD[3:0]	输入	4位并行接收数据
接收控制	RX_DV	输入	接收数据有效
接收错误	RX_ER	输入	接收错误指示
接收时钟	RX_CLK	输入	25MHz（100M）/ 2.5MHz（10M）
状态	CRS	输入	载波侦听
状态	COL	输入	冲突检测
管理	MDC	输出	管理时钟
管理	MDIO	双向	管理数据

注意，TX_CLK和RX_CLK的方向是相对于MAC的输入。这两个时钟分别由PHY根据自身链路速率产生，MAC不能反向提供时钟给PHY（那是RMII模式下的做法）。这一点在FPGA工程里特别容易被混淆，尤其是之前做过RMII设计的人——RMII模式下50MHz参考时钟由MAC侧的时钟源提供，而MII模式下MAC必须被动接收PHY送来的TX_CLK和RX_CLK。如果LAT1595的FPGA逻辑里把TX_CLK当输出引脚去驱动，硬件上必然会打架。

3.2 CRS和COL的内部逻辑位置

在LAT1595内部，MII接口通常挂在一个EMAC（Ethernet MAC）软核或硬核上。CRS和COL信号进入MAC核之后，会被送到一个叫“flow control / duplex control”的逻辑块。全双工模式下，该逻辑块会忽略CRS和COL；半双工模式下，CRS用于载波侦听，COL用于冲突检测，驱动退避算法的状态机。

这里有一个可能在FPGA工程里遇到的实际问题：CRS和COL在MAC核内部如果被当作异步信号直接使用，而它们来自PHY，且与RX_CLK（25MHz）同步，那么如果MAC核内部用TX_CLK域去采样，就会产生跨时钟域问题。LAT1595的MAC核通常已经做好了同步处理，但当我们在FPGA里自己扩展逻辑时，比如想用CRS做链路空闲判断、流量统计等，就一定要自己加两级同步器，否则大概率出现亚稳态导致的偶发逻辑错误。

3.3 PHY侧与MAC侧的连接映射关系

从PHY角度看，CRS和COL是输出信号，MAC侧是输入信号。PHY内部根据RXD、RX_DV、TX_EN、TXD等信号综合出CRS：只要RX_DV有效或者TX_EN有效，CRS就置高。COL则是当PHY的接收和发送同时发生时（半双工模式下）被拉高。所以CRS的时序其实和RX_DV、TX_EN是严格相关的，它不是一个独立的随机信号，而是由收发活动“组合”出来的。

这个特性意味着：如果PHY芯片的CRS引脚在硬件设计时被悬空，PHY内部逻辑可能仍然能正常工作，但CRS引脚会因为浮空而随机跳动，MAC侧如果读了它，就可能得到错误的“忙”状态。反过来，如果CRS被接到一个电平固定的引脚（比如直接接GND），那PHY输出的实际CRS信号就被外部电路强制拉低了，半双工模式下MAC无法侦听载波，网络行为异常。所以CRS在硬件上不能随意绑死，要根据模式需求处理。

4. 全双工MII模式下CRS的典型处理方案与取舍

4.1 方案一：在PHY侧配置寄存器，让CRS不再产生

不少PHY芯片（如Marvell、Broadcom、Realtek的常见千兆/百兆PHY）提供寄存器位来控制CRS功能。最典型的是在100M全双工模式下，通过PHY的特定寄存器（例如Marvell的Copper Control Register、Broadcom的Shadow Register等）把“Carrier Sense”功能关掉，或者把CRS引脚设置为强制低电平输出。

这样做的好处是MAC侧完全不用关心CRS，硬件上把引脚接到固定的高/低电平即可。缺点也很明显：PHY寄存器配置需要额外的初始化代码，而且不同厂商的PHY寄存器映射不一样，驱动代码的通用性会下降。此外，一旦以后需要切换半双工模式（比如现场被强制到10M半双工），这套配置就会导致载波侦听失效。

从实际项目角度看，如果产品定义明确“只做千兆/百兆全双工，永不支持半双工”，那么在PHY寄存器里关掉CRS是可行且干净的。但一旦产品需要兼容工业现场的老旧交换机或Hub，建议不要这么做。

4.2 方案二：在MAC侧忽略CRS，只保留内部逻辑上的“虚拟载波侦听”

这是目前绝大多数主流MAC/驱动采用的方案。MAC核在全双工模式下，内部逻辑自动忽略外部CRS信号，发送行为完全由内部FIFO状态和流控机制控制，不等待CRS。与此同时，MAC仍然向驱动软件上报链路状态（link up/down），这个状态来自PHY的寄存器（通过MDIO读取），而不是来自CRS引脚。

这样做的好处是PHY不需要做特殊配置，硬件连接保持标准MII引脚定义即可，驱动代码可移植性最好。缺点是不能完全“物理上不管”——引脚还是得接好，因为PHY在链路刚建立、自协商过程中可能会让CRS出现跳变，如果MAC核没有对CRS做去抖处理，这些跳变可能被上层误判为链路抖动。

在LAT1595的FPGA设计中，通常做法是：MAC核实例化时，把duplex mode配置为全双工，并确认MAC核内部已经把CRS、COL的输入在逻辑上忽略。如果你用的是软核MAC（比如Lattice的Ethernet MAC IP或第三方IP），需要查看IP核的端口说明，有些IP核干脆不把CRS/COL引出来，而是在IP内部直接接地；有些IP核则保留这两个信号，需要用户自己处理。

我自己用LAT1595的MAC IP核时，发现该IP在全双工模式下默认把CRS和COL输入当作“don't care”，但综合工具仍然要求这两个信号有驱动源，不能悬空。所以在FPGA顶层，我把CRS和COL的FPGA引脚约束为输入，然后在RTL里统一连接到MAC核的对应端口，同时在模块内部加了一级同步器，将PHY来的CRS同步到RX_CLK域后再送进MAC核。同步器输出的信号即便没有被MAC核使用，也保证不会有亚稳态问题传导到其他逻辑。

4.3 方案三：硬件上通过下拉/上拉电阻固定电平

在电路板设计层面，有些人会直接把CRS和COL引脚通过10kΩ电阻下拉到地，或者上拉到高电平，认为这样“既满足了引脚不能悬空的要求，又不会影响正常工作”。实际上这个做法需要谨慎。

如果下拉到地，CRS恒为低，PHY侧正常工作在半双工模式时MAC将永远认为线路空闲，冲突检测失效。如果上拉到高，CRS恒为高，MAC在半双工模式下会一直认为线路忙，永远不发送数据。这两个结果在全双工模式下来看问题不大（因为MAC忽略CRS），但一旦链路协商成半双工，行为就是灾难性的。

所以如果你采用固定电平方案，前提必须是：产品软件层强制指定全双工模式，并且自协商被关闭或只允许全双工。否则我建议还是老老实实把CRS接入MAC，让协议栈自己处理。

4.4 我的推荐：全双工为主、兼容半双工的折中做法

结合LAT1595的实际场景，我推荐的做法是：

硬件上完整接入CRS和COL，不悬空、不完全固定电平。
MAC核运行在全双工模式，软件配置强制全双工，关闭自协商中的半双工能力（通过设置PHY的advertised abilities寄存器）。
PHY侧不主动关闭CRS，保持默认行为。
FPGA内部对CRS、COL添加同步器和可选的去抖动滤波（防止link切换瞬间的毛刺被MAC状态机误采）。
驱动层不依赖CRS判断链路状态，链路状态只从PHY的Link Status寄存器读取。

这个方案的好处是：正常工作时CRS完全不影响数据通路，全双工的吞吐和延迟都正常；万一以后需要兼容半双工场景（更换PHY、或修改PHY寄存器），只需要把MAC核配置改成半双工，硬件无需改动，FPGA的同步器和信号通路仍然有效。灵活性最高，改造代价最小。

5. 踩坑实录：LAT1595上CRS处理不当的真实报错与排查过程

5.1 现象描述：系统偶尔“整个网络接口消失”

我最初调试LAT1595时遇到的问题很诡异：FPGA加载完成后，网络接口能正常起来，ping也通，但运行十几分钟到几十分钟不等，网络接口会突然“消失”——ifconfig里看不到网卡，或者网卡还在但ping不通。而且这种现象在低温环境下更容易复现，温度低的时候基本十几分钟必现。

第一次遇到时我第一反应是PHY芯片不稳定，换了PHY芯片、换了晶振，问题依旧。又怀疑是电源纹波，加了电容滤波，也没有本质改善。排查了两三天，整个人都是懵的。

5.2 排查链路：从软件栈逐步逼到硬件信号

我的排查顺序是这样的：

查看内核日志，确认网卡驱动是否报错。结果没有任何error级别的消息，只是在故障瞬间出现过一次“tx timeout”的警告。
查看PHY状态，通过MDIO读取PHY寄存器，发现故障时PHY的Link Status从“up”变成了“down”，但随即又恢复up。也就是说，PHY认为链路短暂断开了一下。
用示波器抓PHY的链路状态引脚（如果有的话），发现这个引脚并没有变化，说明PHY的物理链路其实没问题，但寄存器里的Link Status位发生了一次翻转。
检查MDIO总线上是否有干扰，发现MDIO在故障瞬间出现了一串异常波形。继续追，发现是MAC侧主动发起了一笔MDIO读操作，读的恰好是PHY的Link Status寄存器。
继续向上追：为什么MAC会突然读Link Status？因为MAC收到了一个link change事件。再追，发现link change事件来自MAC核的“link status change”中断，而这个中断的触发条件是——CRS信号出现了一个由高到低的跳变。

到这里真相大白了：PHY在正常运行过程中，CRS本身会因为远端偶尔发来的广播包、ARP包而拉高再拉低，这个拉高再拉低的动作被MAC核当作“链路状态变化”上报给了中断控制器，于是驱动就误以为链路down了，触发了一连串的PHY寄存器读取和重新协商流程。虽然链路最终恢复了，但在这期间数据通路会被暂时挂起，表现就是网络接口“消失”了一段时间。

5.3 根因分析：MAC核把CRS当作链路状态信号了

为什么MAC核会把CRS当作链路状态变化呢？查了LAT1595的MAC IP核说明文档，发现它在“链路状态检测”部分有一个设计选择：当CRS信号从高变低时，MAC核会触发一次“carrier lost”事件。这个事件在IP核内部被映射到了中断控制器，用于表示“载波丢失”。

在半双工模式下，这个事件确实有意义——载波丢失意味着冲突退避结束，或者链路空闲。但在全双工模式下，CRS的跳变只是正常收发活动的体现，不应该被视为“链路故障”。问题就在于IP核的默认配置里，这个事件在两种模式下都被上报了，导致全双工模式下会出现误报。

5.4 解决：在FPGA内部滤除CRS在正常收发时的跳变

定位到根因后，解决方案就比较清晰了：在全双工模式下，不能让CRS的每一个下降沿都直达MAC核的链路状态检测逻辑，需要做“语义翻译”——把“CRS跳变”转换成MAC核真正关心的“链路物理断开”。

链路物理断开的特征是：RX_CLK消失、RX_DV长时间无活动、或者PHY的Link状态寄存器翻转。这几种情况与CRS的正常跳变有本质区别。于是我做了两件事：

第一，把FPGA输入的CRS信号做了一级同步和滤波。用一个几十微秒的窗口对CRS做“确认”：只有当CRS保持低电平超过这个窗口，才认为载波真的丢失；如果只是短暂跳变，就过滤掉。这个窗口时间可以根据实际PHY的行为调整，太小了滤不掉毛刺，太大了会延迟链路down事件的检测。

第二，在驱动层面，把MAC核的事件掩码寄存器重新配置，在确认模式为全双工时，屏蔽掉“carrier lost”事件上报，只保留真正的link down中断（由MDIO状态寄存器变化触发）。

改完之后，跑了一个星期的长时间压力测试和低温测试，问题再也没有复现。这里也提醒一下：如果你的MAC核提供了中断掩码寄存器，一定要去查datasheet里每个中断位的触发条件，不要只看名字想当然。

6. 软件配置要点：设备树、驱动与PHY寄存器的配合

6.1 设备树中MII模式的描述方式

在Linux系统下使用LAT1595的Ethernet MAC时，设备树里需要明确指定phy-mode为“mii”。设备树节点大致长这样：

&emac0 { status = "okay"; phy-mode = "mii"; phy-handle = <&phy0>; phy0: ethernet-phy@0 { reg = <0>; /* PHY地址为0，按实际硬件配置 */ }; };

phy-mode的值直接决定了MAC核的接口配置。如果这里误写成“rmii”，MAC核会按RMII的引脚定义去采样，届时TX_CLK/RX_CLK的相位关系完全不对，网络接口根本起不来。

6.2 驱动里关于双工模式的处理

在驱动初始化时，需要读取PHY的协商结果，并据此配置MAC核的双工模式。这里有一个容易踩的坑：有些驱动只在link up时配置一次双工模式，但如果链路在运行中被重新协商（比如对端重启），双工模式可能发生变化，而MAC核没有同步更新，就会导致收发行为异常。

所以建议在驱动的adjust_link回调函数里，每次链路状态变化时都重新把双工模式写入MAC核寄存器，同时根据双工模式动态决定是否处理CRS/COL中断。伪代码如下：

static void adjust_link(struct net_device *ndev) { struct phy_device *phydev = ndev->phydev; int duplex; if (phydev->link) { duplex = phydev->duplex; /* 配置MAC核双工模式 */ mac_write_duplex(ndev, duplex); /* 全双工时屏蔽carrier lost中断，半双工时打开 */ if (duplex == DUPLEX_FULL) mac_enable_carrier_lost_irq(ndev, false); else mac_enable_carrier_lost_irq(ndev, true); } }

这里最关键的一点是：不要假设链路永远不会从全双工切到半双工。工业现场的对端交换机可能在调试中被重启、换配置，链路重新协商后可能改变双工模式。如果你在驱动里写死了“只匹配全双工”，那么一旦对端变成半双工，你的MAC核还是按全双工逻辑运行，CRS被忽略，冲突检测失效，网络性能会断崖式下降。

6.3 PHY寄存器侧的关键配置

PHY初始化时，需要把本端支持的速率/双工能力设置好。以最常见的百兆PHY为例，需要操作的是PHY的ANAR（Auto-Negotiation Advertisement Register，地址4）和BMCR（Basic Mode Control Register，地址0）寄存器。

如果你想关闭半双工能力，让链路只能协商到全双工，可以这样操作：

/* 读取ANAR寄存器 */ u16 anar = phy_read(phydev, MII_ADVERTISE); /* 清除100Base-TX Half和10Base-T Half位，保留Full位 */ anar &= ~(ADVERTISE_100HALF | ADVERTISE_10HALF); phy_write(phydev, MII_ADVERTISE, anar); /* 重启自协商 */ u16 bmcr = phy_read(phydev, MII_BMCR); bmcr |= BMCR_ANRESTART; phy_write(phydev, MII_BMCR, bmcr);

这样配置之后，对端即使只支持半双工，两端协商不出双方都支持的half模式，就只能放弃协商或者协商到全双工（如果对端也支持全双工）。如果对端是只能半双工的老旧设备，那么链路协商会失败，网络接口无法起来——这其实是好事，因为半双工和全双工强制错配导致的网络瘫痪比link down更可怕。

6.4 用mdio-tools手动验证PHY行为

在调试过程中，我强烈建议在Linux用户态使用mdio-tools（或老版本的mii-tool）来手动读写PHY寄存器，快速验证硬件连接和PHY配置是否生效。例如：

# 查看PHY基本状态 mii-tool eth0 # 读取PHY的ANAR寄存器（地址4） mdio-tools eth0 reg read 4 # 读取PHY的基本模式控制寄存器（地址0） mdio-tools eth0 reg read 0

如果你发现mii-tool的输出显示“negotiated 100baseTx-HD”或“100baseTx-FD”，但驱动里配置的模式与之不符，那问题基本就锁定在MAC核模式配置上。这种软件工具定位问题的方法，比反复猜硬件原因要高效得多。

7. 关于CRS信号处理的最终建议清单

调试MII接口的CRS信号，我总结下来其实就几条原则，但每条背后都有真实的“学费”。整理成清单放在这里，方便你做硬件设计评审或写代码时对照自查。

硬件设计层面

CRS和COL引脚必须接入MAC，不能悬空。如果MAC核确实用不到，也要接上下拉电阻固定到确定电平，避免浮空输入带来的不确定电流消耗和状态抖动。
如果决定使用固定电平方案，务必确保软件强制全双工，且关闭自协商中的半双工能力，否则链路协商到半双工时行为会异常。
PHY的CRS、COL与MAC之间不需要串联电阻或滤波电容（除非datasheet有特殊要求），正常走线即可。但要注意信号完整性，CRS/COL属于慢速状态信号，对走线长度要求不高，不过尽量远离TX_CLK/RX_CLK这类高速时钟线，避免耦合噪声。

FPGA逻辑层面

进入MAC核的CRS信号，建议先做两级同步器（同步到RX_CLK域），再做可选的脉冲滤波。不要直接把来自PHY引脚的电平信号接入MAC核内部逻辑。
如果MAC核提供了中断掩码，检查每个中断位的触发条件，尤其是与CRS/COL相关的事件，在全双工模式下要评估是否需要屏蔽。
不要在多个时钟域里直接使用CRS做判断。CRS本身与RX_DV/TX_EN同步产生，但它跨越了RX和TX两个时钟域，所以任何基于CRS的逻辑都要明确自己处在哪个时钟域，避免跨域直采。

软件驱动层面

链路状态判断，一律以PHY的Link Status寄存器为准，不要依赖CRS。CRS反映了介质活动，但不等同于链路物理连接状态。
在adjust_link回调里动态更新MAC核的双工模式，并动态使能/屏蔽CRS相关中断。不要只配置一次。
通过设备树明确配置phy-mode为“mii”，不要靠“默认值”蒙混过关。默认值往往是“不工作”的同义词。

测试验证层面

全双工压力测试要包含多种帧长混合流量，观察是否有“praticle lost”或tx timeout异常。
半双工测试建议使用一个真正的Hub（不是交换机）来连接两个节点，制造一个真实的冲突环境，验证退避算法是否正常工作。
低温环境测试对信号毛刺问题很有帮助，很多偶发故障在低温下更容易暴露，如果你的产品有温度范围要求，一定要做高低温摸底。

8. 附：LAT1595以外，这个方法对谁同样有效

这篇文章虽然一直以LAT1595为背景，但CRS信号处理的原则并不仅限于这一颗芯片。任何带MII接口的MAC，无论是FPGA软核（Lattice、Xilinx、Altera的Ethernet MAC IP），还是MCU内嵌的MAC（STM32、NXP、Microchip等），在处理CRS时面临的本质问题是一样的：全双工模式下这个信号是否会被误用、半双工模式下是否还能正确参与冲突检测。

如果你用的是带MII接口的MCU，处理方式可能更简单一些，因为MCU内部MAC核的寄存器已经把CRS/COL行为封装好了，驱动代码通常也是厂商提供的，你需要做的只是在初始化时正确配置双工模式，并确认中断屏蔽位。但原理是一样的。而FPGA方案因为有灵活性，反而更容易踩坑——因为一切都暴露在RTL层，稍不留神就会把信号处理错。

最后说一点个人体会：调试这种“看起来很简单但实际很玄学”的信号，最重要的是建立一套可靠的观测手段。我后来在FPGA里加了一个调试探针，把CRS、COL、RX_DV、TX_EN这几个信号实时映射到GPIO上，用逻辑分析仪去抓。一旦网络出现异常，先看这几个信号的状态，基本能立刻定位是PHY侧行为异常，还是MAC侧逻辑处理有问题，省去了大量猜测的时间。如果你也在调类似的接口，建议从一开始就把观测手段预留好，别等问题出现了再临时加。