本文约11,600字，建议收藏阅读

作者 | 林Nova

出品 | 汽车电子与软件

#01

随着汽车智能化、网联化浪潮的持续推进，车载网络架构正经历前所未有的变革。传统的CAN、LIN等总线技术已难以满足高速数据传输与实时数据处理的需求，而以太网凭借其高带宽、低延迟、可扩展性强等优势，正迅速成为下一代汽车电子系统的核心通信骨干。从智能座舱的多屏交互、自动驾驶传感器数据的实时融合，到车载信息娱乐系统与云端的高效互联，以太网技术正在重新定义汽车内部的数据流动方式。

在这一背景下，英飞凌科技作为全球汽车半导体领域的领导者，推出了Aurix™ TC4x系列微控制器，其中集成的千兆以太网（GETH）模块尤为引人瞩目。该模块不仅支持高速、可靠的以太网通信，更针对汽车功能安全（ISO 26262）、信息安全（HSM）及实时性要求进行了深度优化，为未来E/E架构的演进提供了关键的技术支撑。

这一代的GETH模块最高支持到5G速度的全双工以太网，具体特性如下：

• 支持10M、100M、1G、2.5G、5G速率全双工模式的以太网端口

• 支持10M和100M速率半双工模式的以太网端口

• 用于数据传输的、具备64位宽数据总线的主机主控接口

• 主机接口上的多通道DMA引擎，可以最少的软件干预传输数据

• 用于应用配置的32位从属接口

• 支持IEEE 802.1 AVB和TSN规范的硬件要求，包括：

• IEEE 802.1Qav – 时间敏感流的转发和队列增强

• IEEE 802.1AS 2020 – 时间敏感应用的定时和同步

• IEEE 802.1Qbu – 帧抢占

• IEEE 802.1Qbv – 计划流量的增强

• 在主机端口与入口/出口端口之间进行流量分类

• 灵活的/可编程的数据包头检测，用于过滤、监控方案，并支持防火墙保护和入侵检测服务

• 桥接功能（仅在具有以太网桥的产品中）：

• 该网桥连接两个以太网端口和一个公共主机接口

• 允许在这三个模块之间静态建立数据路径，即以太网帧的转发

• 汽车安全功能：

• 存储器错误校正码（ECC）保护

• 有限状态机奇偶校验和超时保护

• 应用/CSR接口超时保护

本文将对GETH模块内部的硬件进行介绍，并说明其以描述符为核心的收发控制逻辑，最后进行代码解析和示例展示。

#02

2.1 GETH结构

在TC4x系列芯片中，一个GETH模块最多包含两个XGMAC模块，和一个Bridge模块，向下连接至用于实现高速通信接口物理层的HSPHY（High Speed Phy），GETH模块与Port无直接连接，其架构关系图如下。

从图中可以看出fGETH模块为整个GETH模块的时钟输入，fSRI是总线时钟，用于与GETH模块进行数据交互使用。GETH模块同时还连接了IR中断模块和SMU功能安全监控模块。

每个GETH模块包含两个XGMAC模块，用于实现以太网链路层功能。同时这一代的GETH模块新增了一个Bridge，用于进行两路以太网之间各个DMA通道之间的数据路由。

每个XGMAC模块通过SGMII、USXGMII、RGMII、RMII、MII等数据接口及MDIO管理接口连接到HSPHY模块，以实现高速信号的物理层转换。

GETH内部详细结构如下图所示。

这一代的芯片总线位宽增加到了64位，对应的GETH模块内部也对总线访问接口做了优化，设置了Local Cross Bar，并配备两条LCB2SRI连接通道，这一设计可满足对SRI系统持续数据吞吐能力要求极高的应用场景。其中一条LCB2SRI通道可专用于执行读取传输操作，另一条则专用于执行写入传输操作。

具体实现方式是：将发送（TX）帧的数据Buffer配置在由第一个主控端寻址的地址空间内，而将接收（RX）帧的数据Buffer设置在由第二个主控端寻址的地址空间中。通过这种配置，单条LCB2SRI通道的完整Buffer深度可以完全被单向帧数据所利用。

理想情况下，描述符应存储于本地缓冲RAM中。此举能够避免因单字传输（例如EDMA执行描述符状态回写或清除描述符OWN位等操作）而在LCB2SRI通道上引发阻塞情况。

2.2 GETH时钟

GETH模块时钟为fGETH，其来源为fSOURCE0，即系统时钟，分频系数为SYSCCUCON1.GETHDIV，计算公式为：

例如在TC4D9中配置fSOURCE为500MHz，配置SYSCCUCON1.GETHDIV为2，则fGETH为250MHz。

GETH模块的寄存器控制总线时钟和其他外设一样，使用SPB时钟。

2.3 XGMAC

2.3.1 总览

