企业官网建设流程全解析

1. IST 是什么，为什么现在绕不开它

IST，全称 In-System Test，中文一般叫“在系统内测试”。这个说法的关键词是“在系统内”——芯片已经焊在板子上、板子已经装进整机、整机已经通电运行了，此时我们仍然要能把它拉起来做一轮结构化的自检。IST 落地最典型的两个场合：一是整机上电瞬间的那几百毫秒自检窗口，二是设备运行过程中由软件周期性触发的后台自检。它跟产线上用 ATE 打的那一遍测试不是同一件事，跟板级的 ICT、FCT 也不是一回事——它测的是“这颗已经装好的芯片，现在还好不好”。

我第一次被 IST 真正坑到，是在一个车载域控项目上。片子出厂测试全过，板级 ICT 也全过，装机之后客户要求做上电自检，跑一轮覆盖 SRAM、部分逻辑和互联的检查。结果发现测试向量在 ATE 上跑得好好的，搬到板子上一跑就报错，排查了三天才发现是板级时钟树在测试模式下的分频配置和 ATE 环境差了四倍，锁相环还没锁定就急着灌向量。这类问题在 IST 里非常典型：测试逻辑本身没问题，出问题的是“测试逻辑所在的那个系统环境”。

这篇内容面向几类人：做 SoC/ASIC DFT 设计、需要在设计阶段就把 IST 能力埋进芯片的工程师；做板级硬件和底层固件、要负责把 IST 跑起来并判定结果的人；以及做功能安全、可靠性或售后诊断、需要决定“值不值得上 IST”的负责人。我会把 IST 的机制、设计侧要留的口子、固件侧怎么调度、向量怎么算容量和时间、常见故障怎么查，按我实际做项目的顺序讲一遍。看完你应该能自己判断：你的项目要不要上 IST，上的话最小可行方案长什么样。

有一段话我想说在前面。IST 最大的价值不是“多测一遍”，而是把失效检测的时间点从产线搬到了设备全生命周期。产线测试只能证明出厂那一刻是好的，而芯片的老化、焊点疲劳、互联微裂、存储单元弱保持，这些东西只会在使用中慢慢冒出来。IST 给了你一个在这些问题变成整机故障之前抓住它们的机会。但它代价明确：面积、功耗、时间、以及一套需要长期维护的测试数据链路。想清楚这笔账再动手，比一上来就堆 DFT 资源重要得多。

2. 从 ATE 到 ICT 再到 IST：三层测试的分工逻辑

2.1 三个层级各自管什么，边界在哪

要理解 IST 为什么存在，得先把测试层级摆清楚。半导体行业里的测试大体分三层：晶圆与封装级的 ATE 测试、板级的 ICT/FCT、以及系统级的 IST。这三层的目标、手段和成本结构完全不同，混着看很容易得出错误结论。

看这张表就能明白，三层之间不是替代关系，而是“接力”。ATE 抓的是制造缺陷，漏检率通常在 DPPM 量级；ICT/FCT 抓的是装配缺陷；IST 抓的是时间维度上的退化。真正让 IST 从“可选”变成“必选”的，是 ISO 26262 这类功能安全标准对“潜在故障”的要求——你不能假设一个芯片在整个生命周期里一直好着，必须有能力周期性证明它还好。

这里有个容易踩的坑：有人觉得 IST 就是“把 ATE 向量搬过来跑一遍”。不行，至少不全行。ATE 向量是在理想的时钟、理想的电压、理想的温度下生成的，而 IST 的运行环境是全系统环境，时钟来自板级晶振、电压来自整机电源、温度从零下到上百摄氏度都可能。直接在系统里跑 ATE 向量，测试过度（over-test）导致的误报会多到无法使用。正确做法是为 IST 单独裁一套向量，保留高缺陷覆盖的部分，砍掉对时序敏感的部分。

2.2 IST 真正解决的四个问题

那 IST 到底解决什么？我在实际项目里总结下来是四件事。

第一是逃逸失效。ATE 和 ICT 都有漏检，尤其是那些边缘性的、只在特定电压温度角下才显形的缺陷。IST 因为运行在真实工作电压和真实温度下，反而能抓到一些 ATE 在标准条件下抓不到的东西。这不是理论，我在一个工业控制项目上见过一批 SRAM 单元，常温 ATE 全过，在系统里跑到 85 度时上电自检稳定报错，最后定位到是一批弱保持单元。

