我之前遇到过一件事：帮同事review一组transition fault的测试向量时，生成结果和功能仿真都过了，可一上ATE就出现偶发的不稳定。几个人排查了大半天，最后定位到问题竟然出在Launch和Capture两个时钟沿的配置上——工具默认按下降沿当发射沿，可那块设计里的扫描触发器是上升沿触发，等于所有向量都把“发射”动作放错了位置。那次之后我就一直想写一篇关于Scan测试里Launch与Capture机制的文章，因为这东西几乎决定了at-speed测试能不能真正跑到点子上，但它恰恰是很多DFT工程师和测试工程师容易一带而过的地方。

这篇文章会从Launch与Capture在扫描测试里的真实分工开始，讲清楚LOS和LOC两条路线的差异，再把时钟、SE控制、EDT压缩这些实际操作里躲不开的细节拉出来过一遍，最后分享几个让我花过不少时间的排错案例。适合刚接触DFT的芯片工程师，也适合已经跑过几轮at-speed pattern、但始终觉得“这个沿的时序没完全吃透”的同行。

1. 别把Launch和Capture理解成“发射”和“接收”：它们在测试流程里的真实分工

1.1 Shift阶段只是摆好姿势，真正的状态变化要从Launch沿说起

扫描测试的基本流程看起来很简单，就是把触发器串成链，Shift时用移位时钟把测试向量推入各条扫描链，再给一个Capture时钟把响应锁存回来。但很多人没细想的是：Shift阶段做得再多，电路内部也只是搭好了一个确定的静态状态，并没有发生功能意义上的跳变。

真正让电路“动起来”的，是Launch沿。

Launch沿产生的时机是在SE信号从1变为0之后。它之所以重要，是因为触发器从这个沿开始切换到正常工作路径，数据会从功能D端进入。对transition fault测试来说，Launch沿要制造一个跳变：信号从0跳到1，或者从1跳到0，然后这个跳变沿着组合逻辑向后传播，直到下一个触发器的D端。等Capture沿到来时，如果D端已经稳定到期望值，那就说明这条路径能在规定时间内完成任务。

我喜欢用一个弹球的类比来解释：Shift阶段相当于把球摆到斜坡顶端，摆好位置但球还没动；Launch沿就是松手，让球真正开始滚；Capture沿相当于在斜坡底部按下快门，确认球有没有在指定时间内滚到底。如果把快门按下得比路径真实耗时早，球的惯性还没到，明明可以通过的路径被判成失效；如果按下得太晚，又会掩盖真正的慢路径缺陷。

这就是为什么Launch和Capture不是两个孤立的时钟脉冲，它们之间的关系，本质上就是被测路径的时序窗口。

1.2 Capture沿锁定响应，但锁定质量取决于launch到capture的距离

Capture沿的工作是锁存组合逻辑输出。这个沿出现的位置窗口，直接决定了被测的是哪一段路径。

以最常见的two-pulse方式为例：一个Launch沿让所有信号开始转换，经过一个周期的传播时间，Capture沿再把结果锁入扫描触发器。这里有一个关键前提——Capture沿和Launch沿之间的时间差，必须和真实功能路径的时钟周期一致。如果捕获沿来得早，等于拿一个比真实工作频率更快的时钟去测，所有路径都会变得很紧，测试结果会过度激进；如果捕获沿来得晚，相当于放慢频率，小延迟缺陷会被掩盖。

很多人误以为ATPG工具会自动处理好这件事。但工具的“自动”是建立在约束正确的基础上的。如果SDC里写错了时钟周期，或者设计里存在门控时钟、分频时钟，工具默认找出来的Launch沿未必落在真实的触发沿上。上文提到的那个ATE偶发不稳定案例，本质就是工具和机台对“哪个沿算launch”理解不一致。

1.3 为什么stuck-at测试只有一个Capture脉冲，而transition测试必须拆成两个沿

有一类测试不需要Launch，就是最经典的stuck-at测试。它检测的是静态逻辑故障，比如某根信号固定为0或固定为1。对这类故障来说，只要给一个稳定的激励，等组合逻辑输出稳定下来，慢速Capture一次就能看到结果。