XGMAC是GETH模块实现链路层的核心模块，其内部包含XGMAC-CORE、MTL传输层、DMA模块以及各个总线接口，结构如下图所示。

除了IEEE 802.3规范中定义的默认接口外，XGMAC还支持多种行业标准的PHY接口。该XGMAC符合以下标准：

• IEEE 802.1AS 2020 and 802.1-Qav-2009 for Audio Video (AV) traffic

• IEEE 802.3-2015 for Ethernet MAC, Gigabit Media Independent Interface (GMII), 10G Media Independent Interface (XGMII)

• IEEE 1588-2008 for precision networked clock synchronization

• IEEE 802.3az-2010 for Energy Efficient Ethernet (EEE)

• AMBA 3.0 and APB3 slave ports

• AMBA4 AXI and ACE protocol specification, February 2013, ARM Ltd for AXI4 and APB4 interface

• NBASE-T Alliance 2.5 and 5 Gigabit Ethernet (USXGMII)

• Reduced Gigabit Media Independent Interface (RGMII), Version 2.6, Broadcom Corp., Hewlett-Packard Co., Marvell Technology Group, Ltd.

• RMII specification version 1.2 from RMII consortium

2.3.2 CSR Slave Interface

CSR全称为Control and Status Register，在GETH内部DMA、MTL、MAC都有各自的寄存器。前文也提到，MCU通过SPB总线访问该接口，接口内部转AHB协议进行数据处理。这些对于程序员来说是透明的，我们只需要根据寄存器说明访问寄存器即可。

2.3.3 DMA控制器

DMA负责把从外界接收到的数据包，传输到系统内存中的RX Buffer里，同时把系统内存中Tx Buffer里需要发送的数据传输出去。DMA包含8个独立通道（上一代为4个），每个通道具备独立的Tx引擎和Rx引擎。Tx Engine的方向是从系统内存到MTL，Rx Engine则是从MTL到系统内存中。

GETH模块的DMA利用一种寄存器和Descriptors Lists（描述符链表）结合的机制，在高效搬运数据的同时，最大程度减小CPU的负荷。

描述符是保存在系统内存中的具有特定格式的数组结构（通常组织为环形缓冲区），GETH中相关的寄存器会指向对应的描述符，而描述符指向内存中的用户Buffer，这个结构有点类似CSA的机制。每个DMA有一个Tx描述符链表和一个Rx描述符链表。

列表中的描述符数量由相应的发送/接收描述符环长度寄存器配置。当DMA处理完列表中最后一个描述符后，将跳转回列表地址寄存器指向的描述符，从而形成描述符环结构。

所有描述符列表均驻留在应用系统的物理内存地址空间中。每个描述符最多可指向两个缓冲区，此设计支持使用两个物理寻址的缓冲区，而非必须采用内存中的连续缓冲区。

数据buffer位于应用物理内存空间，也就是RAM中，可包含完整数据包或数据包片段，但其容量不可超过单个数据包。buffer仅存储数据本身，其状态信息由描述符进行维护。数据链式存储是指单个数据包可跨越多个buffer分布，但单个描述符不能跨多个数据包。当检测到EOP（包结束）标志时，DMA会自动跳转到下一个数据包对应的buffer。

XGMAC支持DMA描述符的环形结构架构，具体描述符结构及DMA访问描述符的机制下面的章节中会进行介绍。

XGMAC-AXI始终采用DMA控制器执行描述符获取、描述符回写及数据传输操作。DMA通过以下并行任务优化数据包传输效率：

• 多描述符预取

• 数据传输

• 描述符回写

所有DMA阶段均以流水线方式独立运作：新数据包的描述符获取可与前一数据包的数据传输操作同步进行，同时还可执行上上个数据包的描述符回写操作。这种流水线工作机制有效缩小数据包传输间隔，显著提升整体传输吞吐量。

以太网收发中断

XGMAC中可因多种事件产生中断，这些事件会被状态寄存器捕获，且每个中断源都设有中断使能位，这意味着仅当相应中断使能位被置位时，对应事件才会触发中断信号（sbd_intr_o）的发送。

其中DMA通道的发送和接收中断是应用中使用最多的，也就是我们常说的以太网的收发中断。

