我们Saniffer频道很多粉丝都是从事涉及PCIe高速接口的芯片研发、设计、验证、测试、支持的工程师，你平时有没有想一想，如果有一天，AI比你更懂PCIe协议栈，你还剩下什么？你有没有遇到过这种场景：凌晨2点，实验室灯还亮着。 你盯着一条PCIe链路——LTSSM卡在Polling状态，怎么都起不来。你已经做过所有“标准动作”：Reset拉低重来换线、换slot调整EQ参数抓log、看TLP甚至开始怀疑REFCLK是不是有问题但问题依然在那里，一动不动。这种时候，经验告诉你：  这不是“不会”，而是“要时间”。  是靠反复试、反复猜、反复验证，一点点把问题逼出来。这也是为什么，一个成熟的PCIe工程师，值钱。但现在，有一件事情正在悄悄改变这个逻辑。越来越多的团队，开始把这些步骤交给AI：自动分析LTSSM状态跳转自动比对历史case自动生成debug路径甚至直接给出“最可能的root cause排序”原来需要1~2天定位的问题， 现在，有些团队已经能在几十分钟内收敛范围。更关键的是——AI不会累，不会情绪波动，也不会“卡思路”。问题来了： 如果AI可以完成80%的调试和验证工作，那剩下的20%，还需要多少工程师？你可能觉得，这还只是“辅助工具”。但如果你把视角拉大一点，从DE、DV，到Post-Silicon，再到FAE，你会发现：AI不是在优化某一个环节，而是在吞掉整个链条。最近硅谷一个越来越常被提到的词是： “永久底层”（Permanent Underclass）它指的不是短期失业，而是——在技术体系中，被永久替代掉的位置。更讽刺的是：最早讨论这个问题的， 不是普通工程师， 而是——正在造AI的那群人。接下来这篇文章，我们不讲空洞的“AI趋势”， 只讲一件更现实的事情： 在芯片研发和测试一线，AI已经具体影响了哪些岗位？ 哪些能力正在快速贬值？哪些能力反而在升值？ 以及——你现在该怎么应对？如果一种 AI 发展的净社会结果，是让更多人在美国滑向失业、住房不稳甚至无家可归，在国内则滑向长期“躺平”、延迟就业和失去上升通道，那么社会并不需要那种发展路径上的 AI。所以，我有的时候也在想，当AI让更多人不快乐时，我们还需要AI吗？但是，真正的问题从来不是“要不要 AI”这个抽象命题，而是：生产率收益由谁拿走，转型成本由谁承担，人的判断权、议价权和基本尊严是否还被保留。昨天虎嗅的一篇文章把这种焦虑概括成“永久底层”，参见《永久底层：硅谷的AI从业者普遍认为，普通人已经“完蛋了”》，这个提法很尖锐，但它抓住了一个真实变化：AI 正在从“辅助”迅速走向“委托”。对半导体工程人群来说，最重要的分界线并不是“白领/蓝领”，而是任务是否结构化、可验证、可被工具链评分。凡是有成熟规格、回归体系、覆盖率指标、日志、波形、ATE 数据、fail bin、root-cause loop 的工作，AI 都更容易先吃掉一层、再吃掉一层。METR 的时间跨度研究也说明了这一点：当前前沿代理在短而清晰、可自动评测的任务上能力提升极快，但在长链条、强上下文、模糊目标的工作上仍不稳；而 ASIC 从 DE、DV 到 post-silicon，恰恰同时包含这两类任务，所以真正发生的不是“一夜清零”，而是先自动化子任务，再压缩团队规模与岗位层级。“永久底层”这篇文章抓住了什么，也夸大了什么作为一篇问题意识极强的评论，这篇文章有两点是说对了的。第一，连 AI 公司自己都已经开始把“劳动力市场冲击”当成公开议题。Anthropic 明确写过，用户正越来越倾向把完整任务直接委托给 Claude，而不是把它当作协作助手；它还专门讨论了在“工资下滑、就业减少、贫富差距扩大”情景下需要考虑的政策反应。Dario Amodei 甚至把强 AI 比作“数据中心里的天才之国”，直言这可能是现代劳动市场最大的变化之一。与此同时，世界经济论坛 在《Future of Jobs 2025》中也记录到：40% 的雇主预计会在 AI 能自动化任务的地方减少用工。但这篇文章如果被理解成“普通人已经完蛋了”，就说过头了。到 2026 年为止，公开证据仍然更支持“岗位重构”而不是“全面塌方”。Anthropic 自己跟踪的 labor-market 研究强调，真正有害的 AI 冲击通常应该先体现为失业上升，但它目前的初步结果还没有显示那种剧烈、明确的结构性失业；国际劳工组织 2025 年更新版也认为，多数工作更可能是被改造，而不是被整块删除。更关键的是，在芯片行业，自动化上升和人才短缺是同时成立的：Deloitte 估计到 2030 年全球半导体还需要新增一百多万名熟练人才，而美国半导体行业协会 估计美国半导体行业到 2030 年还会新增约 11.5 万个岗位，其中约 6.7 万个可能招不满。换句话说，危险不是“行业没工作了”，而是“行业有工作，但工作形态、门槛和人力结构变了”。高速芯片链条里，AI正在怎样逐步替代人在芯片规划、物理实现和后端调参环节，AI 已经不是概念验证，而是商用品。Google DeepMind 在 Nature 论文里把强化学习 floorplanning 描述为能在 6 小时内完成过去常常要几个月的人类工作，之后又公开称 AlphaChip 已用于多代 TPU。商业 EDA 领域里，Synopsys 的 DSO.ai 已经被用于 100 多个 commercial tape-out；公司披露 STMicroelectronics 在云上获得了超过 3 倍的 PPA 探索生产率提升，SK hynix 则拿到了 15% cell area reduction 和 5% die shrink。Cadence 说其 Cerebrus AI Studio 让单个工程师可以同时推进多个 block，而MediaTek 报告某 SoC block 上 die area 缩小 5%、功耗下降超过 6%。Siemens 则宣称 Aprisa AI 带来 10 倍生产率、3 倍算力效率和 10% 更好的 PPA。对做 CPU、GPU、DPU、NIC、SSD controller、AI accelerator，尤其是 PCIe 5.0/6.0 高速芯片的人来说，这直接冲击的是那类靠经验反复调 script、调 flow、调 recipe 的资深实现工程师与 CAD/flow 工程师。在 DE 和 DV 侧，侵蚀更直接，因为这里大量工作天然就是“规格—代码—验证计划—回归—debug”的文本和工具链闭环。Synopsys 最新 Copilot 已能从自然语言生成 RTL、自动修 lint、从规格生成 formal testbench，并给出“2–5 倍更快生产率”“RTL 约 30% 提升”“formal 4–5 倍效率”这类早期客户反馈。Cadence 的 ChipStack AI Super Agent 则公开写明能生成 formal verification plan + SVA 并自动证明，还能生成 dynamic verification plan、UVM sequences、checkers 和 coverage，并做 autonomous triage 和 root cause proposal。Siemens 的 agentic toolkit 里有 Verification Planning Agent；Questa One 的 Property Assist 被 MediaTek 说成能“省下几周工程时间”，Regression Navigator 能“省下几天回归和 debug 时间”。如果把场景代入一个 PCIe 6.0 controller、retimer、CXL endpoint 或 AI NIC：L0p/L1 交互、link width change、flit mode、equalization、error injection、compliance 这些角落状态组合本来就爆炸性增长，而 AI 现在已经在吃掉 verification plan 初稿、SVA boilerplate、UVM sequence skeleton、第一轮 fail triage、coverage gap 分析与 regression 排序这些曾经高度依赖老师傅经验的活。在 post-silicon、PVE、PE/TE、FW test 和失效分析这边，AI 的渗透方式是“先左移，再数据闭环”。NVIDIA 与 Siemens 联合披露，Veloce proFPGA CS 已能在 first silicon 之前几天内抓到万亿级验证周期，把大量软件验证与系统场景测试提前到 pre-silicon。NI 明确说现代化 post-silicon validation lab 的标准化基础设施能够自动化超过 80% 的重复性任务，而 Nigel AI 已能解释 LabVIEW 项目结构、帮助定位设置、解释文档、给出任务操作说明。到了量产测试端，Advantest 的 ACS RTDI 能把 test insight 在同一次 insertion、毫秒级转成 production step；Synopsys 的 Silicon.da 可以处理 petabytes 级 design / monitor / diagnostic / fab / production test 数据，用于 downstream manufacturing、RMA debug 与历史根因分析；Siemens 的 Tessent Diagnosis 直接把 failure analysis 的大量前处理数字化，被称作 failure analysis 的 digital twin。换句话说，PVE、FW/FTE、PE/TE、failure analysis 工程师里最容易被吃掉的，不是最终签字责任，而是那些“肉眼看 log、写胶水脚本、调 tester 参数、做 fail clustering、给 FA 排嫌疑名单”的重复环节。Firmware、应用工程、客户方案工程和现场 FAE 也并不安全。OpenAI 的 Codex 已经能在隔离环境里读写代码、运行 test harness、linters 和 type checkers；Anthropic 对 50 万条 coding 交互的分析显示，Claude Code 的对话有 79% 属于自动化而不是增强。与此同时，Synopsys 的 Knowledge Assistant 承诺在 EDA design / verification / test 栈上把“找答案时间”缩短约 70%；NI Nigel 也能总结文档、解释 dependencies 和项目结构。由此推断，FW/FTE、AE、CSE、field FAE 中那部分“寄存器 bring-up 脚手架、测试脚本骨架、重现步骤编写、文档检索、问答型支持、例行性 trouble-shooting”会被越来越快地压缩。能够留下来的，是那些高歧义、高风险、高责任的部分：复现不稳定的系统问题、跨芯片/板卡/软件栈定位性能断崖、在客户现场协调业务风险和技术取舍、以及在证据不完整时做判断。哪些岗位最容易被蚕食，哪些岗位更能留住议价权最危险的，不是“初级”这个字面标签，而是工作是否可模板化、可验证、可由反馈环推动持续自动改进。因此，高风险岗位包括：DE 里写模块骨架、寄存器映射和大量常规 glue logic 的人；DV 里写 verification plan 初稿、SVA/UVM boilerplate、做 regression scheduling 和 fail triage 的人；FW/FTE 里主要做驱动脚手架、测试脚本、日志清洗与回归自动化的人；PE/TE 里主要做 ATPG 参数搜索、tester recipe 反复试错、良率分析初筛的人；FA 里做大批量 fail case 前处理和嫌疑排序的人；以及 AE/CSE/FAE 里以文档答疑、标准流程支援为主的人。因为这些任务都很接近 METR 所说的“短、清晰、可度量”的任务分布，也和 GDPval、vendor agent 工具最容易吃到的区间高度重叠。相对更能留住议价权的，是那些必须把物理世界、系统上下文、责任归属和业务取舍捆在一起的岗位：跨层系统架构师；真正负责 signoff 的 owner；post-silicon root-cause lead；混合信号、封装、SI/PI、热、可靠性和系统 bring-up 专家；能把客户 workload、板级限制、协议行为、现场现象和公司决策连成闭环的人。它们也会被 AI 增强，但短期内更像“一个人管更多 agent”，而不是“人直接被删掉”。这也是为什么我更倾向于判断，未来几年的主旋律是每个项目所需 headcount 下降、entry-level 入口缩窄、mid-level 中层被压扁、而少数能定义问题和签字负责的人更值钱，而不是芯片工程师整体突然消失。给工程师的建议真正该做的，不是跟 AI 比谁更会吐文本，而是把自己迁移到 AI 最难替代的位置：定义问题、设定验收标准、拥有数据闭环、承担结果责任。对 DE/DV 来说，这意味着把重心从“写更多 RTL / UVM”转向 executable spec、golden reference、scoreboard semantics、coverage intent、signoff criteria；对 FW/FTE 来说，要从“写脚本和小工具”转向“设计 bring-up strategy、telemetry schema、failure taxonomy 和跨层 debug 流程”；对 PE/TE 和 FA 来说，要从“跑流程”转向“做实验设计、因果归因和量产决策”；对 AE/CSE/FAE 来说，要从“答问题的人”变成“把协议、系统、客户场景和商业目标绑起来的人”。这是一个推论，但它和今天自动化最强的区域完全一致：越靠近机器可评分的子任务，越容易被压缩。更具体地说，未来三到五年最稳的路线不是“抗拒 AI”，而是“成为 AI-native 工程师”。一是尽快学会在团队内部搭建 RAG 和 agent workflow，让规格、errata、波形、log、测试记录真正可检索、可评测、可复用；二是把“评估 AI 输出是否可信”的 eval 设计变成你的核心能力；三是向更稀缺的物理直觉靠拢，例如高速接口的 SI/PI、功耗/热、封装、可靠性和系统联调；四是补上产品和客户语境，因为模型天生缺乏真实组织上下文。Synopsys 已经在公开表述里把“工程师必须演化 skillsets and workflows”说得很直白，而 OECD 和 WEF 的最新信号也都更接近“AI 正在重塑工作内容和职业阶梯”，而不是简单的岗位破坏。AI最后可能如何结局我认为，AI 的“结局”主要不是技术问题，而是制度分配问题。以下几种结果最值得参考。受监管的增强型均衡。这是我认为概率最高的一种。AI 大幅提高知识工作的吞吐量，企业减少部分中低层岗位，但培训、转岗、职业认证、便携福利和劳动协商跟上，生产率收益部分回流给劳动者。对芯片行业来说，这意味着团队更小、项目更快、entry-level 更少，但工程职业本身不会消失。ILO 和 Anthropic 都在往这个方向提示：多数岗位更可能被重构，而不是整体冗余。寡头自动化与“永久底层”。这是我们上面虎嗅《永久底层》文章最担心的情景，也是现实中最不能低估的风险：模型公司、云厂、资本和核心 IP 持有者拿走大部分收益，中层知识岗位被长期压价，很多人退化成“AI 监督员”“低价承包者”或间歇性就业者。如果社会补偿和再分配严重滞后，这就会演化成稳定的 underclass。Anthropic 已经把 automation tax、sovereign wealth fund、social services 等讨论摆上台面，本身就说明这个情景并非幻想。强烈反弹与部署减速。如果失业、降薪、入行门槛关闭和社会不满快速上升，很多国家会走向更严格的 licensing、责任追究、行业准入、强制 human sign-off、工会合同和高风险用途限制。芯片行业尤其可能走这条路，因为芯片、算力、制造设备和网络安全本来就是战略基础设施。这样一来，AI 不会消失，但会被更像“核设施”而不是“普通 SaaS”那样对待。危机后再分配与新社会契约。如果前期冲击足够痛，政治系统最后往往会被迫重新分配 AI 租金，包括自动化相关税、公共基金、主权财富基金、面向 care economy 的岗位扩张、以及把算力收益部分社会化。这条路的前提不是技术善意，而是冲突已经大到“非解决不可”。现在一些政策文件已经把“automated labor taxes”“care and connection economy”“AI jobs transition framework”放入讨论范围，说明这种再契约并非遥不可及。我的基线预测是：到 2026–2032 这一段，芯片行业的结局不会是“没有工程师”，而会是“更少的 junior、更薄的 middle、更多由 AI-native senior 工程师带着 agents 完成的项目”。换句话说，真正会被淘汰的不是“工程师”这个职业本身，而是那些只提供可模板化、可验证、可复制劳动的人。如果社会没有把收益分给大多数人，文章里说的“永久底层”就会从修辞变成现实；如果分配机制跟上，AI 就会成为一种提高工程和社会产出的基础设施，而不是把多数人扫地出门的装置。最终决定权，不在模型参数里，而在制度、议价和分配里。开放问题与局限有三点需要坦白。第一，半导体细分岗位级的公开失业数据，到今天仍然远少于软件行业，所以我对“具体哪类芯片岗会先被裁掉多少”只能做结构性判断，不能给出高置信度的精确数字。第二，很多 EDA 厂商提供的 uplift 数字属于 vendor 或客户案例，方向非常可信，但幅度在不同公司、流程成熟度和项目类型之间会差很多。第三，你附的文章更适合当作“风险感受和问题意识”的放大镜，而不应被当作所有细节都已独立证实的事实总表。近期外部报道可作补充参照：- theguardian.com  //* ‘Wake up to the risks of AI, they are almost here,’ Anthropic boss warns- investopedia.com  //* Anthropic Study Reveals Which Jobs Are Most Exposed to Real-World AI Risks- businessinsider.com  //* Companies laying off staff this year include Meta, Amazon, and Oracle — see the list更多关于PCIe, NVMe, SATA, SSD, CXL等的测试工具和技术，请下载Saniffer公司2026.2.24最新更新的白皮书15.1版本 - PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1-low resolution.pdf（低分辨率版本，file size: 63MB）；需要高清图片pdf版本的请参见本文底部的联系方式联系我们获取（file size: 204MB)链接: https://pan.baidu.com/s/1R-tJEqwBlzBaDR0WLuMU0Q?pwd=9av3 提取码: 9av3如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。