第二是老化与漂移。电迁移、热载流子注入、负偏压温度不稳定性，这些东西让晶体管的阈值电压随时间偏移，最终表现为时序路径变慢。IST 里如果用片上时钟做环振或者路径延时测量，可以间接监控这种漂移趋势，在真正失效之前给出预警。

第三是现场诊断与返修定位。设备坏了送修，传统做法是换板卡试。如果 IST 能在故障现场就把结果落到非易失存储里，维修端一读就知道是哪颗芯片、哪一类资源出的问题，返修效率的提升非常明显。这一条在售后成本高的行业里价值极大。

第四是批次一致性验证。同一个型号的芯片来自不同批次、不同封装厂，装机之后行为可能有细微差别。IST 跑一遍就能拿到一个横向可比的健康度指标，比看功能是否正常要敏感得多。

2.3 什么时候不该上 IST

反过来说，IST 也不是谁都需要。如果你的产品是消费类、生命周期三年、坏了直接换新、成本敏感度极高，那 IST 带来的面积和验证成本很可能不划算。我在一个低成本物联网模组项目上算过账：为了支持完整 IST，芯片面积多出大约百分之三，加上固件侧的测试代码和向量存储，整体物料成本上升接近百分之五，而产品设计寿命只有两年半。这种情况下，把资源投到更严格的筛片和更保守的老化试验上，收益反而更大。

判断标准其实很简单：看你的失效代价和检测窗口之间的距离。失效代价高（人身安全、停机损失、售后返修贵），检测窗口窄（不能等坏了才知道），IST 就值得上。反之就别硬上，做了也是给自己找麻烦。

3. 芯片里要埋什么：IST 的底层抓手拆解

3.1 测试访问通道：从 TAP 到私有接口

IST 要能执行，第一件事是“进得去”。芯片必须对外开一个可控的通道，让板上的主控或者外部工具能把测试数据送进去、把结果取出来。

最标准、最省事的做法是复用 IEEE 1149.1（也就是常说的 JTAG）定义的测试访问端口，TAP 是五根线：TCK、TMS、TDI、TDO，加上可选的 TRST。这套东西的好处是几乎所有芯片都有，板级互联测试（边界扫描）本来就要用，多加一个自定义指令就能进 IST 模式，不需要额外的引脚。缺点是 JTAG 的串行速率有限，通常几兆到几十兆赫兹，如果 IST 要向量的数据量大，加载时间会成为瓶颈。

于是有了第二种做法：给 IST 开一条私有高速通道。常见形态是把测试数据当作普通数据，通过芯片已有的高速接口（比如片上总线的某个从端口、PCIe 的某个 BAR 空间、以太网的自定义协议帧）灌进片上测试控制器。主控把向量从 Flash 搬到内存，再 DMA 到测试控制器，速度可以到几百兆字节每秒。代价是要在芯片里规划一块地址空间和一个测试控制器，设计复杂度上升。

我在实际项目里更倾向第三种折中方案：上电自检用私有通道（快），调试和深度诊断用 JTAG（通用）。上电自检对时间敏感，几百毫秒的窗口里塞不进太多串行数据，必须走高速通道；而开发阶段和售后返修时，JTAG 的通用性和工具链成熟度无可替代。两条路并存，成本增加有限，收益很实在。

注意：测试通道的模式切换必须在安全的状态机控制下完成，不能出现“功能模式下误进测试模式”的情况。JTAG 的 TAP 控制器在杂散时钟或者上电毛刺下有可能被推到一个非预期状态，业界通常会在 TAP 上加一个监控逻辑，检测到状态机跑到保留态就强制复位。这一条在电磁环境恶劣的整机里必须做。

3.2 复用片上 DFT 资源：扫描链、MBIST、LBIST

通道解决了“进得去”，接下来是“测什么”。IST 的测试能力完全建立在设计阶段埋进去的 DFT 资源上，没有这些资源，IST 就是空的。

扫描链是最主要的结构测试手段。设计阶段把时序单元串成若干条链，测试模式下把内部状态从链上移出、把激励从链上移入，就能用较少的引脚实现对组合逻辑和时序逻辑的深度覆盖。IST 环境下要注意的是链的数量和长度配置——ATE 上可以用几十条链并行跑，IST 环境下受限于测试控制器和通道带宽，往往只能跑少数几条，测试时间会长很多。

