简介IEEE 802.3-2022《以太网标准》正式版全文面向网络设备研发、芯片与物理层设计、互操作测试及协议教学人员用于系统查阅以太网自1Mb/s至400Gb/s各速率的媒质访问控制、独立接口、物理层与供电规范。压缩包内仅一个PDF文件约93.79MB单文档达7025页比2018版增补1400余页重点补入25G至100G条款并对10G部分作出修订已整合此前各项修订条款编号与目录完整可按速率、传输介质、子层快速定位802.3df-2024、802.3ck-2022等后续修正案未包含在内。文档涵盖自动协商、前向纠错、节能以太网、同轴与光纤接入等条目附有大量参数表格与一致性测试要求便于对照原文核对寄存器配置与链路预算。已有287人学习下载适合需要权威原文比对、撰写设计文档或准备认证测试的工程师与高年级学生查阅。1. 一份 7025 页的以太网基线文档谁该下、谁可以跳过做 25G/100G 链路联调的人大概都遇到过同一个场景光模块插上去 link 能起来跑个几分钟就偶发 CRC 错抓包看不出问题最后翻到 MAC/PCS/FEC 那一层才发现两边对 RS-FEC 的插入位置理解不一致。这类问题没有速成答案只能回到源头条款——作为行业标准 IEEE802.3 的最新整合版802.3-2022 把历史上所有修订合并成一份 7025 页的基线文档覆盖 1 Mb/s 到 400 Gb/s 的 MAC、MII、PHY 与管理面定义。它适合做芯片、交换机、PHY、光模块和网卡固件的人只想查一根网线怎么接的可以跳过。下面按骨架怎么读 → 参数怎么提 → 附加能力怎么查 → 哪里会翻车走一遍。2. 拆解协议骨架MAC、MII、PHY 三段式怎么读2.1 一套 MAC 定义如何覆盖 1 Mb/s 到 400 Gb/s802.3 的结构不是按速率平铺而是按子层纵向切分。最上面是 MACMedia Access Control它定义帧格式、寻址、CSMA/CD 以及全双工下的流量控制MAC 之下是 RSReconciliation Sublayer负责把 MAC 的并行数据转换成 MII 的时序MII 往下依次是 PCS物理编码子层、PMA物理介质附加子层、PMD物理介质相关子层最后到 MDI 接口。理解这条链比死记速率表重要得多——因为不管 100M 还是 400G改动集中在 PCS/PMA/PMD 三段MAC 与 RS 的接口语义基本保持稳定。提示读这份文档时先看 Clause 1 的总体架构图再跳到具体速率条款比从头按页翻效率高一个数量级。这种分层带来的直接好处是同一套 MAC 服务原语MA_DATA.request 等可以在不同速率下复用。工程上遇到换速率后上层驱动不用动的现象根源就在这里。但也正因为分层很多问题不会在 MAC 层暴露而是沉到 PCS 的编码对齐或 PMD 的光功率预算里排查时必须按子层逐段切。2.2 MII 家族对照表与选型逻辑MII 是这份文档里最容易读乱的部分因为它不是一个接口而是一族接口。不同速率、不同封装、不同背板场景对应不同的 MII 变体选型错了后面寄存器配置全对也跑不通。下面这张表是我实际做对接时常用的对照速率与接口的对应关系以 802.3-2022 正文条款为准。MII 变体典型速率数据位宽时钟特点常见场景MII10/100 Mb/s4 bit25 MHz / 2.5 MHz早期 MAC-PHYGMII1 Gb/s8 bit125 MHz千兆铜/光XGMII10 Gb/s32 bit156.25 MHz DDR10G 芯片间XLGMII40 Gb/s64 bit156.25 MHz DDR40G 背板CGMII100 Gb/s64 bit156.25 MHz DDR100G 背板25GMII25 Gb/s64 bit156.25 MHz25G 芯片间选型的判断顺序我一般这样走先确定线侧速率和编码NRZ/PAM4再看 MAC 与 PHY 是同一颗芯片还是分立分立就查 MII 的位宽和时钟是否匹配最后核对管理面走 Clause 22 还是 Clause 45。很多人一上来就抄参考设计的 MII 配置结果 MAC 侧是 XGMII、PHY 侧只支持 USXGMII中间还得加桥接白白多一层延迟和调试成本。2.3 按 Clause 编号定位具体速率7025 页不可能通读实操上是把 Clause 编号当成索引。管理面锚点集中在几条Clause 22 定义 RS 与 MII 以及 10/100 Mb/s 相关的 MDIO 寄存器寄存器地址 0–15Clause 28 是 10/100/1000 Mb/s 的自协商Clause 30 是管理对象定义Clause 31 是 MAC ControlClause 45 是 MDIO 的可扩展管理接口支持 0–65535 的寄存器地址空间。速率条款则按世代分布在中后段100BASE、1000BASE、10GBASE、25GBASE、40GBASE、100GBASE、200GBASE、400GBASE 各有独立章节。实操路径是先在目录里搜速率前缀如 100GBASE-R再在命中的 clause 里找 PCS/PMA/PMD 三节最后回到 Clause 45 查对应的 MMD 寄存器。这条路径固定下来以后查任何一个新速率都能在十分钟内定位到关键参数不用在 PDF 里反复滚轮。3. 把标准变成工程输入条款索引、MDIO 寄存器与参数提取3.1 PDF 书签与条款编号的导航套路拿到这份 7025 页的 PDF第一件事不是读而是建索引。官方 PDF 一般带书签但层级往往只到 clause细到子条款还得靠文本检索。我习惯先用pdftotext把正文抽成纯文本再用grep建一份条款号 → 标题 → 页码的对照表后续查参数直接搜表比在阅读器里翻快得多。# 把 PDF 转成带页码标记的文本便于后续按 clause 检索 pdftotext -layout -nopgbrk ieee802.3-2022.pdf ieee802.3-2022.txt # 抽取形如 45.2.1 ... 的条款标题行输出条款号与标题 grep -nE ^[0-9]{1,3}(\.[0-9]){0,3}[[:space:]][A-Z] ieee802.3-2022.txt \ | sed -E s/^([0-9]):([0-9.])[[:space:]](.*)$/\2\t\3/ \ clause-index.tsv # 按关键词定位例如查所有与 FEC 相关的条款标题 grep -i forward error correction\|RS-FEC\|Firecode clause-index.tsv这段脚本做三件事pdftotext -layout保留原始排版避免表格被拆散-nopgbrk去掉分页符让跨页段落连续第二条grep用正则匹配数字开头 大写字母开头的标题行再sed重排成条款号 标题的 TSV。参数上唯一需要按文档调整的是正则里的[0-9]{1,3}如果条款号超过三位802.3 里不会把上限改掉即可。生成clause-index.tsv之后后面所有查参数的动作都围绕这张表展开相当于给这份黑匣子装了一个检索入口。3.2 Clause 22 与 Clause 45 的寄存器表怎么读管理面是标准落地时最常被查的部分。Clause 22 定义的是经典 MDIO寄存器地址 0–15靠 STA 直接读写Clause 45 把地址空间扩到 16 位用 MMDManagement Data Input/Output 的 device address区分不同子层。两张表混用是新手最容易翻车的地方先把职责分清管理接口地址空间设备寻址方式典型寄存器Clause 220–15直接 PHY 地址0 控制、1 状态、2/3 PHY ID、4/5 自协商通告、6/7 对端能力Clause 450–65535MMD 设备地址 寄存器地址1.x PMA/PMD、3.x PCS、4.x PHY 扩展、7.x ANClause 22 的控制寄存器地址 0里bit 12 是自协商使能、bit 9 是重启自协商、bit 15 是复位状态寄存器地址 1里 bit 5 表示自协商完成、bit 2 表示链路状态。这些位定义在标准正文里有明确表格写驱动时按位拼值别用参考代码里是 0x1140这种魔法数——参考代码换个 PHY 就可能失效。下面这段 Python 是从 3.1 生成的文本里把 Clause 22 寄存器表抽出来的思路重点在定位表头 按位解析不在代码本身。import re # 读取全文定位 Clause 22 控制寄存器表格附近的内容 with open(ieee802.3-2022.txt, encodingutf-8, errorsignore) as f: text f.read() # 找到 Register 0 到 Register 1 之间的段落 start text.find(Register 0) end text.find(Register 1, start 1) block text[start:end] # 抽取 Bit(s) 行与 Name 行输出成 bit - 功能 的映射 for line in block.splitlines(): m re.match(r\s*([0-9](?:\.[0-9])?)\s(\S.*), line) if m: print(fbit {m.group(1)}: {m.group(2).strip()})逻辑说明先读入文本用find定位寄存器表起止避免整篇正则扫描再用逐行正则抓位号 描述。参数上start的查找串要按实际 PDF 抽出来的文本微调有的版本写成 Register 0 (Control Register)。这段代码不追求通用追求的是换一份标准文本还能跑——把查找串改掉即可。真正的寄存器值不要靠这段脚本生成位定义必须回到正文表格逐位核对脚本只负责把表抽得可读。3.3 PCS/PMA/PMD 参数核对清单定位到具体速率 clause 之后真正要抄进代码或测试计划的是三个子层的参数。以 100GBASE-R 类条款为例常见要核对的有PCS 的编码方式64B/66B、PMA 的并行通道数与通道对齐机制、PMD 的类型光/电/背板与对应的波长或插入损耗预算。这些参数在正文里通常以参数 最小值 典型值 最大值的表格给出抄的时候连单位和测试条件一起抄否则现场复现时量纲对不上。我自己的核对习惯是开三列条款号、参数名、测试条件。比如PMD 发送光功率这一项必须同时记下是平均功率还是峰值、测量点是 MDI 还是 TP2、参考接收机带宽是多少。少记任何一个限定词后面测试计划就会写成看起来对但结论不可复现的空壳。4. PoE、EEE 与 FEC三个最容易被读错的附加能力4.1 PoE/PoDL 功率分类与 PSE/PD 类型对照PoE 在 802.3-2022 里已经演进到四类功率等级Type 1 到 Type 4背后是 802.3af、at、bt 的合并。读这部分的关键是区分两组数PSE 输出能力与 PD 可用功率两者之间隔着线缆损耗。表格里的功率值是端口上可用不是PD 芯片能吃满。类型PSE 输出功率PD 可用功率典型供电线对Type 115.4 W12.95 W2 对Type 230 W25.5 W2 对Type 360 W51 W2 对可选 4 对Type 490 W71.3 W4 对落地时最容易出问题的是分级classification阶段PSE 通过检测电阻和分级脉冲判断 PD 类型PD 侧如果分级电阻精度不够就会被降级供电。我一般会在 PD 端先量分级电阻实际值再对照标准里的容差范围而不是直接相信 BOM 上的标称值。PoDLPower over Data Lines是单对线的版本条款编号不同别和 PoE 的功率表混用。4.2 EEE 低功耗空闲与唤醒时间预算EEEEnergy-Efficient Ethernet的核心是 LPILow Power Idle链路空闲时收发双方进入低功耗状态定期发 Refresh 保持同步有数据时靠 Wake 信号唤醒。标准里给的是各速率的唤醒时间上限比如 1000BASE-T 和 10GBASE-T 的 tw 值不同设计低延迟业务时要先把这段预算扣掉。很多项目在实验室跑 EEE 没问题上现网就出现偶发丢包原因往往不是 EEE 本身有 bug而是对端设备的唤醒时间比标准上限还慢或者中间串了不支持 EEE 的交换芯片导致协商结果不一致。排查方法是关掉 EEE 对比复现如果关闭后丢包消失问题就锁定在 LPI 状态机的唤醒路径再去查 Clause 78 及相关速率条款里的定时参数。4.3 FEC 插在哪一层、选哪种FEC 是高速以太网绕不开的一环。802.3-2022 里出现的 FEC 主要有 Firecode早期 10G 背板用、RS-FEC(528,514)25G/100G 的 Clause 91/108 一类以及 RS-FEC(544,514)更高速率。选型不是越强越好而是看链路预算和延迟容忍度强 FEC 能压低误码率但会引入额外延迟和带宽开销而且两端必须选同一种否则 PCS 层根本对不齐。判断插在哪一层看 clause 里 PCS 与 PMA 之间的功能框图FEC 通常位于 PCS 之内或 PCS 与 PMA 之间具体位置决定了它是编码前还是编码后生效。工程上我习惯把 FEC 类型、所在 clause、是否可旁路三项写进对接文档三方MAC 厂、PHY 厂、模块厂各填一遍对不上就当场拉齐比事后抓包猜快得多。5. 避坑与排查读 802.3 的五个血泪教训5.1 把 2022 当成最新全量现象按 802.3-2022 设计 800G 相关链路翻遍全文找不到对应条款。原因2022 是整合版之后 IEEE 又陆续发布了 802.3ck、802.3db、802.3cy、802.3cz、802.3cx、802.3de、802.3cs、802.3dd、802.3df 等一系列修订其中 802.3df-2024 涉及 400/800Gb/s 内容802.3ck-2022 与 802.3db-2022 涉及 100/200/400Gb/s 修订这些都不在 2022 版正文里。解决立项时先列一张基础版 适用修订的清单把项目实际用到的速率对应的修订号标出来再去补相应文档不要假设一份整合版能吃下所有速率。5.2 速率关键词歧义现象搜 100G 出来一堆条款不知道哪个对。原因100G 在不同介质和封装下对应不同 clause光模块、背板、铜缆各有独立 PMD 定义PCS 也可能不同。解决检索时带上介质限定词比如 100GBASE-R、100GBASE-KR、100GBASE-CR先锁定 PMD 类型再回查 PCS 参数。5.3 全双工与半双工混淆现象按 CSMA/CD 的逻辑调共享介质参数结果在全双工链路上完全不生效。原因CSMA/CD 只对半双工共享介质有意义全双工下没有冲突检测流量控制走的是 MAC ControlClause 31的 PAUSE 帧。解决先确认链路工作模式半双工才去查冲突窗口和退避算法全双工直接看 PAUSE 与水线watermark配置。5.4 把事实标准当 802.3 条款现象在 802.3-2022 里搜 SGMII、RGMII怎么都搜不到完整定义。原因SGMII、RGMII 这类接口是厂商推动的事实标准并不在 802.3 正文里给出完整规范标准只定义了 GMII、XGMII 等。解决涉及这类接口时以厂商手册和应用笔记为主802.3 只作为 MAC 行为与帧格式的参考别拿标准去套一个它没定义的接口。5.5 量纲与单位对不上现象按标准表格抄了光功率 -X dBm实测发现偏差很大。原因dBm 是绝对功率标准里往往同时给平均功率与峰值、OMA 与平均功率测量点和参考接收机带宽也不同。解决抄参数时强制带三件事——单位、测量点、测试条件缺一个就回到原文对应表格核对别凭经验补。6. 进阶把标准变成可复现的测试计划与版本管理习惯读到能干活的程度标志不是你记住了多少条款而是能把某条速率 clause 翻译成一张可执行的测试计划。我现在的做法是固定三段映射条款号 → 参数名与限值 → 测试条件与仪器设置。以 100GBASE-R 为例PCS 的 64B/66B 编码、PMA 的通道对齐、PMD 的光功率预算分别落在不同子条款映射表里每一行都要写清楚测什么、限值多少、在哪个点测、用什么参考接收机。这张表一旦建立换速率时只需替换条款号测试框架不用重写。提醒映射表的每一行都必须能回溯到具体条款的表格编号不允许出现经验值这种无出处的条目否则半年后没人能复现。第二个习惯是版本管理。802.3 是持续修订的2022 之后还有一批修订在陆续发布所以我在项目仓库里固定放一个spec-baseline.md记录本项目依据的基础版802.3-2022、适用的修订号清单、以及每条修订影响到的条款范围。每次升级基线先做差量对比把新增条款、修改条款、废止条款三类列出来再决定要不要动代码里的参数。这个动作看起来繁琐但能避免上线后才发现某条限值在修订里被收紧了这种返工。第三个是可验证性。标准里的很多参数是范围值不是单点值测试计划要覆盖边界最小值、典型值、最大值各测一遍尤其是 FEC 的纠错门限和 EEE 的唤醒时间这两类参数在边界附近最容易暴露硬件差异。仪器设置也要写进计划比如误码率测试的图案、测试时长、置信度否则不同人跑出来的结果没法比对。血泪经验是我曾经在一个模拟项目里直接拿参考设计的寄存器值上线实验室跑了一周都正常现场批量部署后才发现那组值只在某一版 PHY 硅片上成立换批次就翻车。从那以后我每次把标准参数落进代码前都强制走一遍条款原文 → 寄存器位定义 → 硅片手册三方核对任何一环对不上就停下来查而不是先跑起来再说。希望帮到你。本文还有配套的精品资源点击获取