今天正在美国举行的2026年度PCI-SIG开发者论坛对于业内关注PCIe 6.0的朋友非常重要，看过我们写的针对PCIe 6.0测试工具白皮书的朋友知道，PCIe 6.0自从2022.1正式发布以来，经过5次小规模PCIe 6.x PRE-FYI workship + 今年4月份的一次re-test，今天总算正式认证了PCIe 6.0 协议层兼容性测试（CTS）供应商，SerialTek成为PCI SIG正式批准的Gold Suite approved for PCIe 6.0 Link and Transaction Layer Endpoint Testing。2026年5月6日至7日，圣克拉拉会议中心， 加利福尼亚州2026年PCI-SIG®开发者大会将于2026年5月6日至7日提前回归圣克拉拉！PCI-SIG社区的成员——包括系统架构师、设计师、工程师及工程经理——一致认为，这是一场您绝不容错过的盛会。PCI-SIG开发者大会是一项专为本组织900多家成员公司举办的免费活动；这些成员公司致力于开发并向市场推出采用PCI Express®技术的新产品。本次大会为您提供了一个绝佳的机会，让您可以直接向业界顶尖的PCIe®专家请教，并参与各类技术培训，从而掌握最佳实践，进而有效提升产品的上市效率与互操作性。PCIe 6.0 正式进入“官方 CTS 合规时代”：为什么这对所有服务器、AI、SSD、NIC、Switch、GPU 厂商都极其重要？最近，PCIe 6.0 测试领域迎来一个非常关键、甚至可以说具有“里程碑意义”的消息：SerialTek 正式获得 PCI-SIG 批准，成为 PCIe 6.0 Link Layer（链路层）和 Transaction Layer（事务层）Compliance Testing（CTS 协议兼容性测试）的官方授权测试平台。这意味着：SerialTek Kodiak™ PCIe 6.0 Protocol Test System 已正式进入 PCI-SIG 官方 PCIe 6.0 协议兼容性测试生态。对于当前整个 PCIe 6.0 产业链——包括：AI GPUSSDSmartNIC / DPUPCIe SwitchFPGACXL设备高速服务器平台主板与系统厂商这都是一个极其重要的信号。因为它意味着：PCIe 6.0 正式从“研发调试阶段”，进入“标准化合规验证阶段”。一、为什么 PCIe 6.0 CTS 如此重要？很多工程师知道 PCIe 6.0 很快：PAM4FLIT 模式FEC64 GT/s更复杂的 LTSSM更严苛的时序与误码要求但是很多人其实忽略了：PCIe 真正难的，从来不是“跑起来”，而是：跨厂商稳定互通。尤其到了 PCIe 6.0 后：Root ComplexEndpointSwitchRetimerCXL Device之间的组合已经极其复杂。过去 PCIe 4.0/5.0 时代，一些系统“偶尔掉链路”、“训练失败”、“Recover 卡死”、“Uncorrectable 暴涨”，很多时候还能靠经验、Firmware Patch、Retry、降速解决。但 PCIe 6.0 不一样。因为：PCIe 6.0 已经进入“误差预算极其有限”的时代。任何协议层、链路层细节实现差异，都可能导致：建链失败LTSSM异常Recovery反复震荡Replay异常FLIT错误FEC恢复失败DLLP/TLP处理异常长时间运行后掉链高负载下随机错误所以：CTS（Compliance Test Suite）已经不是“加分项”，而是“入场券”。二、PCI-SIG 官方批准意味着什么？这次最核心的内容是：SerialTek Kodiak 已获得 PCI-SIG 官方 Gold Suite Approval即：官方批准其用于 PCIe 6.0 协议层 CTS 测试。这不是普通“支持 PCIe 6.0”。而是：PCI-SIG 正式认可：该平台能够执行 PCIe 6.0 Compliance Test Specification（CTS）规定的官方协议兼容性测试。PCI-SIG 在新闻稿中特别提到：测试设备厂商需要提交正式 MOI（Method of Implementation），并经过严格验证。 必须证明其能够正确执行所有要求的 Compliance Test，并准确输出 pass/fail 结果。换句话说：这并不是“厂商自己说支持 CTS”。而是：PCI-SIG 官方审核通过。这对于整个产业链意味着：更统一的测试标准更可信的测试结果更稳定的跨厂商互通更高质量的 Integrators List（集成商列表）更高的客户采购信心三、为什么这对于 PCIe 6.0 市场是划时代事件？因为：PCIe 6.0 是历史上第一次如此复杂的 PCIe。它不仅仅是速率翻倍。而是：PCIe 5.0PCIe 6.0NRZPAM4无FEC引入FEC普通 TLPFLIT Mode较简单误码模型极复杂误码恢复较宽 Margin极窄 Margin这意味着：过去很多“看起来能工作”的设备：到了 PCIe 6.0 后， 可能已经“不是真正兼容”。因此：官方 CTS 的价值被空前放大。四、SerialTek Kodiak 为什么越来越被关注？近年来，PCIe 6.0 圈子里，SerialTek Kodiak 的曝光度越来越高。尤其在：PCI-SIG FYI WorkshopPre-FYIAI GPU互通测试SSD兼容性验证Retimer调试CXL bring-up高速服务器验证中，越来越频繁出现。原因其实很现实：PCIe 6.0 已经不是传统“协议分析仪”能轻松应对的时代。SerialTek 这次官方新闻稿里面，其实透露了几个非常关键的技术点：1）64 GT/s 下的 deterministic capture（确定性抓包）PCIe 6.0 最大的问题之一：流量太大。很多传统平台：抓不久Buffer不够丢包Trace处理慢分析效率低而 Kodiak 强调：deterministic capture高速处理深 Trace Buffer最长 8 TB 内部存储这对于：AI训练服务器GPU集群大规模NVMe长时间稳定性验证非常关键。因为很多 PCIe 6.0 问题：根本不是“瞬时问题”。而是：跑几个小时、几天后， 才随机触发。2）Protocol + Link Behavior 全栈可见性这次官方新闻稿特别强调：Full-stack visibility即：不仅能看 TLP/DLLP。还要：看链路行为。因为 PCIe 6.0 的很多问题：实际上是：RecoveryEqualizationFLITReplayFECLTSSM共同作用。传统“只看协议包”的时代已经过去。3）Quarch 集成功耗分析新闻稿里面一个非常容易被忽略、 但实际上极其重要的点：Quarch integrated power analysis这意味着：协议分析 + 功耗行为， 已经开始融合。这在：SSDCXLAI服务器GPU系统里非常关键。因为很多 PCIe 6.0 问题：其实是：Power Integrity + Protocol 联合问题。例如：掉链瞬时恢复Surprise DownLTSSM异常可能都和：电流尖峰电源波动热行为有关。五、PCIe 6.0 官方 CTS 时代已经到来过去几年， PCIe 6.0 更多还处于：实验室Bring-upPre-FYI原型验证阶段。但这次 SerialTek 获得 PCI-SIG 官方批准，实际上释放了一个非常重要的行业信号：PCIe 6.0 正在正式进入规模化合规验证阶段。这意味着：未来：CPUGPUSSDSmartNICSwitchRetimerAI服务器厂商，都必须更加重视：官方 CTS Compatibility Testing。六、为什么中国市场尤其需要关注？目前中国：AI服务器GPUSSDDPUCXL高速交换国产CPU都在快速推进。但 PCIe 6.0 的核心难点：已经越来越不是“做出来”。而是：能否稳定通过 PCI-SIG Compatibility Ecosystem。而 CTS 平台， 正是其中关键基础设施。七、SerialTek 在 PCIe 6.0 时代的重要性正在快速上升过去很多工程师提到协议分析仪， 首先想到的是：“抓包”“协议解码”但在 PCIe 6.0 时代：协议分析平台已经开始变成：系统级验证基础设施。尤其：CTSComplianceInteroperabilityLong-run stabilityAI服务器验证CXL验证正在成为未来几年最核心的需求。而此次：PCI-SIG 官方批准 SerialTek Kodiak 作为 PCIe 6.0 CTS 平台，对于整个行业， 是一个极其重要的里程碑。小结PCIe 6.0 的真正挑战， 已经不只是“速度”。而是：在 64 GT/s + PAM4 + FLIT + FEC 的复杂体系下，实现跨厂商长期稳定互通。这也是为什么：CTS（Compliance Test Suite） 在 PCIe 6.0 时代的重要性， 远远超过过去几代 PCIe。而 SerialTek 此次正式获得 PCI-SIG 官方批准，意味着：PCIe 6.0 官方协议兼容性测试生态，已经开始真正成熟。对于：AI服务器SSDGPUSmartNICCXL高速互连研发团队来说，这绝对是一个值得重点关注的重要行业事件。更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2026.1.6最新更新的白皮书15.1版本 - PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1-low resolution.pdf（低分辨率版本，file size: 63MB）；需要高清图片pdf版本的请参见本文底部的联系方式联系我们获取（file size: 204MB)链接: https://pan.baidu.com/s/1R-tJEqwBlzBaDR0WLuMU0Q?pwd=9av3 提取码: 9av3如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。

