做可测性设计的工程师应该都经历过这种场景网表里扫描链已经全部插入成功覆盖率数字也说得过去可是一跑测试仿真密密麻麻的X态一路往下传查了半天才发现是某个时钟沿和扫描使能沿没对齐。这时候多数人的第一反应是去翻仿真波形对着一个信号盯半天。我现在的做法是先别急着开波形回到Tessent Shell里把ETChecker跑一遍把边沿关系的问题提前扫干净。这一篇是Tessent专栏的第二篇上一篇聊了Tessent Shell的基本用法和它在整个DFT流程里的位置这一篇专门把ETChecker拿出来讲清楚。内容定位是介绍(1)所以我会先把它的职责边界、入手方法、常见误报和工程化经验讲透。写这篇内容之前我先说明白下面提到的命令和参数很多是我按实际使用习惯写的示意具体语法要以你本机安装的Tessent版本帮助为准但执行的思路和排查的路径是通用的。1. ETChecker从哪一步开始介入DFT流程1.1 一个让我彻底重视ETChecker的场景先说一个真实发生过的情况。之前某颗芯片主控制器里有一段逻辑依赖内部生成的高速测试时钟功能仿真怎么跑都正常综合也没有问题但ATPG仿真一跑从某个锁存器开始后续所有寄存器的值全部变成了X。查了整整两天最后定位到是测试时钟使能和锁存器的透明窗口发生了冲突导致数据在锁存器里被意外穿透。这个问题的本质就是时钟事件和扫描事件之间的边沿关系没有对齐。从那之后我形成了一个习惯网表交到ATG之前先跑一遍ETChecker。它的核心价值就是把这类边沿关系不干净的设计隐患在静态阶段暴露出来而不是等到了仿真阶段让X态去感染一片逻辑。说白了ETChecker像是一个专门盯测试事件时序的交警不等出事就先站在路口把问题拦下来。1.2 ETChecker在Tessent Shell里的位置Tessent Shell里其实有一整套检查工具有些人会把它们混在一起觉得都是跑个检查命令出一份报告。实际上它们解决的问题完全不同。如果放在一条产线上来类比DRC是查结构LEC是查功能等价STA是查时序裕量而ETChecker查的是测试模式下面事件与事件之间的边沿关系是否一致。它关注的是这个沿到底该不该在这个时刻出现而不是这个路径能不能在这个时钟周期内收敛。所以它的位置很特殊既不是纯粹的结构检查也不是纯粹的时序收敛工具而是一个面向DFT测试模式的静态事件检查器。在Tessent Shell里ETChecker通常会在网表准备好、时钟约束和复位约束声明完成后运行它的输入是网表和约束环境输出是一份关于事件冲突的报告。理解了这一点你就明白了为什么有些人跑完ETChecker会一脸茫然——因为他们在拿DRC或者LEC的思路去解读结果自然对不上号。2. ETChecker到底在查什么我把它的职责拆成三块2.1 名字怎么念不重要重要的是它盯住的问题关于ETChecker的全称不同资料里的口径并不完全一致有人说是Edge Trigger Checker有人说是Event Test Checker。以我自己的使用经验我更倾向于把它理解为面向测试事件的边沿一致性检查器。与其纠结缩写到底代表哪几个单词不如看它实际做的事情它遍历网表里的时钟信号、扫描使能信号、复位信号以及由这些信号衍生出来的各类门控逻辑检查它们在被激活或者释放的时候相互之间的边沿关系是否存在竞争和冲突。这个定位很关键。因为DFT模式下的信号行为和功能模式有一个很大的差异测试时钟、扫描使能、复位释放这些事件很多是由同一组测试引脚或者控制器逻辑同时驱动的。在功能模式下这些信号各有各的约束时序收敛是综合工具和STA工具保证的但在测试模式下它们的相位关系可能会变得非常微妙。ETChecker就是专门盯这块的。2.2 三类真正值得交给ETChecker的检查我在项目里实际依赖ETChecker的场景大致可以分成三类。第一类是扫描使能与采样时钟沿的关系。扫描使能信号释放的沿和时钟捕获的沿之间如果间隔不够或者沿方向配错了就会出现同一拍里既想捕获又想移位的混乱情况。ETChecker会把这类风险按事件类型列出来。第二类是复位释放沿和第一个捕获沿的关系。异步复位信号释放的那个时刻和紧随其后的时钟采样沿之间必须满足一个合理的间隔。如果复位释放太靠近采样沿寄存器的输出状态就很难确定这在仿真里典型表现为复位后的第一拍出现不定态。第三类是门控时钟的使能沿问题。现在设计里大量使用ICG单元门控使能沿落在什么位置决定了时钟上升沿是不是会被削掉或者多出一个毛刺。ETChecker会根据网表里锁存器的透明窗口属性去比对这个使能沿是否落在安全区间里。2.3 边界ETChecker不管什么我自己刚接触ETChecker的时候最迷惑的地方是它和静态时序分析之间的边界。后来一个做DFT时间很长的朋友点了我一句ETChecker只回答这个边沿关系是不是存在潜在冲突不回答这个路径时序上能不能收敛。换句话说它不计算setup和hold的裕量也不管负载和延迟它管的是逻辑上的事件顺序和相位关系。这个边界一定要记清楚否则你会拿着ETChecker的报告去跟做STA的同事争论最后发现两个人聊的完全是两件事。同样它也不是用来替代DRC的网表里的短路开路、单元连接错误这些问题ETChecker不负责也报不出来。3. 第一次跑通ETChecker从启动Shell到看懂报告3.1 进入Tessent Shell后先别急着读网表很多人拿到网表第一件事就是read_verilog然后急着跑检查。这个顺序其实是错的。我建议进入Tessent Shell后先加载单元库文件再读网表最后再声明时钟和复位。原因是ETChecker在判断门控时钟使能沿的时候需要知道锁存器的透明窗口、单元的内部延迟信息这些信息都来自库文件。如果库没加载检查器就会用默认的安全模型去猜猜出来的结果往往是一堆莫名其妙的误报。这是我踩过的实实在在的坑。第一次跑ETChecker的时候忽略了库加载这一步结果报告里报了几百条门控时钟问题几乎全是假的。后来把库加载进去再跑干净多了。所以如果你跑出来的结果异常夸张先回头检查库文件到底有没有加载成功。3.2 模式设置与时钟、复位声明的执行顺序Tessent Shell里有一些模式概念不同模式下面检查的语义会有差异。我一般在做ETChecker的时候会先把当前的模式切到测试捕获模式然后再去声明时钟和复位。这样检查器会按照捕获过程中实际看到的事件顺序去分析而不是按照功能模式下的行为去分析。具体执行思路可以用下面这段示意命令来理解# 以下命令仅为执行思路示意具体语法以本机版本帮助为准 tessent read_cell_library slow_vdd1_lv.lib tessent read_verilog top_dft_netlist.v tessent set_current_mode capture tessent add_clocks -port clk_test -period 10 tessent add_resets -port rst_n -active_low tessent check_test_events tessent write_check_report etchecker_result.txt这个顺序里set_current_mode放在时钟声明前面我个人认为是比较稳妥的。因为模式定了之后后面声明的时钟和复位会被放到正确的上下文里解释。如果反过来先声明时钟再切模式某些版本里可能会出现时钟事件归属不清晰的情况。3.3 输出报告的三种状态怎么读ETChecker的报告通常会把检查结果分成几类。我自己习惯简单分成三种状态来看正常通过的、风险疑似的、明确违规的。正常通过的不说了。风险疑似这一类报告里往往会用可能需要确认这类词汇比如某个跨时钟域路径上的事件传递。很多新人看到疑似就紧张看到违规反而没什么感觉这是不对的。我的经验是明确的违规通常是真问题但是数量不会太多而那些一大片的疑似项才需要你逐条过一下因为里面可能藏着真正的边沿冲突也可能只是约束没写完整造成的误报。另外报告末尾一般会有一个汇总表格我每次都会先看汇总再倒回去看具体条目而不是从头到尾硬刷一遍。一千条报告从头刷到尾人一定会麻抓不住重点。4. 第一批跑ETChecker必然撞上的五个坑4.1 内部生成时钟没显式声明误报一堆第一次跑项目的时候我对着报告里铺天盖地的错误发愁后来定位到原因那颗芯片里有一个内部时钟分频逻辑我没有把分频后的时钟显式声明成生成时钟。检查器在网表里看到这些分频节点总觉得它们跟主时钟的关系是乱的于是把所有经过这个分频器的路径全都报了一遍。解决思路也很直接把所有内部生成时钟的源头显式加进时钟声明里让检查器知道这个时钟是从哪来的、分频关系是什么。做完之后报告数量直接降了一个数量级。这个坑的普遍性非常高凡是设计里有分频、倍频、门控的第一件事就是先把时钟树完整声明一遍。4.2 异步复位释放沿被按同步方式检查另一个让我折腾了一段时间的问题是异步复位。ETChecker默认会按比较保守的方式来分析复位释放和时钟沿的关系如果你的复位实际上是通过异步释放再到同步器打拍的方式进入逻辑的需要把这个事实告诉检查器否则它会按最糟糕的假设给你报一连串的复位释放冲突错误。我一开始以为报错是网表的问题盯着复位树看了半天最后才意识到是约束没沟通清楚。处理方式就是在命令里对复位信号增加异步处理或者同步释放的相关声明让检查器知道这条复位的实际释放路径。这个事在项目交接的时候特别容易出问题因为做DFT的人和写RTL的人对复位的理解角度不一样你跑出来的假报错源头往往是两边约束语义不一致不一定是ETChecker本身的问题。4.3 门控时钟使能沿与锁存器的透明窗口门控时钟是ETChecker的重点关注对象也是最容易出假报错的区域。门控单元里锁存器有一个透明窗口使能信号必须在窗口关闭的时候变化否则时钟输出就有可能被截断。检查器会根据库里的单元信息来判断这个关系。在这个问题上我踩过的坑是某个项目里用了一个自定义的门控单元变体库文件里对它的透明窗口描述不完整ETChecker读不到足够的属性信息就直接报了十几条使能沿违规。后来确认了库文件缺失相应属性补上之后再跑就全清了。所以当你看到门控相关问题集中爆发而且区域都集中在某几个特定单元上的时候先怀疑库信息而不是先怀疑网表逻辑。4.4 跨时钟域路径被当成同域事件处理现在芯片几乎都是多时钟域设计跨时钟域的路径本身在功能设计里有自己的同步策略。但到了测试模式下扫描链可能会把不同时钟域的寄存器串在一条链上而检查器默认的分析假设未必完全符合你实际的同步方案。这类报告通常表现为疑似级别的提示说明两个不同时钟域的事件之间存在潜在交叉。我的处理经验是不要直接去过滤这些报告也不要盲目加约束把所有跨域都定义成异步关系。正确做法是把每个跨域点找出来确认它在功能设计里的同步机制是什么、在测试模式下是否还有意义然后分类处理。这个步骤虽然费时间但是值得因为跨时钟域的边沿问题一旦在仿真里炸开定位成本远高于检查阶段的分类成本。4.5 报告里定位困难时如何快速找到具体单元ETChecker报告里会给出和问题相关的路径和单元名但有些复杂场景下报告看起来像天书不知道该从哪里下手。我的做法是先用报告里的关键单元名在网表里搜找到它在层次化结构里的位置再往上游和下游各看一级。很多边沿问题看上下游一级就能明白事件是怎么传过去的。如果项目里开了调试工具可以直接把报告里的路径高亮到电路图上比对着网表文本找快得多。另外我习惯把报告输出成文件然后按问题类型做排序和分组再逐组处理。一次处理一类问题效率远高于逐条处理因为你处理同一个根因产生的几十条报错不用每条都从头分析一遍。5. 让ETChecker长期可用的三条工程经验5.1 约束的完备性决定报错质量跑了几次ETChecker之后我越来越确认一件事这个工具跑得干不干净七分靠约束三分靠网表。如果你的时钟声明不完整、复位信息缺失、门控单元库属性不全ETChecker只能靠默认假设去猜猜出来的结果就是满屏误报。反过来约束给得越充分报告越干净偶尔冒出来的一条错误基本就是要重点关注的真问题。所以我现在会专门维护一份给ETChecker用的约束文件跟综合约束分开管理。这份文件里记录所有测试时钟、复位、异步路径、门控单元相关的声明网表每更新一版我先把约束文件核对一遍再跑检查。这种习惯看起来不起眼但能帮你省掉大把看报告的时间。5.2 用基线化管理替代人工看海量报告ETChecker这类工具跑出来之后很多人会把报告扔给团队里的人看一下。我的建议是尽快做基线化。也就是说第一次把网表和约束调干净之后把这份报告存为基线后续每次网表改动只对比新旧报告之间的差异。这样做的好处很明显如果这份网表本身就没什么问题每次跑出来几百条信息里面大多数是重复的、已知的、可以解释的。真正需要关注的只是新增的那几条。我管这个叫增量审查。没有基线管理的话每次面对几百条报告人的注意力很快就会被疲劳感吞噬真正的变化项反而被淹没了。基线化之后看报告变成一件轻松的事先看增量再决定要不要深入。5.3 低功耗与多模式场景下的联动注意如果你负责的芯片还带了UPF低功耗设计ETChecker的使用会再复杂一层。因为电源关断域内的寄存器在测试模式下可能处于隔离或者保持状态这些状态下的时钟事件和扫描事件关系跟正常上电状态下完全不同。ETChecker需要知道UPF里的隔离逻辑、保持逻辑和复位逻辑这些额外的约束信息否则会把电源关断域内本来正常的行为当成冲突来报。多模式场景也一样。同一个网表捕获模式、移位模式、低速测试模式、高速测试模式ETChecker对边沿关系的判断结果是不同的。我在项目里会在脚本里轮流切模式跑几遍然后分别收集报告而不是只跑一次就下结论。有人觉得这样麻烦但每次多花十几分钟能拦下不少后面仿真阶段要花一两天才能定位的问题。6. 关于ETChecker这个系列我后续打算怎么展开这一篇我主要把ETChecker的定位、职责、首次运行流程和最常见的几个坑讲清楚了。因为是介绍(1)所以涉及到的具体命令和参数没有展开到很深的程度更多是把骨架搭好。按照我自己的使用脉络下一部分我准备重点写两块内容一是如何把ETChecker的报告结果和仿真波形做交叉定位也就是报告里报出的疑似项怎么在波形里快速验证、快速判真假二是更细的检查命令族和参数项比如不同检查类别对应的关键字、报告过滤条件怎么写以及如何把这些检查集成到自动化回归脚本里。写到这里说点个人感受ETChecker这个工具刚接触的时候会觉得它不过是一个普通的检查命令跑完看一眼报告就完了。但用得越久越会发现真正让这个工具有价值的其实是使用它对整个测试模式事件体系的理解。你把时钟、复位、门控、跨时钟域这些关系都梳理清楚了它反馈给你的报告才会是可靠的。反过来你越急着过滤报错它就越容易把真正的隐患藏在一堆噪音里。这也是我强调先补约束、再做基线、最后才谈过滤的原因。