MBIST（存储器内建自测试）几乎是为 IST 量身定做的。它的原理是在存储器周围加一圈自测电路，按固定的算法（常见的有 March C-、March SS、Checkerboard、Walking 1/0）对每个存储单元做读写，检测固定型故障、跳变故障、耦合故障、地址译码故障。MBIST 的价值在于它不需要外部向量，片上自己跑，特别适合上电自检这种“没有数据来源”的场景。我在项目里做上电自检，MBIST 永远是第一优先级的，因为它启动最快、覆盖最扎实、对通道没有依赖。

LBIST（逻辑内建自测试）用的是片上伪随机向量发生器加多输入特征寄存器，自己产生向量、自己压缩结果。它的优点是向量为零存储开销，缺点是覆盖收敛难、测试时间长、功耗高。我的经验是 LBIST 适合做“粗筛”——上电时快速跑一遍，覆盖率不用追到九十几，能到七八成就够了，剩下的深层覆盖留给基于扫描链的定向向量。

还有一个容易被忽略的东西：片上时钟生成与测量电路。IST 里如果要测路径延时、监控老化，不能靠板级晶振，得在片上做环振或者延时链，测出来的值再跟基准比。这类结构的精度受工艺角和电源电压影响，标定做不好，测出来的数根本没法用。

3.3 测试调度与数据通路：控制器、加载机制、时钟与复位隔离

有了通道和资源，还需要一个“调度员”。片上测试控制器要管的事情比想象中多：它要管理测试模式的进入和退出、产生测试时钟、控制扫描链的移位和捕获、启动 MBIST 并收集结果、把结果压缩后写回寄存器或内存。

时钟是这里最容易出事的地方。IST 使用的时钟通常有两个来源：一是功能时钟（来自板级晶振经锁相环倍频），二是测试时钟（由测试控制器产生或者由外部直接提供）。两者切换时如果处理不当，会出现时钟切换毛刺、锁相环未锁定就灌向量、跨时钟域路径亚稳态等问题。我的做法是测试控制器里做一个硬性的“等待锁定”状态，锁相环锁定信号不稳住就绝不启动任何一次移位，同时把测试时钟的切换做成同步的无毛刺多路选择。这几行逻辑看着简单，能省掉后面几个月的调试。

复位隔离也要单独说。IST 进入测试模式时，芯片内部的功能复位可能会被测试控制器接管，此时那些“复位释放后才能正常工作”的模块（比如锁相环、稳压器、模拟模块）状态是未知的。如果测试向量里涉及这些模块的输出，结果就不可信。所以在做 IST 的覆盖规划时，必须把这类模块单独列出来，要么等它们就绪，要么在测试期间旁路掉。

数据加载机制上，我推荐分级加载：上电自检只加载最小必需的一组向量（通常几十到几百 KB），保证在几百毫秒内完成；周期自检时再按时间预算分批加载更多向量。这样既满足了上电时间要求，又给了后台一个提升覆盖度的机会。分级策略的关键是要有个统一的测试任务表，把每类向量的优先级、执行时机、时间上限、失败后的动作都写清楚，而不是散落在各处的硬编码。

4. 实操：从需求到跑通一条 IST 流程

4.1 第一步：把失效模式和测试资源对齐

IST 的实操第一步不是写代码，是坐下来把失效模式列清楚。这一步做不好，后面所有工作都是白费。

具体做法是拉一张表：左边写“我担心的失效模式”，右边写“用什么资源能测出来”。比如担心 SRAM 弱保持，那就用 MBIST 加保持时间测试；担心互联微裂，就用边界扫描配合板上施加激励；担心时序路径老化，就用片上延时监控；担心组合逻辑的桥接和固定故障，就用扫描链向量。这张表填完，你会发现有些失效模式当前根本没有对应的资源——这些就是要找设计和 DFT 团队补的口子。

我在一个通信设备项目上做这张表时发现，客户最担心的“电源域切换后某个模块状态错乱”这个失效模式，用现有的扫描链完全测不到，因为那条路径在测试模式下被旁路了。最后是补了一条专门的测试路径，把电源域切换后的关键状态引到一个可观测的寄存器里。补这一个口子花了两周设计时间，但避免了整个 IST 方案在这个关键失效模式上是空白的。