昨天读到一篇文章读《NAND闪存技术》：从 Vt、disturb 到 SSD 系统约束，我想在该文章的基础上，结合Saniffer公司在这方面的经验，对于文中谈到的中文版《NAND闪存技术》，英文版为《NAND Flash Memory Technologies (author: Aritome, Seiichi)》书中涉及到的大量的NAND FLASH的各种特性，来介绍一下业内是如何来测试这些特性并进行分析的，对于这本书感兴趣的也可以买来看看，对于业内从事涉及闪存NAND FLASH相关产品研发、测试、应用、支持的朋友拓展知识面有很多帮助，不过这本中文版是2025.2发售的，不知道它是翻译的英文版本的哪个年份的，亚马逊只有这本英文版的较早2015年的paperback 纸面书，我买的中文版《NAND闪存技术》还在运输途中，了解的朋友可以本文底部留言说一下。从《NAND闪存技术》讲起：为什么 NAND 需要被认真测试？这篇文章《读〈NAND闪存技术〉：从 Vt、disturb 到 SSD 系统约束》，里面有一句话非常值得 SSD、存储系统、硬件测试工程师反复咀嚼：很多 SSD 系统层的问题，本质上并不是从 FTL、ECC 或固件策略才开始的，而是早已埋在 NAND cell、阈值电压 Vt、隧穿氧化层、电子注入、读写扰动和 3D NAND 结构差异之中。Seiichi Aritome 所著的 NAND Flash Memory Technologies，中文版《NAND闪存技术》，正是一本从器件底层解释 NAND 行为的书。它并不是一本 SSD 控制器开发手册，而更像一本帮助工程师理解“为什么 SSD 会有这些限制”的底层地图。书中覆盖 NAND 发展历史、cell 结构、读写擦原理、多位单元、scaling 挑战、可靠性、3D NAND 以及未来趋势等内容；作者在前言中也特别说明，这本书不仅面向 NAND 器件开发人员，也适合 NAND 用户、SSD 工程师、应用工程师、技术经理、新工程师和研究生阅读。这也正是今天这篇文章想讨论的问题：当 NAND 已经进入 3D TLC / QLC 主流时代，尤其是 QLC 正在大量进入企业级 SSD、AI 存储、数据中心和消费级 M.2 SSD 市场时，我们如何用测试手段把 NAND 的“不可见特性”变成可测、可分析、可优化的数据？一、读懂 NAND，首先要读懂 VtNAND Flash 存储信息，本质上是通过 floating gate 或 charge trap 中的电荷改变 cell 的阈值电压 Vt。SLC 只需要区分 2 个状态，MLC 区分 4 个状态，TLC 区分 8 个状态，而 QLC 要区分 16 个状态。状态越多，单位容量越高，但每个状态之间的 read window margin 就越窄。这就是为什么 QLC 容量大、成本低，但对 SSD controller、LDPC、读重试、读阈自适应、磨损均衡、数据保持和温度补偿提出更高要求。表面上看，SSD 工程师面对的是 RBER 上升、读延迟变长、读重试次数增加、性能 QoS 波动、寿命缩短；再往下看，其实是 Vt 分布在 P/E cycling、retention、read disturb、program disturb、温度变化和层间差异下发生了漂移。换句话说，SSD 固件算法不是在管理一个理想的数字介质，而是在驯服一个持续漂移、老化、受温度影响的模拟物理系统。二、QLC 热潮背后：低成本每 TB 与高可靠性之间的拉扯过去十多年，NAND 从 SLC、MLC、TLC 走到 QLC，核心动力一直是降低 bit cost。3D NAND 又通过垂直堆叠继续提高容量密度。Aritome 书中也提到，3D NAND 的量产推动了基于 NAND 的高性能、低功耗 SSD 持续发展。但是，QLC 的工程难度也非常现实。已有资料中总结得很直白：QLC NAND 的使用不仅出现在数据中心、云计算中心和 AI 智算中心，也会因为价格、良率和市场供需等因素进入普通 M.2 SSD；但 QLC 的 endurance、RBER 和可靠性压力，要求 SSD controller 厂商必须做更深入的 NAND 特性分析，否则容量和成本优势很容易被读写错误、性能波动和寿命问题抵消。所以，QLC 时代真正关键的问题不是“能不能点亮 NAND”，而是：能不能知道不同 P/E 次数后 Vt 分布如何移动？ 能不能知道高温保持后 RBER 如何变化？ 能不能知道 read disturb 在哪些 page、WL、layer、plane 上更明显？ 能不能知道 2.4 GT/s 实速下 DQS timing margin 还剩多少？ 能不能知道 P/E/read 操作的电流尖峰会不会影响 SSD 供电设计？ 能不能把这些数据转化成 LDPC、read retry、media management、功耗策略和筛选策略？这就是 NAND Characterization 的价值。三、NanoCycler：把 NAND 的“器件行为”变成可测数据NplusT 是一家位于意大利的公司，成立于 2002 年，创始人为 Tamás Kerekes。公司长期聚焦非易失性存储测试、NAND user mode characterization、可靠性测试和 burn-in，并具备硬件、FPGA、嵌入式软件、数据库、统计分析和用户体验等研发能力。NplusT 的 NanoCycler 被官方定义为 One Stop NAND Characterization 平台，目标是帮助高性能 SSD 和其他基于 NAND 的存储设备完成 NAND 探索、SSD 设计所需的核心数据提取，以及 NAND 器件在装配前的可靠性、功能和性能筛选。它的价值可以概括成三句话：第一，按真实应用速率测试 NAND。NanoCycler 支持最高 2.4 GT/s 的 at-speed characterization，让被测 NAND 在接近实际 SSD 应用的环境中运行。第二，把错误学、功耗、时序和温度放在同一个平台里看。它支持 aging/endurance、retention、working window、RBER monitor、distribution analysis、optimal read conditions、DQS timing margin analysis、power profiling、timing characterization 等功能。第三，用并行架构提高统计意义和测试效率。NanoCycler 每个 package 可以独立运行测试，在 test flow、温度、电压、频率等条件上互不影响；系统可从单 package 扩展到 84-site rack，多机还可级联并共享中央数据库。四、NanoCycler 能对应测试《NAND闪存技术》中的哪些核心问题？如果把《NAND闪存技术》当作一本 NAND 机理地图，那么 NanoCycler 就像是一套把这些机理“落到实验数据”的工具。书中强调多位单元需要 tight Vt distribution，因为 Vt 分布宽度直接决定 read window margin；NanoCycler 可做 distribution analysis、optimal read conditions、RBER monitor，用于分析不同状态分布、读阈选择和原始误码率变化。书中把 P/E cycling、data retention、read disturb、program disturb、erratic over-program 等可靠性问题作为核心章节；NanoCycler 对应支持 aging/endurance、retention、disturb 相关测试和 error recovery flow trigger rates，帮助 SSD 团队将这些器件层退化机制转化为可量化指标。书中讨论 3D NAND 带来的 RC delay、poly-Si channel、层间差异和功耗等新约束；NanoCycler 和 BarnieMAT 可以结合整页 bitmap、fail distribution per layer、topologic view of fails、Vt distribution、BER trend 等方式观察 3D NAND 在 layer、WL、page、block 维度上的差异。这就形成了一条非常清晰的链路：书中讲 Vt、disturb、retention、endurance、3D NAND 约束；NanoCycler 负责把这些现象测出来；BarnieMAT 负责把海量测试数据变成工程师看得懂、能决策的图。五、NanoCycler 适合哪些工程场景？对于 SSD controller 公司，NanoCycler 可用于 LDPC/ECC 算法优化、读阈策略、read retry 策略、media management 策略、坏块坏页筛选、QLC 适配和供应商 NAND 横向比较。对于 SSD drive 厂商，它可用于来料评估、批次差异分析、温度/电压容限、实速接口 margin、功耗尖峰分析、失效复现和量产筛选策略制定。对于高校和研究院所，它可以把 NAND 研究从“现象描述”推进到“可重复实验”：例如 RBER vs P/E cycle vs retention time vs temperature，层间差异、读扰模式、Vt shift、tail bit 位置追踪、3D NAND topology fail map 等。已有资料也明确指出，寿命期错误学、整页位图、0→1/1→0 错误方向分离，可以支撑 3D 层间与平面内差异、邻近耦合与读扰机制研究。对于失效分析工程师，NanoCycler 的价值不只是“测坏了没有”，而是帮助回答：为什么坏？坏在哪个层？哪个 WL？哪个 page？是 retention 造成的，还是 disturb 造成的？是 NAND cell 本身的问题，还是接口 timing margin、供电尖峰、温度条件诱发的问题？六、功耗与高速接口：NAND 测试不只是 RBER很多工程师谈 NAND 测试，第一反应是 BER、RBER、ECC、Vt distribution。但在现代 3D NAND 和高速 SSD 中，功耗和信号完整性同样关键。NanoCycler 官方资料显示，它可以在每路电源上以 50 ns 采样率、1 mA 分辨率捕获功耗波形，并可统计长时间操作过程中的平均电流和峰值电流；同时，它还支持 1 ns edge placement、20 ns response time detection，以及 ps 级 DQS alignment window 信息。这对于 SSD 硬件工程师很重要。因为 NAND 的 program、erase、read 操作会产生电流尖峰；多个 die、LUN、plane 并行操作时，尖峰可能叠加，进一步影响 PMIC、去耦、电源轨设计和整机稳定性。上传资料中也特别指出，理解 NAND timing 和 current profile 对于电源调节器设计、仿真、校准，以及避免电流尖峰对齐非常关键。所以，一套真正有价值的 NAND Characterization 平台，不应该只看错误率，也要同时看：RBER 怎么变； Vt 分布怎么移动； 读阈怎么选； 功耗尖峰在哪里； DQS window 还剩多少； 温度、电压、老化和并行操作会如何共同影响结果。七、BarnieMAT：从“测到数据”到“看懂数据”NAND 测试最大的难点之一，不是没有数据，而是数据太多。一个 NAND array 的数据天然带有空间结构：block、page、WL、BL、layer、plane、die、LUN。只看一串 CSV 或平均 BER，很多关键信息会被抹掉。NplusT 的 BarnieMAT 正是为这类 array-based component 数据分析设计的软件。官方介绍中提到，BarnieMAT 可将大量测试数据转化为人脑可以理解的信息，提供图形化框架、快速 array processing、适配多级单元和 3D 结构、Python 自动化分析、API、Python library、remote control port 和 SDK 等能力。它内置大量分析功能，包括 map-to-distribution、cell-by-cell differential map、fail count from multiple arrays、Vt average per wordline、block fail density、fail count per page、neighbor bit failure、distribution tail cell trace-back，以及 SQL-like table processing。展示能力则包括 array topologic view、2D/3D distribution、关键 cell 标记、实时分布统计和丰富图表。在 NanoCycler + BarnieMAT 的组合里，NanoCycler 更像“显微镜 + 实验平台”，BarnieMAT 则像“数据解剖台”。前者把 NAND 的真实行为测出来，后者把这些行为以 Vt distribution、BER trend、fail map、layer distribution、read retry option analysis、power profile 等方式呈现出来。八、推荐阅读：《NAND闪存技术》如果你是 SSD 固件、硬件、验证、测试、失效分析工程师，或者是高校、研究院所从事存储、半导体、计算机系统研究的老师和学生，强烈建议读一读 Seiichi Aritome 的 NAND Flash Memory Technologies，或者中文版《NAND闪存技术》。这本书最有价值的地方，不是教你某一个 SSD 算法，而是让你理解：为什么 NAND 必须按页写、按块擦；为什么 P/E cycling 会影响 retention 和 disturb；为什么 QLC 更依赖读阈优化和 ECC；为什么 3D NAND 不是简单叠层，而是引入了新的电气、工艺和可靠性约束。读完这本书，再看 NanoCycler 这类 NAND Characterization 设备，会更容易明白：这不是一台“普通 NAND 测试仪”，而是一套把 NAND 器件物理、可靠性、SSD 算法和系统设计连接起来的研发平台。结语：更好的 SSD，来自更早看见 NAND 的真相今天的 NAND，尤其是 3D QLC NAND，已经不是“能读能写”就够了。真正的问题是：在高温、低温、老化、保持、读扰、写扰、高速接口、电源尖峰、多 die 并行和真实 SSD 工作负载下，它还能不能稳定、可预测、可管理？这也是 NanoCycler 和 BarnieMAT 这类工具的价值所在：它们让 NAND 的 Vt、RBER、disturb、retention、endurance、timing margin、power profile 和 topology fail pattern 不再停留在论文、书本或经验判断中，而是变成可以测量、可以分析、可以指导产品决策的数据。如果您正在从事 NAND Flash、3D NAND、QLC NAND、SSD controller、SSD 固件、LDPC/ECC、SSD 验证测试、来料筛选或失效分析相关工作，欢迎访问 saniffer.cn，或关注 Saniffer 公众号，留言交流 NanoCycler、BarnieMAT 以及 NAND Flash 特性测试解决方案。我们也欢迎高校、研究院所和企业研发中心一起探讨 NAND 测试、QLC 可靠性分析和 SSD 研发验证中的真实工程问题。对于NAND FLASH以及各类新型存储技术的测试，NplusT公司提供了非常成熟的各类测试方案，如果大家下周去比利时参加IMW 2026 (international memory workshop)国际会议的话，不要忘记访问一下NplusT公司展位。更多关于PCIe, NVMe, SATA, SSD, CXL等的测试工具和技术，请下载Saniffer公司2026.2.24最新更新的白皮书15.1版本，其中针对NAND和各类新型存储技术NVM请参见chapter 7.1&7.2 - PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1-low resolution.pdf（低分辨率版本，file size: 63MB）；需要高清图片pdf版本的请参见本文底部的联系方式联系我们获取（file size: 204MB)链接: https://pan.baidu.com/s/1R-tJEqwBlzBaDR0WLuMU0Q?pwd=9av3 提取码: 9av3如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。