而transition fault测试关注的是信号能不能在限定时间内完成指定的转换，这从本质上是一个动态问题。“能不能转换成功”和“转换速度够不够快”是两件事。要测清楚这两件事，就必须用两个沿：先用Launch沿制造跳变，再在设定的时间点用Capture沿去观察跳变是否在容限内完成。

有些刚开始写测试程序的工程师会把stuck-at和transition的两拍混在一起，认为给两个脉冲就更保险。实际上对stuck-at测试硬塞两个脉冲，不但浪费测试时间，还可能因为第二次capture把本已稳定下来的状态推翻，让测试结果变得不可解释。正确的做法是：stuck-at一拍捕获，transition两拍发射加捕获。

2. LOS与LOC：两条完全不同的发射-捕获路线，选错可能让测试白跑一轮

2.1 Launch-off-Shift（LOS）的原理和代价

在at-speed测试里，实现Launch与Capture最直接的方式叫Launch-off-Shift，也就是经常听说的LOS，也称作skewed-load方式。它的核心思想很简单：把扫描移位过程中的最后一个时钟沿直接当成发射沿。

具体过程是这样的。电路一直处于Shift模式，SE信号为1，最后一个移位脉冲把链上的所有扫描单元格子填满。这个最后一个沿本身就是Launch沿，它在SE仍然为1（或刚刚跳变到0）的时刻，完成了一次数据的移入。紧接着，SE快速跳变为0，电路退回功能模式，然后很短时间后产生Capture沿。

LOS的优点非常明显：因为Launch沿来自扫描输入，工程师可以精确控制每个触发器在发射时刻的初始值，这对故障激活条件的构造非常有利。实测下来，在同样规模的故障集下，LOS的覆盖率通常比LOC高出几个百分点，生成pattern的数量也可能更少。

但代价也相当直接。SE信号在“最后一个shift沿”和“capture沿”之间必须完成从1到0的翻转，而且留给它的时间窗口极短。如果SE翻转得不够快，或时钟分布网络有偏斜，就会出现部分触发器还在Shift模式、部分已经切回功能模式的混乱状态。这种情况轻则测试失真，重则直接产生亚稳态。

所以LOS并不是一个可以随意选用的方案，它对后端时钟树设计、DFT时钟约束、SE信号的插入位置都有很高的要求。一旦哪一环没做好，LOS测试在ATE上跑出来的数据往往是“看起来有覆盖率，但重复性很差”。

2.2 Launch-off-Capture（LOC）的原理与工程优势

和LOS相对的是Launch-off-Capture，也常被叫做broadside方式。LOC的思路是：先把测试向量完整地移入扫描链，SE信号继续保持为0足够长的时间，让所有触发器稳定下来，然后发出第一个Capture沿——这个沿在这个方案里承担Launch的职责，紧接着再发第二个Capture沿，真正地捕获响应。

简单说，LOC用“捕获沿来做发射”，两个脉冲来自同一组Capture时钟，它们在时序关系上更接近芯片真实的功能操作。

LOC在工程上为什么更受欢迎？因为它对SE信号的要求很低。SE在第一个Capture沿到来之前就已经稳定为0，不存在LOS那种“必须快速翻转”的紧张窗口。时钟树设计也相对轻松，后端CTS只需要保证正常的Capture时钟能到达所有触发器即可，ATPG工具对这种模式的支持也是最成熟的。

代价是故障覆盖率通常会略低。原因是LOC的launch沿初始状态并不是直接来自扫描输入，而是来自上一拍捕获后的结果，这意味着有些路径的初始状态约束无法被精确构造。为了弥补，ATPG往往需要多生成一些pattern，测试时间也会小幅增加。

2.3 工程上怎么选：不是越高级越好，而是看你的设计收敛瓶颈在哪

实际项目中选择LOS还是LOC，很少是因为“哪个覆盖率更高”这种单一指标决定，更多是在时序收敛、后端工作量和覆盖率之间做权衡。

我自己的经验是：量产项目如果后端时序收敛压力很大，优先选LOC，这是最不容易翻车的路线。但如果设计里存在高速模块，或缺陷率一直偏高、需要更高测试灵敏度，可以在关键模块单独用LOS跑一组pattern，和LOC的pattern并行投入。现在有些工具也支持在同一设计里让不同时钟域分别采用LOC和LOS，这种混合模式正在成为主流，因为它兼顾了两边的好处，代价是配置复杂度上升，对时序分析能力要求更高。