心得：这张失效模式表不要只叫 DFT 的人填，一定要把系统、软件、售后、可靠性的人都拉进来。他们提出的失效场景往往超出芯片设计者的想象，而 IST 能覆盖的范围恰恰应该由这些真实场景来决定。

4.2 第二步：设计阶段必须留好的几个口子

设计阶段的决定几乎不可逆，尤其是流片之后。下面这几条是我认为必须留的，缺任何一条后面都会很难受。

独立的测试模式寄存器组。测试配置不能跟功能寄存器混在一起，否则测试期间的配置修改会污染功能状态，退出测试模式后芯片行为不可预测。独立寄存器组还便于做权限控制，防止功能软件误操作。

结果压缩与签名寄存器。IST 的原始输出通常是几百万比特的响应数据，不可能全部搬到外部比对。标准做法是片上做多输入特征寄存器压缩，最后输出一个几十比特的签名，跟预期签名比。这要求设计阶段就把压缩逻辑放进去，并且预留足够多的签名寄存器（我一般建议至少留两个，一个给上电自检、一个给周期自检，避免结果互相覆盖）。

可读的失败指示。只给一个“通过/失败”位是不够的，返修时需要知道是哪一类资源失败。至少要有资源分组指示，比如存储器组、逻辑组、互联组各自一个状态位。再细一点的话，存储器按块编号、逻辑按扫描链编号，返修定位的价值会大很多。

向量存储的物理规划。IST 的向量要存在 Flash 里，这块空间必须在存储器规划阶段就定下来。如果流片后才发现空间不够，就只能砍覆盖度。我一般会按预估容量留出百分之五十的余量，因为向量在最后收敛阶段往往会膨胀。

测试模式的进出安全逻辑。前面提过 TAP 状态机监控，这里补充一条：测试模式的进入应该要求一个“解锁序列”，比如连续写入特定长度的特定数据，避免单次寄存器误写就进测试模式。这个开销极小，但能显著降低现场误触发风险。

4.3 第三步：向量生成、压缩与容量估算

这是最技术的一块，我把计算过程摊开讲。

先算逻辑部分的扫描测试时间。假设设计里有 16000 个扫描触发器，分成 8 条链，每条链 2000 位；向量深度（pattern 数）为 5000；每个向量除了 2000 个移位周期，还需要约 30 个捕获与流水线周期；测试时钟频率 50 兆赫兹。

单个向量的周期数约为 2000 + 30 + 2 = 2032 个周期。5000 个向量就是 5000 × 2032 ≈ 1016 万个周期。除以 50 兆赫兹，约为 0.203 秒。这就是逻辑扫描在理想情况下需要的时间——两百毫秒。如果上电自检的总预算是 300 毫秒，那光逻辑扫描就吃掉三分之二，明显不够，必须靠裁剪向量深度或者提高测试时钟频率来压。

再算 MBIST。假设一颗 8192 字 × 32 位的 SRAM，用 March C- 算法，大约需要 10 倍字数的读写周期，也就是约 8.2 万个周期，测试时钟 100 兆赫兹的话，约 0.82 毫秒。几百颗这样的存储器并行跑，总时间也就几十毫秒。这就是 MBIST 最讨人喜欢的地方——便宜、快、覆盖扎实。

然后是向量容量。5000 个向量、16000 个扫描位，原始数据量是 5000 × 16000 = 8000 万比特，也就是 10 兆字节。这显然放不进 Flash 预算里。靠压缩能压多少？业界常用的压缩方案在典型设计上能做到 10 倍到 50 倍的压缩比，取决于向量的稀疏程度和设计里是否有大量无关位。按 20 倍保守估计，压缩后约 500 KB。这个数字是可以在存储器规划里消化的。

但如果你的设计里无关位很少、向量很稠密，压缩比可能只有 5 倍，那就变成 2 MB，预算就很紧张了。**所以容量估算必须用你实际的向量统计结果，不能拍脑袋用行业平均值。**我的习惯是在向量收敛到七成左右的时候先做一次统计，把最坏情况的上界算出来，然后按这个上界去申请空间。