我们Saniffer公众号前面几年经常提到业内碰到的SSD掉盘的问题，有些影响面和波及面非常广，各种各样的问题，这其中有些我们通过PCIe协议分析仪串在链路中间抓取双向流量进行分析得到原因，有些则通过一些工具主动“激发”出问题从而推测出问题的所在。我们今天在这里总结一下SSD掉盘到底有哪些原因，还有哪些原因是工程师不怎么想得到的。什么是“掉盘”？“掉盘”在工程上几乎从来都不是一个单点故障名词。它通常是控制器固件、PCIe/NVMe 协议状态机、低功耗链路状态、热插拔/复位时序、供电完整性、背板或 retimer、中间管理通道，以及 BIOS/OS 驱动策略共同作用后的外在现象。NVM Express 规范明确给出了 APST、Keep Alive、CSTS.CFS 等机制；Linux 内核与 微软 StorNVMe 文档又说明了主机侧是如何参与这些状态转移的。这意味着：很多“盘坏了”的现场，根因其实并不在 NAND（当然，如果真的是NAND Flash坏了，我们可以通过NplusT公司的NanoCycler做一些失效和特性分析），而在盘能不能被重新枚举、能不能按预期退出低功耗、能不能在异常电源与复位序列下完成链路训练。公开案例显示，掉盘高发的根因并不神秘，反而很集中：深度低功耗/APST 唤醒失败、电压处理/电源时序缺陷、背板/retimer/sideband 通讯异常、控制器/HBA 固件异常或异常恢复路径不健壮、平台 BIOS/驱动与 SSD 固件组合不匹配。从 戴尔 的 Micron 2200S “No Drive Detected/STOP Error”，到 联想 的 Kioxia BG5 永久不可见，再到 慧与 UBM6 背板“Removed/Inserted”抖动，以及 思科 对 NVMe/SATA SSD“improper voltage handling”的现场通报，模式都非常一致：先掉枚举，再谈介质。真正被 99% 团队忽略的，不是“有没有升级过 firmware”，而是有没有把协议、sideband、功耗、拓扑、管理面日志在同一时间轴上对齐。单看 SMART 不够，单跑 fio 不够，单盯协议抓包也不够。最短诊断路径通常是：协议抓包 + sideband 采样 + 电源扰动复现 + 主动工作负载四线并举。以 SerialTek、Quarch、SanBlaze、Serial Cables 这四类工具组合为例，已经足以把绝大多数掉盘问题压缩到某一层：协议、链路、供电、热插拔、还是平台软件。可以先记住五个结论。其一，低功耗最危险：APST、ASPM L1/L1.2、CLKREQ#、PERST#、WAKE# 的组合，是最容易被误判为“随机坏盘”的区域。其二，热插拔不是插上能认盘就算过：必须在 I/O 压力、管理面轮询、固件升级、异常掉电与 retimer/backplane 参与时验证。其三，控制器异常恢复路径必须当正式功能测试，而不是靠线上用户替你回归。其四，上线前测试一定要覆盖真实拓扑，包括 M.2、U.2/U.3、EDSFF、直连、经 switch、经 retimer、单口/双口。其五，生产监控必须先盯“枚举与链路健康”，再盯温度与 SMART。说明：本文提到的相关产品均来源于网络公开信息。掉盘真正发生在哪里把 SSD 掉盘拆开看，本质上是在问：它死在了哪一层。NVMe 规范说明，主机可以通过 APST 让控制器自动转入非工作电源状态；如果控制器在唤醒时不能按它自己宣称的延迟返回，主机就会把它视为超时、失联或需要 reset。规范还明确写到：Keep Alive Timer 过期会记录 Error Information Log，并把 CSTS.CFS 置位；而 CSTS.CFS 代表严重错误，主机应尝试 Controller Reset，如果再不清，再考虑更激进的 NVM Subsystem Reset。更麻烦的是，规范同时警告：Subsystem Reset 可能导致 PCIe 链路掉下去，一些 OS 或 hypervisor 甚至会因此崩。这也是为什么“低功耗掉盘”如此隐蔽。金士顿 A2000、Solidigm P44 Pro，以及中国市场常见的京东上可以买到的某款M.2 SSD，公开内核修复都直指最深电源状态退出失败：盘在最深 sleep state 之后变得 whole disk unresponsive，修复方法不是换 NAND，而是先禁止最深 power state或更新固件/内核 quirk。换言之，工程上首先要怀疑的是ENLAT/EXLAT 报告、APST 配置、L1/L1.2 sideband 协议、以及 PERST#/CLKREQ#/WAKE# 时序，而不是先宣判“闪存寿命完了”。主机侧同样是因子，而不是背景板。StorNVMe 文档明确说明，Windows 会根据 ENLAT+EXLAT 与当前容忍延迟来挑最深可接受 power state；微软给现代待机场景的建议甚至明确到：StorNVMe 不支持 APST enabled 的设备用于 Modern Standby。Linux 则把 ASPM 的 L0s/L1/L1.1/L1.2 暴露成 sysfs 开关，并提供 per-device reset/remove/rescan 接口用于排障。这说明：同一块 SSD 在 A 平台不掉、在 B 平台掉，并不奇怪；主机 BIOS、ACPI、电源策略、驱动与内核 quirk 会直接改变你看到的现场。更容易被忽略的是“盘外掉盘”。联想公开的控制器/适配器变更记录里，直接写过“NVMe drive missing after few Lane/Phy glitches between PCIe switch downstream port and Endpoint”“drive missing status even when drive is present”“FW exception during reboot of a server with PCIe gen5”“heavy IO + NVMe passthru from OOB after 5–8 hrs hit KA”这类问题。也就是说，盘从 OS 视角消失，根因可以在switch、retimer、HBA/RAID FW、OOB 管理、MCTP/NVMe-MI 通道，甚至恢复路径本身。把掉盘只当 SSD 介质问题，是许多团队的第一层误判。下面这张图，是本文建议的分层思维框架。它不是规范原图，而是对公开案例和工具链能力的工程抽象。全球真实案例库公开证据主要来自 镁光、英睿达、铠侠、三星 等 SSD/存储厂商，和 戴尔、联想、惠普、思科 等平台/OEM 的官方支持公告；下表还补充了开源内核公开修复记录。需要坦诚说明的是：绝大多数公开案例不会披露厂内实验室到底用了哪台仪器。因此，表中的“诊断工具”分成两层：公开诊断线索与建议复盘工具。后者是基于故障机理给出的最佳最短路径，不代表厂商公开确认使用过这些品牌设备。除了表中的“显性掉盘”，还要特别留意那些还没真正消失、但已经在边缘的征兆。较新的公开发布件里，Solidigm P44 Pro 被 Linux 内核加入 “NODEEPESTPS” quirk；联想控制器变更记录则记载了“lane/phy glitch 后 drive missing”“MCTP request failed with drive missing status even when drive is present”“PCIe gen5 reboot 时 FW Exception”“bad Phy/链路降速”等问题；戴尔某些企业 NVMe 固件发布说明则把“thermal shutdown behavior”“PERST handling”“invalid command handling”“OOB command during shutdown”列为修复项。这些都说明：掉盘不是突发事件，而是很多边缘征兆长期未被监控后的最终形态。工具化诊断流程工作流一：怀疑 APST、ASPM L1/L1.2、resume/idle-wake 导致的间歇性掉盘。第一步，不要一上来“更新到最新再看”，而是先冻结现场：记录 BIOS、SSD FW、OS、驱动/内核、ACPI/电源计划、是否启用 Modern Standby、当前 ASPM/L1.1/L1.2 配置。第二步，用 SerialTek 在“进入空闲—触发唤醒—重新训练—掉盘/恢复”的窗口抓LTSSM、DLLP/TLP、Config Space 历史变化；Quarch 同步抓电源轨迹与 sideband，重点盯 CLKREQ#、 PERST#、 WAKE#、SMBus/NVMe-MI 活动。第三步，分别做 A/B 试验：关闭最深 APST、限制 power-state latency、关闭可疑 L1.x、再与原始配置对照。如果关掉最深 PS 后现象消失，你就基本锁定了“盘或平台在低功耗退出路径上不成立”，而不是“盘体随机坏”。工作流二：怀疑热插拔、背板、retimer、switch 或 sideband 交互。第一步，把问题从“某台机器偶发掉盘”重构成“某个拓扑下可复现的枚举失效”：直连、经 retimer、经 switch、不同槽位、不同线缆/背板、不同双口/单口配置都要分开。第二步，用 Serial Cables 的测试底座把每槽上电顺序、presence、热插拔、slot telemetry、NVMe-MI/MCTP纳入自动化矩阵；Hydra 一类平台本身就支持 per-slot power sequencing、hot-plug simulation、温度与功耗遥测、NVMe-MI/MCTP 访问。第三步，用 Quarch 做brownout、glitch、ramp、fault injection、pin timing 复现；如果问题只在“高 I/O + 热插拔”“高 I/O + OOB 轮询”“重启 + firmware flash”“功率波动 + presence bounce”这几种组合下出现，那么根因多半已不在纯协议层，而在协议层与平台电源/sideband/拓扑的交界面。工作流三：怀疑控制器固件 assert、exception handling 或 OOB/Keep Alive 路径。第一步，用 SanBlaze 主动加载工作负载，而不是只等用户业务复现。它的 PCIe Gen5 RM5/DT5 平台本身就具备read/write/compare、error injection、custom opcode、NVMe-MI over SMBus、power on/off、hot-plug 与 drive presence under software control、per-drive voltage/power measurement能力，适合把“边干活边出错”的路径系统化复现。第二步，把前台 I/O 与后台管理动作用矩阵化方式并发：命名空间操作、Firmware Download、sanitize、NVMe-MI 轮询、日志抓取、OOB passthrough。第三步，SerialTek 负责看哪一拍开始偏离规范，Quarch 负责看那一拍前后有没有 rail、reset、sideband 异常，SanBlaze 负责保证故障并不是随机流量造成的偶然现象。第四步，一旦怀疑进入 CSTS.CFS 或 Keep Alive 失效，恢复梯度要保守：先 Controller Reset，再评估是否值得做更激进的 NVM Subsystem Reset；不要把 NSSR 当成通用治疗手段，因为规范已经明确说过它可能让 PCIe links go down，并对某些 OS/hypervisor 造成不良影响。最有价值的采集物不是更多日志，而是更好的时间轴。建议所有实验都固定输出同一套证据包： SSD FW、 BIOS/driver/kernel、 IdentifyControllerpower-state table、 AER/PCIeerror、 NVMeerror log、 OOB logs、 SerialTek PCIe trace、 Quarchpower+sideband、 SanBlazeworkload script、 SerialCablesslot topology。如果一轮实验结束后，你还不能回答“先掉的是链路、还是电源、还是侧带、还是主机先 reset 了盘”，那就说明这轮实验设计得还不够好。预部署测试计划现实中最贵的掉盘，不是实验室重现不了的那个，而是根本没被纳入预部署验证矩阵的那个。公开资料已经足够说明这件事：SanBlaze 的 NVMe 平台面向 development、QA、qualification、manufacturing test；支持 NVMe-MI、conformance、error injection、power control、per-drive measurement；Quarch 提供 margining、power loss、brownout、glitch、sideband capture；Serial Cables 提供多槽位、热插拔、每槽供电与 NVMe-MI/MCTP；SerialTek 则负责把 LTSSM/TLP/DLLP/config 变化一次抓全。把这四者组合起来，已经能覆盖大多数“上线前就该发现”的问题类型。要特别强调三条实施原则。第一，用真实拓扑做测试，不要只在开发板或直连 AIC 上测完就宣布通过。第二，把管理面流量当成工作负载的一部分，因为 MCTP/NVMe-MI/OOB 与前台 I/O 并发时，恰恰最容易把边界状态打出来。第三，把固件升级路径当成一级功能测试；公开案例已经反复证明，很多掉盘并不是业务负载首发，而是升级、重启、resume 或 power-cycle 首发。如果团队需要一个最小可执行配置，我建议是：一台 Serial Cables 多槽测试底座（例如Gen5 switch卡） + 一套 Quarch PAM/PPM/热插拔模块 + 一台 SanBlaze RM5/DT5 + 一台 SerialTek 协议分析仪。这样你能同时做真实主机下的枚举、工作负载、power margining、热插拔、NVMe-MI/MCTP、以及协议/sideband/功耗三线对齐。对于企业盘，若涉及双口、U.2/U.3、EDSFF、OOB 管理与 OCP 规范，则应继续把 UNH-IOL 和 Open Compute Project 的测试思路纳入脚本与验收口径。修复、监控与行动建议修复掉盘，最忌讳“统一关掉所有低功耗、省事就行”。这只能暂时把问题藏起来，却不能告诉你是谁在低功耗退出时失配。更正确的做法是分层修。协议/固件层，修 ENLAT/EXLAT 报告、修 APST/Keep Alive/reset state machine、修 invalid command/OOB/shutdown 处理、修 thermal shutdown 行为；公开发布件已经反复把这些列为正式修复项。平台软件层，把 BIOS、驱动/IRTS/StorNVMe 或内核 quirk 与 SSD FW 做成套验证，不要相信“只刷盘固件就够”。热插拔与背板层，校正 presence debounce、retimer FW、OOB 管理路径以及 reset sequencing。供电层，对 brownout、rail droop、ramp 与 power-chirp 做边界收敛，而不是仅测 steady-state 功耗。对机械与装配问题，我建议比大多数团队更保守。若故障与特定槽位、温区、弯折、插拔次数、运输/振动、按压动作强相关，就要把 U.2/M.2/EDSFF 连接器接触与焊点当成一等嫌疑。电子封装与焊点可靠性研究早已确认，热循环和机械应力会显著影响焊点微结构与疲劳寿命；而平台发行说明里也不断出现 lane/phy glitches、bad phy、drive present 但被上层判断 missing、链路降速后异常等征兆。工程上应把 AOI、X-ray、温循前后复测、槽位轮转与链路余量问题并行推进，而不是等软件团队“继续跟一版 firmware 试试”。推荐修复动作可以压缩成一个简表：生产监控上，不要只看 SMART。最有效的告警体系，应该先覆盖“有没有开始丢枚举”。Cisco 与 HPE 的公开案例都表明，带外管理面往往比 OS 更早看到 inoperable、 removed、 inserted、 missing；Linux 文档则说明了链路电源状态、ASPM 开关、reset/rescan 等都可被纳入平台可观测面。建议把下面这些对象放进生产告警与值班剧本里。最后，建议把“协议、sideband、功耗、拓扑”这四条证据链，变成平时SSD掉盘的标准排障模板。 只靠替换硬件，你会在同一类故障上反复交学费；只靠改一版 firmware，你会在线上把另一个边界条件放出来。真正能把掉盘率打下来的团队，靠的不是运气，而是复现实验设计。对经常看我们公众号的朋友来说，Saniffer 已公开过一批很有价值的中文资料：包括 Quarch 的 NVMe 热插拔/电压拉偏/功耗测试讲座、PCIe Gen4/5/6 协议分析讲座，以及 SanBlaze NVMe 测试平台介绍，想把本文变成日常SSD失效分析/掉盘培训的一个素材，请关注微信公众号 Saniffer。更多关于PCIe, NVMe, SATA, SSD, CXL等的测试工具和技术，请下载Saniffer公司2026.2.24最新更新的白皮书15.1版本 - PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1-low resolution.pdf（低分辨率版本，file size: 63MB）；需要高清图片pdf版本的请参见本文底部的联系方式联系我们获取（file size: 204MB)链接: https://pan.baidu.com/s/1R-tJEqwBlzBaDR0WLuMU0Q?pwd=9av3 提取码: 9av3如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。