3. 时钟沿、SE翻转时刻和脉冲宽度：这些时序参数决定向量在ATE上能不能跑

3.1 一个完整测试周期里，Shift、Launch、Capture的位置关系

把一次测试展开来看，会看到这样一段清晰的时序序列：

• Shift阶段：SE = 1，测试时钟连续输出多个移位脉冲，把下一个向量移入所有扫描链，同时把上一轮的响应从链尾移出。
• Launch阶段：SE变为0，在稳定了足够时间后，输出第一个有效脉冲沿，启动内部状态跳变。
• Capture阶段：紧接着输出的第二个有效脉冲沿，把跳变后的结果锁存进扫描触发器。
• 下一轮Shift阶段：SE重新变为1，继续移位，循环往复。

在这段序列里，Launch与Capture之间的那段时间是整条测试链路上最敏感的部分。这段间隔由测试时钟周期决定，而测试时钟周期又来自芯片功能时钟频率的约束。测试工程师在写ATE时基时，往往需要为Shift阶段设一个低速时钟，为Launch-Capture阶段设一个高速时钟，这就是所谓的“慢速移位、快速捕获”策略。

这个策略的意图很容易理解：Shift阶段要推入大量数据，但此阶段不关心时序细节，用慢速时钟可以降低测试功耗和信号噪声；而Launch到Capture这段窗口则必须模拟真实工作频率，否则transition fault测试就失去了意义。实际配置ATE的时候，这两个时基之间的切换时刻必须精确控制，我见过不少测试程序就是因为时基切换早了或晚了半个周期，导致一整个向量组全部废掉。

3.2 SE信号是at-speed测试最容易忽略、也最容易翻车的环节

很多做DFT的新手在分析时序时，会花大量时间盯着时钟沿，却忽略了SE信号。但在at-speed测试里，SE恰恰是最容易出错的控制信号。

一个很常见的错误场景是这样的：设计里的SE由测试引脚直接驱动，当测试时钟频率很高时，SE在Launch沿到达的瞬间还没来得及稳定到0，或者发生了跳变边沿的毛刺。这时部分扫描触发器仍然处于Shift模式，那个所谓的“Launch沿”实际被当成了又一个Shift沿，整个链上锁存的位就会被推偏一位。响应数据从Capture沿读出来时，看起来信号都对齐了，实际上压缩器里对位的早已错位，退网失败后需要很长时间才能追查到位移误差。

想尽量避免这个问题，必须做好两件事。第一，在网表或RTL里给SE加同步逻辑，让它和测试时钟域保持确定的时序关系；第二，在STA和ATPG约束里，把SE声明成伪静态信号（case analysis为0或1），禁止工具在Shift和Capture交界处对SE做不合理的时序假设。

3.3 多时钟域下的跨域Launch与Capture：能测才测，不能测就约束住

一个复杂SoC里往往有多个异步时钟域，CPU、总线、外设、模拟模块各自跑各自的频率。这种情况下，ATPG对launch与capture的处理要比单时钟域复杂得多。

如果两个时钟域之间没有确定的相位关系，那么一个时钟域的launch沿和另一个域的capture沿之间的间隔就不是固定值。此时如果ATPG强行跨域做launch-capture，测试结果不但不可复现，甚至连仿真故障模拟都会出现海量的未知态。标准做法是在工具里把异步时钟定义成不同的时钟组，让ATPG默认不测跨域路径，或只做静态stuck-at测试。如果两个时钟域之间存在同步器或FIFO，且约束明确，可以把它们放进同一个时钟组，允许ATPG生成跨域transition pattern。

这里我想特别提醒一点：跨时钟域路径在覆盖率报告里不应该被简单当成“可测但未覆盖”。如果大量跨域路径因为异步关系被排除在测试之外，需要评估它们对应的功能路径是否由其他机制（比如系统级测试、软件自检）兜底。否则这里的“漏测”会成为一个长期隐患，尤其是芯片量产之后出现特定的耦合失效时，很难用常规扫描pattern定位。

3.4 在WGL和STIL文件里“看见”launch与capture，而不是只靠工具生成的波形图

