每次跑完placement习惯性点开congestion map发现扫描链像一根“贪吃蛇”一样从chip左上角一路扭到右下角把本来就不宽裕的绕线通道直接堵死——这种场景做过数字后端的朋友应该都不陌生。扫描链功能上一点问题没有但在物理实现阶段它往往就是绕线拥塞和时序违例的隐形炸弹。今天要聊的就是Innovus里专门收拾这个烂摊子的利器setScanReorderMode。这条命令的核心价值很简单在placement阶段允许工具按物理位置重新调整扫描单元的连接顺序让一根“S型乱走”的扫描链变成沿着chip走“弓字形”的规整链路。看起来只是改个连接顺序但实测下来它对congestion、route closure时间、乃至整体功耗都能带来肉眼可见的收益。这篇东西适合刚接触Innovus数字后端的同学当成工具手册来看也适合已经在项目里被扫描链绕线折磨得头大的工程师照着里面的思路和脚本跑一遍大概率能少熬两个通宵。1. 从“一根链”说起setScanReorderMode到底在优化什么1.1 扫描链为什么会成为绕线噩梦先想一个问题扫描链本质上就是把几百上千个寄存器的SI/SO首尾串起来逻辑上是一条链。但这条链的综合结果往往和物理位置毫无关系——综合工具生成netlist时是按功能逻辑分组的它根本不管你最后放的位置。结果就是网表里排在第100位的寄存器和排在第101位的寄存器在物理上很可能隔着十万八千里。这种情况下如果placement工具老老实实按网表顺序去连线扫描链的信号线就会在整个chip上到处横穿。一根两根还好当芯片里有几十条扫描链、每条链几百个寄存器时这些长距离走线叠加起来Block里的局部绕线资源就会被大量吞噬。更麻烦的是扫描链信号在测试模式下本来就不要求时序多紧但它却会占用那些本该给高速数据信号使用的绕线通道典型“占着茅坑不拉屎”。还有功耗问题。DFT测试模式下扫描链翻转频率极高长距离跨block的走线每根都是巨大的动态功耗来源。以前我做某颗SoC芯片时光优化扫描链走线测试模式的动态功耗就降了将近15%这数字在低功耗项目里相当可观。所以扫描链Reorder不是“锦上添花”在很多场景下是必须做的一步。1.2 Reorder改变的是连接顺序不是逻辑功能很多人一听到Reorder就紧张怕把功能改坏。其实完全不用担心——扫描链Reorder改的只是shift模式下数据的串行连接顺序也就是把第100位的寄存器从“接第101位”改成“接物理上离它最近的另一个寄存器”但每个寄存器在链里的输入输出逻辑、Scan Enable控制、Capture阶段的并行功能完全不受影响。可以这么理解一条扫描链就像一队人依次传话原来是按编号排队网表顺序现在队长允许大家按站位就近传话物理位置排序。传话的内容、每个人听到之后做什么一点都没变变的只是谁传给谁。这个改变只影响测试时的shift过程不影响正常功能模式和capture模式。Innovus里做这件事核心就是setScanReorderMode。它决定的是“工具在多大幅度上允许改变扫描链拓扑”以及“改变时优先考虑什么目标”。理解这条命令关键不是背参数而是搞清楚每种模式背后工具在优化什么、牺牲什么。这一点我会在下一章详细展开。2. 命令参数与模式选型别拿一套默认值走天下2.1 setScanReorderMode的关键参数和常见写法这条命令在Innovus的placement流程里一般放在runPlacement或place_opt之前。命令本身不是“立即执行重排”的动作而是先设置好重排的策略和约束真正的重排动作发生在后面跑place或optDesign的过程中。先看一个最常见的调用方式setScanReorderMode -mode physical -lock true这里两个选项-mode指定重排优化目标常见的有default、physical、power以及组合模式combined/mixed具体以你用的Innovus版本帮助为准。physical模式以物理位置为第一优先级power模式以测试功耗为第一优先级。-lock true在重排完成后锁定扫描单元的相对位置防止后续优化步骤把它们又打乱。这个选项我强烈建议打开后面讲“结果被洗掉”的问题时会细说。除了这两个还有几个在实际项目中经常配合使用的参数-ignoreDontTouch true忽略dontTouch属性允许工具对带dontTouch标记的单元也进行重排。一般不建议全局打开只建议在明确知道某些库单元重排安全的情况下使用。-ignoreLocked true忽略已被lock的单元强行加入重排。除非你非常明确要动某些锁定单元否则默认不打开。-maxReorderRange或者类似的范围限制参数限制一次重排允许跨越的寄存器数量范围防止工具为了局部物理优化而把某段链排得过于“离谱”。各版本名字可能不太一样可以用setScanReorderMode -help查一下确认。关于版本差异我得提醒一句Cadence在Innovus不同版本上对这个命令的选项命名有过调整最稳的做法是装好环境后先敲一遍setScanReorderMode -help把你版本里的实际选项抄下来对照。我下面的写法是基于我常用的版本思路通用但选项名以你本机为准。2.2 三种模式怎么选physical、power与combined模式选型是这条命令的灵魂选错模式结果可能南辕北辙。先看physical模式。它的目标是让物理连接长度最小化工具会把扫描链按各单元在chip上的实际坐标重新排序最终效果就是链的走线基本沿着一条尽量短的路径把一串寄存器串起来。这种模式对缓解拥塞和绕线资源最直接适合大部分普通设计。如果你的芯片没有特别的低功耗诉求优先用这个。再看power模式。工具会优先考虑让shift阶段翻转功耗最小通俗地说就是让相邻的寄存器尽量共享相同或相近的扫描数据路径减少不必要的翻转。这种模式在低功耗芯片、尤其是需要跑很长的shift测试时间的芯片上收益明显。但要注意power模式下physical的收益会打折扣链的走线可能不如physical模式那么干净。最后是combined有些版本叫mixed或者直接支持多个mode叠加。这个模式让工具在物理和功耗两个目标之间做权衡通过内部权重决定更偏向谁。我的经验是这个模式不是万金油工具内置的权重不一定适配每个设计。实际项目里我会先跑一版physical和一版power分别看看congestion、链长、功耗的数据再决定用哪个。如果你的flow时间很紧无法做多版本对比拿默认的combined模式也算是个安全的兜底方案。2.3 与scanReorder和lockScanChain的配合关系光setScanReorderMode还不够命令是“设定偏好”执行重排的动作通常由后续的place阶段完成。另外还有两条命令经常在一起用。第一条是scanReordervisible名称就叫这个功能是直接触发扫描链重排。你可以通过过滤条件指定只对某些scan chain重排scanReorder -chain {chain1 chain2} -filter ref_name ~ *BUF*这种定向操作在调试单条链问题时非常有用不用整chip重跑。第二条是lockScanChain功能是锁定某条扫描链不让工具对它动手。比如某些关键的模式需要精确控制扫描链结构或者扫描链上挂了压缩逻辑、不能随便改连接顺序直接用这条命令把整条链锁住lockScanChain -chain {critical_chain}这两条命令和setScanReorderMode配合使用的思路是先全局设定重排策略setScanReorderMode跑一版看整体效果再把某些特殊链锁住lockScanChain剩下的交给工具。实操中我一般会先锁住所有带DFT压缩结构的链再让工具去优化普通链。3. 实操跑一轮Scan Chain Reorder优化的完整流程3.1 先把扫描链的家底摸清楚动手之前先得知道你的设计里有哪些扫描链、每条链多长、单元分布怎么样。Innovus里可以直接用下面的方式把扫描链信息导出reportScanChain -verbose这个命令会把每条链包含的寄存器数量、起始端点、终止端点全部打出来。如果链特别多建议先数一数规模心里有数再开始。另外一个非常值得看的指标是“链条横跨范围”。简单做法是把它在GUI里高亮出来或者用命令输出每个寄存器的坐标算一下链首和链尾寄存器的坐标差。如果发现某条链的物理跨度超过了chip长度的一半基本可以确定这条链是重点优化对象。还有个小技巧用如下方式把每条链的寄存器列表导出来在perl或者python里做一次简单的坐标聚类分析get_prop [get_scan_chains] insts_list没有脚本基础也没关系Innovus GUI里的report对话框可以直接把扫描链对应单元highlight到版图上肉眼也能判断哪些链是“重灾户”。3.2 记录Placement基线别等改完才后悔优化的效果好不好得有个对比基线。跑setScanReorderMode之前先跑一版不打开该命令的placement记下几项关键数据Placement后的Total Wirelength这是最直观的指标可以用report_placement_qor查看。Violation情况重点看congestion相关的Hover/Overflow用summaryReport -no_html -outfile查看。扫描链相关的时序在scan shift时钟下跑一次初检记录hold margin的紧张程度。如果项目关注功耗还要记录place后测试模式的动态功耗估算值。这些数据记录得越全后面判断优化效果就越有理有据。我见过不少同事跑完优化一看congestion好了就声称“有效果”结果连wirelength具体数字都说不出来这种方式不好。做优化和做实验一样控制变量、量化对比才能沉淀出真正可复用的结论。顺便说一句跑基线这版不一定要完整跑到routeplace阶段结束后的数据就足够作为对比参考了。毕竟扫描链Reorder解决的主要是placement层面的物理分布问题。3.3 配置并执行Reorder基线记录完毕开始正式配置。我的典型做法分两步第一步先锁定不可动的链第二步再设置全局策略lockScanChain -chain {chain_with_compression chain_xyz} setScanReorderMode -mode physical -lock true place_opt_design注意这里place_opt_design就是触发重排和具体place优化的动作。在Innovus里setScanReorderMode只是把策略挂上真正应用发生在后续的place/opt阶段。如果你的项目对测试功耗比较敏感我会建议在这一步额外做一次对比实验只改mode参数setScanReorderMode -mode power -lock true place_opt_design两次跑完之后把前面记录的wirelength、congestion、功耗三项数据放一起对比就能明显看出模式差异。通常physical模式会赢在congestion和wirelengthpower模式会赢在功耗具体差距有多大真的只有跑了才知道。执行过程中建议把log里的scan chain相关消息单独grep出来setScanReorderMode -mode physical -lock true -verbose place_opt_design | grep -i scan这样你能实时看到工具到底重排了多少条链、动用了多少寄存器。我曾经遇到过一次命令挂上去之后log里一条Reorder记录都没有排查了半天发现是某条全局变量把扫描链的dontTouch属性全置上了工具一条都没敢动。所以验证“命令真的生效了”这步别看都不看就往下走。3.4 看结果congestion、timing、DRV一个都不能少Reorder跑完之后验证环节要覆盖三块内容。第一块是物理层面的验证。通过reportCongestion或者直接看GUI里的congestion map对比基线数据重点看之前拥塞严重的区域是不是明显缓解。这里特别提醒不是所有拥塞都能归因于扫描链要区分是哪一层metal的congestion。扫描链这种长走线影响的通常是偏上层的绕线资源如果优化后问题区域从“红”变“黄”基本就算有效果。第二块是时序验证。重启时序检查流程特别注意scan shift clock group下的hold timing。扫描链重排之后相邻级之间的物理距离变了布线长度变了RC延迟也跟着变之前平衡好的hold路径可能被打破。通常在Innovus里重排流程会自动做时钟树、会自动修hold但如果你用的flow比较旧或者把某些修hold的步骤手动关闭了这里就需要人工介入。后面第4章我会专门讲这个问题。第三块是DRV检查。重点看max transition、max capacitance这类信号完整性指标。长走线的RC变大transition容易劣化如果DRV这边爆出一堆新violation说明工具在重排时对物理约束的权衡没做好可以考虑把-maxReorderRange类的范围参数收紧一点。3.5 固化参数形成团队标准脚本验证完效果之后最重要的一步是把参数固化到项目的flow脚本里。这一步看着简单但我见过太多团队靠工程师手动敲命令调参数换个人、换个版本效果就飘忽不定。固化的思路有几条分享给你参考把setScanReorderMode的相关设置集中放在一个单独的tcl脚本里例如scan_optimization.tcl其他flow脚本source它。这样策略调整只改一个文件不会散落在各个步骤里。在脚本头部加版本检查比如利用Innovus的version命令判断当前版本是否支持你选的mode选项不支持就给出warning避免脚本在新版本上静默失效。把模式选择做成变量例如SCAN_REORDER_MODE顶层Makefile里传参方便不同block、不同项目快速切换。如果你做的是多个block同时跑这个设计会非常省事。在脚本里留一个“dry-run”开关配合-setScanReorderMode -verbose跑短流程确认设置被正确应用再跑全流程。从实践角度讲扫描链优化的参数不需要天天改。真正做一次有效实验把结论写进文档然后让脚本稳定跑起来比每次全手动调参要可靠得多。4. 常见问题与排查技巧实录4.1 Reorder之后扫描链总长反而变长了这个现象我第一次遇到时也挺懵明明开了Reorder结果reportScanChain显示链的总长比之前还大。后来排查发现问题出在锁链和dontTouch的“漏网之鱼”上以及工具在重排时的局部最优陷阱。先排查锁链用reportScanChain -lock检查有没有某些chain被意外锁定。如果设计里DFT工具给关键链加了dontTouch或fixed属性工具重排时会跳过这些单元结果链为绕过这些固定点反而绕了更远的距离。再排查“局部最优陷阱”工具在Reorder时并不会保证全局最优。如果某条链里有几百上千个寄存器它的搜索算法往往只在局部窗口内做优化容易陷入“局部最优”。遇到这种情况我有两个办法。第一把-registerLimit或者类似的限制参数调大给工具更大的搜索范围代价是运行时间变长。第二手动介入先用reportScanChain -verbose把链导出来用脚本按坐标重新给寄存器排序然后把排序结果写回约束文件里再配合setScanReorderMode让工具按你的排序继续。这个方法麻烦但能让结果完全是确定性的。4.2 Scan Path上频繁出现Hold违例扫描链做好物理优化后scan shift路径上的hold违例是最常见的“并发症”。原因一句话就能解释重排后路径物理距离变短了延迟变小而时钟树是后建的hold check要满足的最小时延被打破。遇到这个情况别慌先确认是重排引入的、还是本来就存在的。把寄存器的物理坐标对比一下如果重排后相邻两级确实离得更近了那基本可以断定是Reorder带来的。解决办法在scan chain的时钟group上增加hold fixing策略让工具在重排后的网络list上重新做CTS和hold优化。如果项目对scan shift hold margin要求很严可以在setScanReorderMode之后、CTS之前先手动给关键scan path加balance。重排流程建议和CTS流程放同一个opt阶段跑让工具一次搞定不要在重排和CTS之间插入其他对布局影响较大的操作。通常做完这些hold问题就能压下来。如果还有零星violation大概率是跨block的链段这时候手动修比让工具全局修更安全。4.3 Reorder结果被place_opt/optDesign“洗掉”这个坑特别隐蔽说它隐蔽是因为place_opt_design既能触发Reorder又可能在后续迭代优化中把你的重排结果“重新打乱”。具体现象是重排之后你再跑一次place_opt_design或者同样的脚本跑了两次第二次结果和第一次不一样扫描链的报告也不一样了。原因在于Innovus在做placement优化时有机会重新决定scan cell的放置位置和链的排布你在前面setScanReorderMode里开的策略如果后续步骤没有延续就可能被覆盖。解决办法在setScanReorderMode里把-lock true打开让工具在重排完成后锁定结果。如果重排之后还有多次optDesign迭代确保每次optDesign前都再次执行setScanReorderMode设置而不是只设置一次就以为全程生效。用lockScanChain把关键链锁住尤其是DFT压缩链、跨block链这类链一旦被洗掉重排影响面积更大。另外一个更稳妥的做法是把重排后的scan chain连接关系直接写出来作为约束文件固化。Innovus支持把扫描链约束导出成SDC或者专用的scan chain constraint后续重新跑flow时直接载入而不是每次都依赖工具现场重排。这样能保证不同实验之间结果可复现调试问题时会省非常多的力气。4.4 冷门操作按名字选中特定PG Term比如biasnw有朋友在群里问过一个问题Innovus里怎么选中某个标准单元上名字为biasnw的PG term。这个操作其实不止扫描链优化用得上做IR drop分析、手工检查PG连接、或者定位特殊power域时经常要用。方法不复杂但很容易卡在命令语法上。命令行里比较直接的是用dbGet按属性过滤再用select_obj选中dbGet [dbGet top.insts.name * -p .pgTerm.name] -m0如果版本里的属性名不叫pgTerm叫pg_term就把命令里的pgTerm替换成pg_term可以用这条命令先看schemadbGet top.insts.? -p1看到属性名之后再执行过滤。整个过程其实就是“先确认属性名再按名字匹配最后选中”三步。GUI的话可以用Innovus的search功能在Edit菜单下找到Search by name匹配模式填pgTerm.name or pg_term.name: biasnw它会把所有名字含biasnw的候选列出来手动勾选即可。有两点想顺手提醒一是注意正则和通配符biasnw如果带前后缀可能需要写成biasnw二是如果单元很多在GUID下直接搜索容易卡顿建议还是用命令行的方式输出列表后配合count统计效率会高很多。这种小技巧平时不起眼真到要定位某个特殊pin时能省很多时间。最后说几句实在的扫描链优化是我做数字后端这么多年里投入产出比最高的优化手段之一。它不改变功能、不改变架构只是把“网表里的顺序”和“物理上的位置”对齐了一下就能缓解拥塞、降低功耗、稳定时序甚至还能让CTS和route阶段省下不少迭代时间。在项目时间紧张的时候这种“四两拨千斤”的优化思路尤其珍贵。但也要承认setScanReorderMode不是万能的。碰到锁链太多、DFT结构特殊、或者某些链上挂了电平转换之类的特殊单元工具的重排效果很可能不理想。这时候别硬跟工具较劲锁起来手动处理反而更高效。我自己在项目中养成的习惯是每接手一个新block先花半天时间跑一轮全开Reorder的对比实验用数据说话再决定这套block最终用不用、用哪种模式。别嫌麻烦这份对比实验的数据不光是给物理实现提供依据到了DFT和测试团队评审的时候也是你手里最硬气的那张底牌。