配置上还有个细节：压缩向量在加载时需要解压逻辑，解压逻辑本身也要进测试模式、也要占用测试时间。解压是流式的，一般不构成瓶颈，但如果解压逻辑依赖某个片上锁相环的高频时钟，那这个锁相环的启动时间就要算进总预算里。

4.4 第四步：固件侧的集成与执行流程

向量准备好了，接下来是固件把它跑起来。这部分我写一段接近实际的伪代码，把关键环节标出来。

/* IST 执行骨架，C 语言描述，非特定平台 */ #define IST_CHUNK_SRAM_KB 64 /* 分块加载，避免一次性占用大缓存 */ #define IST_PLL_LOCK_TIMEOUT 20000 /* 等待锁相环锁定的最大轮询次数 */ typedef enum { IST_STAGE_NONE = 0, IST_STAGE_MBIST, IST_STAGE_LBIST, IST_STAGE_SCAN, IST_STAGE_DONE } ist_stage_t; static ist_stage_t g_stage = IST_STAGE_NONE; /* 阶段一：上电最小自检，必须在 key-on 时间窗内完成 */ int ist_boot_minimal(void) { if (ist_enter_test_mode() != 0) { /* 解锁序列 + 模式切换 */ return IST_ERR_NO_ACCESS; } if (ist_wait_pll_lock(IST_PLL_LOCK_TIMEOUT) != 0) { ist_exit_test_mode(); /* 失败也要保证能退出来 */ return IST_ERR_CLK_NOT_READY; } g_stage = IST_STAGE_MBIST; ist_start_mbist(IST_MBIST_ALL_SRAM); /* 优先级最高，先跑 */ if (ist_wait_mbist_done(IST_DEFAULT_WAIT) != 0) { ist_record_fault(IST_FAULT_MBIST_TIMEOUT); } else { ist_check_signature(IST_SIG_MBIST); } ist_exit_test_mode(); return ist_collect_status(); /* 汇总到状态寄存器 */ } /* 阶段二：周期自检，后台分批执行，单批时间受限于任务调度 */ int ist_periodic_chunk(uint32_t chunk_id) { const uint8_t *pat = ist_get_pattern_addr(chunk_id); uint32_t len = ist_get_pattern_len(chunk_id); if (ist_enter_test_mode() != 0) return IST_ERR_NO_ACCESS; if (ist_load_pattern(pat, len) != 0) { /* DMA 搬入片上测试控制器 */ ist_exit_test_mode(); return IST_ERR_LOAD_FAIL; } g_stage = IST_STAGE_SCAN; ist_start_scan(IST_SCAN_ALL_CHAIN); ist_wait_scan_done(IST_SCAN_TIMEOUT_MS); ist_check_signature(IST_SIG_SCAN); ist_exit_test_mode(); return ist_collect_status(); }

这段代码里有几个点值得展开。

第一，任何路径都要有退出测试模式的动作，包括出错路径。这是血泪教训。我见过因为测试模式卡死在错误分支里，导致整机上电后功能完全不正常、又查不出原因的案例。芯片在测试模式下，功能逻辑是停摆的，固件没把它退出来，整机就是一块砖。

第二，等待锁相环锁定必须设超时。板级时钟可能因为晶振问题、负载问题、温度问题起振慢或者根本不起振，无限等待会让上电流程彻底卡死。超时之后要退出来并报故障，让整机至少能进降级模式或者引导模式。

第三，分块加载的时间上限要跟系统调度匹配。周期自检跑在后台，如果一次占用 CPU 或者总线太久，会影响功能任务的实时性。我的做法是给每个 chunk 设一个硬性时间上限，超了就中断当前 chunk、记录进度、下次接着来。注意 chunk 之间必须重新进入测试模式，不能跨 chunk 保持测试模式，否则功能逻辑长时间停摆。

第四，签名的比对本该在片上做，但状态收集要在固件里做。片上只负责给出签名和分组状态位，固件负责把结果写到非易失存储、打时间戳、累计失败次数。这样售后读到的是一条有历史的结果记录，而不只是一个瞬时状态。

4.5 第五步：判定阈值与结果处理

向量跑完了，最后一步是判“过还是不过”。这一步看起来最简单，实际上最容易做成噪声源。