DMA_CH(#i)_Status寄存器捕获该发送DMA与接收DMA通道对的所有中断事件。DMA_CH(#i)_Interrupt_Enable寄存器则包含每个中断事件对应的使能位。DMA通道中断分为两类：正常中断与异常中断，它们分别由DMA_CH(#i)_Status寄存器的位[15:14]指示。正常中断组对应数据包正常传输过程中发生的事件（如TI、RI、TBU），而异常中断组则用于错误事件。通过向相应位位置写入1'b1可清除中断事件。当所有已使能的中断事件（包括NIS和AIS）均被清除后，DMA通道的中断源即被清除，DMA_Interrupt_Status寄存器中的对应位也随之清零。

中断不支持队列机制。若驱动程序未响应前次中断时相同中断事件再次发生，系统不会生成额外中断。例如，DMA_CH(#i)_Status寄存器的接收中断位[6]指示有一个或多个数据包已传输至应用buffer。驱动程序必须扫描从最后记录位置到DMA所拥有的首个描述符之间的所有描述符，以确定实际接收的数据包数量。

2.3.4 MAC Transaction Layer（MTL）

MAC事务层提供FIFO存储器，用于在应用系统内存与XGMAC IP之间缓冲和调节帧数据。其原生接口通过简明的握手协议实现主机与MAC事务层之间的数据传输。

MTL模块还为应用与XGMAC时钟域之间的数据传输提供了可靠的同步机制。在传输和接收路径上，MTL均设有异步FIFO，在这个64位系统中其位宽为68位——包含64位数据位和4位控制位。

MTL模块通过应用发送接口（ATI）、应用接收接口（ARI）以及XGMAC控制接口（MCI）与应用系统进行通信。

这一代的MTL层的Buffer较上一代（RX 8k，TX 4k）有较大提升，TX和RX分别支持到32k大小。

在发送过程中，应用软件通过TX DMA通道将以太网数据包推入对应队列。当达到队列阈值时（阈值模式）或完整数据包已存入队列时（存储转发模式），数据包将被取出并传输至MAC层。

在接收过程中，接收模块（Rx Module）接收MAC层传来的数据包并将其推入接收队列（Rx Queue）。当队列状态（通过可编程突发长度PBL及水位线标识的填充等级）超过配置的接收阈值（由MTL_RxQ(#i)_Operation_Mode寄存器的位[1:0]设定）时——在阈值模式下，或在存储转发模式下收到完整数据包时——该状态会向DMA发出指示。DMA可据此队列填充状态发起向AXI接口的预配置突发传输。

2.3.5 The MAC layer（MAC-Core)

该MAC层完全符合IEEE 802.3-2008行业标准，实现了XGMII/GMII/MII/RGMII/RMII全双工接口用于与物理编码子层通信。MAC层通过MAC发送接口（MTI）、MAC接收接口（MRI）以及MAC控制接口（MCI）与应用侧进行数据交互。该MAC层支持以下PHY协议：

当MTL或应用端通过置位SOP信号向XGMAC推送数据时，数据发送过程即被启动。XGMAC检测到SOP信号后开始接收数据，并立即向XGMII/GMII/MII/RGMII/RMII接口发起数据发送。从应用端启动发送到将帧数据实际发送至XGMII/GMII/MII/RGMII/RMII接口所需的时间是可变的，其延迟因素包括：帧间隔（IFG）延迟、来自XGMAC接收器的暂停发送请求、前导码与帧起始定界符（SFD）的发送耗时，以及半双工模式下的退避延迟等。

只要XGMAC内部缓冲区具备空间，即可持续接收来自应用端通过MTL推送的数据。

在帧结束信号传送至XGMAC核心之后，应用端可选择等待控制器完成正常发送操作，也可立即开始向XGMAC发送下一帧，而后再接收发送状态信息。

下面我们展开介绍下该MAC内核的一些协议外的特性

TBU & VLAN Tag Modification

发送总线接口模块（TBU）负责对发送帧进行VLAN标签和源地址（SA）的灵活操作，包括添加、替换或删除VLAN标签，以及添加或替换源地址字节。所有操作均可通过控制状态寄存器（CSR）进行配置，实现对每帧或全局发送帧的精确控制。TBU支持基于每帧或全局范围的VLAN标签动态处理，通过配置MAC_VLAN_Incl寄存器的VLT位域，可实现VLAN标签的插入、删除或替换功能，从而满足不同场景下对帧标记的差异化需求。

Source Address Modification

TBU模块支持源地址（SA）的添加与替换操作，通过MAC_Address0_High和MAC_Address0_Low寄存器配置SA字段内容。若原始帧包含FCS，TBU会自动更新为准确的FCS校验值，所有操作均可通过MAC_Tx_Configuration寄存器的控制位按每帧粒度触发。

SA添加功能将预设地址插入发送帧的SA字段，而SA替换功能则直接覆盖原有地址字段。两种操作共享相同的寄存器配置和触发机制，由硬件自动完成FCS校验值的同步更新。

Transmit frame controller module (TFC)

发送帧控制器（TFC）采用两级寄存器结构，用于缓冲从TBU模块接收的数据和字节使能信号，在应用层与发送协议引擎（TPE）之间提供数据流调控。该缓冲机制同时为帧数据添加CRC校验码和填充字节提供处理空间。

TFC支持四种帧尾处理模式：对≥60字节的帧自动添加CRC；对短帧补充填充至60字节并追加CRC；仅添加CRC而不补填充；禁用CRC由应用自行处理校验码。所有模式均需根据MAC层的预期修改功能进行选择，CRC替换模式还会重新计算并覆盖末4字节的校验值。

Transmit protocol engine module (TPE)

发送协议引擎模块（TPE）是以太网帧发送的核心控制单元，其内置的发送状态机严格遵循IEEE 802.3/802.3z规范，支持XGMII和GMII/MII多种工作模式。该模块主要实现七大功能：前导码和帧起始定界符（SFD）生成、半双工模式下的冲突后阻塞信号产生、超时传输终止（Jabber timeout）保护、半双工流控（背压机制）、发送状态报告、以及支持IEEE 1588时间戳的快照逻辑。

当TPC模块请求新数据包发送时，状态机会按序发送7字节前导码（0x55模式）和1字节SFD（0xD5），随后传输有效数据。在半双工模式下，状态机通过监测冲突窗口（1个时隙时间）动态响应冲突事件：在帧头阶段检测到冲突时会完整发送前导码和SFD后再发送32位阻塞模式（0x55555555）；若在CRC字段期间发生滞后冲突，除发送阻塞模式外还会置位滞后冲突状态位。

TPE模块通过可配置的Jabber定时器（默认2048字节，巨帧模式下扩展至10240字节）防止异常长帧传输，并在半双工模式下采用延迟机制实现流控：当应用层通过流控寄存器请求暂停接收时，状态机在检测到数据包接收时会主动发送32字节阻塞模式（0x55）触发远端站点退避。值得注意的是，全双工模式下该模块会忽略物理层冲突信号，且即使处于背压状态，本地发起的传输请求仍会被调度执行。此外，当启用IEEE 1588时间戳功能时，该模块会在SFD送上发送总线的瞬间捕获系统时间（支持外部或内部时源），为高精度时间同步提供关键时间基准。

Loopback support  

XGMAC支持在XGMII和GMII模式下将发送帧环回至接收器。该功能默认禁用，可通过配置MAC_Rx_Configuration寄存器的环回位使能，但仅限全双工模式使用——半双工模式下因需检测载波侦听和冲突信号可能导致数据包丢失。

由于收发时钟异步，系统采用自由运行的异步FIFO实现发送数据到接收路径的环回。在GMII模式下，使用深度为5、位宽36位的FIFO，每帧读取时读写指针会初始化为2个单位的偏移量，这种设计既可防止帧传输期间的溢出/下溢，又能将潜在溢出限制在帧间隔（IFG）期间。该FIFO深度可支持最高9022字节的帧长（允许GMII收发时钟200ppm频差），但更大帧长可能引发数据损坏，故不建议在GMII模式下环回超长帧。

Address filtering module (AFM)

地址过滤模块（AFM）检查所有接收帧的目的MAC地址和/或源MAC地址，并向RFC报告地址过滤状态。同时，它对VLAN帧执行精确VLAN过滤及基于VLAN的哈希计算。

地址过滤基于应用程序配置的不同参数实现。这些参数作为控制信号输入AFM，AFM根据输入信号的组合状态报告地址过滤结果。需注意的是，AFM本身并不直接过滤接收帧，而是向RFC模块上报地址过滤状态（是否丢弃帧），同时还会指示接收帧是否为组播或广播帧。

2.3.6 Packet filtering

XGMAC接收数据包过滤机制包含三大核心功能：地址过滤模块（AFM）对每个输入帧的源地址和目的地址进行检测；支持基于多VLAN标签的扩展过滤及VLAN哈希过滤；提供网络层（源/目的IP地址）和传输层（源/目的端口）的双层级匹配过滤。所有过滤操作按严格定义的流程顺序执行，具体流程见下图展示。

2.3.7 IEEE 1588 Timestamps  

IEEE 1588标准定义了精密时间协议（PTP），能够通过网络通信、本地计算和分布式对象等技术，实现测量与控制系统中的时钟精确同步。该协议适用于支持组播通信的局域网系统（包括但不限于以太网），可使具有不同精度、分辨率和稳定性的异构时钟系统实现亚微秒级的全局同步精度，且对网络及本地时钟计算资源消耗极低。

XGMAC同时支持IEEE 1588-2002（版本1）和IEEE 1588-2008（版本2）标准，前者支持UDP/IP传输PTP协议，后者支持以太网直接传输PTP协议。其提供可编程的双标准支持，具体功能包括：支持两种时间戳格式；可选对所有数据包或仅PTP包进行快照；支持仅对事件消息触发快照；支持基于普通时钟、边界时钟、端到端透明时钟和点到点透明时钟四种时钟类型的快照机制；可配置普通时钟和边界时钟的主从模式；能识别以太网直传PTP包的报文类型、版本及载荷内容并返回状态；提供数字或二进制格式的亚秒级时间测量选项。

2.3.8 Power management

XGMAC支持IEEE 1801标准（即统一电源格式UPF）以实现电源管理功能。在XGMAC中，电源管理通过电源管理模块实现，该模块支持魔术包和远程唤醒（或局域网唤醒）帧的接收与检测。

用户可以选择监听其中一种或两种电源管理帧（远程唤醒帧和魔术包）。当通过配置寄存器进入低功耗模式时（需注意CLC寄存器中时钟控制位的设置），仅当接收到魔术包或远程唤醒帧且相应检测功能已启用时，MAC才会退出低功耗模式。退出低功耗模式后，软件需重新开启CLC寄存器中的应用时钟。

远程唤醒帧检测流程如下，当MAC处于睡眠模式且MAC_PMT_Control_Status（0x00C0）中的远程唤醒位已启用时，接收到远程唤醒帧后将恢复正常操作。应用端通过对地址（0x00C4）执行顺序写入操作，配置全部八个唤醒过滤器寄存器（4个唤醒过滤器各对应2个寄存器）。通过向MAC_PMT_Control_Status寄存器的位2（RWKPKTEN）写入1来启用远程唤醒功能。

2.4 XGMAC Descriptors描述符机制

GETH模块的收发机制采用了寄存器与描述符结合的方式，来进行数据处理，下面我们来详细介绍这套机制以及描述符的结构。

类似CSA的机制，描述符存放在系统内存中，使用尽可能简洁的寄存器来表征描述符的状态。描述符（Descriptors）是存放在系统内存，也就是RAM中的链接信息，它的主要功能是用作Buffer的指针，另外包括一些状态信息和控制信息。每条描述符大小为4个word，一共16字节。描述符之间虽然可以配置为带间隙，但是一般都是连续存放。

从数据传递方向的角度来说，描述符有发送描述符(Transmit Descriptor)和接收描述符(Receive Descriptor)；从功能的角度来说，描述符有两种：

• Normal Descriptor：常规描述符，用来描述packet的数据，并提供适用于将要传输的packet的控制信息；

• Context Descriptor：增强描述符，用于提供适用于将要传输的数据包的控制信息。

增强描述符一般很少会用到，所以本文着重介绍常规描述符，围绕其在发送端和收发端的功能进行展开。

虽然虽然手册上说一个描述符可以指向至多两个Buffer，且可以把MAC帧的Header和Payload分开存放，但是实际使用过程中，包括MCAL相关的代码及配置，都是一个描述符指向一个Buffer，多个描述符组成一个RingBuffer结构，如下图所示。

比如当我们执行发送操作时（通过写描述符尾寄存器），DMA就会从当前发送描述符（Current Descriptor Pointer）指向的位置开始往下轮询，直到描述符尾指针，对所有属于DMA控制的描述符指向的Buffer执行数据搬运。

2.4.1 描述符相关寄存器

这里我们先介绍下和描述符相关的寄存器。这里注意一下，由于搬运是由DMA通道执行的，所以每个DMA通道有自己的一套描述符寄存器。

• DMA_CHj_Current_App_TxDesc_L (j=0-7)：当前发送描述符，用于指向DMA下一条会读取的描述符，也就是当前用户可用的描述符；

• DMA_CHj_Current_App_TxBuffer_L (j=0-7)：当前发送描述符指向的Buffer地址，虽然描述符里有Buffer的信息，但是Aurix还是提供了当前发送Buffer的寄存器，表示当前发送描述符指向的Buffer地址；

• DMA_CHj_Current_App_RxDesc_L (j=0-7)：当前接收描述符，表示当前用户可用的接收描述符。

• DMA_CHj_Current_App_RxBuffer_L (j=0-7)：当前接收描述符指向的Buffer地址。

• DMA_CHy_TxDesc_List_Address (y=0-7)：发送描述符基址，指向第一个发送描述符；

• DMA_CHy_RxDesc_List_Address (y=0-7)：接收描述符基址，指向第一个接收描述符；

• DMA_CHy_TxDesc_Ring_Length (y=0-7)：发送描述符长度，注意0表示1个描述符，以此类推；

• DMA_CHy_RxDesc_Ring_Length (y=0-7)：接收描述符长度，注意0表示1个描述符，以此类推；

• DMA_CHy_TxDesc_Tail_Pointer (y=0-7)：发送描述符尾指针，指向最后一个描述符之后的地址；

• DMA_CHy_RxDesc_Tail_Pointer (y=0-7)：接收描述符尾指针，指向最后一个描述符之后的地址。

我们通过一个实际场景来介绍下这些描述符寄存器的作用，描述符的内容可以先不用关注，后面会介绍。这是我在使用过程中的一段实际内存，它里面放了4个发送描述符，因为我这里配置了4个Buffer。

然后我们看各个寄存器的值：

我们可以看到当前CURRENT_TXDESC指向的是第二个描述符，也就是说我们要发送数据的话就使用这个描述符。然后TXDESC_LIST_ADDRESS指向第一个描述符，TXDESC_RING_LENGTH为3表示配置了4个描述符。当我们向TXDESC_TAIL_POINTER写入尾部地址时，DMA会轮询从CURRENT_TXDESC到TXDESC_TAIL_POINTER（左闭右开）的所有描述符，执行发送操作。当然只有第二个描述符的DMA归属位置位了，到第三个时DMA会自动Suspend，详细流程我们后面再讨论。

2.4.2 Transmit Descriptors发送描述符

这里我们只介绍常规描述符。

常规描述符有两种状态，Read-format和Write-back Format。当我们需要向外部发送数据，要按照Read-format向其中写入Buffer地址及控制信息，然后将其控制权释放给DMA；DMA在执行完搬运和数据发送之后，会对该描述符进行回写，提供时间戳及状态信息，相当于回调，告知发送状态。

Read-Format

Read Format下的描述符如上图所示，主要包括两个Buffer指针、Buffer长度信息和一些其他的控制信息。从上到下4个Word依次是TDES0到TDES3，我们一一展开介绍。

• TDES0：

• BUF1AP：Buffer1的地址；

• TDES1：

• BUF2AP：Buffer2的地址，但是我们一般不使用，包括Infineon官方的MCAL代码都是不用的；

• TDES2：

• IOC（31）：Interrupt on Completion，完成中断标志位，packet发送完之后会置位；

• TTSE（30）：Transmit Timestamp Enable，发送时间戳使能位；

• B2L（29:16）：Buffer2的长度；

• VTIR（15:14）：VLAN标签插入、替换标志位，VLAN一般由上层处理，AUTOSAR中也一般交给EthIf来管理，所以该位一般是0；

• B1L（13:0）：Buffer1的长度；

• TDES3：

• OWN（31）：DMA控制权标志位，该位置位表示DMA拥有该描述符的控制权，它会去读取相应的Buffer，并回写该描述符，并将该位清除；

• CTXT(30)：常规描述符和增强描述符位，0表示常规描述符；

• FD(29)：First Descriptor，表征第一个描述符，一般数据存在于多个Buffer时，有头部、连续描述符之分，我们一般使用连续Buffer，只需要一个描述符，因此FD包括下面的LD一直都置位；

• LD(28)：Last Descriptor，表征是最后一个描述符；

• CPC（27:26）：CRC Pad控制位；

• SAIC（25：23）：SA Insertion Control，源地址插入控制，可以配置让MAC层根据MAC地址寄存器自动修改源MAC地址，而不用上层指定；

• SLOTNUMorTHL（22:19）：Slot Number Control Bits in AV Mode，AV模式下的槽数量控制位，用于上层Header信息的辅助处理，一般不使用；

• RES_18（18）：预留；

• CIC/TPL（17：16）：Aurix提供了TCP/IP的CheckSum辅助计算功能，能够通过硬件计算为上层降低负载；

• TPL（15）：Reserved or TCP Payload Length；

• FL/TPL（14：0）：Packet Length or TCP Payload Length，一般用作Packet长度；

Write-Back Format

我们可以看到Write-Back格式的描述符包含了时间戳和状态位，状态位这里就不展开介绍了，感兴趣的读者可以翻阅手册进行查询。

2.4.3 发送流程介绍

发送DMA（TxDMA）的数据传输操作流程如下：

1. 描述符获取引擎从系统内存或描述符预取缓存中读取有效描述符（OWN=1），并将其交付给数据传输引擎。

2. 引擎处理描述符控制位和缓冲区大小，根据寄存器（TxPBL）设置计算待请求的数据传输量。在发起数据传输请求前，会检查对应发送队列（TxQ）是否有可用空间。

3. 当AXI主控制器接受请求（调度至总线）后，引擎立即计算下一次数据传输量并发起新请求。第二次请求可能为以下情形之一：

a. 同一缓冲区的后续数据突发传输（若首请求仅传输缓冲区部分数据）

b. 缓冲区2的数据突发传输（若首请求已完成缓冲区1的传输）

c. 下一个描述符的缓冲区1数据突发传输（若首请求完成缓冲区2传输或缓冲区2为空）

d. 下一个描述符缓冲区的全新数据包传输（若首请求完成整包传输）

4. 任意时刻最多允许两个未完成的数据传输请求等待处理。

5. 当请求数据被提取并写入MTL的对应发送队列（TxQ）后，该请求即视为完成。此后引擎可按照步骤3发起后续请求。

6. 当描述符的所有有效缓冲区数据提取完成后，该描述符将被释放并推送至描述符回写引擎进行闭合处理，同时预取缓存中的下一个描述符将进入处理流程（返回步骤2）。

所有操作均采用流水线方式实现，有效避免了因描述符读写造成的瓶颈与开销。此外，引擎可连续请求两个数据包传输（针对小于编程PBL值的包），无需等待前一个包完全获取完成。这种机制可将读命令的系统延迟隐藏在前一个命令的数据传输过程中，从而显著提升吞吐量。

DMA初始化之后，停留在Suspend Tx DMA Queue状态中进行等待，用户写入描述符尾寄存器之后DMA开始进行Transmit轮询，完成发送之后继续停留在Suspend状态中。当前发送描述符寄存器是描述符链表的关键句柄，DMA每次完成一次发送后其会指向下一个描述符，末尾的描述符使用完之后会回到第一个描述符。

DMA将数据传输到MTL之后，就会由硬件进行后续数据的打包和发送，参考前面MAC章节。

2.4.4 Receive Descriptor接收描述符及接收流程介绍

接收描述符包括两种类型：常规描述符和增强描述符。常规描述符同样有Read-format和Write-back format。用户按照Read-format格式，根据Buffer的实际容量配置完描述符之后，将描述符控制权释放给DMA，DMA在收到完整且通过校验的packet之后，会将数据搬运到描述符指定的接收Buffer，随后将状态信息以Write-back格式写回到描述符。相比于发送描述符，接收描述符的回写内容比较多，因此它的状态回写会额外占用一个增强描述符，用于补充描述状态信息。

Read-format

Read-format的接收描述符格式如上图，RDES0包含的是接收Buffer的地址，RDES2包含的是Buffer2或者头的地址，但是我们一般packet存放到一个Buffer里，RDES3包含两个重要的位，一个是DMA控制权位OWN，另一个是常规/增强描述符标志位INTE。

Write-Back Format

Write-back格式的描述符见上图，可以看到其信息还是比较多的，但是前面也提到，VLAN一般我们会交给上层处理，所以RDES0一般在Write-back中DMA不去修改它的值。

Receive Context Descriptor

如前所述，接收的回写需要在常规描述符之后跟随一个额外的增强描述符，所以这里介绍下接收增强描述符。它的RDES0是时间戳的低位，RDES1是时间戳的高位，RDES3中包含一个DMA控制权标志位OWN和一个常规/增强类型标志位CTXT等。

2.4.5 接收流程介绍

接收流程和发送流程类似，都是APP操作描述符，然后等DMA操作数据，区别在于APP需要通过轮询或中断来判断是否有数据接收，并进行处理，然后重置描述符，将Buffer还给DMA用于后续数据接收。其流程如下：

1. 描述符获取引擎从系统内存或描述符预取缓存中读取有效描述符（OWN=1），并将其交付给数据传输引擎。

2. 数据传输引擎根据缓冲区大小和寄存器设置（RxPBL）计算出支持的突发传输长度，随即向MTL接收队列读取控制器发出数据传输就绪信号。

3. 当接收队列读取控制器选定某个接收队列（针对多队列配置）并触发RxDMA启动数据传输时。

4. RxDMA引擎发出传输请求，该请求由AXI主控制器接收并执行。随后通过AXI写通道将请求数据传送到系统内存的缓冲区中。

5. 当请求的数据传输在内部完成（即在AXI总线上驱动完成后），若数据包传输未结束（未传输EOP标志），数据传输引擎将返回步骤2继续操作。

6. 若描述符指向的两个接收缓冲区均已存满，引擎会将描述符连同中间状态推送至"描述符回写引擎"，随后从预取缓存中获取下一个描述符并返回步骤2。

7. 若在最后一次突发传输期间传输了EOP标志，引擎会在读取EOP后从接收队列获取最终数据包状态，随后将待关闭的描述符推送至回写引擎，最后返回步骤2。

可以看出，描述符是XGMAC中DMA进行数据处理的核心数据结构，掌握了描述符，才能掌握XGMAC的数据收发处理逻辑。

2.5 Bridge

TC4x的GETH模块提供了一个桥接器，用于进行两路XGMAC之间或者DMA通道之间进行数据路由，实现硬件无感的网路路由功能。

该桥接器专需在终端站点通过双以太网端口接入网络的场景而设计，其具备双重数据处理能力：既能通过多通道DMA接口将任一端口的流量终结至主机系统，又能实现双端口间的数据转发。后一功能主要针对菊花链拓扑结构的以太网网络应用。

篇幅原因这里就不展开介绍了。

#03

3.1 开发环境

在AURIX™ Development Studio工具中，读者可以在首页的左下角直接导入英飞凌官方的Demo示例。

编译器使用的是Tasking公司针对Aurix™ TC4x芯片TriCore™ 1.8内核专门推出的SmartCode编译器，嵌入在ADS软件中，注意需要使用License，可以向官方申请试用版。

调试使用的软件是ADS或者SmartCode内置的WinIDEA，调试器硬件是开发板自带的miniWiggler JDS调试器，通过USB直接连接电脑即可。

3.2 代码解析

本文的示例为一个以太网数据发送实例，通过GETH模块发送以太网报文，由于笔者手中的开发板中没有板载以太网PHY，因此无法实现通过PING设备进行网络连接。

3.2.1 数据结构

主要数据结构包括以下三个，其中IfxGeth_Eth是运行时的全局控制块，phy_t是外置PHY的控制块（本文开发板无外置PHY，采用eGTM模拟参考时钟，无数据接收），IfxGeth_Eth_Config则是Geth模块的配置结构体。

CIfxGeth_Eth geth0;phy_t phy_0;IfxGeth_Eth_Config config;

3.2.2 初始化流程

在TC4x系列以太网架构中，GETH模块与外部的连接必须经过HSPHY，因此即使是RMII协议接口，也需要通过HSPHY连接至PORT，本文不展开介绍，后续HSPHY模块再进行说明。

在geth0_init中，首先执行IfxGeth_enableModule进行模块的使能，也就是时钟的开启。

然后在IfxHsphy_Geth_setupRmiiInputPins中配置输入引脚，这是因为XGMAC中DMA的复位需要依赖外部时钟，因此在初始化DMA模块之前，需要先配置完外部时钟信号，以及引脚连接。

在IfxGeth_Eth_initModuleConfig函数中，初始化一个默认GETH模块配置，然后修改其中特定的以太网相关配置，然后，如Buffer地址，网络速度等配置。

随后在IfxGeth_Eth_initModule模块中进行GETH模块的初始化，该步骤中将进行硬件的初始化。在其中首先会通过IfxGeth_Eth_configureDMA进行DMA的初始化，包括硬件的复位，描述符的初始化，以及DMA中断的配置。然后通过IfxGeth_Eth_configureMacCore配置XGMAC_CORE模块，主要包括MAC层的如物理地址、过滤模式等的配置。最后通过IfxGeth_Eth_configureMTL进行MTL层的配置。

随后通过IfxGeth_startRxDma和IfxGeth_startTxDma函数写入对应的寄存器，启动收发。

最后通过IfxHsphy_Geth_setupRmiiOutputPins配置以太网输出引脚，以进行数据发送。

3.2.3 运行阶段

运行阶段本文主要截取并调整了以下发送代码。

Cuint8 *pTxBuf = IfxGeth_Eth_getTransmitBuffer(&geth0, IfxGeth_TxDmaChannel_0);uint8 DstMacAddress[6] = {0x88, 0x03, 0x19, 0x00, 0x00, 0x88};uint8 TestBuffer[86] = {...}    /* ICMP 包 *//* prepare echo message *//* destination address of transmitted frame is the source address of the received frame */memcpy(&pTxBuf[0], &DstMacAddress[0], 6);/* update source address */memcpy(&pTxBuf[6], &geth0_p0_mac_address[0], 6);memcpy(&pTxBuf[12], &TestBuffer[0], 16);IfxGeth_Eth_sendTransmitBuffer(&geth0, 0, 86+12, IfxGeth_TxDmaChannel_0);

在以上代码中，通过IfxGeth_Eth_getTransmitBuffer函数查询描述符，以获取其指向的buffer，并返回空闲的buffer地址。

然后进行ICMP报文的组包，最后通过IfxGeth_Eth_sendTransmitBuffer进行发送。在IfxGeth_Eth_sendTransmitBuffer中，主要进行发送描述符的构建，最终将描述符的TDES3中的OWN Bit置位，完成数据的发送。

我们将断点打在数据发送代码中，可以看到当前的发送描述符状态，这里只配置了一个描述符和Buffer，其地址为0x70006150，根据发送描述符定义其指向的Buffer地址为0x70003190。

我们观察其中的内容，除去头部的目的MAC地址和源MAC地址，其内容来自原始数据Buffer（右侧）。

随后我们在发送中断中打上断点，代码发送完成之后进入中断。

#04

本文对Aurix™ TC4x中的GETH模块的硬件原理进行了介绍，详细说明了其描述符控制原理，并对英飞凌官方示例进行了解析和实践。

Aurix™ TC4x的GETH模块是其以太网通信核心，全面支持10M至5G多速率操作，集成TSN协议硬加速，通过双LCB2SRI通道实现收发数据路径分离，大幅提升吞吐量。同时硬件级安全机制（ECC、奇偶校验）满足ASIL-D要求，XPCS与HSPHY协同支持SerDes接口，为下一代汽车E/E架构提供高可靠、低延迟的网络基础。