如果有机会直接打开ATE的WGL或STIL测试向量文件，就会发现launch和capture的时序最终会落到具体的Timing和Waveform定义里。

WGL里会为每个测试时钟定义若干个波形形状，比如：Shift的时钟可能是普通方波，而Launch和Capture常常被定义成带绝对偏移的沿。偏移值一般是用ns为单位写死的，比如“Launch沿在t=10ns处上升，Capture沿在t=20ns处上升”。如果这些偏移值和SDC里定义的时钟周期不一致，ATE上就会看到测试时间很短但良率下降、或过测变多。

我平时会习惯直接在WGL/STIL文件里搜索波形定义，反查每个launch/capture沿对应的绝对时刻，然后再对应到std cell仿真波形上做交叉检查。这个过程看起来繁琐，但对多时钟域设计特别有效——曾经有一块芯片因为两个时钟域在WGL中的launch偏移互相差了一个shift周期，仿真全过，上机后stuck-at都稳定，唯独transition pattern忽好忽坏，最后就是靠逐行检查STIL的Timescale才定位到问题。

4. ATPG配置与EDT压缩：从工具侧把Launch/Capture真正落地

4.1 ATPG里最常调的那些Launch/Capture相关选项

把设计网表读进ATPG工具之后，真正决定launch和capture起源的，是几个看起来不起眼的配置点。

第一是pattern类型。如果跑的是transition故障，需要在工具里明确launch-off-capture或launch-off-shift。工具对这两类pattern生成的内部时序模板完全不一样。第二是capture周期数。Transition fault测试默认是两拍，但有些自定义故障模型可能需要更多捕获周期，这里要谨慎修改。第三是时钟组定义。多个异步时钟域必须分到不同的组，工具才会自动把跨域路径从launch/capture时序分析范围里排除。

另一个容易被忽略的是扫描单元库里的触发沿属性。有些库里的触发器是上升沿触发，有些是下降沿触发，还有少数混合了两种沿。ATPG生成的launch和capture沿必须根据实际情况映射到正确的极性，否则就会出现我在开头提到的那个案例——工具默认把launch放在下降沿，可设计的触发沿在上升沿，整体错位。

建议在每次跑ATPG之前，先花半小时检查一下时钟信息报告，看看工具理解到的launch沿和capture沿是否和你预想的一致。这比跑完几百轮pattern之后再去查数据异常要划算得多。

4.2 “scan链过长，EDT会覆盖不到吗”：真实项目里的完整分析和排查路径

关于EDT和长扫描链的关系，网上的说法其实很混乱。先给一个比较严谨的结论：EDT的故障覆盖率本身不会因为扫描链变长而直接下降，但链长会显著影响shift周期数，从而改变pattern的加载/卸载效力和测试时间。真正的风险不是“覆盖不到”，而是“效率流逝”和“数据在长链上被压坏”。

EDT（内嵌确定性测试）的核心价值在于，芯片内部的大量扫描链可以并行移位，外部只需少数几个测试通道。每条链的长度决定了单个pattern需要多少个shift周期。假设一条链有3000个触发器，那么每个pattern必须经过至少3000个shift周期才能完成一次load/unload。如果链与链之间的长度差异特别大，短的链只能空等，测试时间就被最长链锁死。

如果发现覆盖率上不去或pattern数异常膨胀，我的排查路径一般是这样的。先看EDT报告里的channel utilization——也就是每个外部通道是否都塞满了有效数据，如果利用效率低，很多周期都在传输无效位，链的均衡性就要重新评估。再跑一个简单的chain test，确认每条长链上的数据能否完整、无冲突地load/unload——这一环节最常见的失败是链上出现了未知态，这些未知态一旦进入EDT压缩器，会污染同一通道内其他链的数据。最后再检查end-of-chain的掩码配置，确认长链末端的扫出数据没有被压缩逻辑吃掉。

4.3 X态污染：EDT压缩器对launch/capture沿上不定态的反应

EDT压缩器的存在，让测试通道数大幅减少，但也带来了一个新的敏感点：它对X态异常敏感。在launch沿或capture沿附近出现的任何X态——比如未初始化的触发器、被异步复位释放的寄存器、被时钟门控盖掉的路径——都会通过压缩网络传播到观测端，把其他并行链里原本有效的观测数据也覆盖成未知。