直接拿签名做“相等”判定，在 IST 环境里是有风险的。因为整机环境的电压、温度、时钟抖动都跟 ATE 不一样，某些对时序敏感的测试可能出现在临界状态，导致签名偶发不匹配。常见的处理办法有三种：一是对这类测试改用“计数式判定”，比如内部重复跑三次，取多数结果；二是对关键测试做多次采样后取稳定值；三是把这类测试从 IST 的判定集合里移出去，只保留在 ATE 上做。

关键取舍：IST 要的是“低误报”，不是“最高覆盖”。一个误报率百分之一的 IST 方案，在十万台设备规模上就是一千次误报，售后会被打爆。宁可少测几个边缘项，也要把误报压到千分之一以下。

结果处理上，我建议分三级：通过（签名匹配，正常计数清零）、可疑（签名不匹配但重测通过，累计计数但不报警）、失败（连续多次不匹配，写入故障记录并触发整机告警）。可疑这一级的价值在于它能把环境引起的偶发失败跟真实退化区分开，同时保留数据用于趋势分析。很多退化不是一蹴而就的，而是“可疑”的次数慢慢变多，这个趋势信号比单次失败更有预警价值。

5. 常见问题与排查技巧实录

5.1 典型故障速查表

下面这张表是我这几年累积下来的，按“现象—可能原因—排查动作”组织，可以直接抄去用。

这张表里，我想特别说“MBIST 大量报错但功能正常”这一条。它出现的频率比想象中高。原因通常是 MBIST 的测试时钟频率高于存储器在测试模式下的实际可用频率——功能模式下有各种流水线和缓冲掩盖了时序问题，测试模式下的直接访问把这些余量全暴露了。解决办法不是硬降频率了事，而是要搞清楚这个余量到底有多少，因为如果余量真的很小，功能模式在高低温下也可能出问题。MBIST 的报错有时候是提前告诉了你一个真实的隐患。

5.2 三个真实踩坑案例

第一个案例是时钟切换。前面提过我遇到的那个锁定问题，这里说细节。当时的测试控制器里，测试时钟和功能时钟通过一个多路选择器切换，选择信号来自测试模式寄存器。问题在于切换的瞬间，两路时钟都可能有边沿，产生了窄脉冲。这个窄脉冲把扫描链的一位数据打歪了，向量跑出来签名就是错的，但错误位置随机，看起来像是随机硬件缺陷。最后是在多路选择器后面加了两级同步触发器，并在切换时插入一个固定的等待窗口，问题彻底消失。教训：任何时钟切换都必须当作跨时钟域问题处理，哪怕两路时钟同源。

第二个案例是向量存储。一个项目在上电自检阶段加载了完整向量集，本意是覆盖最大化，结果上电时间从原来的一秒出头顶到了四秒多，客户直接拒收。复盘发现三分之二的时间花在从 Flash 读向量上，而不是测试本身。最后改成上电只跑 MBIST 加一小部分关键扫描向量，完整向量放到运行期后台分批跑，上电时间回到一秒以内。教训：IST 的时间预算要拆开算“加载时间”和“执行时间”，很多时候瓶颈在加载不在执行。

第三个案例是签名误报。一个工业项目在低温环境下 IST 失败率大概百分之二，客户以为是芯片质量问题。排查了两个月，最后定位到是一条包含模拟模块输出的扫描链，模拟模块在低温下建立时间变长，捕获到的值抖动。这个测试项在 ATE 的常温环境下从来没问题，在整机低温环境下就暴露了。处理办法是把这条链从 IST 判定集合里移出，改用功能自检的方式覆盖。教训：IST 的向量筛选必须做温度角评审，ATE 通过不代表 IST 通过。

5.3 几条不会写在文档里的经验

第一，IST 的调试周期要按“月”来预留，不要按“周”。即使 DFT 做得再规范，把向量在真实系统上跑通、把误报压下来、把时间预算调到位，半年是很正常的。如果项目排期里只给了六周，那基本可以肯定最后会砍覆盖度收场。

第二，从第一天就建立向量版本管理。向量、签名、固件、测试控制器配置这四样东西必须版本绑定，任何一个变了，其他三个都要重新验证。我见过因为向量更新了但签名没更新，导致整批设备误报的事故。做法很简单：给每套 IST 配置打一个版本号，芯片里存一份、Flash 里存一份、固件里带一份，三者不一致就拒绝执行测试并报配置错误。

