在FPGA以太网开发这条路上，选IP核这件事看起来不起眼，实际上能决定你后面三个月是顺风顺水还是天天抓bug。我见过太多项目，板子画好了、PHY选好了、时钟也规划完了，结果卡在IP核选型上——有人用Tri Mode Ethernet MAC搭好了千兆链路，却发现要自己手写一大堆胶水逻辑去对接DMA；也有人直接上了AXI Subsystem，结果发现资源占用比预期高出一截，时序还不好收敛。这两个IP核都在Xilinx的以太网解决方案里扮演核心角色，但它们面向的场景、抽象层次、集成成本完全不同。这篇内容就是把我自己在几个实际项目里踩过的坑、做过的对比、以及最终选型的判断逻辑完整摊开来讲，帮你在下一个项目里少走弯路。
1. 先搞清楚这两个IP核到底各自在干什么
1.1 Tri Mode Ethernet MAC的定位：一个纯粹的MAC层引擎
Tri Mode Ethernet MAC，简称TEMAC，从名字就能看出来它的核心能力——支持10/100/1000 Mbps三种速率的以太网MAC控制器。它实现的是OSI模型里数据链路层的上半部分，负责的事情包括：帧的封装与解封装、CRC校验的生成与验证、地址过滤、流量控制、以及和PHY之间的GMII/RGMII/SGMII接口管理。
你可以把它理解成一个“纯手工”的MAC引擎。它给你提供的是最底层的以太网帧收发能力，至于帧怎么来的、往哪里去、怎么和你的应用逻辑对接，全部由你自己决定。它的接口通常是AXI4-Stream或者更简单的FIFO-like本地接口，你需要自己写逻辑去驱动它。
这种设计的好处是灵活。你可以用它做非常定制化的东西，比如自己实现一套精简的协议栈、做超低延迟的直通转发、或者把MAC层嵌入到一个非标准的系统架构里。坏处也很明显——你得自己处理很多事情，包括但不限于：描述符管理、缓冲区分配、中断处理、多队列调度。如果你的项目需要完整的TCP/IP卸载或者DMA搬运，光靠TEMAC是不够的，你还得额外集成DMA控制器和中断控制器。
从资源占用来看，TEMAC本身比较轻量。在7系列FPGA上，一个千兆TEMAC大概占用几百个LUT和几个Block RAM，具体数字取决于你使能了哪些功能（比如是否开启VLAN、是否支持Jumbo Frame、是否有多播过滤等）。这个资源量对于中低端FPGA来说非常友好。
1.2 AXI Ethernet Subsystem的定位：一个完整的以太网子系统
AXI Ethernet Subsystem，有时候也被叫做AXI 1G/2.5G Ethernet Subsystem，它做的事情比TEMAC多得多。它内部其实就包含了一个TEMAC（或者更高速率的MAC），但在外面包了一整套AXI接口的基础设施：AXI4-Lite用于寄存器配置、AXI4-Stream用于数据通路、AXI4用于DMA描述符访问。它还集成了DMA引擎、缓冲区描述符管理、中断聚合、以及可选的硬件校验和卸载等功能。
换句话说，AXI Ethernet Subsystem给你的是一个“开箱即用”的以太网解决方案。你只需要通过AXI4-Lite配置几个寄存器，把AXI4-Stream接到你的数据源/数据汇，再处理好DMA描述符环，就能跑起来一个完整的以太网数据通路。它把很多繁琐的底层细节都封装好了，你不需要关心MAC和DMA之间怎么握手、描述符怎么对齐、中断怎么合并。
但代价是什么呢？首先是资源占用更高。因为集成了DMA和AXI互联逻辑，整体面积比单独一个TEMAC大不少。在Artix-7这个级别的器件上，一个完整的AXI Ethernet Subsystem可能会占用上千个LUT和十几个Block RAM。其次是灵活性受限——你很难去修改它内部的MAC行为，比如你想做一个非标准的帧格式或者极低延迟的旁路通道，AXI Ethernet Subsystem的架构可能就不太适合。
1.3 一张表看清两者的核心差异
| 对比维度 | Tri Mode Ethernet MAC | AXI Ethernet Subsystem |
|---|---|---|
| 抽象层次 | MAC层引擎 | 完整子系统（MAC+DMA+AXI互联） |
| 数据接口 | AXI4-Stream或本地FIFO接口 | AXI4-Stream + AXI4-Lite + AXI4 |
| DMA支持 | 无，需外接 | 内置DMA引擎 |
| 描述符管理 | 无 | 内置BD环管理 |
| 中断支持 | 需自行设计 | 内置中断聚合与队列管理 |
| 资源占用 | 较低 | 较高 |
| 灵活性 | 高 | 中等 |
| 开发周期 | 较长 | 较短 |
| 适用场景 | 定制协议、低延迟、资源敏感 | 标准以太网通信、快速原型、Linux对接 |
这张表不是让你死记硬背，而是帮你在做选型决策时快速定位。接下来我会把每个维度展开讲，尤其是那些表格里看不出来的“隐性成本”。
2. 选型时最容易忽略的三个隐性成本
2.1 胶水逻辑的开发和调试时间
很多人选TEMAC的理由是“资源省”，但很少有人认真估算过自己写胶水逻辑要花多少时间。我拿一个真实项目举例：当时我们需要在一个Artix-7 35T上实现千兆以太网数据采集，每秒大概需要传输80MB的ADC采样数据。最初方案是TEMAC加一个自己写的DMA控制器，觉得这样资源最省。
结果呢？光是DMA描述符环的设计和调试就花了将近三周。问题出在几个地方：描述符的内存对齐要求、AXI4-Stream的背压处理、中断和轮询的混合调度、以及缓冲区溢出时的恢复逻辑。这些东西在AXI Ethernet Subsystem里都是现成的，但自己写就意味着每一个边界条件都要考虑到。
更麻烦的是调试。当你自己写的DMA和TEMAC之间的握手出问题时，你面对的是两个独立的IP核加上你自己的逻辑，波形抓起来非常痛苦。而AXI Ethernet Subsystem内部虽然也有复杂的握手，但至少Xilinx已经帮你验证过了，你只需要关注外部的AXI4-Stream接口。
所以我的经验是：如果你团队里没有对以太网DMA非常熟悉的人，或者项目时间比较紧，不要轻易为了省资源而选TEMAC。省下来的LUT可能只值几百块钱，但多花的三周人力成本可能是这个数的好几倍。
2.2 驱动和软件栈的适配成本
如果你用的是嵌入式Linux或者裸机环境，AXI Ethernet Subsystem的软件生态要成熟得多。Xilinx的SDK和PetaLinux里都有现成的驱动，你只需要在设备树里配好寄存器地址和中断号，基本就能跑起来。而TEMAC的话，你要么自己写驱动，要么去找第三方的MAC驱动来改，这个工作量也不小。
我印象很深的一次是帮一个客户调试他们的裸机以太网程序。他们用的是TEMAC加自研DMA，结果在LWIP协议栈的移植上卡了很久。问题在于LWIP默认的以太网驱动接口和他们的硬件描述符结构不匹配，需要写一层适配层。而如果用AXI Ethernet Subsystem，Xilinx已经提供了lwip的适配示例，改改就能用。
当然，如果你做的是完全定制化的协议，不需要跑标准协议栈，那这个成本就不存在。但大多数项目还是需要至少跑一个UDP或者TCP的，这时候软件栈的成熟度就很重要了。
2.3 时序收敛的难度差异
AXI Ethernet Subsystem因为内部逻辑更复杂，时钟域交叉更多，时序收敛的难度通常比TEMAC高。特别是在低端器件上，比如Spartan-7或者Artix-7的低速等级，如果AXI互联的时钟频率跑得比较高（比如125MHz以上），很容易出现时序违例。
TEMAC的话，因为逻辑相对简单，时序通常比较好收敛。但这也取决于你怎么用它——如果你在TEMAC外面包了一大堆组合逻辑，那时序一样会差。
这里有一个实操建议：如果你决定用AXI Ethernet Subsystem，尽量把AXI4-Stream的数据位宽设大一点（比如64位或128位），这样可以用更低的时钟频率达到同样的吞吐量。比如你要跑千兆，用8位@125MHz和用64位@15.625MHz，后者的时序压力小得多。当然，位宽大了资源也会上去，这是一个权衡。
3. 不同项目场景下的选型决策树
3.1 场景一：标准千兆以太网通信，跑Linux或LWIP
这是最常见的场景。如果你的FPGA需要和上位机做标准的TCP/UDP通信，或者要接入一个Linux系统，那AXI Ethernet Subsystem几乎是默认选择。原因很简单：驱动现成、协议栈适配成熟、开发周期短。
具体来说，如果你用的是Zynq或者Zynq MPSoC，PS端自带千兆以太网控制器，你甚至不需要在PL端加以太网IP。但如果你需要多个网口，或者需要从PL端直接采集数据并通过以太网发送，那AXI Ethernet Subsystem就是最顺手的方案。
在这个场景下，我通常会把AXI Ethernet Subsystem配置成：使能DMA、使能中断、使用64位AXI4-Stream数据位宽、开启硬件校验和卸载。这样CPU的负担最小，吞吐量也容易做上去。
3.2 场景二：超低延迟的定制协议
有些应用对延迟极其敏感，比如高频交易、工业实时控制、或者某些雷达信号处理场景。这些场景下，标准的以太网协议栈带来的开销（比如中断延迟、内存拷贝、协议栈处理）是不可接受的。你需要的是从PHY到应用逻辑的直通路径。
这时候TEMAC就更合适。你可以把TEMAC配置成纯AXI4-Stream模式，数据从PHY进来后直接流进你的处理逻辑，中间不经过任何DMA或内存。发送方向同理，你的逻辑直接产生以太网帧，通过TEMAC发出去。整个路径的延迟可以做到微秒级甚至更低。
我做过一个工业控制的项目，要求从收到以太网帧到输出控制信号的总延迟小于2微秒。用AXI Ethernet Subsystem根本做不到，因为光DMA和中断的开销就超过这个数了。最后用TEMAC加纯组合逻辑的方案，延迟做到了800纳秒左右。
3.3 场景三：资源极度受限的低端FPGA
如果你用的是Spartan-7或者更小的器件，资源非常紧张，那TEMAC可能是唯一的选择。AXI Ethernet Subsystem在低端器件上可能会占用你一半以上的逻辑资源，根本不现实。
但即使在这种情况下，你也要仔细评估。如果你的应用只需要跑一个简单的UDP收发，不需要高性能DMA，那TEMAC加一个精简的DMA（比如自己写一个简单的FIFO搬运逻辑）可能就够了。但如果你的应用需要多队列、需要硬件校验和、需要复杂的描述符管理，那即使资源紧张，也可能要考虑换一个更大一点的器件，或者重新评估需求。
3.4 场景四：需要多网口或高速率（2.5G及以上）
AXI Ethernet Subsystem支持2.5G的速率（通过AXI 1G/2.5G Ethernet Subsystem），而TEMAC通常只支持到1G。如果你需要2.5G或者更高的速率，那选择就很明确了。
多网口的话，两者都可以通过实例化多个IP核来实现。但AXI Ethernet Subsystem因为集成了DMA，多个实例之间的AXI互联会更复杂，需要仔细规划地址映射和中断分配。TEMAC的话，多个实例相对独立，互联逻辑需要自己设计，但灵活性更高。
4. 从TEMAC迁移到AXI Ethernet Subsystem的实操要点
4.1 接口层面的变化与适配
如果你之前用的是TEMAC，现在想迁移到AXI Ethernet Subsystem，首先要理解接口层面的变化。TEMAC的典型接口是：GMII/RGMII接PHY、AXI4-Stream接用户逻辑、以及一些配置寄存器。AXI Ethernet Subsystem的接口则是：GMII/RGMII接PHY、AXI4-Stream接DMA（内部）、AXI4-Lite接配置、AXI4接DMA描述符。
关键区别在于：在TEMAC方案里，你的用户逻辑直接和MAC的AXI4-Stream对接；而在AXI Ethernet Subsystem方案里，你的用户逻辑是通过DMA和MAC间接对接的。这意味着你需要重新设计数据通路——从“直接流”变成“描述符驱动”。
具体来说，你需要：分配一块内存作为DMA缓冲区、初始化描述符环、配置DMA寄存器、然后通过AXI4-Stream发送或接收数据。这个过程在Xilinx的文档里有详细说明，但实际调试时还是有几个坑。
4.2 描述符环的初始化陷阱
描述符环的初始化是迁移过程中最容易出问题的地方。我踩过的坑包括：描述符地址没有对齐到要求的边界、描述符的Own位没有正确设置、以及描述符环的长度不是2的幂次。
Xilinx的AXI Ethernet Subsystem要求描述符环的起始地址对齐到环大小的边界。比如你的环有64个描述符，每个描述符16字节，那环的总大小是1024字节，起始地址必须对齐到1024字节。这个要求如果不满足，DMA可能根本不动，或者行为异常。
另一个坑是Own位的管理。在接收方向，你需要把描述符的Own位设成“硬件拥有”，这样DMA才会把收到的数据写进去。在发送方向，你需要等DMA把Own位交还给软件后，才能重用这个描述符。如果Own位管理出错，会出现数据丢失或者DMA挂死。
4.3 中断与轮询的混合策略
AXI Ethernet Subsystem支持中断和轮询两种方式。在实际项目中，我通常采用混合策略：用中断来处理事件通知（比如收到一帧、发送完成），用轮询来处理批量数据搬运。
具体做法是：在中断服务程序里，只做最少的事情——记录状态、唤醒一个处理线程，然后尽快退出中断。真正的数据处理放在线程里，通过轮询描述符环来批量处理。这样可以避免中断风暴，也能降低延迟。
如果你用的是裸机环境，没有线程的概念，那就需要在主循环里轮询描述符环，同时用中断来处理异常事件。这种模式下，中断服务程序要尽可能短，只设置一个标志位就返回。
5. 那些文档里不会告诉你的调试经验
5.1 用ILA抓AXI4-Stream握手是最有效的调试手段
不管你选哪个IP核，AXI4-Stream的握手信号（TVALID和TREADY）都是调试的重点。我习惯在关键路径上插入ILA（Integrated Logic Analyzer），抓取TVALID、TREADY、TDATA、TLAST这几个信号。
对于TEMAC方案，重点看MAC和用户逻辑之间的握手。常见问题是：用户逻辑没有及时拉高TREADY，导致MAC侧背压，进而丢帧。或者用户逻辑在TVALID有效时没有保持TDATA稳定，导致数据错误。
对于AXI Ethernet Subsystem方案，重点看DMA和用户逻辑之间的握手。常见问题是：描述符没有及时提供，导致DMA空闲；或者用户逻辑处理速度跟不上，导致DMA背压，进而影响MAC侧的接收。
ILA的触发条件设置很关键。我通常会把触发条件设在TLAST有效且TREADY为低的时候，这样可以抓到帧尾的背压情况。另外，把TVALID和TREADY同时为高的周期数也值得关注，这反映了实际的有效吞吐量。
5.2 时钟域交叉处的亚稳态问题
以太网IP核通常涉及多个时钟域：PHY侧的接收时钟、MAC侧的GTX/TX时钟、AXI互联时钟、以及用户逻辑时钟。这些时钟域之间的交叉如果处理不当，会出现亚稳态问题。
Xilinx的IP核内部已经处理了大部分时钟域交叉，但在IP核和用户逻辑的边界上，你还是需要自己注意。比如，如果你用TEMAC的AXI4-Stream接口，而这个接口的时钟和你的用户逻辑时钟不同，那你就需要在两者之间加FIFO或者握手同步逻辑。
我的经验是：尽量让用户逻辑的时钟和IP核的AXI4-Stream时钟同源。如果做不到，那就用异步FIFO来隔离。不要试图用简单的双触发器同步器来跨时钟域传输多位数据，那一定会出问题。
5.3 复位顺序和复位时长的影响
以太网IP核的复位顺序和复位时长经常被忽略，但它们是很多“玄学”问题的根源。比如，如果MAC的复位没有完成你就开始配置寄存器，配置可能不生效。或者如果DMA的复位和MAC的复位顺序不对，DMA可能无法正确初始化。
Xilinx的文档里通常会给出推荐的复位顺序，但实际项目中，我建议在复位后加一个足够长的延时（比如1毫秒），确保所有内部状态机都回到空闲状态。这个延时看起来浪费，但能避免很多偶发问题。
另外，复位信号的亚稳态问题也值得注意。如果复位信号来自不同的时钟域，一定要做同步处理。我见过一个项目，复位信号直接从外部按键进来，没有做任何同步，结果偶尔会出现复位不彻底的情况，导致以太网链路时好时坏。
5.4 链路建立过程中的自协商问题
如果你用的是千兆以太网，PHY和MAC之间的自协商过程可能会出问题。常见现象是：链路指示灯亮了，但就是收不到数据。这通常是因为自协商没有完成，或者双方协商到了不同的速率/双工模式。
调试这个问题，首先要确认PHY的寄存器状态。大多数PHY芯片都有状态寄存器，可以读出当前的链路速率、双工模式、以及自协商是否完成。如果自协商没有完成，可以尝试强制设置速率和双工模式，看看是否能通。
另外，MAC侧的自协商配置也要和PHY匹配。有些MAC IP核支持自协商，有些不支持。如果不支持，你需要在MAC侧强制设置成和PHY一样的速率和双工模式。
6. 性能调优：让以太网吞吐量跑满的实战技巧
6.1 缓冲区大小的选择逻辑
缓冲区大小直接影响吞吐量和延迟。缓冲区太小，容易溢出丢包；缓冲区太大，延迟增加，内存占用也大。
对于AXI Ethernet Subsystem，我通常会把接收缓冲区设成至少能容纳两个最大帧（Jumbo Frame的话就是2×9000字节）。发送缓冲区类似。这样可以在DMA搬运和用户处理之间形成一个缓冲，避免因为处理不及时而丢包。
对于TEMAC方案，缓冲区的设计更灵活，但也更需要你自己把控。我通常会在MAC和用户逻辑之间加一个FIFO，深度根据数据速率和处理延迟来定。比如千兆速率下，如果用户逻辑的处理延迟是10微秒，那FIFO至少要有10微秒×125MB/s=1250字节的深度。
6.2 中断合并与轮询周期的平衡
中断合并是提高吞吐量的重要手段。AXI Ethernet Subsystem支持中断合并，可以设置收到多少个帧或者经过多长时间后才产生一次中断。这样可以减少中断次数，降低CPU负担。
但中断合并也会增加延迟。如果你对延迟敏感，就要把合并阈值设小一点，或者干脆用纯轮询模式。纯轮询模式下，CPU会一直检查描述符环，延迟最低，但CPU占用率最高。
我的经验是：对于吞吐量优先的场景，中断合并阈值可以设成8到16个帧；对于延迟优先的场景，设成1到2个帧，或者用轮询。具体数值需要根据实际测试来调。
6.3 校验和卸载的收益评估
AXI Ethernet Subsystem支持硬件校验和卸载，可以在硬件里计算IP、TCP、UDP的校验和。这个功能可以显著降低CPU负担，特别是在高速率下。
但校验和卸载也有代价：它需要额外的逻辑资源，而且配置起来稍微复杂一点。你需要设置哪些帧需要卸载、卸载哪些层的校验和、以及如何处理校验和错误。
我的建议是：如果你的CPU负担很重，或者速率超过500Mbps，那就开启校验和卸载。如果速率不高，或者CPU很空闲，那不开也无所谓，让软件去算校验和也行。
7. 写在最后的一些个人体会
选IP核这件事，没有绝对的对错，只有适不适合。我见过用TEMAC做出非常优雅设计的项目，也见过用AXI Ethernet Subsystem把项目搞得一团糟的案例。关键还是看你的需求、团队的能力、以及项目的时间预算。
如果让我给一个简单的判断标准：先问自己三个问题——第一，我需不需要跑标准协议栈？第二，我的团队有没有能力自己写DMA和驱动？第三，我的器件资源够不够？这三个问题的答案基本就能帮你做出选择。
另外，不要害怕在项目初期做原型验证。花两天时间搭一个最小系统，把两个IP核都跑一遍，看看哪个更顺手、哪个更符合你的预期。这个投入绝对值得，比你在项目中期发现选错了再回头要划算得多。
还有一点：Xilinx的IP核版本更新比较频繁，不同版本之间的行为可能有差异。如果你在网上找到的参考设计是基于旧版本的，迁移到新版本时一定要仔细看Change Log，特别是那些标注为“Behavioral Change”的条目。我在这上面吃过亏，一个看似无关紧要的更新，导致DMA的描述符对齐要求变了，结果调试了一整天才发现。