这在很多实际项目里表现为：故障注入率正常，覆盖率却突然掉头，或同一组pattern在几个批次芯片上观测到的失效不一致。定位方法也比较固定：把捕捉到的响应和仿真器的“无故障响应”做比对，找出哪些通道数据被X态污染，再反推出污染源所在时钟域或信号组。

要彻底解决，光靠ATPG的X态屏蔽功能还不够，更重要的是在设计阶段就把异步逻辑约束好。比如复位信号必须在测试模式下同步化，跨时钟域的握手信号不能在alpha测试窗口内产生跳变。DFT约束多花一份心，后面测试阶段就能少掉一大半不可重复的怪问题。

5. 实测排错心得：三个让我花掉整整一周的坑

5.1 门控时钟被旁路后，launch沿直接丢了

有一块低功耗SoC，RTL里用了大量集成时钟门控单元。ATPG跑出来的transition覆盖率挺不错，但故障模拟时总有零星的fail，而且fail的位置不固定，今天是这条链，明天又是另一条链。花了很长时间才发现，问题出在测试模式下时钟门控被旁路的处理方式上——旁路使能信号是异步的，导致某些触发器在launch沿来临时时钟门控还在关闭状态，时钟根本没有到达时钟端。

这个案例带给我最大的收获是：launch沿是否真的“到达”了每个触发器的时钟端，必须依靠门控时钟的测试约束来保证，而不是默认工具能处理好一切。后来我在所有关键门控单元上都加了test mode enable信号，并在SDC里把门控旁路路径声明为测试专用路径，问题才彻底消失。

5.2 LOC覆盖率卡在91%上不去，问题出在初始状态无法构造

另一个项目里，某CPU域的transition fault覆盖率卡在91%左右，怎么加pattern都纹丝不动。查了未覆盖故障分类，发现大量故障的激活条件需要触发器的初始状态为“某一特定向量组合”，而在LOC模式下，launch沿的初始状态是由上一轮capture结果决定的，无法像LOS那样由扫描输入精确指定。

针对这批路径，我换了一种思路：只用LOS模式生成了一组针对性的pattern，单独覆盖这条逻辑子集。覆盖率顺利突破95%，测试时间也没有增加太多。这件事告诉我，LOC和LOS不是什么“二选一”的对立关系，而是可以取长补短的两个工具。覆盖率出现瓶颈时，先看故障分类，再决定要不要引入第二种launch策略。

5.3 复位信号的不定态污染了整个EDT压缩输出

最后一个案例比较隐蔽。EDT压缩器的观测输出在低电压和高温条件下总出现不一致，看上去像压缩器硬件出了问题。排查到最后，发现真正的元凶是某些寄存器的异步复位信号在capture窗口附近恰好被释放，复位释放的瞬间产生了一个X态，经过两级组合逻辑传到EDT压缩器里，干扰了同通道好几位有效数据。

从那以后，我在设计DFT测试规格的时候，对所有复位信号都做了一个铁律：测试模式下复位释放必须由同步逻辑产生，禁止直接在capture窗口附近异步释放。同时会在ATPG里针对这类路径做X态屏蔽。如果设计已经流片无法修改，就只能用工具层约束兜底，但代价是覆盖率会有所损失。

一些写在最后的个人体会

这些年接触过不少扫描测试相关的项目，我最大的感受是，Launch与Capture机制听起来是ATPG工具里的一个普通配置，但它牵扯到的链条远比想象中长——从DFT架构设计、SDC时序约束、后端时钟树，一路延伸到ATE上的WGL/STIL时序定义和EDT压缩配置。任何一个环节对“两个沿”的理解有偏差，最后都会以测试数据异常的形态出现在你面前。

如果你正准备开始跑transition pattern，我的建议是先别急着生成海量向量，而是花半天时间把你设计里所有时钟域在launch和capture沿上的行为画清楚，确认SE信号在每个沿附近的时序，再打开门控时钟的测试约束检查一遍。这套动作看起来很基础，但它能帮你省掉后面无数个查询“为什么覆盖率不达标”的深夜。等这套基础打扎实了，你会发现LOS、LOC、EDT、X态屏蔽这些更高级的话题，其实都只是Launch与Capture机制的延伸和扩展。