第三，留一个“IST 禁用”的逃生开关。不管测试做得多小心，总会有现场出问题需要临时关掉的场景。这个开关要能做到不重新烧录固件就生效，而且要留下审计记录，不能变成悄悄关掉就没人知道。

第四，结果数据要能带出来。IST 的价值一半在测，一半在数据。如果结果只存在设备里，客户不导出来，那这半边的价值就丢了。我建议在售后诊断协议里就规划好读取 IST 历史记录的接口，包括最近若干次的执行时间、结果、失败分组，这一条在返修争议处理上非常有用。

6. 成本账：面积、功耗、时间怎么算

6.1 面积与功耗的实际代价

面积上，IST 相关逻辑的成本主要来自四块：扫描链本身、MBIST 控制器与存储器周围的测试逻辑、测试控制器与调度状态机、以及签名压缩与结果寄存器。前两块属于常规 DFT，绝大多数设计本来就有；IST 额外增加的主要是后两块。

按我的经验，测试控制器加压缩逻辑加寄存器组，在中低复杂度设计上通常占逻辑面积的百分之一到百分之三。如果再加上私有高速测试通道和对应的地址空间解码，可能到百分之四。这个数字听起来不大，但在成本敏感的芯片上是要认真算的。压缩做法很简单：如果你的产品支持片上软件升级，那它已经有一条高速数据通道了，尽量复用这条通道做 IST 数据加载，不新开私有通道，能省下相当一部分面积和解码逻辑。

功耗上，压力主要在测试模式。扫描移位的翻转率远高于功能模式，因为移位时每个触发器每个周期都可能翻转，而功能模式下绝大多数触发器很少动。翻转率高直接带来动态功耗高，如果测试时钟频率又高，瞬时电流可能超出整机供电能力，导致电压跌落、测试失败甚至复位。常见的控制手段有：降低测试移位频率、采用低位填充向量（用 0 填充无关位来降低翻转）、分区域轮流测试而不是全片同时跑、在测试期间让无关模块保持时钟门控。这几条里，低位填充是最有效也最便宜的一条，代价是可能略微影响某些测试的故障覆盖，需要做权衡。

还有一个容易忽略的点：测试模式下的电源网络余量。功能模式的电源网络是按功能功耗设计的，测试模式功耗可能显著高于典型功能功耗，如果电源网络设计时没有把测试模式作为最坏情况考虑，测试期间就可能出现电压跌落导致误报。这一条必须在电源规划阶段就跟 DFT 团队对齐，流片之后无解。

6.2 时间预算的分配方法

时间预算是 IST 项目里最容易失控的东西，我推荐一个固定的分配框架。

对上电自检，把窗口按下面比例分：存储器自检占四成、关键逻辑自检占三成、加载与配置开销占两成、余量一成。为什么存储占大头？因为存储自检的覆盖性价比最高，而且 MBIST 的启动最不依赖外部条件。为什么留一成余量？因为实际跑起来永远比估算慢。

对周期自检，不要设总时间上限，而要设“单次占用比例上限”。我的做法是单次后台自检占用的总线带宽不超过百分之十、CPU 时间不超过百分之五，这样在任何功能负载下都不会明显影响实时性。按这个比例，一套完整向量的跑完时间可能长达几十分钟甚至几小时，这没关系——周期自检本来就不追求快速完成，追求的是不影响功能的前提下持续监控。

有一个判断值得分享：如果一套 IST 方案跑完一轮需要的时间超过设备两次维护之间的间隔，那它就失去意义了。设计时要先算一轮的耗时，再跟设备的实际工作周期比。差距太大的话，要么砍向量，要么接受不完整覆盖。

6.3 全生命周期的收益怎么估

最后说收益估计，这块很难算准，但有个简化模型可以用。

把设备的失效分两类：一类是能被 IST 提前发现并处理的，一类是不能的。收益主要来自前者的三个途径：避免整机现场故障（省下停机损失）、把故障定位从板级缩小到芯片级（省下返修工时）、提前预警让计划性更换替代非计划停机。你要做的是估计这三个途径各自能省多少钱，再乘上“IST 能提前发现”的比例。