SerialTek公司在2025/8月份，也就是8个月前的FMS闪存峰会上展示了使用其PCIe 6.0训练器模拟PCIe 6.0 RC (CPU端）直接连接Micron PCIe 6.0 E3.S SSD 9650（具体可参考：【专题】全球最全面的 PCIe 6.0/CXL 3.0 测试工具方案探讨汇总），参见下图，我们可以看到Micron E3.S SSD是通过一张SerialCables PCIe 6.0 E3/AIC转接卡转接后插在SerialTek的训练器的PCIe 6.0插槽的。我们今天就来谈谈如何将PCIe 6.0 E3或者E1 SSD转接成插卡或者MCIO cable连接到主机端进行测试。 首先，我们来看看截至今天全球PCIe 6.0搭建测试环境的现状： 2028年底之前大部分公司无法买到PCIe 6.0服务器；参见之前Saniffer的分析文章：PCIe 6.0 与 CXL 3.0 发展现状。 在将近2年缺乏PCIe 6.0服务器的空档期内，唯一可以使用的就是SerialCables公司的PCIe 6.0 switch卡，具体可以参见Saniffer之前拍摄的大量视频，添加Saniffer公众号查询关键词：PCIe 6.0 switch。建议：【高清视频】PCIe 6.0主机卡+Gen6 E3.S转接卡初次使用演示 其中，上述高清视频第一段中，包含了我们拍摄的多个Gen6 switch卡的视频，如下： 我们之前做过很多期PCIe 6.0主机卡（也叫switch卡）的高清演示视频，感兴趣的可以查询一下Saniffer公众号往期文章，或者直接点击下面的连接，包括Gen6 Switch + Switch；Switch + CX-8（一）和（二）；Switch + Quarch故障注入卡 + Switch；Switch + 0.3米延长线 + Switch卡等等；另外，我们也拍摄了如何使用Gen6 switch卡连接Gen6 SSD的几期视频，包括Gen6 switch + MCIO x8 转接2*EDSFF female connector；Gen6 switch + MCIO x8 to 2* MCIO x4 + Gen6 8盘位盘柜，等等。 你在买到SerialCables公司的PCIe 6.0 switch卡之后如何连接PCIe 6.0 EDSFF SSD呢？这个就是今天我们要探讨的主题。你可以使用PCIe 6.0 x8/x16 EDSFF 转接金手指转接卡，或者PCIe 6.0 x8 MCIO转接成2个Gen6 x4 EDSFF female接口来连接PCIe 6.0 SSD。 我们今天的文章较长，大约6000字，总计拍摄了5个高清视频，依次讲解了PCIe 6.0 x8/x16 EDSFF转接卡，以及MCIO x8 to 2个Gen6 x4 EDSFF转接线。 1）SerialCables PCIe 6.0 x8 E3转AIC转接卡高清视频演示 该视频主要围绕PCIe 6.0时代EDSFF设备（尤其是E3.S形态）在当前过渡阶段的实际使用与验证方法展开，可以归纳为以下几层核心信息： 首先，视频介绍了EDSFF设备的基本形态和应用背景。当前常见的是企业级SSD，以及部分CXL内存扩展模块。这类设备本质上是为服务器设计的新一代接口形态，但由于PCIe 6.0服务器尚未普及，实际工程中很难直接在标准平台上使用，因此需要通过转接方案来进行测试与验证。 其次，重点讲了一个非常典型的工程实践：通过EDSFF转PCIe插卡（AIC）的方式，将E3.S设备接入台式机或工作站环境。示例中使用的是PCIe 6.0 x8的EDSFF转接卡，将一块美光的CXL设备（Gen5 x8、双倍厚度）转换为标准PCIe金手指接口，从而插入仅支持PCIe 5.0的主机进行调试。这种方法本质上是当前验证PCIe 6.0设备“最现实可行”的路径。 然后，视频演示了在Linux系统下的识别与链路验证流程。通过 lspci 可以识别到设备（如Micron CXL device），再结合 lspci-t 找到其上游端口，进一步读取链路状态。结果显示链路协商为 32GT/s x8（即PCIe Gen5 x8），这与主机能力（Gen5 x16）和设备能力（Gen5 x8）是匹配的，说明链路训练与协商是正常的。这一段实际上体现了一个关键点：即使是“PCIe 6.0设备”，在现有平台上仍然是向下兼容运行的验证模式。 最后，视频补充了不同类型E3.S设备的对比，包括CXL模组（双厚度）与普通SSD（单厚度）。强调了一个工程上很重要但容易忽视的点：EDSFF的厚度（1T/2T）直接影响内部器件数量，从而影响容量与功能（尤其是CXL内存扩展）。这不仅是机械结构差异，本质上也关联系统设计能力。 一句话总结：这段内容本质是在讲——在PCIe 6.0尚未全面落地的阶段，如何通过EDSFF转接卡 + Gen5主机 + Linux工具链，完成对新一代SSD/CXL设备的识别、链路训练验证和实际工程测试路径。 2）静态介绍SerialCables PCIe 6.0 EDSFF to AIC 各种转接卡 该视频主要围绕 SerialCables PCIe 6.0 EDSFF → AIC 转接卡的结构、类型及测试应用场景展开，整体可以从“形态、接口差异、供电机制、以及测试价值”四个层面来理解。 首先，文档系统性介绍了EDSFF转PCIe插卡（AIC）转接卡的基本作用。在当前PCIe 6.0服务器尚未普及的背景下，这类转接卡成为连接新一代E1.S / E3.S SSD或CXL模组与传统台式机/工作站平台的关键桥梁。其核心思路是：将EDSFF接口设备转换为标准PCIe金手指接口，从而可以直接插入主板PCIe插槽，实现设备初始化、识别与基础验证。 其次，文档详细区分了几种常见转接卡类型： E3.S（Gen6 x8）转接卡：最常见形态，支持将E3.S SSD或CXL模组转为x8金手指插卡，结构上包含标准EDSFF接口和对应尺寸的bracket，安装方式类似服务器插盘但转为PCIe插卡使用。 E1.S转接卡：电气结构基本一致，差异主要在机械结构（bracket和固定方式），适配不同尺寸的EDSFF设备。 x16高带宽转接卡（多见于CXL设备）：支持更高带宽需求，通常采用三段式金手指设计，对应x16链路，适合内存扩展类或高性能设备。 这一部分的核心结论是：不同转接卡本质电气类似，差异主要体现在接口规格（x4/x8/x16）与机械适配结构上。 第三，文档强调了一个非常关键但容易被忽略的设计——外部供电与电源控制能力。这些转接卡普遍具备： 10-pin（5+5）外部供电接口 可连接 Quarch PPM（可编程电源模块） 支持对SSD/CXL设备进行电压拉偏（margining）测试 当使用外部供电时，设备电源不再来自PCIe插槽，而是由外部可编程电源提供，从而可以模拟电压波动、异常供电等复杂场景。这使得该转接卡不仅是“转接工具”，更是电源级验证治具的一部分。 第四，文档介绍了供电模式切换机制。转接卡上通常带有一个开关，用于选择： PCIe插槽供电（默认） ATX/外部电源供电 如果切换到外部供电但未连接电源，设备将无法上电，表现为“系统识别不到盘”。这一点在实际调试中非常关键，也是常见故障来源之一。 最后，文档通过实际操作演示说明，这些PCIe 6.0转接卡完全向下兼容PCIe 5.0设备，可以用于当前环境下的验证工作。例如将Gen5 x4 SSD插入Gen6转接卡，再接入台式机进行测试，这种“跨代验证”是当前工程实践中的常态。 整体总结一句话：这份文档本质是在讲——SerialCables 的PCIe 6.0 EDSFF转接卡不仅解决了“没有Gen6服务器如何测试设备”的问题，同时通过外部供电与可编程电源接口，把它升级成一个集“接口转换 + 电源测试 + 可靠性验证”于一体的关键测试平台组件。 3）SerialCables PCIe 6.0 E3转AIC转接卡+Kioxia E3.S SSD演示 该视频主要围绕一个实际验证场景展开：在普通台式机平台上，通过 SerialCables PCIe 6.0 EDSFF E3.S → AIC（金手指）转接卡，成功接入并识别一块 Dell OEM  KIOXIA 的E3.S SSD（CD7，PCIe Gen5 x4），从而验证转接方案的可用性与兼容性。 首先，从硬件结构与搭建方式来看，文档展示的是一个典型的“非服务器环境验证方案”。将E3.S SSD通过PCIe 6.0转接卡转换为标准PCIe插卡形态后，直接插入台式机主板插槽进行测试。上电后可以看到风扇运转、指示灯点亮，说明设备已正常供电并进入工作状态。这一步实际上解决了一个关键问题：在没有原生EDSFF背板或服务器的情况下，如何快速验证E3.S设备。 其次，在设备识别与系统层验证方面，文档通过Linux环境下的 lspci 命令进行确认。系统成功识别出： NVMe设备类型（Non-Volatile Memory） BDF地址（如 01:00.0） 设备厂商与型号：KIOXIA CD7（Dell OEM） 这说明从PCIe链路建立、枚举（enumeration）到操作系统识别，整个流程是打通的。换句话说，这个转接方案不仅是“物理连接成功”，而是完整实现了协议层面的正常工作路径。 第三，这个案例隐含一个非常重要的工程结论：PCIe 6.0转接卡对PCIe 5.0设备具备良好的向下兼容能力。虽然转接卡本身是Gen6设计，但实际接入的是Gen5 x4 SSD，依然可以被系统正常识别并工作。这对于当前行业阶段尤为关键，因为： Gen6设备尚未大规模普及 大量验证仍基于Gen5 SSD/CXL设备 转接卡需要承担“跨代验证桥梁”的角色 最后，从应用价值角度来看，这份文档实际上证明了一个非常实用的测试方法论： “用低成本台式机 + PCIe 6.0转接卡，替代昂贵服务器环境，实现EDSFF SSD的基础验证与调试。” 这种方式特别适用于： SSD研发初期 bring-up PCIe链路调试（训练/枚举阶段） 实验室快速验证环境搭建 客户现场问题复现 总结一句话：这份文档本质是在用一个简单但非常典型的实验，证明了——通过SerialCables的PCIe 6.0 EDSFF转接卡，可以在普通PC环境中完整打通E3.S SSD从上电、建链、到系统识别的全过程，是当前PCIe 5/6代过渡阶段非常高效的一种验证手段。 4）静态介绍SerialCables PCIe 6.0 EDSFF to AIC 带Quarch PAM治具的转接卡 该视频本质上是对一款SerialCables PCIe 6.0 EDSFF → AIC 转接卡（带 Quarch PAM/PPM 测试能力）的系统性介绍，不仅讲清了“转接卡本身”，更重要的是讲清了它在测试体系中的定位与价值。 首先，从基础形态与定位来看，这款转接卡的核心功能是将 EDSFF（E3/E1形态）设备转换为标准PCIe插卡（AIC），从而可以在台式机、工作站或服务器中直接使用。需要特别强调的是，EDSFF已经从最初的“SSD专用形态”（Enterprise Data Center SSD Form Factor），逐渐演变为更广义的数据中心标准形态（Enterprise Data Center Standard Form Factor），不仅用于SSD，也广泛用于CXL内存扩展模块等设备。因此，这类转接卡的应用场景已经从单一存储扩展，扩展到了内存池化、CXL验证等更前沿领域。 其次，在硬件结构与版本差异方面，文档详细对比了多种规格： Gen6 x8 / x16 不同带宽版本 E3 / E1 不同EDSFF形态 普通转接版 vs 带Quarch接口版本 其中关键区别在于：带“Q”的版本（如 VE3Q）集成了Quarch测试接口能力，在转接卡上增加了一个小型载板（治具），可以把电压、电流、功耗以及Sideband信号从链路中“引出来”，供测试系统采集分析。这一点使其从一个“被动转接器”，升级为主动测试入口。 第三，也是这份文档最有价值的部分，在于与Quarch测试体系的结合，主要体现在两个方向： 1️⃣ 功耗与信号监测（PAM） 通过USB Type-C连接到Quarch PAM模块，再接入Power Studio软件，可以实现： 电压、电流、功耗的高精度采样（μs级） Sideband信号（如PERST#、CLK等）同步监控 长时间记录（分钟/小时/天级别） 任意时间点回溯分析 这意味着可以把协议问题与电源/功耗问题进行时间对齐分析，这是传统协议分析仪做不到的。 2️⃣ 可编程供电与异常注入（PPM） 通过外接电源接口（5+5 pin），结合Quarch PPM模块，可以实现： 标准供电（12V / 3.3V） 电压拉偏（±5% / ±10% / 更大范围） 极端测试（瞬间掉电到0V） 高功耗设备供电（>75W，突破PCIe插槽限制） 特别关键的是：PCIe插槽本身最大供电约75W，对于CXL内存模块或高性能设备（100W~200W）远远不够，因此必须依赖外部供电体系。同时，PPM还能模拟电源波动，用于验证设备在异常电源条件下的稳定性与数据可靠性。 第四，从工程使用注意事项来看，文档也强调了几个非常实际的点： 外供电模式下，必须先启动电源模块，再启动主机，否则设备无法正常枚举 使用完外供电后需要切回PCIe供电模式，否则会出现“设备找不到”的问题 高功耗设备必须使用外部供电，否则PCIe插槽供电不足 测试环境中不建议使用低质量转接卡，否则会引入不可控变量 这些细节实际上反映了该设备已经进入真实研发与验证场景，而不仅仅是展示级产品。 最后，从整体价值来看，这款转接卡的定位可以总结为一句话： 它不是一个简单的转接卡，而是一个“EDSFF/CXL设备测试入口平台”。 它同时解决了三个问题： 形态转换（EDSFF → PCIe插卡） 功耗与信号观测（PAM） 供电控制与异常注入（PPM） 在当前PCIe 5.0向6.0、以及CXL快速发展的阶段，这类设备对于SSD验证、CXL内存调试、功耗分析、系统级稳定性测试都有非常高的工程价值。 总结一句话：这份文档实际上是在讲清一个核心理念——未来高速接口测试，不再只是“看协议”，而是必须把协议 + 电源 + 物理环境三者统一起来，而这款带Quarch能力的PCIe 6.0转接卡，正是这个体系中的关键连接点。 5）6 -静态介绍SerialCables PCIe 6.0 MCIO x8 转接2个x4 EDSFF SSD线缆 该视频主要围绕一根SerialCables PCIe 6.0 MCIO x8 → 2×EDSFF（x4）线缆的结构、使用方式以及工程实践中的关键注意事项展开，本质上是在讲清楚：在PCIe 6.0测试环境中，如何通过线缆把Switch资源有效“扇出”到多个EDSFF设备，同时避免典型工程事故。 ** 注意：该视频用来将SerialCables Gen6 Switch卡的MCIO x8 cable connector连接两块Gen6 x4 E3.S或者E1.S SSD使用。具体这部分内容可以参考我们之前的高清视频：【高清视频】PCIe Gen6 SSD测试环境搭建演示 当然，你可以使用PCIe 6.0 EDSFF 盘柜，这样更方便，但是成本增加一些，参考视频：【高清视频】手把手教你如何搭建PCIe 6.0 SSD测试环境 首先，从功能与拓扑结构来看，这根线缆的核心作用是将一个 PCIe Gen6 x8 MCIO接口拆分为两个Gen6 x4的EDSFF接口。MCIO端通常连接在PCIe 6.0 Switch卡上，而Switch卡在系统中扮演双重角色： 对上游CPU来说，它是一个Endpoint 对下游SSD、GPU等设备来说，它又相当于Root Complex 因此，这类线缆实际上是构建PCIe 6.0测试环境中的“关键连接件”，用于把Switch上的MCIO端口扩展成多个EDSFF设备接口，实现多设备并行测试。 其次，在信号与供电分离设计方面，文档强调了一个非常关键的点： 这类MCIO线缆只传输PCIe高速信号和sideband信号，不承载电源。 因此，每个EDSFF设备必须通过额外的供电路径（通常是标准SATA电源接口）来供电。这一点在实验室环境中非常常见，但也意味着： 系统连接复杂度增加 供电路径必须单独规划 错误连接可能导致严重后果 第三，文档重点强调了一个非常容易被忽略但极其危险的问题：EDSFF线缆支持“正反插”，但并不等价于USB Type-C的安全反插。 虽然物理上可以插反，但如果方向错误： 一旦接入电源（SATA供电） 可能导致线缆烧毁（自燃） 严重情况下可能损坏SSD设备 这是因为EDSFF线缆不像带bracket的转接卡那样具有机械防呆结构，因此在测试环境中必须： 严格按照箭头标识对齐插入 在上电前进行人工确认 避免未经培训人员操作 这一点在视频中被反复强调，说明在实际工程中确实发生过事故案例。下面是该线缆以及EDSFF female connector上面箭头，以及和E3.S SSD对接时候两个箭头要对接在一起。我们之前拍摄过PCIe 5.0 MCIO x4 转接到一个EDSFF接口的视频，是类的，感兴趣的可以查看：PCIe Gen5 EDSFF 延长线使用演示 第四，从工程实践角度来看，这种线缆与转接卡的一个重要区别在于： 转接卡：结构固定，有机械约束，不易误插 线缆方案：灵活，但无防呆，风险更高 因此，线缆更适用于： 高灵活度测试环境 多设备扩展（fan-out）场景 Switch级系统验证 但同时也要求更严格的操作规范和流程控制。 最后，这份文档实际上隐含了一个非常典型的PCIe 6.0实验室架构： CPU → PCIe 6.0 Switch → MCIO x8 →（线缆拆分）→ 多个EDSFF设备 这套结构是当前在没有成熟整机平台情况下，构建Gen6测试环境的主流方法之一。 总结一句话：这份文档的核心不是介绍一根线，而是在强调——在PCIe 6.0高速测试环境中，MCIO到EDSFF的线缆是实现多设备扩展的关键组件，但同时也是最容易引发“人为错误导致硬件损坏”的风险点，必须严格规范使用。 更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2026.1.6最新更新的白皮书15.1版本 - PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1-low resolution.pdf（低分辨率版本，file size: 63MB）；需要高清图片pdf版本的请参见本文底部的联系方式联系我们获取（file size: 204MB) 链接: https://pan.baidu.com/s/1R-tJEqwBlzBaDR0WLuMU0Q?pwd=9av3 提取码: 9av3 如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。    

我们平时个人经常使用笔记本电脑其实当前来讲都是PCIe 3.0或者4.0 M.2接口的NVMe SSD了，可能不搞研发的人不知道这些M.2 SSD在研发阶段碰到问题是如何来分析的。 我们今天的视频通过测试一下客户送测的一个PCIe 4.0 x4 M.2 SSD来顺便做一个知识普及视频，来看看如何使用业内领先的SerialTek公司的PCIe 5.0 x4（兼容分析PCIe 3.0/4.0)协议分析仪来分析抓取M.2 SSD转接之后，和标准的M.2 SSD接口的双向流量来分析问题，希望对于对这方面好奇的朋友可以有一定收获。 实测现场还原：SerialTek如何抓取PCIe插卡与M.2 SSD全链路流量？ 1）客户的M.2转接卡 + 客户M.2 SSD + SerialTek 插卡interposer抓取双向数据 上面这段视频主要演示了一个 M.2 SSD 通过我们客户自己的转接卡接入 PCIe 分析仪进行抓包验证 的实际环境。左侧是 Gen5 x4 PCIe 分析仪，右侧是华硕 Z790 Intel 平台；M.2 盘先通过转接卡变成 AIC 插卡，再插到PCIe协议分析仪 Pod 的 Device Adapter 上，Host Adapter 则插入主板 PCIe 插槽。 实际开机抓包后，前面板显示链路工作在 Gen4 x4。进入系统后停止抓包并查看 Trace，LTSSM 过程正常。 这个视频的最后重点展示了 SerialCables Gen5 M.2 转 AIC 转接卡。从日常实测结果看，这张转接卡在 Gen5 环境中没有任何 Bit Error，信号质量表现较好，因此对于 Gen5 SSD 测试，作者建议优先使用这类高质量转接卡。 2）SerialCable PCIe 5.0 M.2转接卡 + 客户M.2 SSD + SerialTek 插卡interposer抓取双向数据 这段视频主要验证我们将客户的M.2/AIC转接卡替换成 SerialCables 的 M.2 转 AIC 转接卡 在实际抓包环境中的表现。测试对象还是同一块 M.2 SSD，通过 SerialCables 转接卡接入插卡式 PCIe 分析仪，另一端连接华硕 Intel 平台主板插槽。 测试流程是先在软件界面开始抓包，然后开机进入系统。分析仪前面板显示链路为 Gen4 x4，系统正常启动，没有明显异常。 抓包结束后查看 Trace，大约捕获了 400多 MB 数据。进一步看 LTSSM 状态，链路进入 L0 之后没有出现额外的 Recovery，说明这套连接环境整体比较稳定，转接卡在这次测试中没有引入明显链路异常。 3）客户M.2 SSD + SerialTek M.2 interposer抓取双向数据 这段视频验证的是：不通过 M.2 转 AIC 转接卡，而是让 M.2 SSD 直接接入 Gen5 x4 M.2 分析仪环境。测试时，将分析仪 Pod 两侧的小板从之前的 AIC x4 Adapter 换成了 M.2 Adapter，另一端仍然连接华硕 Z790 主板的 M.2 插槽。 测试流程同样是先开始抓包，然后主机开机。前面板显示链路正常协商到 Gen4 x4，没有看到错误提示，随后系统顺利启动。 停止抓包后查看 Trace，初始化过程没有异常，整体链路表现稳定。这个视频主要说明：在同一块 SSD、同一套主机平台下，直接使用 M.2 Adapter + Gen5 x4 M.2 分析仪 也可以完成稳定抓包，链路训练和系统启动过程都正常。 总结 通过上述三种场景，我们看到，无论你将你的M.2 SSD通过自己的转接卡，还是SerialCable转接卡，还是不转接，直接通过M.2进行数据抓取，通过SerialTek PCIe 5.0协议分析仪都可以得到完美的结果。不过，对于PCIe 5.0信号，建议一定要使用SerialCables这类转接卡，全球的客户都在使用，信号有保证，不要去图省事在国内平台购买SI不过关的产品徒增导入各类意想不到的信号问题。 更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2026.1.6最新更新的白皮书15.1版本 - PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1-low resolution.pdf（低分辨率版本，file size: 63MB）；需要高清图片pdf版本的请参见本文底部的联系方式联系我们获取（file size: 204MB) 链接: https://pan.baidu.com/s/1R-tJEqwBlzBaDR0WLuMU0Q?pwd=9av3 提取码: 9av3 如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。  

