我之前遇到过一件事帮同事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-ShiftLOS的原理和代价在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-CaptureLOC的原理与工程优势和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很少是因为“哪个覆盖率更高”这种单一指标决定更多是在时序收敛、后端工作量和覆盖率之间做权衡。对比维度LOSskewed-loadLOCbroadside故障覆盖率通常更高略低但可通过pattern数量弥补SE时序要求极高SE需在launch沿附近快速翻转低SE提前变为0即可时钟树/CTS约束严格需要精细设计宽松适合常规后端流程后端DFT工作量较大较小ATPG运行时间通常较短通常较长pattern数量更多典型应用场景高性能CPU、超高速接口大多数SoC/ASIC量产项目我自己的经验是量产项目如果后端时序收敛压力很大优先选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沿在t10ns处上升Capture沿在t20ns处上升”。如果这些偏移值和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沿直接丢了有一块低功耗SoCRTL里用了大量集成时钟门控单元。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机制的延伸和扩展。