简介面向移动设备高速串行接口设计、验证与协议开发人员的MIPI M-PHY v5.0规范文档围绕低引脚数、高带宽与优秀能效下的物理层实现、兼容性核对和测试展开。压缩包仅含1个PDF文件约2.81MB整合2022年发布的Errata 01勘误内容集中说明4.11高速交易须遵循章节定义、4.11.1中RX_EYEMON_Start与RX_EYEMON_Enable的启动关系及计数饱和、目标计数为零等关闭条件并对5.1.2.9中TEYE_HS_G3_TX、VDIF_AC_HS_G3_TX等参数定义作出澄清。读者可据此对照UniPro、DigRF v4等协议场景检查设计约束理解勘误对现有实现与测试流程的影响减少因旧版规范或理解偏差带来的兼容性风险。该文档兼顾规范正文与勘误标记便于定位条款、核对版本差异并可作为物理层调试、互操作性验证和测试用例设计的参考底稿。已有953人学习适合需要查阅原始规范、落实勘误并指导调试的中高级工程师。1. 板子第一次跑 HS-G5 眼图对不上时先怀疑你手里那份规范副本硬件回来第一次上高速串行链路示波器扫出来的眼图和 DUT 自检报告差了将近 2 dB第一反应是 PHY 模拟前端有问题折腾两天才发现是两个人手上拿的 mipi m-phy spec v5.0 不是同一份一份是 2021 年 6 月 23 日发布的正文另一份是打了 Errata 01、把 11 处更正直接标在正文里的版本。这两份东西页码一样、章节号一样、图号一样唯独关键参数的取值和眼图定义不一样对着吵是吵不出结果的。这份资源就是 M-PHY v5.0 正文加上 2022 年 8 月 22 日的 Errata 01共 11 条更正覆盖 4.11 节的 RX Eye Monitor、5.1.2.9 的 TX 眼图、5.2.1.1 表 19 的抖动频点、5.2.2.3 的 RX 眼图。它解决的不是“M-PHY 是什么”这种问题而是“我手上这版到底该怎么实现、怎么测”的问题。适合做 PHY 集成、SerDes 验证、协议一致性测试的人也适合做 UniPro 或 DigRF 上层、但需要下探到电气层定位问题的人。2. HS-G5 把单 lane 推到 23 Gbps 量级先理顺 GEAR 体系和文档结构再翻页M-PHY 的文档不好读不是因为厚是因为它的参数全是“条件参数”——同一个眼图模板在不同 GEAR、不同 Rate、不同 LINE 状态下取值完全不同。直接翻到第 5 章看电气指标看到的是一堆 TEYE_HS_G3_TX、VDIF_AC_HS_G5_TX 这样的符号不知道在哪个状态下测、测的是裸信号还是后处理过的信号。所以阅读顺序必须先架构后电气这条路径在 v5.0 上加了一条 Errata 支线走错就要返工。2.1 为什么阅读顺序必须从 LINE/LANE 状态机切入M-PHY 的层次是 PIN、LINE、LANE、SUB-LINK、LINK、M-PORT 六级物理上真正承载信号的是 LINE一条 LINE 由一对差分线构成两条 LINE 组成一个 LANE 做双向。LINE 不是一直处于传输态它有一套状态机LINE-RESET 用来复位和重新同步STALL 是省电的中间态SLEEP 和 HIBERN8 是两级低功耗真正跑数据的只有 PWM-Burst 和 HS-Burst 两种 Burst 状态。信号方案也分两套低速用 PWM 单端脉宽调制高速用 NRZ 差分。这个结构直接决定了电气参数的组织方式。规范里所有 HS 相关的眼图、差分电压、抖动指标都隐含“在 HS-Burst 期间、在指定 GEAR 下、经过指定参考通道”这三个前提。你要是跳过第 4 章直接看 5.1.2.9会以为 TEYE_HS_G3_TX 是个全局常量实际上它是 HS-G3 TX 累积眼图模板的横向开口而且 Errata 01 的 Item 3 明确写了 HS-G4 和 HS-G5 的累积眼图是“在参考封装和参考通道均衡器之后”定义的。少了这句话测试点选错数据全废。GEAR 和 Rate 的关系也得先捋清楚。每个 HS-GEAR 有 Rate A 和 Rate B 两档Rate B 通常比 Rate A 高一个固定比例用来做 PLL 分频和扩频规划。常见档位如下具体数值以规范表格为准GEARRate AGbpsRate BGbps引入版本HS-G11.2481.456v1.xHS-G22.4962.912v1.xHS-G34.9925.824v2.xHS-G49.98411.64v4.xHS-G519.96823.32v5.0HS-G5 相对 HS-G4 是翻倍这个翻倍带来的连锁反应就是 Errata 01 里一半条目的来源CDR 带宽跟着上移抖动测试频点要重排测试设备的上限顶不住了。2.2 正文页码和 PDF 页码是两套坐标偏移量是恒定的 20 页Errata 01 的每一条都给两个页码Spec Page Number 和 PDF Page Number。这不是冗余设计是给两种使用场景准备的。看纸质打印件或者按章节引用的用 Spec Page Number在 PDF 阅读器里跳转的用 PDF Page Number。正文前面有封面、版权页、免责声明、目录、图目录、表目录、版本历史这些页用罗马数字编号不占阿拉伯数字页码所以两套坐标之间有一个固定差值。把 11 条的位置列出来看这个差值是 20一条不差Item章节Spec PagePDF Page14.11547424.11.1547435.1.2.9759545.1.2.9 Figure 3376965~95.2.1.1 Table 1990110105.2.2.397117115.2.2.3 Figure 4498118我一般直接用 PDF 页码跳跳过去之后不要只看那一页往上翻半页确认章节标题因为 Errata 是“替换某段文字”替换点和上下文强相关只截取被替换的那一段容易改出新问题。特别是 Item 2 和 Item 10替换的是整节的正文段落前后文的指代关系必须一起看。提示如果你手上的正文副本没有按 Errata 位置做标记建议先按 PDF 页码逐条标注再开始读否则读到 5.2.2.3 时很容易把旧版的两段话和新版的表格混着理解。2.3 一条可以直接照抄的精读路线按下面这个顺序走一遍大概三天能建立完整的参数地图比从头到尾线性读快得多第 4.1 节到 4.3 节搞清 PIN/LINE/LANE 层次、LINE 状态机、NRZ 与 PWM 两套信号方案第 4.11 节读 RX Eye Monitor 功能重点看 Errata Item 1 和 Item 2 的更正这节是这次唯一有设计影响的地方第 5.1.2.9 节TX 侧眼图和差分电压参数配合 Errata Item 3、Item 4 的新图第 5.2.1.1 节表 19RX 侧抖动容限频点表配合 Errata Item 5 到 Item 9第 5.2.2.3 节RX 侧眼图和差分输入电压配合 Errata Item 10、Item 11回头再看第 4 章的 Burst 时序这时候你才知道每个参数挂在哪个状态的哪一段上。第 3 章到第 5 章是电气指标第 6 章才开始讲协议无关的测试方法第 4 章是架构。别按章节号顺序读按“状态机 → 功能 → 电气”这个依赖顺序读。3. Errata 01 的 11 条更正只有 1 条会动你的设计其余 10 条都在改测试口径拿到 Errata 最怕的是不分青红皂白全部当成设计变更结果 RTL 改了一轮发现根本不影响功能反过来更怕的是把 Technical 类的条目当成“仅测试”忽略掉。Errata 01 每一条都标了 Editorial 还是 Technical也标了 Technical Impact这两个字段要分开看Editorial 指表述修改Technical 指技术内容修改但 Technical 不等于影响设计很多条明确写了 “Only used for testing”。3.1 Item 14.11 节从“可以不做”变成“做了就必须照做”Item 1 是全文唯一一条明确写了 “Potential impact on existing designs” 的更正。位置在第 4.11 节第 837 行动作是在 “for high speed transaction” 后面插入一句“however if implemented, then the definitions in this section shall be followed.”这句话的杀伤力在于它改变了这一节的法律地位。原来 4.11 节描述的高速事务特性是可选实现厂商可以按自己的理解做一个近似版本只要不影响互操作就行。加了这句话之后特性本身仍然是可选的但一旦你决定实现它这一节里的定义就是强制性的不能打折。血泪经验是如果你们的 PHY 里有一个“差不多能用”的眼图监视或者高速事务诊断模块而且当初是照着早期草案做的这条要当作设计变更来评估不是文档变更。注意这里说的“可选”是指功能是否实现可选不是指标可选。实现了就得按定义走没实现就不受约束但也不能对外宣称支持。3.2 Item 2RX Eye Monitor 的三条终止条件必须写进状态机Item 2 替换了 4.11.1 节第 857 到 863 行的全部内容官方给的理由是 “To improve clarity”技术影响写的是“仅测试用”。但这段替换把 RX_EYEMON_Start 的时序约束写死了做验证的人如果只按旧版实现会得到一个退不出来的状态机。新版的定义是RX_EYEMON_Start 必须和 RX_EYEMON_Enable 在同一时刻、也就是 RCT 这个参考时刻一起拉起。然后 Start 在三种情况下要被清掉触发条件行为实现要点RX_EYEMON_Tested_Count ≥ RX_EYEMON_Target_Test_CountPHY 接收端拉低 Start比较器要在计数更新后一拍内生效别留组合毛刺RX_EYEMON_Error_Count 饱和PHY 接收端拉低 Start饱和判定要先于计数回绕否则会漏掉终止RX_EYEMON_Target_Test_Count 0无限比较模式Start 在 Enable1 期间保持高Enable 在 RCT 拉低后Start 由主状态机的 LINE-RESET 或系统复位清除这是唯一一个不靠计数退出的分支复位路径必须覆盖第三条是坑最多的地方。Target_Test_Count 设成 0 表示无限次比较逻辑上就是不设终点Start 一直挂着。这时候唯一的退出路径是 Enable 置 0 之后碰上 LINE-RESET 或者系统复位。如果验证环境里只做寄存器读写、不触发 LINE-RESET这个信号就永远为高后面的测试序列全被卡住。我一般会在验证平台里加一条强制路径任何用到 Eye Monitor 的用例结束时必须打一次 LINE-RESET把这个状态清干净。3.3 Item 3 到 Item 11眼图定义重写和抖动频点重排剩下的条目按影响面分两组。第一组是眼图相关Item 3、4 改 TX 侧Item 10、11 改 RX 侧都是把原来的一段描述拆细并把一张图拆成两张图理由是“澄清参数定义”技术影响统一写“仅测试用”。第二组是表 19 的抖动频点Item 5 到 Item 9 集中在同一张表上改动最密集。先看眼图这组。TX 侧的核心变化是把 HS-G3、HS-G4、HS-G5 三个 GEAR 的累积眼图模板明确分开TEYE_HS_G3_TX 和 VDIF_AC_HS_G3_TX 定义 HS-G3 的累积 M-TX 信号眼图模板HS-G4 和 HS-G5 分别用 TEYE_HS_G4_TX/TEYE_HS_G5_TX 和 VDIF_AC_HS_G4_TX/VDIF_AC_HS_G5_TX。三个模板的中点都落在 UIHS/2 上差分输出电压的绝对值在模板中点处要大于对应的 VDIF_AC 门限。累积眼图要符合对应 GEAR 的模板总发送抖动 TJTX 定义在差分输出零交叉点的均值附近。关键在于后处理口径。Item 3 明文写了 HS-G4 和 HS-G5 的累积 M-TX 信号是“在参考封装和参考通道均衡器之后”定义的。这句话决定了你仿真里那条通道模型必须提前搭好不能拿裸 die 的输出直接比模板。RX 侧同理Item 10 写明 HS-G4 和 HS-G5 的累积眼图要用参考封装和接收端参考均衡器做后处理TEYE 的位置在眼图正中央。再看表 19 这组改动量小但每一个都影响测试计划Item参数变化工程含义5fSJ0_RX修正笔误标称值替换纯 typo按更正后的表取值6、7fSJ2_RX新增子行 20 MHz用于 HS-G510 MHz 用于 HS-G1 到 HS-G4CDR 带宽随速率上移抖动频点要跟到带宽之上8、9fSJ4_RX新增子行 500 MHz用于 HS-G5 及以上1/30 UIHS 用于 HS-G1 到 HS-G4测试设备上限封顶再高的频点没有实际意义fSJ4_RX 这条最能说明问题。按 1/30 UIHS 折算HS-G4 在 Rate B 下 UI 约 85.9 ps30 个 UI 约 2.58 ns对应频率约 388 MHz到 HS-G5 的 Rate BUI 缩到约 42.9 ps30 个 UI 只有 1.29 ns折算出来约 777 MHz。这个频点信号源打不上去测出来也没有参考价值所以规范直接封在 500 MHz。你要是没看 Item 8按公式一路算下去测试计划里就会出现一个物理上做不到的频点评审时被问一句“你打算用什么设备产生 777 MHz 的抖动”就下不来台。fSJ2_RX 的逻辑类似。10 MHz 这个频点在 HS-G1 到 HS-G4 上位于 CDR 带宽之上用来验证接收端对带外抖动的抑制HS-G5 速率翻倍后 CDR 带宽跟着上移10 MHz 可能落到带宽之内测出来的就是容限而不是抑制能力所以要加一个 20 MHz 的子行。这两条放在一起看规律很清楚抖动频点不是绝对频率是相对 CDR 带宽的位置速率一变就要重排。4. 眼图模板落到实测TX 和 RX 的参考通道、后处理与判定边界规范和实测之间隔着两层东西一层是参考通道模型一层是眼图累积方式。Errata 01 里关于眼图的四条更正本质上都在补齐这两层的定义。做测试计划时如果不把这两层显式写进去测出来的眼图宽度和高度都没有可比性和供应商对数也对不上。4.1 TX 侧模板中点和差分电压是两个独立判定TX 侧的判定分两条线一条看形状一条看幅度两条都要过。形状这条线是眼图模板。规范给的是一个六边形或者菱形的禁区累积眼图的轨迹不能侵入这个区域。判定时要注意模板的横向坐标单位是 UI纵向坐标是归一化到 VDIF_AC_HS_Gx_TX 的比值所以不同 GEAR 的模板形状一样但绝对尺度不一样不能跨 GEAR 复用同一套采样点。幅度这条线是差分输出电压。规范要求 HS-TX 差分输出信号的绝对值在模板中点位置要大于对应的 VDIF_AC_HS_G3_TX、VDIF_AC_HS_G4_TX 或 VDIF_AC_HS_G5_TX。注意这里说的是“绝对值大于”不是“峰峰值大于”测的时候探头极性接反了也能过但眼图上下沿会翻模板判定会挂两个现象要一起看才能定位是接反还是真的幅度不够。累积方式这条线最容易被忽略。TJTX 定义在差分输出零交叉点的均值附近也就是说抖动的参考基准是零交叉的统计中心不是某一个特定的交叉点。测试设备如果按单次触发取交叉点抖动量会偏大跟规范定义的累积眼图对不上。常见做法是让设备做长时间累积把直方图统计中心找出来再算 TJ。4.2 RX 侧参考均衡器不能省容限测试的注入点要往前挪RX 侧比 TX 侧多一层麻烦因为接收端看到的信号是经过通道衰减和均衡之后的规范不可能要求你在 PIN 上直接灌一个完美眼图。所以 Item 10 明确了HS-RX 在 RXDP 和 RXDN 引脚上收到的输入信号要满足 VDIF_ACC_RX、TEYE_RX 和 TJRX 的限值其中 HS-G4 和 HS-G5 的累积眼图必须用参考封装和接收端参考均衡器做后处理。这句话对测试环境搭建的约束是硬性的。做 RX 容限测试时信号源输出的压力信号要经过参考通道模型再经过参考均衡器才等价于规范描述的那个节点。如果你的测试夹具里没有这一段直接拿信号源输出对模板测出来的容限会偏乐观芯片在真实系统里跑不起来。另一个细节是 TEYE 的位置。规范写的是 TEYE_HS_G3_RX、TEYE_HS_G4_RX、TEYE_HS_G5_RX 的位置都在眼图正中央也就是水平方向以零交叉均值为中心、垂直方向以共模电平为中心。眼图不对称的时候居中和不居中的判定结果能差出一个数量级这个必须写进测试规范里不能靠测试员手感。参数所属侧判定内容后处理要求TEYE_HS_Gx_TXTX眼图模板横向开口参考封装 参考通道均衡器G4/G5VDIF_AC_HS_Gx_TXTX模板中点处差分电压绝对值下限同上TJTXTX零交叉均值附近的累积抖动累积眼图统计TEYE_HS_Gx_RXRX眼图模板居中放置参考封装 接收端参考均衡器G4/G5VDIF_ACC_HS_Gx_RXRX差分输入电压绝对值下限同上TJRXRX目标 BER 下的累积抖动累积眼图统计4.3 用一段脚本把模板判定固化成可复现的检查模板判定靠人眼看容易吵架尤其是边界附近差几个毫伏的情况。我一般会把模板顶点和实测采样点都倒进脚本里做多边形内点判定输出一个明确的“侵入/未侵入”结论。下面这段只做判定不做画图依赖只有 numpy 和 matplotlib 的 Path跑起来很轻。import numpy as np from matplotlib.path import Path # 模板顶点横向单位 UI纵向归一化到 VDIF_AC_HS_Gx_TX # 这里的坐标是占位示意实际必须逐点抄规范图里的顶点不同 GEAR 不能混用 MASK { HS-G3: [(-0.50, 0.0), (-0.25, 1.0), (0.25, 1.0), (0.50, 0.0), (0.25, -1.0), (-0.25, -1.0)], HS-G5: [(-0.45, 0.0), (-0.22, 1.0), (0.22, 1.0), (0.45, 0.0), (0.22, -1.0), (-0.22, -1.0)], } def check_eye(gear, samples_ui, samples_mv, vd_if_mv): samples_ui 是横轴 UI 偏移samples_mv 是归一化前的毫伏值 poly Path(MASK[gear]) # 纵向归一化把毫伏换算成相对于 VDIF_AC 的比值 norm np.asarray(samples_mv, dtypefloat) / float(vd_if_mv) pts np.column_stack([np.asarray(samples_ui, dtypefloat), norm]) inside poly.contains_points(pts) # True 表示落入禁区判失败 return { gear: gear, total: len(pts), violations: int(inside.sum()), # 侵入点数必须为 0 worst_margin: float(np.min(np.abs(norm))) if len(norm) else None, } print(check_eye(HS-G5, [-0.1, 0.0, 0.1], [120, 90, 130], vd_if_mv100))逻辑说明先把实测采样点的纵轴从毫伏归一化成相对 VDIF_AC 的比值这一步不做模板顶点和采样点就不在同一个坐标系里判定结果没有意义。然后用多边形内点判定看采样点是否落进禁区落入即判失败因为眼图模板描述的是“信号不能进入的区域”不是“信号必须覆盖的区域”这个方向新手经常搞反。参数说明samples_ui是相对理想交叉点的水平偏移单位是 UI取值一般在 -0.5 到 0.5 之间samples_mv是对应点的差分电压实测值正负都要有vd_if_mv是当前 GEAR 的 VDIF_AC 门限用来做归一化基准MASK里的顶点坐标必须按 GEAR 分开维护HS-G3 和 HS-G5 的横向开口不一样混用会得到完全错误的结论。脚本返回的violations是硬性指标只要不为 0 就得回查测试链路worst_margin只是参考别拿它当合格判据。5. 对照 Errata 做合规审查5 个高频翻车点和排查手法Errata 这类文档的坑不在内容难在于它和正文是两份文件任何一次交叉引用都可能踩空。下面五条是我在几个项目里真实遇到过的按“现象 → 原因 → 解决”写遇到同类问题时可以直接对号。5.1 版本类翻车页码、副本和图号三处错位翻车一按 Spec Page Number 翻 PDF翻到的是完全不相干的章节。现象是按 Item 3 给的 Spec Page 75 跳到 PDF 第 75 页看到的是第 4 章末尾的状态机描述根本没有 5.1.2.9。原因是正文前面有 20 页罗马数字编号的封面和目录两套坐标差了 20 页。解决办法是统一用 PDF Page Number 列跳转跳完再往上翻半页核对章节标题别只信页码。翻车二团队里有人用未标注的旧副本评审时两边参数对不上。现象是同一个 TEYE 参数两个人报出来的数值差一截谁也说服不了谁。原因是 Errata 首页那句 “we suggest you consider discarding any previous copies of this MIPI Specification not so marked” 被忽略了旧副本还在流转。解决办法是把带标记的版本作为唯一基线旧副本从共享目录里删掉或者至少在文件名里加版本后缀评审时先核对文件哈希。翻车三图号引用错位Item 4 和 Item 11 把一张图拆成两张后正文里的“参见图 33”指向变了。现象是设计文档里引用的图 33 和实际要看的眼图模板对不上工程师看着旧图调参数。原因是拆图之后图号顺延后面的图全部后移一位。解决办法是在项目文档里引用“章节号 图标题”而不是裸图号比如写“5.1.2.9 节 HS-G3 HS-TX 累积眼图模板”不写“图 33”。5.2 参数类翻车抖动频点、UI 折算和 CDR 带宽翻车四HS-G5 抖动容限测试用了 10 MHz测出来偏乐观。现象是 RX 抖动容限在 10 MHz 频点轻松通过但系统联调时链路误码率不达标。原因是表 19 的 fSJ2_RX 在 HS-G5 上新增了 20 MHz 子行10 MHz 只适用于 HS-G1 到 HS-G4用错频点等于跳过了真正有压力的那一段。解决办法是把抖动频点按 GEAR 参数化写进测试用例别在脚本里硬编码一个 10 MHz。翻车五fSJ4_RX 按 1/30 UI 一路折算到 HS-G5得到一个设备做不到的频点。现象是测试计划评审时被质疑或者信号源根本产生不了那么高的抖动频率。原因是没有采纳 Item 8 的 500 MHz 封顶。解决办法是把 1/30 UI 只用于 HS-G1 到 HS-G4HS-G5 及以上直接取 500 MHz并在测试计划里注明“该频点受测试设备带宽限制按规范封顶值执行”。5.3 状态机类翻车无限比较模式退不出来翻车六RX Eye Monitor 开了无限比较模式测试序列卡死。现象是 Target_Test_Count 配成 0 之后RX_EYEMON_Start 一直保持高电平后续用例全部超时。原因是 Item 2 的第三条终止条件没实现Target_Test_Count 为 0 时 Start 不靠计数退出只能在 Enable 于 RCT 拉低之后由主状态机的 LINE-RESET 或系统复位清除。解决办法有两个一是验证平台在每个用例结束时强制打一次 LINE-RESET二是在寄存器模型里对这个组合加断言配置成 0 时打印告警提醒测试员这个用例必须走复位路径收尾。提示Item 1 的那句话也要单独拉出来做一次设计评审。如果产品里已经实现了 4.11 节描述的高速事务特性评审结论应该是“按定义逐条比对”而不是“这条只是文档修改”。6. 把 Errata 变成可执行的核对清单我的版本管理和回归习惯规范类资源最容易死在“读过但没用起来”。我现在的做法是把它拆成两层一层是不可变的基线一层是可执行的检查。基线就是带 Errata 标记的正文 PDF 加上一份自己维护的差异表差异表只记三列——条目号、受影响章节、对本项目的结论影响设计 / 仅影响测试 / 不适用。这张表比读十遍文档有用因为它逼你对每一条给出明确判断而不是笼统地说“已经参考了”。第二层是自动化核对。规范是 PDF但关键句子可以抽出来做关键词检查防止有人在合并分支时把旧版文档又带回来。做法很土但很有效#!/usr/bin/env bash # 把 PDF 转成文本检查 Errata 01 的关键更正是否已经在基线文档里 set -euo pipefail PDF$1 TXT$(mktemp /tmp/mphy.XXXXXX.txt) trap rm -f $TXT EXIT pdftotext -layout $PDF $TXT # 每条对应 Errata 里一处必须存在的表述缺一条就报错 declare -a KEYS( however if implemented, then the definitions in this section shall be followed RX_EYEMON_Target_Test_Count 0 reference package and reference channel equalizer 20 Mhz is used for HS-G5 500 Mhz is used for HS-G5 and above ) fail0 for k in ${KEYS[]}; do if grep -qiF -- $k $TXT; then echo [OK] $k else echo [MISS] $k fail1 fi done exit $fail逻辑说明pdftotext -layout保留版面避免跨行断句把关键词切断grep -qiF用固定字符串匹配并忽略大小写因为 PDF 抽出来的文本大小写和连字符经常和原文不一致数组里每一条对应 Errata 的一个更正点缺任何一条就返回非零可以直接挂到 CI 或者提交钩子上。参数说明脚本第一个参数是待检查的 PDF 路径KEYS数组按项目实际情况增删只保留对你们有约束的条目别把 11 条全塞进去维护成本会失控返回值 0 表示五条关键表述都在非 0 表示基线文档不是打了补丁的版本。这个脚本我只在文档入库和版本切换时跑不是每次都跑跑一次大概两秒。最后说个习惯。早期我做 PHY 集成时吃过一次亏Errata 出来三个月才知道期间流的一版测试芯片里 Eye Monitor 的退出逻辑是错的流片回来才发现无限比较模式退不出来只能靠系统复位兜底多花了一轮验证。从那以后我每次拿到规范类资源第一件事不是读正文是先看有没有 Errata把每一条的 Technical Impact 抄进项目风险表再决定读哪几章。这个顺序反过来做返工成本会高一个量级。希望帮到你。本文还有配套的精品资源点击获取