我们知道由PCIe训练器仿真的协议层PCIe RC 是用来测试用户开发的EP，市场上大多数公司是开发各类PCIe 外设的，不论GPU，AI加速卡，DPU，网卡，SSD主控芯片，等等，所有需要PCIe 6.0训练器仿真RC的场景多，PCI SIG进行CTS测试也是以测试外设为主；但是PCIe 训练器仿真的EP则专门用来测试用户开发的RC设备，一般情况是各类CPU，当然也包括PCIe Switch的RC端（连接下行EP外设的部分）。SerialTek PCIe 6.0协议分析仪的训练器Tester(也叫Exerciser）功能支持设置成仿真RC或者EP。有用户问如果设置成EP来测试他们开发的CPU的时候，CPU是否可以在初始化过程中会扫描到这个仿真的EP device并且给它分配一个BDF(Bus: Device. Function)呢？这个就要了解BDF扫描机制是如何在系统里面实现的，我们今天先简单讲一下 PCIe 枚举里 BDF 的实现细节，再给你一个尽量贴近工程实际、尤其适合“CPU + PCIe协议仿真的 EP”场景的回答。先上答案：SerialTek公司的PCIe 6.0训练器在设置成EP emulation的时候是可以被CPU正确识别到BDF的，该设备在业内不同的主机系统里面都正确通过PCIe枚举的过程验证并且获得BDF分配，该仿真的EP和正常的PCIe EP device没有什么特别不同的地方。这么说吧，如果这个仿真的 Endpoint 最终被 CPU/Root Complex 成功枚举到，CPU 在初始化扫描过程中就会“看到”并给它分配一个 BDF。但要注意，BDF 通常不是 Endpoint 自己预先决定并上报给 CPU 的固定号码，而是 Root Complex / 固件 / 操作系统在枚举过程中分配和记录的地址。Linux 文档里也直接把设备地址写成 domain:bus:device.function 这种形式，并明确这是系统里的 PCI 设备地址表示法。我们上面这个场景里可以这样理解：1）CPU 会不会“扫描到”这个 FPGA EP 的 BDF？会，但更准确地说是：CPU/RC 在扫描配置空间时发现了这个设备，然后给它安排了一个 BDF，并在后续访问中按这个 BDF 去访问它。前提是链路先起来，LTSSM 至少走到能正常进行配置访问的状态，并且 FPGA 这边把一个合法的 PCIe 配置空间端点行为模拟出来了，比如 Vendor ID / Device ID、Header Type、BAR、Class Code 等基本字段能被正确读到。Linux 内核文档也说明了 PCI 设备是通过总线上的配置与资源模型被内核识别和管理的。2）BDF 到底是什么？BDF = Bus / Device / Function。 通常写成：bb:dd.f如果把 PCI domain 也带上，Linux 常写成：dddd:bb:dd.f例如 0000:17:00.0，其中 Linux 文档明确说明前面的部分可表示 PCI domain 和 bus，而后面的目录对应某个 slot/function 设备。它本质上是配置访问地址，不是设备内部某个永久烧录的“身份证号”。3）BDF 一般是怎么实现出来的？核心在 PCIe 枚举（enumeration）。大致过程是：Root Complex 从某个 bus 开始扫描；对每个可能的 device number、 functionnumber 发起配置读；如果读到有效的 Vendor ID，说明这里有设备；然后系统给它建立对应的 bus/device/function 记录；如果遇到桥（Bridge / Switch Port），再给下游分配新的 bus number，继续往下枚举。所以：Bus Number：通常由 RC/固件/OS 在枚举桥和下游总线时分配。Device Number：对直连 RC 端口下的设备，常由 RC 侧拓扑/端口位置决定；在 switch 下游也和枚举拓扑位置有关。Function Number：如果一个设备是多功能设备，则 function 号通常体现为 0~7 中的某个功能号；SR-IOV 场景里还会出现更多由 PF 派生出来的 VF 逻辑函数。Linux 文档对 function、PF/VF 的表述也能印证这一点。4）PCIe协议分析仪的RC/EP仿真都是通过设备内部的高端FPGA实现的，在 FPGA 仿真 Endpoint 时，哪些东西是 FPGA 自己决定的，哪些不是？一般来说：FPGA / EP 自己决定的：Vendor ID / Device IDClass CodeRevision IDHeader TypeBAR 大小与类型Capability / Extended Capability是否多功能设备（multifunction）MSI/MSI-X、AER、PCIe Capability 等配置空间内容不是 FPGA 自己最终决定的：Bus Number多数情况下的 Device Number系统里最终看到的完整 BDF也就是说，FPGA 提供“我是什么设备”的配置空间内容；系统决定“你在这台机器里住哪个地址号”。 有些 SoC/PCIe EP 控制器会提供“PCIe gadget”一类接口，让你配置 vendorid、deviceid、BAR 大小等，但这不等于你能直接指定最终 BDF。Linux 文档里这类 EP gadget 接口就体现了这一点：可配置的是设备属性，而不是最终系统分配给它的完整 BDF。5）那 CPU 初始化时，是“先知道 BDF”，还是“先发现设备再形成 BDF”？更贴近真实实现的说法是：先按候选的 bus/device/function 地址去探测配置空间，读到有效设备后，这个地址就成为该设备的 BDF。所以从软件视角看，像是在“扫描 BDF”； 从设备视角看，是“系统在一堆可能地址里探测，发现你后把那个地址作为你的 BDF”。6）这个 BDF 是不是每次开机都固定？不一定。 Linux 内核参数文档就明确提醒，PCI 的 bus/device/function 地址可能会因为插入新硬件、主板固件变化、或者内核参数变化而改变。因此：在简单、固定拓扑里，BDF 往往看起来比较稳定；但只要拓扑、桥分配策略、BIOS/UEFI 行为变了，BDF 就可能变化；所以工程上通常不要把 BDF 当作设备的永久身份标识。7）结合你这个“CPU + FPGA 仿真 EP”的场景，最实用的结论如果你的 FPGA Endpoint 仿真是正常的，那么 CPU 初始化时通常会：建链成功；对配置空间发起读请求；读到有效 Vendor ID / Device ID；给它纳入系统 PCI 设备树；在软件里表现成一个 BDF，比如 00:01.0、 01:00.0 之类。但如果下面任一项有问题，CPU 就可能根本“看不到”这个 BDF：链路没起来；FPGA 没有正确响应配置读；Vendor ID 读回 0xFFFF；Type 0 / Type 1 Header 模拟错了；BAR 或 capability 结构异常，导致枚举中断或驱动阶段失败。8）一句话总结BDF 不是 FPGA Endpoint 预先“报给 CPU”的固定编号，而是 CPU/Root Complex 在 PCIe 枚举过程中，根据系统拓扑和配置访问结果，为这个被发现的 Endpoint 确定并使用的地址。更多关于PCIe 6.0/CXL的测试工具和技术，请下载Saniffer公司2026.1.6最新更新的白皮书15.1版本 - PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1-low resolution.pdf（低分辨率版本，file size: 63MB）；需要高清图片pdf版本的请参见本文底部的联系方式联系我们获取（file size: 204MB)链接: https://pan.baidu.com/s/1R-tJEqwBlzBaDR0WLuMU0Q?pwd=9av3 提取码: 9av3如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。