scan chain DRC 全流程：违例分类、定位与修复

1. 先把话说透scan chain 与 DRC 到底在解决什么问题做 DFT 的头一年最容易出现的错觉就是scan chain 插进去、网表吐出来、ATPG 跑出个数活就干完了。真正上过几次流片前的 signoff 流程才发现插链只是把结构搭起来真正决定这条链能不能用、覆盖率能不能推上去的是插链之后和 ATPG 之前那段最不起眼的工作——scan chain 的 design rule check业内习惯直接叫 DRC。这篇东西想聊的是一条刚插完的扫描链为什么十有八九是脏的DRC 到底在查什么报出来的那几千条违例里哪些是噪音、哪些是必须回去改 RTL 的硬伤以及从零跑通一次 DRC 到把违例清理干净的完整路径。适合刚入行、被安排接手 DFT 模块的工程师也适合做前端设计、后端实现的同学——因为 DRC 报出来的问题一大半最终要落回 RTL 或约束上去修DFT 一个人扛不下来。先把概念对齐。scan chain是把芯片里数量庞大的触发器在测试模式下串成一条或多条移位寄存器链让外部通过少量引脚就能把任意测试向量移进芯片内部再把内部响应移出来比对。它把原本几乎无法观测的时序单元变成了可控可观测的节点是数字芯片可测性设计里最基础也最有效的手段。而design rule check就是在 ATPG 真正开始生成向量之前对整张网表做一遍结构性体检时钟能不能控住、异步端会不会把链打乱、有没有无法建模的黑盒、有没有 X 传播的源头、链本身接得对不对。检查不通过就直接跑 ATPG结果通常是覆盖率莫名其妙卡在某个数字上不去或者仿真出现一堆 X排查成本比提前查高出十倍。所以这段流程的价值不在于跑一个命令而在于它是把不可测结构提前暴露出来的唯一低成本窗口。流片之后再发现某个模块的时钟在测试模式下根本关不掉那不是改几行代码的事那是整个测试方案要推倒重来。下面所有内容都围绕这个判断展开。2. 规则清单拆解每一类违例背后的电路逻辑2.1 时钟可控性是扫描链的命门扫描链能工作的前提非常朴素shift 阶段所有扫描单元必须能被同一个或几个同步的时钟干净地推着走。所以第一条、也是最致命的一类规则就是扫描单元的时钟端必须来自可控的时钟源。什么叫可控在测试模式下你能通过顶层端口或者测试控制信号把它稳定地打开、稳定地关闭且它的行为可以被工具建模。不满足的典型形态有几种。第一种是组合逻辑驱动的时钟比如某个人为了省一个门控单元用clk en直接当时钟用工具在建模时无法确定这个时钟的相位关系只能报违例第二种是门控时钟单元在测试模式下没有旁路集成时钟门控本身没问题但如果它的 enable 在 scan 模式下被功能逻辑锁死shift 期间时钟就被关掉了链根本移不动第三种是分频/倍频后的派生时钟没有在测试模式下切到统一源导致同一条链上的单元被不同频率的时钟驱动。为什么这条规则排第一因为时钟违例不会给你覆盖率低一点这种温和的后果它直接让链失效。我见过一个模块DFT 插入阶段一切正常DRC 报了几十条时钟违例被当成噪音忽略结果 ATPG 跑出来链完整性测试直接 fail回头查了两天才发现是某个子模块的门控单元 enable 接在了功能寄存器输出上scan 模式下恒为 0。处理思路通常是三条在时钟路径上插入测试模式多路选择scan 模式下切到干净的测试时钟给门控单元补上测试使能引脚让它在前端就被强制打开对确实无法统一的派生时钟按时钟域拆链各自用各自的时钟。注意门控单元的测试使能不是接个常量 1就完事。恒开会让 shift 和 capture 阶段的功耗评估失真正确做法是接测试模式信号功能模式下仍然正常门控。2.2 异步复位与置位最容易被忽视的隐形杀手第二类高频违例来自扫描单元的异步 set/reset 端。道理很简单shift 阶段你在推数据如果某个单元的异步复位突然有效它的值就被强制拉到一个固定电平链上的数据流当场断掉后续所有位全部错位。工具检查的就是这些异步端在测试模式下是否处于无效状态或者是否被一个可控信号统一控制。实际项目里最麻烦的不是完全没接而是接了但控不住。比如某个 IP 内部自带复位逻辑复位源来自一个模拟模块的输出这个输出在数字侧根本不可控又比如复位信号经过一串组合逻辑后扇出到几百个触发器其中某几条路径上还混了功能使能。这些在功能仿真里完全正常因为功能模式下复位本来就该由系统控制但测试模式下你没有那个系统。修复的常见手法是在复位路径上做隔离加一个测试模式或门scan 模式下把复位强制拉到无效电平或者在靠近触发器的地方做局部旁路。这里有个经验性的取舍——尽量在靠近源头的地方做隔离而不是在每个触发器前面加门。前者只改一处面积和时序影响可控后者会让复位树的负载和延迟评估全部失效后端会来找你麻烦。还有一个容易被忽略的点异步端的极性。有些库单元的复位是低有效你在做隔离的时候如果极性搞反功能模式下芯片就起不来了。这类低级错误在 DRC 报告里看不出来因为工具只关心测试模式下的行为所以修完之后一定要跑一遍功能回归别只盯着 DRC clean。2.3 X 源覆盖率的头号敌人X 传播是 DRC 里最玄学也最耗时的部分。所谓 X 源就是那些在 ATPG 建模时无法确定逻辑值的节点未初始化的存储器、没有行为模型的宏单元、双向端口、模拟模块的输出、多驱动总线、未定义的测试控制信号等等。这些节点一旦扇出到时序单元的数据端ATPG 在生成向量时就必须放弃对这些单元的控制和观测覆盖率立刻掉一块。工具通常会把 X 源分成几类来报可控的 X可以通过约束或者测试模式信号屏蔽、不可控的 X结构上就没办法、以及传播路径上的 X。前两类看报告就能分清第三类最烦因为它的源头可能在很远的地方报告里只告诉你某个触发器输入端是 X。处理 X 源的核心思路不是消灭它而是圈住它。业界常用三种手段一是加测试点在 X 源和正常逻辑之间插入一个可控的隔离单元让 ATPG 可以选择切断传播二是在工具里设置 stop point 或者 X-handling 策略让 ATPG 在遇到 X 时主动停止向前推演而不是让 X 污染整片逻辑三是在约束层面用 case analysis 把某些控制信号钉死把不确定的分支裁掉。我个人的偏好是优先用第二种和第三种因为不动网表风险最低只有在 X 源扇出极大、严重影响覆盖率时才考虑加测试点。加测试点是要算账的一个测试点大约等于几个门几百个测试点就是几千门还要评估它对时序和布线的影响不是拍脑袋就能加的。2.4 组合环、锁存器与黑盒三类无解结构的处理姿势这三类结构有个共同点ATPG 引擎对它们的建模能力天然有限。组合环指组合逻辑形成的环路没有寄存器打断。ATPG 做逻辑推演时会陷入死循环或者直接放弃该路径结果就是环上所有节点都变成 X。DRC 会明确报出来修复方式要么是找到环的源头在 RTL 上打断通常是某个使能信号的组合反馈要么是在环上插入测试点强制断开。前者是治本后者是妥协能治本尽量治本。锁存器的问题在于电平敏感。扫描链是基于边沿触发的移位寄存器模型锁存器插在中间会让时序关系变得依赖时钟脉宽工具建模困难而且锁存器本身很容易成为 X 传播通道。现代流程里通常会要求所有锁存器在测试模式下被旁路或者被替换实在替换不了的要在 DRC 阶段标注出来让 ATPG 把它们当作透明或者黑盒处理。黑盒就是没有功能模型的模块第三方 IP、模拟电路、存储器编译器生成的阵列。工具看不到内部只能把输出全部当 X。处理方式是给黑盒建一个简化的行为模型很多存储器厂商会提供带测试信息的模型或者在 DRC 里把它定义为 stop point承认这部分覆盖率拿不到但至少不让它污染其他区域。提示黑盒的处理决定要写进测试计划文档别只留在某个人的脑子里。等到覆盖率评审时才发现某个 IP 的黑盒定义漏了重新跑一轮 ATPG 的时间成本很高。2.5 扫描链结构本身的规则lockup、跨时钟域与多驱动前面几类偏功能结构这一类是纯粹的接线正确性。跨时钟域的链段之间必须有 lockup latch。原因是 shift 时前后两级可能由不同时钟驱动存在相位差如果不加锁存器做缓冲hold 时间会出问题链上数据会在硅片上出错而在仿真里看不出来。DRC 会检查链的时钟域划分发现跨域没有 lockup 就报违例。一个扫描单元不能被分配进两条链也不能它的 scan-in 端被多个驱动源同时驱动。这类违例通常出现在手工改网表或者多轮插链叠加的场景表现是链长统计对不上shift 出来的数据和预期错位。未被扫描替换的时序单元也要报。有些触发器因为综合优化被保留在网表里但没有替换成带扫描功能的版本它们在 shift 期间不参与移位但会在 capture 阶段被时钟打到产生不可控的响应同样影响覆盖率。这几条规则的特点是机械但致命不修就是硬伤没有妥协空间好在定位和修复都比较直接。3. 从环境搭建到跑出报告一次完整 DRC 的落地流程3.1 输入物料清单与库的准备跑 DRC 之前先把物料备齐缺一样后面就要返工。需要的东西大致是带扫描结构的网表RTL 阶段跑早期检查门级阶段跑正式签核检查两者规则集略有差异、标准单元库而且必须是带测试信息的那一版很多库会单独提供一份描述单元扫描能力的文件缺了它工具根本不知道哪些单元能当扫描单元用、哪些有测试使能引脚、异步端的极性是什么。此外还需要扫描链定义文件描述链的数量、每条链包含哪些单元、顺序如何以及测试模式的定义有哪些测试模式信号、各自的默认值、scan enable 和测试时钟怎么接。这里有个很实际的坑库的版本必须和网表综合时用的版本严格一致。我遇到过网表是用 A 版本库综合的DRC 时拿的是 B 版本库两个版本里某个门控单元的引脚定义改了结果工具报了几百条不存在的引脚错误看起来像是设计问题实际上是物料问题。所以在流程脚本里把库版本号写成变量并且打印到日志开头是个很划算的习惯。3.2 测试模式的建立与约束施加DRC 不是静态扫描网表它是在测试模式这个特定工况下做检查所以必须先把工况建立起来。典型做法是先定义测试模式信号并给它们赋固定值测试模式使能拉高、scan enable 拉高进入 shift 状态、测试时钟定义为时钟源、异步复位强制到无效电平。这些约束本质上是告诉工具在这个场景下哪些信号是确定的。这一步最容易出问题的是约束和实际接线不一致。比如 RTL 里测试模式信号是高有效脚本里按低有效写了工具就会在错误的工况下做检查报出来的违例一半是假的另一半真问题被掩盖。我的做法是让约束文件和 RTL 里的参数定义共用同一个来源或者至少在脚本里加一句断言检查把测试模式信号的实际取值打印出来人工确认一遍。另一个细节是时钟的定义方式。有的流程喜欢直接给时钟端口定义周期和波形有的流程只需要声明这是一个时钟而不关心频率。DRC 阶段通常只需要后者但如果你后面要接着做 ATPG最好一次定义到位省得两套脚本对不上。3.3 跑检查、设置报告上限与输出路径准备工作做完核心就是几条命令。下面这段是通用写法示意不同工具的语法不一样逻辑是一致的# 读入设计与库 read_verilog ./netlist/top_scan.v read_db ./lib/std_cell_tt.db read_db ./lib/std_cell_test.db # 建立测试模式工况 set test_mode_signal [get_port TM] set scan_enable [get_port SE] set test_clock [get_port TCK] set_case_analysis $test_mode_signal 1 set_case_analysis $scan_enable 1 # 声明扫描链与测试时钟 read_scan_def ./def/top.scandef set_dft_clock -name TCK -port $test_clock -period 10 # 关键一步把报告上限调大默认值往往只报前若干条 set_drc_report_limit 5000 set_drc_output_dir ./rpt/drc # 执行检查并输出 run_drc -checks all report_drc_violations -verbose ./rpt/drc/drc_summary.rpt write_drc_violations ./rpt/drc/drc_detail.rpt这段里最容易被忽略的是set_drc_report_limit。多数工具的默认报告上限很小遇到一个扇出上千的违例源报告里只显示前若干条你会误以为问题不大实际上后面压着几千条同源违例。把上限调大让问题一次性暴露比反复放宽上限重跑要省事得多。输出路径也要固定。DRC 报告是要做版本对比的每次跑完存到一个带日期和版本号的目录里后面回归时才有 diff 的基础。随手覆盖同一个文件名等你想知道这次改动到底新增了哪些违例时就只能凭记忆。3.4 读懂报告三类信息的优先阅读顺序报告出来之后不要一头扎进明细列表那个列表可能有几千行。正确的阅读顺序是三层。第一层看汇总统计总共多少条违例、分成几类、每类多少条。这一步的目的是识别重灾区通常数量最集中的那一两类就是本轮的主要矛盾。第二层看每类的代表性实例每一类挑前几条看具体是哪个模块、哪个单元、什么原因。这一步用来判断违例的性质——是设计问题还是约束问题是集中在某个子模块还是全芯片散落。集中在一个模块的多半是那个模块的测试模式没接好散落全芯片的往往是约束写错了或者库不对。第三层才看明细和传播路径针对第二层圈出来的关键违例去看工具的详细描述包括 X 是怎么传过来的、哪些节点受影响。这一步最耗时所以一定要在前面两层筛完之后再进。提示把三类违例分开看待——必须改 RTL 的、可以通过约束或工具设置规避的、可以接受并记录在案的。三类混在一起处理很容易在可以规避的问题上花掉大量时间而真正需要改设计的问题被拖着。4. 典型违例的定位与修复实录4.1 时钟路径上的组合逻辑与门控单元假设报告里出现大量时钟源不可控违例第一件事是按模块聚类。如果违例全部集中在某个子模块直接去看那个模块的时钟从哪来。常见情况是这个模块内部做了本地时钟分频或者用了自己生成的使能信号当时钟。修复分两个层面。结构层面在模块的时钟输入处加一个测试模式多路选择功能模式走内部派生时钟测试模式走顶层直通的测试时钟。约束层面如果这个派生时钟在测试模式下其实是可控的比如分频比固定、寄存器可预置可以在工具里显式声明这个时钟的关系让工具接受它。两种都要评估代价前者动网表要重新跑综合和后端后者不动结构但需要额外的验证来证明声明是准确的。门控单元的情况略有不同。多数标准单元库里的集成时钟门控都带测试使能引脚问题往往出在这个引脚没有接或者接了一个功能信号。修复方式是把测试使能接到全局测试模式信号上。这里要提醒的是级联门控一个门控的输出驱动另一个门控的时钟输入时两级都要接测试使能只接一级等于没接。4.2 异步端口的屏蔽异步复位/置位的违例定位技巧是看复位树的扇出结构。工具报的违例通常会给到具体的触发器实例你把同一类违例的实例名拿出来看如果它们共享同一个复位源那问题就在这个源上如果分散在多个源说明复位策略整体没做。修复的标准做法是在复位源附近插入隔离逻辑用测试模式信号把复位在 scan 阶段强制拉到无效电平。写成逻辑大致是功能复位与测试模式取或低有效则取与测试模式有效时输出恒为无效电平。这个门插入的位置很关键要插在复位树的根节点之后、分支之前这样只影响一处后端好做插在末端每个触发器前面会让复位树变成几百个独立分支时序和负载全乱。对于确实无法统一的异步源比如来自模拟模块退而求其次的做法是在 DRC 里把它标注为例外同时在 ATPG 阶段把这些单元排除在故障列表之外接受这部分覆盖率损失。这个决定要记录不能默认放过。4.3 X 源的隔离与 stop pointX 源处理最讲策略。第一步是分类把所有 X 源按扇出规模排序扇出最大的几个先处理。原因很实际一个扇出几千的 X 源可能贡献了一半的覆盖率损失处理它一个顶处理一百个小的。第二步是判断可控性。如果 X 源是存储器输出看看有没有带测试模型的版本可用有就换模型这是最干净的解法。如果没有就在存储器输出和后续逻辑之间设置 stop point让 ATPG 不再往前推演。如果 X 源是多驱动总线问题通常出在三态控制上需要保证测试模式下三态使能是唯一确定的做法是把使能信号在测试模式下钉死。第三步是评估要不要加测试点。加测试点的判断标准我一般看两条这个 X 源影响的可观测节点数是否超过某个阈值以及加测试点引入的延迟是否在时序余量之内。两条都满足才加否则优先用工具策略解决。4.4 修完之后怎么做回归改完一轮之后不要直接重跑全量先跑一次局部检查只针对改动涉及的模块确认违例数量下降且没有引入新问题。局部过了再跑全量。全量跑完之后最重要的一步是和上一版报告做 diff。新增违例要看清楚是不是自己的改动引起的有些修复动作会带来连锁反应比如你给某个模块加了时钟多路选择结果它的输出时钟被工具识别成一个新的时钟域链上的 lockup 检查重新报违例。这种连锁问题只看违例总数下降是发现不了的必须逐类对比。我习惯把每轮的汇总统计类别、数量、关键实例记在一个表格里几轮下来趋势一目了然。这个表后面写测试计划、做覆盖率评审的时候都能直接用。5. 常见问题速查表与踩坑记录5.1 高频问题速查现象大概率原因排查动作修复方向违例数量上千但集中在少数几个源扇出型结构问题复位树、时钟树按实例名聚类找共享源头在源头做隔离而非末端逐个修DRC 报单元不存在/引脚不匹配库版本与网表不一致核对库版本号、对比单元定义换回综合时用的库版本修完违例后 ATPG 覆盖率反而下降修复引入了新的结构约束对比修复前后的链结构报告回退后改用工具策略而非改网表shift 仿真出现规律性错位跨时钟域缺 lockup 或链序错乱检查链定义文件与时钟域划分补 lockup latch校正链序时钟违例全是可控但未声明约束里没显式定义派生时钟关系看报告里的时钟名补时钟定义或 case analysisX 源反复出现且位置漂移源头在多驱动或未初始化存储追踪 X 传播路径的根节点钉死三态使能或换存储模型5.2 几条不太会写在文档里的经验第一条DRC 报告里数量最多的那一类往往不是最严重的。一个扇出型的复位违例可能报三千条但它改一处就全清了而一条孤零零的组合环违例可能卡住整个模块的 ATPG。所以处理优先级应该按修复成本 × 影响范围排不是按数量排。第二条别在 DRC 阶段追求零违例。有些违例是结构上就消不掉的比如第三方 IP 内部的不可控逻辑。硬追零违例会逼着你去改本不该改的地方引入的风险远大于收益。正确做法是分类、记录、评审让团队知道哪些是已知且接受的。第三条脚本要能一键重跑。DRC 是要跑很多轮的每轮涉及读设计、建模式、跑检查、出报告。把这些串成一个脚本参数化输入输出路径比每次手工敲命令可靠得多。我见过有人手工跑跑了一半去开会回来忘了改过哪个约束只能从头再来。第四条早期用 RTL 跑别等到门级。RTL 阶段的 DRC 虽然精度不如门级但能在综合之前就把时钟、复位、黑盒这些结构性问题暴露出来这时候改代码成本最低。等到门级才发现改一处要重跑综合、DFT 插入、时序分析一圈下来几天就没了。第五条报告要留档。每轮的 DRC 报告、约束文件、库版本号打包存起来。这不是形式主义等到流片后测试程序出问题需要回溯时这些文件是唯一能说明当时检查到了什么程度的证据。6. 上下游衔接DRC 之后还要盯什么6.1 从 DRC clean 到 ATPG 覆盖率达标之间还差什么DRC 通过只代表结构上没有硬伤不代表覆盖率能达标。这中间还隔着几件事。一是故障模型的覆盖范围。默认通常跑 stuck-at如果项目要求 transition delay 或者 path delay需要额外的测试向量和更严格的时钟控制这些对 DRC 的检查项要求更高特别是时钟和时序相关的规则。二是测试向量的规模与测试时间。覆盖率推得越高向量越长测试时间越长测试成本直接上升。这个平衡点在项目早期就要和测试团队对齐不要等到 ATPG 跑完才发现测试时间超标。三是功耗。shift 阶段所有触发器同时翻转动态功耗可能远超功能模式如果 DRC 阶段没有对链的结构做功耗优化比如分组、分时 shift后面可能要靠降低 shift 频率来救反而拖慢测试时间。6.2 与后端时序的相互牵制DFT 插入和后端实现之间有一层天然的张力。你为了让 DRC 通过而在时钟路径上加多路选择后端就要为这个多路选择做时序收敛你为了修 hold 而在链上加 lockup latch可能影响局部布线密度。这些不是谁对谁错的问题是需要在流程早期就约定好的接口。我的做法是在 DFT 插入之前就和后端确认三件事测试时钟的插入点、门控单元测试使能的接法、跨时钟域 lockup 的放置策略。三件事定下来DRC 阶段的返工量能少一半。反过来如果 DRC 阶段才发现要加大量结构那就得重新评估面积和时序预算这个沟通越早越好。还有一点值得提DRC 报出来的某些违例本质上是后端物理实现的问题在前面的投影。比如某个时钟网络在综合后被优化成了组合逻辑驱动这在 RTL 层面看不到只有到门级才暴露。所以 DRC 不是一次性动作它在 RTL、综合后、DFT 插入后、布局布线后各有一次每次检查的重点不同别指望跑一遍就一劳永逸。我个人在几个项目里反复体会到的是DFT 这条线上最贵的成本从来不是工具跑得慢而是问题发现得晚。DRC 这个环节之所以值得单独拿出来讲是因为它把晚发现的成本压到了最低——它不生成向量、不占用大量仿真资源只用结构分析就能告诉你这条链到底能不能用。把这一步做扎实后面 ATPG 阶段的绝大多数玄学问题其实都不会出现。