这个比例怎么估？我一般用两成到四成的区间来算敏感度。如果按两成算都不划算，那基本可以放弃了；如果按两成算划算、按四成算非常划算，那值得做完整方案。这个模型的好处是简单，坏处是需要真实的历史故障数据支撑。没有历史数据的项目，建议先上一套轻量的 IST 收集数据，跑一年再回头算这笔账，用真实数据做决策比用假设强得多。

7. 不同行业形态：IST 的落地差异

7.1 车载域控：上电自检加周期自检的组合拳

车载是 IST 应用最成熟的领域，因为它有明确的标准要求。典型做法是双轨：上电自检在钥匙拧到 ON 之后的几百毫秒内完成，覆盖存储器、互联和一部分关键逻辑；运行期间由软件调度周期自检，覆盖更广的逻辑和平时测不到的部分。两者用不同的签名寄存器，避免互相覆盖。

车载场景下有几个特殊要求值得单独说。一是诊断结果必须可读，通过标准诊断协议把 IST 历史读出来，这是售后和年检都要用的。二是测试过程不能影响功能安全，测试期间功能逻辑是停摆的，所以周期自检必须选在车辆状态安全的时候做，或者把测试拆得足够细，每次只停极小一部分。三是温度范围宽，从零下几十度到上百度都要能跑，这直接把前面说的温度角评审变成必做项。

7.2 通信与工业设备：以现场诊断和返修定位为主

这类设备的特点是常年不间断运行、单台价值高、现场返修成本极高。IST 在这里的首要目标不是“符合标准”，而是“坏之前给信号、坏了之后说得清”。

我的做法是把重点放在可读的故障记录上。除了通过失败，还要记录失败发生在哪一类资源、是首次出现还是累计多少次、当时的温度和工作电压区间是什么。这些信息组合起来，实际上就是一份健康档案。有客户用这套数据把非计划停机比例降下来了，靠的不是提前修，而是根据健康档案发现某批设备的某个存储器块退化趋势异常，提前做了计划性更换。

7.3 消费与物联网：做减法比做加法重要

前面说过低成本的物联网模组不建议上完整 IST。但如果因为某些原因必须上，那就做减法：只保留 MBIST 加一条最关键的扫描链，结果只用一个状态位加一个计数，时间预算压到几十毫秒。这种极简方案能覆盖存储器退化这一大类失效，成本几乎可以忽略，剩下的交给筛片和老化试验。

判断做减法的边界在哪，我的经验是看这块存储器如果失效，设备会是什么表现。如果表现为上电不启动、完全无响应，那它大概率会在出场测试或者早期就被筛掉，IST 的价值有限。如果表现为运行中偶发数据错误、且难以复现，那 IST 就非常值得做，因为它把一件极难排查的事变成了一个明确的状态位。

8. 后续扩展方向的一点个人看法

IST 这个方向往后走，我看到两个明显趋势。一个是从“判定通过失败”往“量化健康度”走，也就是不只是告诉你签名对不对，还要告诉你余量有多大。实现路径通常是片上延时监控加标定表，把测量值映射成一个可比的质量指标，然后看这个指标随时间的漂移速度。这件事的难点不在硬件，在于标定——每颗芯片的基准都不一样，要不要做单片标定、标定数据怎么存、温度补偿怎么建模，这些都要想清楚。

另一个是从“单芯片自检”往“系统级自检”走，把芯片内部的 IST 和板级互联、整机功能自检打通，形成一份统一的结果。我在一个项目上试着做过，最大的阻力不是技术，是各方对“谁的测试结果更可信”的争论。最后的解法是把三层结果都保留、分别记录，只在顶层做一个汇总视图，不去争谁的结论优先。这个思路我觉得更实际。

我自己在实际操作中的体会是，IST 这件事最难的部分从来不是测试逻辑本身，而是跨团队的口径统一：DFT 关心覆盖率，软件关心时间预算，系统关心误报率，售后关心可读性，这四个指标经常互相打架。我踩过几次坑之后的做法是，在项目启动会上就把这四项指标写成一张表，写明各项的目标值和不可退让的底线，后面每次评审都对着这张表看。这比任何技术方案都更能决定一个 IST 项目最后能不能真正上线运行。最后再分享一个小技巧：IST 的向量集不要一次追求完整，先上一套最小可用的，让它真的在设备上跑起来、把数据收上来，然后根据真实数据去决定往哪里加向量。纸上算的覆盖度，永远比不上现场跑出来的那一次记录。