今天早上的文章《PCIe协议经常谈到的Memory-Mapped I/O究竟是啥？》发了以后，有工程师留言问：接大量 GPU 时主板不认设备或无法启动，是不是 MMIO 不足？除了换主板还有办法吗？先说结论：YES，极有可能就是 MMIO 不够导致的。尤其是：大量 GPU（每张 GPU 有多个 BAR）使用 PCIe Switch（会增加层级和 BAR 空间需求）旧主板（BIOS MMIO 空间少）服务器主板没有 64-bit MMIO 优化先通俗讲一下 MMIO 为什么会不够每个 PCIe 设备，都要在 Host 地址空间里“要一块地儿”：BAR0：寄存器映射BAR1：状态空间GPU：可能要好几十 MBSwitch：也要 BARNVMe：每块盘也需要一些 BARBIOS 在开机早期负责给所有设备分配 MMIO 地址。如果设备多到 BIOS 分配不出空间，就会发生：GPU 不认Switch 枚举不完全 BIOS 卡住 直接黑屏无法启动这些在你的实验环境里都非常常见。除了换主板，还有哪些真正有效的解决方法？下面这些方法都是行业里真实有效的工程方案：方案①：开启 “Above 4G Decoding” （一定要打开）在 BIOS 里把：Above 4G decodingLarge BAR support / Re-size BAR全部打开。作用：让 BIOS 使用 64bit MMIO 地址空间，而不受 32bit 的 4GB 限制。这是最经济、成功率最高的方法。方案②：关闭不需要的设备，释放 MMIO 空间如：主板自带 USB 控制器SATA 控制器Onboard NIC声卡Thunderbolt 控制器这些全关后能腾出几百 MB 的 MMIO 空间。方案③：减少 GPU BAR 的大小某些 GPU 支持 BAR 大小调整，例如：关闭 Resizable BAR强制以小 BAR（32-bit BAR）方式工作这样可以减少地址空间需求。方案④：使用更“聪明”的 BIOS一些服务器 BIOS 对 MMIO 分配策略不好，导致：明明空间够，分配失败BAR 没排序不能跨域映射升级到最新 BIOS 很多时候能解决问题。方案⑤：使用带“多域”能力的 PCIe Switch 卡例如 Broadcom(或从Saniffer公司购买使用Broadcom switch芯片)的专业 Switch 厂商的产品有：Upstream Port MMIO aggregation多域划分BAR 转换 / 代理64-bit MMIO remapping这些高级功能可以让多个 GPU 共享 MMIO 空间。方案⑥：换 CPU 反而比换主板有效一些 CPU：PCIe Root Port 数量少64-bit MMIO 支持不完整BIOS 固件太保守例如 server-grade Xeon / EPYC 通常 MMIO 能力远强于桌面 CPU。最终总结大量 GPU 不认 → 90% 可能是 MMIO 不够解决方法按效果从强到弱排序：打开 above 4G decode / 64-bit MMIO关闭主板不用的设备释放 MMIO调整 GPU BAR 大小升级 BIOS使用专业 PCIe Switch（支持多域）更换 CPU / 主板（最后手段）更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2025.6.16最新更新的白皮书12.3版本 - 《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver12.3》。白皮书下载链接 (或者点击下面的二维码直接下载）：https://pan.baidu.com/s/18_c11aeFhSBe2qa-jUFs_Q?pwd=mm9y 提取码: mm9y如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。

几天前我们一篇文章《一文讲懂主机启动时是如何给每个PCIe外设分配BDF的》，有工程师留言问：电脑加电启动的时候，PCIe是全部训练完再枚举，还是训练一个枚举一个？我们这里结论先说：PCIe 在系统加电启动（boot）时，是“全部链路先训练完成（Link Training），再开始统一进行设备枚举（Enumeration）”。不是训练一个枚举一个。今天的文章将尽量给你一个清晰的解释，掌握这部分对于熟悉PCIe协议很有用。1. 为什么必须全部训练完才能枚举？因为枚举需要稳定的 PCIe 拓扑结构（Topology），包括：哪些设备存在每个设备是哪个 Bus/Device/Function每条链路最终的速度、宽度（Gen / Lanes）下游设备是否连通Switch 的下游 port 是不是 active如果链路没有全部训练成功（进入 L0），根本无法构建完整拓扑。因此 PCIe Base Spec 要求在枚举开始前，所有链路必须完成 LTSSM → L0。2. PCIe 链路训练（Link Training）发生在固件阶段（BIOS/UEFI 前期）链路训练包含：DetectPollingConfigurationRecovery（必要时）L0（链路正常状态）这是PCIE PHY + MAC（硬件自动完成），极少需要 CPU 参与。训练过程与设备枚举（RC 软件过程）完全独立。3. 训练完成之后，BIOS/UEFI 才开始做设备枚举 Enumeration枚举过程包括：(1) 为 Root Port 分配 Bus numbers(2) 读取下游设备的 Header Type / Vendor ID(3) 配置 BAR 寄存器(4) 为整个系统分配 MMIO / IO space(5) 初始化 Capabilities（MSI/MSI-X/ACS/ARI 等）这一阶段属于 PCI Firmware Spec 定义的流程，在 BIOS 中由 RC（Root Complex）程序执行。也就是说：只有当所有链路都进入 L0，BIOS 才能完整看到整个 PCIe 拓扑，然后开始枚举。4. 是否存在“训练一个，枚举一个”的例外？正常 PC/服务器启动流程 —— 不会！但是有两种特殊例外情况值得你关注：(A) 热插拔场景（Hot-Plug）Hot-plug port 上：Link Training 在设备插入后发生RC 会动态枚举新增设备但这是运行时行为，不属于系统加电启动流程。(B) 某些 PCIe Switch 的“Port-by-port” 初始化例如一些 Broadcom/PLX Switch 型号可能：Port A 训练成功内部 switch firmware 提前对下游 port 做一些预扫描但这属于 Switch 内部行为，RC 枚举依然要等所有链路可用后才统一开始。5. 所以启动流程可以总结为：Step 1：加电Step 2：所有 PCIe 端口开始 Link TrainingPHY 完成 LTSSM 流程链路进入 L0 或失败进入 RecoveryStep 3：所有链路稳定后，BIOS 才开始 PCI Bus enumerationStep 4：初始化设备、分配 BAR、配置 MSI/MSI-X、ASPM 等6. 在SerialTek PCIe协议分析仪上也能看到这个证据你抓加电 trace 会看到：✔ 一堆 Link Training（TS1/TS2、Equalization Phase 0/1/2）✔ 全部 link 进入 L0✔ 然后才出现 BIOS 的 Configuration TLPs（Type 0/Type 1）例如：Config Read Type 1 → 扫描 BusConfig Read Type 0 → 针对 EndpointMemory Write → 写 BAR这正是枚举开始的标志。这很明确地说明：枚举发生在所有链路训练之后。总结 — 面试级标准答案PCIe 在系统加电启动时，所有链路必须先完成 Link Training（进入 L0），然后 Root Complex 才能进行统一的 Bus Enumeration。不会训练一个枚举一个。例外仅在热插拔或某些 switch 的内部预处理流程，普通服务器/PC 不会边训练边枚举。更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2025.6.16最新更新的白皮书12.3版本 - 《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver12.3》。白皮书下载链接 (或者点击下面的二维码直接下载）：https://pan.baidu.com/s/18_c11aeFhSBe2qa-jUFs_Q?pwd=mm9y 提取码: mm9y如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。

昨天有观众看过《一文讲懂主机启动时是如何给每个PCIe外设分配BDF的》发邮件来询问，主机在启动过程中是BIOS给PCIe设备分配MMIO，自己研发的GPU芯片现在会出现MMIO资源分配不足这么一个问题。想问下MMIO的主要功能和工作机制，如何理解MMIO在PCIe设备的作用，或者MMIO扮演一个什么角色? BIOS给PCIe设备分配的MMIO分配到哪里去等一些问题。下面简单结合你做 GPU 芯片研发的视角来解释一下上面的这些疑问：一、MMIO 是什么缩写？MMIO = Memory-Mapped I/O（内存映射输入输出）意思是： 把设备的寄存器、控制空间等 映射到主机 CPU 的物理内存地址空间里，这样 CPU 就能像“访问内存一样访问设备”。二、MMIO 主要功能是什么？一句话总结：让 CPU（或 DRAM 系统）能通过内存地址去访问 PCIe 设备的寄存器、控制器、DMA配置空间等。MMIO 是设备与 CPU 之间的“命令通道”，“大脑 → 外设”的控制路径。三、MMIO 在 PCIe 设备中扮演什么角色？通俗比喻PCIe 设备内部通常有：控制寄存器（启动 DMA、配置模式）状态寄存器（告诉 CPU 是否完成某任务）某些内部 SRAM bufferdoorbell queue（通知队列）MSI/MSI-X tableBAR 寄存器指向的各种控制空间这些东西都需要一个方式让 CPU / 操作系统来读写。MMIO 就是这个方式。📌 比喻： MMIO 就像是在“大楼（CPU 内存空间）”里面给 PCIe 设备开了几间“办公室”（地址空间），CPU 想跟设备交流，就走到那间办公室敲门（读写地址）。📌 无 MMIO = CPU 根本没法操作 PCIe 设备。四、BIOS 给 PCIe 设备分配 MMIO 是怎么回事？当主机开机时，BIOS/UEFI 会：① 扫描所有 PCIe 设备读取每个设备的 BAR（Base Address Register）寄存器。每个 BAR 会声明：这些空间通常包括：Doorbell queue控制器寄存器内部 SRAM windowMSI-X tableGPU 中的 GPC/SM 配置寄存器DMA engine 的寄存器② BIOS 在 CPU 的物理地址空间中给它们找位置CPU 实际可用物理地址空间（例如 0~TB）中会有一部分保留给 MMIO。比如：BIOS 会从这个区域分配：这就是你说的“MMIO资源不足”：所有 PCIe 设备的 BAR size 总和超过了系统能提供的 MMIO window 大小。五、为什么 GPU/大加速器特别容易 MMIO 不够？因为： GPU 的寄存器空间特别大（上百 MB 甚至更多）  多个 BAR（BAR0、BAR1、BAR2，有时还 64-bit BAR）  大量 doorbell queues、调度器、VM context、DMA 配置寄存器  现代 GPU 的 BAR 空间越来越大（如 AMD 的 64GB BAR 技术）服务器 PCIe 设备多时，MMIO 要求量瞬间爆炸。六、MMIO 的工作机制（简单到极致的解释）假设 GPU BAR0 被分配：此时：CPU 执行：并不是写 DRAM，而是：DRAM 完全不参与。MMIO 的本质： ✔ CPU 发出一个写入 ✔ RC 将其转成 PCIe Memory Write TLP ✔ 发给设备寄存器七、MMIO vs DMA（为什么两者是配套关系？）MMIO 是“控制通道” → 用来告诉 GPU：“开始 DMA”、“配置队列”、“读取状态”DMA 是“数据通道” → 用于搬运大数据，比如 GPU 读写主机内存。DMA 启动依赖 MMIO，但数据搬运不依赖 MMIO。八、BIOS 分配的 MMIO 最终“分配到哪里了”？BIOS 分配的是 CPU 物理地址空间中的一段区域。并不是某个 DRAM 地址， 而是 “标记为 MMIO 的地址”。访问这个区域时：✔ CPU 认为是访问“内存” ✘ 但不会走 DRAM ✔ Root Complex 会把这些读写转发给 PCIe 设备这就是“内存映射 I/O”的精髓。九、为什么会 MMIO 资源不足？原因包括：系统 MMIO window 不够（BIOS 或 CPU 硬件限制）有太多 PCIe 设备GPU BAR 空间大64-bit BAR 占用巨大Non-prefetchable 与 Prefetchable window 不能混用CXL 设备使 MMIO 紧张BIOS 没做好资源分配十、GPU 厂商一般怎么解决 MMIO 不够？常见方法：1. 减少 BAR size（改 IP 配置）例如从 16MB 改为 4MB，甚至拆分功能。2. 使用 BAR virtualization（SR-IOV 等）3. 让部分配置空间通过 doorbell + indirect access，而不是直接 MMIO即：这样 BAR 只需很小。4. BIOS/MMIO window 增大（主板厂 or 固件）5. 使用 64-bit BAR 让 BIOS 分配到 4GB 以上高地址总结概念通俗解释MMIO把设备的寄存器映射成“内存地址”，CPU 就能用读写内存的方式控制 PCIe 设备BIOS 分配 MMIO在 CPU 的物理地址空间里划一块区域给 PCIe 设备作为“控制面板”MMIO 的作用控制设备、配置 DMA、读状态，是 CPU ↔ PCIe 设备的指挥通道MMIO资源不足所有 PCIe 设备 BAR 所需的总空间 > CPU/BIOS 提供的 MMIO 地址窗口实际写 MMIO 不会写进 DRAM会被 Root Complex 转成 TLP 发送给设备寄存器更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2025.6.16最新更新的白皮书12.3版本 - 《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver12.3》。白皮书下载链接 (或者点击下面的二维码直接下载）：https://pan.baidu.com/s/18_c11aeFhSBe2qa-jUFs_Q?pwd=mm9y 提取码: mm9y如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。

结合我们最近和一些国内CPU公司开发、验证工程师的沟通和交流，我们今天将简单介绍一下SerialTek PCIe 5.0/6.0协议分析仪、Quarch故障注入卡、sideband信号长期追踪/记录/回溯等核心工具的功能、使用场景，并结合实际案例说明在芯片研发尤其是CPU设计验证过程中，包括DE/DV硅前以及硅后验证阶段，这些工具对于问题诊断、兼容性测试和稳定性验证的重要作用。同时，我们也需要强调SerialCables PCIe 5.0/6.0转接卡、Golden Sample测试卡等辅助设备在构建完整测试环境中的必要性。一、PCIe协议分析仪的核心作用与技术需求PCIe 5.0 x16接口的CPU芯片开发，协议分析仪是必备工具，无论是在设计仿真阶段还是流片后的Bring Up阶段均需使用。分析仪可用于抓取链路双向数据，诊断链路训练（LTSSM）、流控协商、性能瓶颈等问题，尤其适用于解决开机枚举失败、通信中断、低功耗状态异常等复杂场景。实际案例表明，即使采用成熟IP，仍可能因RC端（CPU）行为异常导致链路不稳定，而协议分析仪可提供明确证据定位问题源头。国内用户相对对于美国市场购买高端PCIe协议分析仪较少，主要受价格及税收影响；但租赁服务存在，且部分企业通过短期租用解决紧急问题。二、关键测试工具介绍与选型建议（一）PCIe协议分析仪 (PCIe protocol analyzer)PCIe协议分析仪必须配合Interposer卡使用，实现透明接入并抓取PCIe信号。支持多种接口类型（AIC插卡、U.2、M.2、EDSFF的E1.S, E1.L, E3.S, E3.L等），可根据需求配置不同规格的Interposer。类似于SerialTek这类高端分析仪其内部采用高端服务器等独立处理架构，解码速度快，不依赖客户端电脑性能，优于传统依赖PC端协议分析仪软件处理的分析仪。（二）故障注入卡（Error Injection Card）可主动模拟各种错误场景（如BIT ERROR、CRC ERROR、Code Violation等），用于验证CPU在异常信号下的恢复能力。支持任意差分通道的接收端进行错误注入，无需收集市面上“烂卡”即可完成CPU健壮性（鲁棒性）测试。英国进口，全球唯一供应商Quarch公司，被几乎所有的CPU厂家研发采纳，包括多家国产ARM/RISC-V CPU厂商广泛采用。（三）长期追踪记录卡 （PAM - power analysis module + sideband signal logging)可持续监控边带信号（如PERST#、CLKREQ#、POWER等）变化，采样精度最高4us，建议设置到64us或者128us采样一次，否则存储的数据量非常庞大，适用于偶发性死机问题的回溯分析。数据可实时存储至主机，结合软件平台查看电压、电流、功耗等参数，适合服务器厂商部署于多地现场后的问题复现。三、测试环境构建与配套设备（一）PCIe分析仪的Interposer选型策略PCIe Interposer按x16/x8/x4划分，x4版本成本较低，但对于分析仪PCIe协议来讲没有很大区别。尽管物理通道减少，但由于协议层交互与通道数量无关，x4分析通常足以覆盖大部分协议级问题。英特尔内部亦采用多路x4切换方式完成全通道测试，建议可通过自研切换装置实现低成本全覆盖。（二）PCIe转接卡与延长线必须使用高质量转接卡或延长线，避免因劣质线材导致信号完整性破坏甚至硬件损坏。曾有客户因使用淘宝低价转接卡导致价值上亿设备烧毁，强调不可节省此类成本。推荐从专业供应商采购，确保阻抗匹配与信号保真。（三）PCIe Golden Sample测试卡PCI-SIG官方认证的唯一Golden Sample卡SerialCables PCIe 5.0 x16主机卡，作为EP端基准设备，用于验证CPU RC端的兼容性与稳定性。支持PCIe 5.0 x16，适用于建链测试，长时间压力测试与自动化回归测试。国内众多CPU头部企业批量采购用于原型机验证。简要总结PCIe协议分析仪是CPU芯片开发中不可或缺的关键工具，尤其在流片后Bring Up与系统级验证阶段具有不可替代的作用。建议优先配置具备独立处理能力的高性能分析仪，并根据预算合理选择x4或x8配置以平衡成本与功能。故障注入卡与长期追踪卡应作为补充工具纳入测试体系，提升对异常场景与偶发问题的应对能力。测试环境中必须配备高质量的Interposer、转接卡及Golden Sample卡，杜绝因外围设备质量问题干扰测试结果。更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2025.6.16最新更新的白皮书12.3版本 - 《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver12.3》。白皮书下载链接 (或者点击下面的二维码直接下载）：https://pan.baidu.com/s/18_c11aeFhSBe2qa-jUFs_Q?pwd=mm9y 提取码: mm9y如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。

接着昨天的视频PCIe低功耗L1.2到底是个什么东东？（一）我们今天的高清视频（总计17分钟）来讲一下SerialTek PCIe协议分析仪抓到的的含L1.2低功耗trace文件，这个可以让你更加感性地增加对于L1.2的了解。 为了方便工程师观看，我们针对本期视频添加了中文字幕供大家参考。如果想看高清视频建议要在电脑上打开上面的视频链接进行观看！创作不易，欢迎分享到朋友圈或者与朋友讨论！如果想搬运我们的视频请告知我们。 PCIe L1.2 低功耗协议：一次完整的链路进入与退出过程解析 在移动端与笔记本平台广泛采用 NVMe SSD 之后，PCIe 的低功耗特性变得尤为重要。L1.1 / L1.2 是 PCIe 中最核心的深度节能状态，使系统能够在不传输数据时几乎关闭整个链路的发射端、接收端以及参考时钟，从而实现毫瓦级功耗。 本文结合抓取的真实 SerialTek PCIe Trace（低功耗 L1.2 场景），对链路如何进入低功耗、如何退出，以及整个 LTSSM 状态机行为进行逐步讲解。 一、整体界面与 Timeline：全局观察链路 60 秒行为 在本次示例中，我们记录了一段约 62 秒 的 PCIe 链路行为（CPU ↔ NVMe SSD）。界面上可以看到： 绿色代表 DLLP（Data Link Layer Packet） 蓝色代表 TLP（Transaction Layer Packet） 中间大片浅紫色区域代表链路进入低功耗 Idle（电气 Idle）状态 在 Timeline 视图中，Downstream/Upstream 的吞吐量以直观颜色亮度显示；移动鼠标滚轮即可快速放大查看数据传输细节。 二、L1.2 的本质：链路 TX/RX + RefClock + PLL 全部关闭 进入 L1.2 时，链路两端（CPU 与 SSD）会： 关闭 Transmitter（TX） 关闭 Receiver（RX） 关闭 Reference Clock（RefClk）输出 关闭 锁相环 PLL 因此，分析仪在该状态下“看不到信号”，从而无法建立时钟锁定。Trace 中这是以“未锁定（unlock）”状态呈现。 进入 L1.2 的标志事件为： Clock Request 拉高（表示请求进入低功耗） 从视频可以看到，当 Clock Request 拉高时，Timeline 上方出现浅色区域，即链路进入深度 Idle。 三、LTSSM 状态机呈现：Detect → Polling → Config → Recovery → L0 → L1 在 LTSSM（Link Training and Status State Machine）视图中，可以看到两端（Upstream/Downstream）分别呈现出： Detect Polling Configuration Recovery L0（正常传输） L1 Idle（低功耗） 在多数分析仪上，L1.1 / L1.2 无法完全区分，会统一显示为 L1 Idle。 四、链路如何退出低功耗（L1.2 → L0）？ 这是本次 Trace 中最核心、最精彩的部分。 当任一端（CPU 或 SSD）准备发数据时，需要： 步骤 1：Clock Request 拉低（表示需要唤醒链路） Trace 中可以清楚看到： Clock Request 由 1 → 0，表示退出低功耗 链路两端开始重新启动 RefClk、TX/RX、PLL 步骤 2：参考时钟恢复需要一定延时 在分析仪界面测量得出： 从 Clock Request 拉低 到 RefClock 恢复并被分析仪重新锁定 大约需要 65 微妙左右。 这 65微妙 的延迟来自 NVMe SSD 的时钟恢复时间，是平台设计的重要特征。 步骤 3：链路自动进入 LTSSM Recovery → L0 RefClk 上来后，链路立即开始发送： TS1、TS2 Training Sequence Recovery.Lock Recovery.Speed 最终进入 L0 之后立即可以发 DLP 流控包、TLP(Packet)、Memory Write 等。 五、链路短暂唤醒：不到 1 毫秒的小规模传输 Trace 中显示，某些业务场景链路仅需要极短交换，例如写入少量 data。此时行为如下： L1.2 → L0 → 传输几包数据 → 立即回到 L1.2 字幕测得多次小周期： 973 微秒 874 微秒 939 微秒 也就是说： **链路从进入低功耗 → 唤醒 → 传数据 → 再进入低功耗 整个往返仅约 0.8–1 毫秒** 这种极短周期被称为： Frequent L1 Substate Flapping（频繁的 L1 出入） 非常典型于 NVMe 设备在系统启动、日志刷新等轻负载时的行为。 六、系统启动阶段：持续约 7–9 秒的大量传输 字幕中的笔记本电脑正在安装操作系统，因此 NVMe SSD 持续被访问。Trace 显示： L0 长时间保持 链路不断发送读写 TLP 没有进入低功耗的必要 测到持续活动时间：7 到 9 秒 这很好地展示了 操作系统启动阶段需要从SSD读取操作系统文件阶段的高 IO 密度。 七、L1.2 实际意义与工程价值 从本次 Trace 可以总结 PCIe L1.2 的几个关键工程特点： 1. 深度省电：TX/RX/PLL/RefClock 全部关闭 是 PCIe 最节能的状态。 2. 唤醒延迟时间：典型 60–70 us 适用于对时延不敏感的客户端/移动平台。 3. 短周期业务会产生频繁进出 L1.2 平台厂商需要在 BIOS/ASPM 中细致调优。 4. 分析工具（如 SerialTek）必须正确同步 RefClk 否则无法解析 Training、DLP、TLP。 5. 真实 Trace 可以观察到流控、唤醒、训练过程的精确时间 对验证 SSD、主控、Root Complex 的电源管理策略极其关键。 八、总结：一次完整、清晰的 L1.2 低功耗示例 本文结合实际 PCIe Trace，完整展示了： 链路进入低功耗（Clock Request 拉高 → RefClk/TX/RX 关闭） 链路退出低功耗（Clock Request 拉低 → RefClk 恢复 → LTSSM Recovery → L0） 0.8–1 ms 的短暂唤醒周期 长达 7–9 秒的持续传输场景 L1.2 对实际平台节能策略的重要性 通过这些实际时序，可以更清晰地理解 PCIe L1.2 的运行机制，为 消费类手机、平板电脑、SSD、笔记本厂商的调优和验证提供参考。 更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2025.6.16最新更新的白皮书12.3版本 - 《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver12.3》。 白皮书下载链接 (或者点击下面的二维码直接下载）： https://pan.baidu.com/s/18_c11aeFhSBe2qa-jUFs_Q?pwd=mm9y 提取码: mm9y 如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。  

我们常用的笔记本有的时候你会发现蓝屏，或者说崩了，除了操作系统、补丁包、应用导致的问题外，还有一块就是和笔记本里面的M.2 NVMe SSD有关。当操作系统要写东西到SSD发现不通了， 可不就直接蓝屏、死机了嘛！大品牌的SSD低功耗测试这块做得相对好很多，很多小品牌，或者使用不知名品牌主控的SSD就容易出这些问题。 再仔细深究一下，除了M.2 SSD本身有问题外，还有相当大的一部分原因就是SSD"进入"低功耗L1.2，然后需要双向通讯（CPU <--> M.2 SSD)的时候“退出”低功耗L1.2出现问题，导致CPU找不到SSD。 其实，这个不仅仅是我们经常用的笔记本电脑有这个问题，各种高速的消费类产品都有PCIe低功耗这个问题，包括使用BGA SSD的手机，Pad/平板，以及使用M.2接口进行通讯的非SSD应用等等。只要使用PCIe协议一定会相当频繁地进/出L1.2低功耗。 我们将通过两期文章，结合SerialTek PCIe 5.0协议分析仪的高清视频讲解，让你成为掌握L1.2低功耗技术的专家。 今天视频拍摄时间很紧张，由于时间关系我们本期视频未添加中文字幕供，但是下面的文字是针对该视频的尽量清晰的总结供参考。如果想看高清视频建议要在电脑上打开上面的视频链接进行观看！创作不易，欢迎分享到朋友圈或者与朋友讨论！如果想搬运我们的视频请告知我们。 下面是我们本次使用的测试的高清图片。   PCIe Gen5 协议分析仪实测：M.2 设备 L1.2 低功耗行为深入解析 （基于 ThinkPad X1 Carbon 实机演示） 本文结合实际演示环境与协议原理，完整解析了 PCIe M.2 SSD 在笔记本电脑中的 L1.2 低功耗行为，以及 SerialTek PCIe Gen5 协议分析仪如何稳定抓取“高频进出低功耗”场景下的链路信号与 TLP/DLLP 流量。下面的文字内容总结来自上述的实际演示的操作记录。 一、测试环境与硬件架构 1. 测试平台 主机：ThinkPad X1 Carbon（PCIe Gen3 x4 M.2 SSD 设计） SSD：原机 NVMe SSD，被移出用于串联协议分析仪 分析仪：SerialTek PCIe Gen5（具备独立高性能处理架构） Interposer：M.2 2242/2280 Host-Side Adapter + Device-Side Adapter（中间插入 Y 型高速线缆） Sideband：使用 Oculink 线缆抓取 CLKREQ#、PERST#、REFCLK、WAKE# 等信号 分析仪被串入 CPU ⇄ M.2 SSD 的 PCIe 通路，能同时抓取： 上下行高速链路数据（TLP/DLLP/Training） Sideband 边带信号（特别是 Clock Request） 这些信号组合可完整还原低功耗行为和链路训练过程。 二、为何笔记本必须频繁进入 PCIe 低功耗？ 手机（如苹果手机内嵌BGA NVMe SSD)、Pad平板、笔记本电脑的电池必须尽可能延长续航，在电池技术没有突破性进展之前，PCIe 设备设计为只要没有传输数据便立即进入 L1.x 低功耗状态，通常在 1 微秒以内 就触发，从而大大提供设备的待机时间。 三种 L1 低功耗模式 模式 说明 L1.0 最浅度的低功耗，部分电路仍工作 L1.1 更低功耗，PLL/时钟部分关闭 L1.2 最深低功耗状态，链路几乎全部关闭 现代笔记本几乎都会直接进入 L1.2。 NVMe Power State 与 PCIe L1.x 的对应关系 PS3 → L1.1 或 L1.2 PS4 → 必定进入 L1.2 于是链路呈现一种极高频率的行为： 每秒数千至数万次： 进入 L1.2 → 被唤醒 → 完成 LTSSM Training → 传输数据 → 再次进入 L1.2 这一模式对PCIe协议分析仪是极大的挑战。 三、低功耗进入/退出机制：Clock Request 的关键作用 低功耗控制包含两部分信号： 1. DLLP 的 Power Management Request (PM_Req) 用于通知对端进入低功耗。 2. Sideband 信号：CLKREQ# 这是最关键的信号之一： CLKREQ# = High（拉高） → 进入低功耗 CLKREQ# = Low（拉低） → 退出低功耗，准备训练链路 在 Trace 中可非常直观看到： 只要 CLKREQ# 拉低 → 马上开始 TS1/TS2 训练序列 随后进入 L0，传输少量 TLP，流量结束后立即再次进入 L1.2。 PCIe协议分析仪的sideband边带信号窗口能完整还原这一过程。 四、LTSSM 行为：从 L1.2 唤醒到再次进入 L0 进入 L1.2 后，链路等效于“冷却”状态，包括： TX/RX 全部关闭 PLL 关闭 REFCLK 可能被门控 因此唤醒时必须执行 完整或部分训练流程： 链路恢复路径（常见） L1.2 → Detect → Polling (TS1/TS2) → Configuration → Recovery → L0 此循环可能在一秒内发生数千次。 训练期间产生的 CRC error、8b/10b disparity error 等属于正常现象，并非链路质量问题。 五、为什么其他分析仪难以捕捉 L1.2 行为？ 视频里面特别强调了一点非常关键： 目前全球范围内只有SerialTek PCIe协议分析仪能够可靠捕捉高频率进入/退出 L1.2 的链路。 大多数分析仪会出现： 无法在 Training 瞬间锁定链路 丢包或解码失败 产生大量伪错误 在 L0 与 L1.2 高频切换时彻底失效 原因是： 训练窗口极短（微秒级） TLP/DLLP 零碎且高频 时钟恢复与锁相环变化极快 Sideband 与高速线必须同步解码 这正是低功耗调试领域的痛点。 六、实测 Trace 中的关键观察 以下基于演示捕获到的 5.25GB Trace 数据总结： 1. 开机阶段大量 Training 开机需要读取 Bootloader 与 Windows 系统文件 链路在一段时间内保持 L0，不进入低功耗 2. 进入 OS 后频繁进出 L1.2 一旦系统完成大批量 IO，链路开始 频繁进入低功耗 CLKREQ# 波形呈典型的“锯齿状”：拉高（L1.2）→拉低（唤醒）→训练→传输→再次拉高 3. 上下行流量不对称 Downstream（CPU → SSD）通常读操作更多 Upstream（SSD → CPU）则反馈数据与 Completion 4. Training 信号与错误均正常 Training 期间黄色标记、CRC 或其他 error 属正常协议行为。 这些观察在 Sideband/TLP/DLLP 窗口中均可完整复现。 七、关键知识点总结 1. L1.2 是笔记本 PCIe 的默认低功耗模式 为了节省电量，链路会在 每一次短暂停顿后立即进入 L1.2。 2. 唤醒链路需要完整 training TS1/TS2 是恢复链路的必须步骤。 3. Clock Request 是判断低功耗行为最关键的信号 几乎可以凭 CLKREQ# 判断每一次进出低功耗。 4. PCIe分析仪能力要求极高 必须同时满足： 高速 AFE + 超强 CDR（锁相能力） 对上百次/秒 Training 的实时锁定能力 对 Sideband 与高速链路的同步采集 内部独立 CPU/GPU 级处理能力（避免 PC 解码过慢） 5. M.2 Interposer 的信号完整性要求极高 包括： 短走线设计 阻抗控制 GND 参考一致性 否则 Training 极易失败。 八、结语 M.2 SSD(或者其它基于M.2接口的低功耗外设)在笔记本电脑中日常运行时，会呈现一种“极高频率的低功耗跳变”行为： 不断在 L0 ↔ L1.2 之间切换。 这种复杂行为目前在全球范围内只有SerialTek的高端 PCIe 分析仪能够长时间正确捕获并解码。通过本次 ThinkPad X1 Carbon 的实机演示，我们真实呈现了： 低功耗为何如此频繁发生 链路训练如何在微秒级执行 Sideband 信号与高速链路如何协同工作 分析仪如何避免丢包、伪错误与链路丢失 该流程对于调试 PCIe 低功耗、M.2 性能问题、功耗优化、系统不稳定问题（如黑屏、睡眠唤醒慢）都具有重要参考价值。 更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2025.6.16最新更新的白皮书12.3版本 - 《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver12.3》。 白皮书下载链接 (或者点击下面的二维码直接下载）： https://pan.baidu.com/s/18_c11aeFhSBe2qa-jUFs_Q?pwd=mm9y 提取码: mm9y 如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。  

我们经常在Linux里面使用lspci插卡某个pcie device 的b:d.f值，那么这个BDF （bus:device.function）值在系统化阶段是如何分配的呢？下面的文章将简要分析一下我们常用的电脑在启动过程中是如何进行pcie device枚举，发现每个device，同时给每个device分配合理的b:d.f的，我们将通过举几个和pcie device交互的例子说明。有的朋友可能会问，该枚举是在link up进入L0，然后协商flow control等信息link logically up之后做的第一件事情吗？整个过程一般会持续多少时间，例如大概几百ms还是几秒钟？有的时候会卡住吗？会有timeout超时机制设置吗？如果路径中间经过pcie switch咋办？我们也会涉及一下上述内容。1. PCIe 设备枚举是在 BIOS/UEFI 的 PCI Bus Driver 完成的执行者：不是 PCIe 协议本身，而是 BIOS/UEFI 软件层（PCI Bus Driver）目的：发现所有端口下的设备，并给设备分配 Bus/Device/Function 编号与资源（BAR space）。PCIe 协议只负责：链路训练（TS1/TS2）、进入 L0、FEC、Lane Negotiation、Scrambling、Symbol Lock、Flow Control Credits 初始化等。设备枚举属于“configuration space access”，是软件行为，不是 PCIe 链路层功能。2. 枚举使用的底层 TLP 类型：Config Read/Write TLP很多工程师误以为 BIOS 枚举设备是通过 MemRd/MemWr TLP。✔ 正确：使用 Config Type 0 / Type 1 TLPType 0 Configuration Read/Write TLP：访问同一个 bus上的设备 (Device/Function)Type 1 Configuration Read/Write TLP：访问下层 bus（例如 PCIe Switch 下的子 Bus）例如 BIOS 读 VendorID：下图是使用SerialTek PCIe 5.0/6.0协议分析仪看到开机后CPU发了第一个MesD_local后大概过了400ms进开始进行pcie device枚举的过程。3. 枚举触发条件：必须等到 PCIe Link 进入 L0 并完成 Flow Control 初始化PCIe LTSSM：DetectPolling（TS1/TS2）Configuration（TS1/TS2 + Lane/Speed negotiation）RecoveryL0  🔥Flow Control 初始化（InitFC1 / InitFC2）链路逻辑 UP✨ BIOS 只有在 Link Training 完全结束、进入 L0、FC credit 也 ready 后才可以开始发 PCIe TLP。因此：✔ 设备枚举是 Link Up 完成后的第一批软件操作之一。4. B:D.F 分配规则（直连设备）Boot 时，BIOS 从：Bus 0 → Device 0–31 → Function 0–7依次尝试访问：若设备不存在： → 返回 0xFFFF_FFFF若设备存在： → 返回 VendorID / DeviceID示例：CPU Root Port 直连设备假设 CPU Root Port 出现在：BIOS 识别这是一个 PCIe Root Port，于是给这个 Root Port 下的新 Bus 指定一个编号：然后 BIOS 开始扫描 Bus = 1 的设备。5. 通过 PCIe Switch 的 B:D.F 分配流程假设结构：枚举过程：Root Port 被枚举（Bus 0, Dev x）BIOS 分配 Secondary Bus = 1BIOS 在 Bus 1 读 VendorID发现这是 PCIe Switch（Device=0x10B5 for PLX/Avago/Broadcom）配置 Switch 的 Primary/Secondary/Subordinate Bus对每个 Downstream Port 再给一个新 Bus 号，例如：BIOS 再依次扫描 Bus 2、Bus 3、Bus 4、Bus 5…6. 与 PCIe 设备交互的典型发现例子例 1：读 VendorID（识别设备类型）BIOS 发：Config Read Type 0 (0:1:0 offset 0x00)返回：→ 说明这是 Intel 网卡。例 2：读 Class Code（判断是否是 Switch、NVMe、GPU、NIC）值示例：Class Code设备类型0x010802NVMe0x030000VGA / GPU0x060400PCIe-to-PCIe Bridge (Switch)0x0C0330USB 3.0 controllerBIOS 根据 Class Code 决定如何深入扫描。例 3：读 BAR（请求资源）BIOS 写 BAR = 0xFFFF_FFFF，然后读回来。如果设备返回：→ 表示需要 4KB MMIO BAR space。BIOS 用此信息分配地址。7. 整个枚举过程一般耗时多久？典型耗时（服务器或 PC）项目耗时PCIe Link Training (TS1/TS2 + FEC lock)5–50 ms PER PORT枚举、高级扫描、BAR 分配10–200 msPCIe Switch 多层拓扑最多 300–800 ms总计通常：100ms~1 秒之间。如有大量 Switch + 多层拓扑（大服务器系统）可能达到 2–3 秒。8. 会卡住吗？是否有 timeout？✔ BIOS 有严格 timeout 机制：常见超时：配置读超时（无响应设备 → 返回 0xFFFF_FFFF）Link Training timeout（链路一直在 Recovery 状态 → UEFI 有 100ms~500ms 的重试）BAR 分配失败（MMIO 资源不足）设备用 DPC / LTSSM 死循环导致 Root Port 死等典型值：Link Training Timeout：100ms~500msConfig TLP Timeout：20ms~50msSwitch 热插拔端口 Recovery 超时：≈100 ms因此：✔ 枚举大概率不会“无限卡死”，都会降级、跳过设备、或者报错继续。9. 为什么偶尔枚举失败？工程师常碰到：Retimer/Switch training 不稳定 → link 一直在 Polling/Recovery 循环BIOS 没有足够的地址空间分配给 BAR（尤其 GPU 或 SmartNIC）PCIe device 还没上电 or VSEC 读不到FLR resetting 需要时间这些都会导致“有时能枚举、有时不能枚举”。10. 流程总结图11. 关键问题回答总结你的问题回答枚举是通过 TLP MemRd 实现的吗？❌ 不是。使用 Config Read/Write TLP枚举何时发生？Link Up → Flow Control Ready 之后立刻进行枚举耗时多少？100ms ~ 1 秒（大型系统可达 3 秒）会卡住吗？有 timeout，会跳过问题设备如何为 switch 分派 B:D.F？BIOS 为每个 downstream port 分配一个新的 Bus number，递归扫描和直连设备的差异？增加 Type1 Config TLP，并分层 bus 扫描结构更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2025.6.16最新更新的白皮书12.3版本 - 《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver12.3》。白皮书下载链接 (或者点击下面的二维码直接下载）：https://pan.baidu.com/s/18_c11aeFhSBe2qa-jUFs_Q?pwd=mm9y 提取码: mm9y如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。