做数字后端的人应该都有这种经历：CTS和布线跑完之后，打开时序报告和DRC报告，总能看到几条net的transition超标、电容超标，或者一条长线从模块一头拉到另一头，delay大得离谱。以前我都是手动打开版图，一个个点net、算位置、再ecoAddRepeater，一个晚上能插二三十个buffer就算效率不错了。后来发现Innovus里有个addRepeaterByRule命令，用规则批量处理这类问题，省了至少一半时间。这篇就把这个命令的用法从头到尾拆一遍，覆盖语法、rule文件写法、三个典型场景和一堆实操踩坑记录，适合正在做数字后端PR、经常被DRC和时序折腾的工程师。
1. addRepeaterByRule到底是干什么的
1.1 从修DRC到修时序，一个命令覆盖三类场景
addRepeaterByRule是Innovus里用来批量插入repeater（缓冲器/反相器）的命令。所谓repeater，本质上就是标准单元库里的buffer或inverter，插在信号路径中间，主要干三件事：切分长线降低RC延迟、隔离高扇出降低负载电容、改善transition时间。
实际项目中，这个命令最常出现在三个场景里。第一是修DRC，比如reportDrc里报了一堆maxTransition和maxCap违规，而且集中在某几条高扇出net上；第二是修时序，特别是hold time violation，利用buffer本身的delay来推路径；第三是给跨模块长信号加中继，这类net往往从floorplan阶段就知道肯定要插几级buffer，只是具体插在哪、插几级，光靠肉眼很难定准，不如交给规则去算。
很多人容易把addRepeaterByRule和optDesign、repairDesign这类自动优化命令搞混。后者是工具整体评估时序和DRC后自动修，你只能通过选项限制它动哪些东西；而addRepeaterByRule是你明确指定“给我处理这组net、用这些cell、最多插几级、离pin多远”，目标更聚焦，可控性更强。所以它特别适合那种你心里已经知道问题在哪、但不想手动一个个点的场景。
1.2 为什么推荐规则驱动而不是手动一个个加
早年间我习惯用ecoAddRepeater手动插图，命令本身不难，难的是确定插入位置和级数。一个高扇出信号，负载在版图里散成一团，你在哪个位置切分、切分后两级buffer的驱动能力怎么配，都需要反复试。一次项目里修几十条net，每条都要开GUI看半天，效率非常低。
addRepeaterByRule把这件事变成了“写规则、批量跑”。你只需要告诉工具：哪些net要处理、允许用哪些cell、线路超过多长就要切、插入点离pin至少多远、最多分几级，工具自己会沿着走线方向计算最优插入位置，并且尽量把多个插入点分散开，避免挤在一起造成局部congestion。它背后用的是工具内置的布线拓扑分析和延迟计算引擎，比我手动目测准得多。
另外，规则可以复用。同一个block里如果有多条结构相似的net，比如一组并行的数据总线、一组寄存器复位信号，写一份rule文件，几条命令全部处理完。下次另一个block遇到类似问题，把rule文件拷过去改个net名就行。这才是规则驱动真正的价值——不是你这次省了多少时间，而是你以后每次都能省。
2. 命令语法与rule文件写法
2.1 基本语法骨架与常用选项
addRepeaterByRule的调用方式不复杂，核心是-rule、-net、-cell这几个参数。我常用的基本骨架是这样的：
addRepeaterByRule \ -rule $rule_file \ -net $net_name \ -cell "BUFX8 BUFX12 BUFX16" \ -prefix REP \ -numStages 2拆开看每个选项的作用。-rule指向规则定义，可以是一个rule文件路径，也可以直接在命令行里写一段inline规则，后面详细说。-net指定要处理的net名，支持通配符，比如*data*。-cell是允许使用的cell列表，工具会在这个列表里选合适的型号，不会自己乱用库里的其他单元。-prefix是生成的实例名前缀，这个特别重要，后面检查插了几级buffer、追踪ECO改动都靠它。-numStages是允许的最大级数，等于告诉工具最长可以串几级buffer。
除了这几个，还有几个我几乎每次都会带上的选项。-skipDriver和-skipLoad分别表示在driver端和load端附近不插buffer，避免把buffer怼在原有pin脸上，给后续布线留空间。-Halo是插入点与周围pin和走线的最小距离，单位通常是um，设得太小容易插进congestion区域，设得太大又可能找不到合法位置。-maxRouteLen是最大走线长度，超过这个值的net会被自动切分。-onRoute在有现有routing的情况下尽量贴着已有走线插，这样对布线资源的扰动最小。
2.2 rule文件的关键参数逐一拆解
rule文件是addRepeaterByRule的核心配置，里面定义了工具做决策时遵循的规则集合。不同版本Innovus对rule文件的格式支持略有差异，但核心字段是通用的。我给一个自己在项目里用过的模板：
Rule: rep_rule1 { net: *; cell: {BUFX8 BUFX12}; numStages: 2; maxRouteLen: 250; maxCap: 0.5; maxTransition: 0.5; Halo: 5; skipDriver: true; skipLoad: true; onRoute: true; prefix: REP; }逐个解释关键字段。net定义这条规则匹配哪些网络，*是匹配所有，也可以写具体net名或用通配符缩小范围。cell就是允许使用的单元列表，我建议至少给两三个不同驱动能力的型号，让工具根据实际负载自己挑。numStages是级数上限，一般高扇出net设2到3级足够，设多了反而引入多余的延迟和面积。maxRouteLen是切分阈值，单位um，超过这个走线长度的net就会被插入repeater切段。maxCap和maxTransition是触发条件，相当于说“这条net如果电容或transition超过某个值，就启动插入流程”。
Halo和skipDriver、skipLoad这几个字段跟在命令行里的同名选项作用一样。onRoute字段决定是否优先沿着已有走线路径插入，我强烈建议保持true。
需要特别注意rule文件里的分号和花括号格式。Rule后面是规则名，名称不能和已有规则冲突；字段之间用分号分隔，最后一个字段后面不写分号也不会报错，但我习惯写全，方便复制修改。要是rule文件写错了，工具会在启动时提示parse error，不过报错位置有时候定位得很模糊，所以写完后先用小范围net试跑一次比较稳妥。
2.3 inline rule与rule文件的选择
并不是每次都要单独写一个rule文件。处理一条临时net时，我更倾向于直接在命令行里写inline rule，这样改动灵活，不用来回切文件。写法就是把rule内容作为-rule的值传进去：
addRepeaterByRule \ -rule "Rule: tmp_rule { net: rst_n; cell: {BUFX4 BUFX8}; numStages: 2; maxRouteLen: 200; skipDriver: true; skipLoad: true; Halo: 5; }" \ -net rst_n什么时候用文件、什么时候用inline？我的判断标准是看“复用性”。如果只是临时修一条net，inline最快；如果打算把一组规则沉淀下来复用，或者规则比较复杂、字段超过十几个，那就写成独立文件，放在项目目录的scripts/eco目录下，方便版本管理。
另外提醒一点，-rule选项本身也可以不依赖rule文件指定net匹配范围，在命令行里用-net单独指定即可。但要注意，如果rule文件里也写了net字段，两者同时存在时，规则的匹配范围会对命令行指定的net做交集。曾经有同事因为rule里写了net: *以为万事大吉，结果命令行里又传了一个具体net名，工具处理的范围比他预期的小很多，半天没查出原因。建议要么rule文件里只写配置型字段，把net匹配完全交给命令行；要么在rule文件里明确写清楚，两条路径不要混用。
3. 三个典型实操场景与具体命令
3.1 场景一：高扇出复位信号插buffer tree
寄存器复位信号是addRepeaterByRule最典型的应用对象。一个全芯片的异步复位信号，扇出经常几百甚至上千，后端PR时如果没做reset tree，这条net的cap和transition基本必爆。处理思路是把单根高扇出线，通过多级buffer展开成树形结构，每一级只驱动一部分负载。
假设现在有一条名为rst_n的net，接了几百个寄存器的复位端，reportDrc显示maxCap违规。我一般这样处理：
report_net -net rst_n -drv addRepeaterByRule \ -rule "Rule: reset_rule { net: rst_n; cell: {BUFX4 BUFX8 BUFX12}; numStages: 3; maxRouteLen: 150; maxCap: 0.3; skipDriver: true; skipLoad: true; Halo: 8; onRoute: true; }" \ -net rst_n这里numStages: 3是因为几百个负载不可能靠一两级buffer撑住，工具会分布成三级树。maxRouteLen: 150是为了让每条分支走线不要过长，尽量分散到负载区域内部。cell里给了三个驱动档位，工具在靠近驱动端的地方选大驱动力的BUFX12，靠近负载端选BUFX4，这种自动分级匹配正是手动插图时最费神的环节。
跑完命令后，我建议立刻做两件事。一是用dbGet top.insts.name REP_*确认插入了多少实例，数量是不是符合预期；二是打开版图看分布，如果发现所有buffer都挤在一起、负载区域反而空着，说明maxRouteLen设得太小，工具切分得太密集，把阈值调大一些重跑。
3.2 场景二：长距离跨模块信号加中继repeater
另一个高频场景是跨模块长走线。floorplan阶段就会知道，某些信号从IP A的端口出来，要走到IP B的端口，中间隔着好几百um甚至上千um。这种长走线即便没有cap和transition违规，信号延迟也大得离谱，setup timing基本没救，必须中途插入中继buffer把长线切短。
这种场景下，maxRouteLen字段就是主角。我常用的参数：
addRepeaterByRule \ -rule "Rule: longwire_rule { net: *; cell: {BUFX8 BUFX16}; numStages: 1; maxRouteLen: 300; skipDriver: true; skipLoad: true; Halo: 10; onRoute: false; }" \ -net "long_sig_*"long_sig_*用通配符匹配一组跨模块信号。numStages: 1是因为每条线只需要一级中继，不需要像复位信号那样摊成树形。maxRouteLen: 300的意思是，从driver到load如果走线超过300um，就在距离driver约300um的位置插一个buffer，把线切成两段；如果实际走线长度600um，可能会插两级。
这里特别说一下onRoute: false的用意。跨模块长线在布线阶段很可能已经绕得很远了，如果onRoute开着，工具会贴着既有走线路径找插入点，插入位置会被布线绕行方向限制。而有些项目里，这类信号更希望后续重新绕线，这时关掉onRoute，让工具以曼哈顿距离估算切分点，反而更合理。这个选项没有绝对好坏，取决于你的布线策略。
3.3 场景三：hold time violation用delay buffer修复
第三个场景是修hold。setup slack足够、hold violation的路径上，我们需要在数据路径上增加延迟。常见做法是插delay buffer（如果库里专门有delayload cell）或者串联普通buffer。
修复前先跑report_timing -hold找到violation路径，确认是哪条net负责数据路径上的信号传递，然后在命令里指定这条net：
addRepeaterByRule \ -rule "Rule: hold_fix { net: data_mid_*; cell: {BUFX2 BUFX4}; numStages: 2; numRepeaters: 2; skipDriver: true; skipLoad: true; Halo: 5; }" \ -net data_mid_*numStages: 2和numRepeaters: 2在这个场景下的区别要搞清楚。numStages指的是可以串几级buffer链，numRepeaters限制的是整条net上一共最多插入多少个repeater。修hold时我通常两个都限制，尤其用numRepeaters防止插入过多造成hold过度修复，反而引入新的setup问题。
还有个关键点：修hold时插入的buffer会增加延迟，但具体能增加多少，工具估算基于当前寄生参数，并不完全精确。所以我跑完这个命令后，一定会重新提取寄生参数，再做一次hold分析，确认每条violation都收敛了。项目里就遇到过工具算出来hold修好了，但重新提参后delay比预估小了0.1ns，violation回来了一部分，所以千万别省提参这一步。
4. 执行结果检查与效果评估
4.1 如何确认repeater真的插对了
命令执行完后，最怕的就是“工具说success，但实际啥也没插”。我的检查习惯分三步。
第一步，查实例。用dbGet按prefix过滤：
dbGet top.insts.name REP_* -l这能看到所有新增的repeater实例，数量、在哪个hierarchical cell下面、连在哪个net上，一目了然。如果返回空，说明这条net压根没匹配到规则，或者被其他属性挡住了。
第二步，查连接关系。选一个新增实例看它的输入输出：
dbGet [dbGet top.insts.name REP_0].instTerms.net.name -e确认buffer的输入连的是原net、输出连的是新net，信号流方向正确。
第三步，回到GUI里看分布。输入gui_show -net $net_name，高亮整条net和新增buffer，检查插入位置是否合理，有没有插在hard blockage里，有没有把几个buffer挤在一堆。这三步都过了，才算真正插入成功。
4.2 插入后的时序与DRC复核
插入repeater这件事本身不是目的，最终要看时序和DRC是否改善。这里要掌握一个原则：先提参，再分析。
setExtractRCOMode -engine postRoute extractRC report_drc -all report_timing -setup -max_paths 50 report_timing -hold -max_paths 50把setup和hold的top 50条路径都报一遍，重点看之前violation的路径是否改善，同时也要扫一眼原本clean的路径有没有被插入操作连累变差。尤其是hold，前面说过，数据路径上多串一级buffer，延迟增加几十皮秒，就有可能把原本干净的setup路径推爆。
DRC方面，重点看maxTransition和maxCap是否收敛。如果报告里还有残留violation，先别急着再插一轮buffer，用report_net -drv看是哪些pin还超标。很多时候是工具为了满足maxRouteLen，把buffer插在了负载区域边缘，最后一小段线还是太长。这种情况把rule里的maxRouteLen调小一点，或者numStages加一级，通常就能解决。
4.3 与后续流程的衔接
addRepeaterByRule插入的实例不是插完就不管了。它属于ECO性质的改动，后面有几件收尾工作必须做。
首先，插入的buffer如果不在标准单元row上（工具有时为了沿走线插入，会把位置定在非row区域），需要跑一遍legalize placement，把这些实例吸到最近的合法位置。我一般用：
legalizePlacement -verbose跑完后重点看moving distance，如果某些buffer被移动很远，说明插入时Halo设得不合理，或者附近根本没有空的row。
其次，net拓扑变了，原有routing很可能需要调整。建议对涉及的net做增量ecoRoute：
ecoRoute -net $net_name最后，确认一切正常后，saveDesign -design $design_name保存ECO后的设计版本。顺便用write_eco -eco_change或write_changes记录这次插buffer的改动清单，方便debug和回滚。
这里必须强调一个习惯：insertion前后各存一份design。ADDRepeaterByRule跑完之后，工具不会自动给你存备份，一旦后面发现插入位置有问题想回滚，没有备份就只能靠手动删buffer，非常痛苦。我自己是每次跑大batch之前先save一份带时间戳的设计，跑完再save一份，哪怕只是临时调试一个几um的Halo参数。
5. 常见问题与避坑经验
5.1 命令执行了但什么都没插，排查思路
这是新人最容易卡住的问题：命令没有任何报错，log里甚至提示successfully finished，结果回GUI一看，net还是老样子。我的排查顺序是这样。
先查net有没有dontTouch属性。Innovus尊重dontTouch标记，如果net被set_dont_touch或setDoNotTouch标记了，addRepeaterByRule默认不会碰它。查法：
dbGet top.nets.name $net_name.dontTouch返回1就是被锁了。这种时候必须跟前端确认能不能临时去掉标记，或者改用别的修法，不能自己偷偷解开，否则后续LVS/formal会有麻烦。
再查rule的匹配范围。如果rule文件里net字段写了具体的net名，而你要处理的net名不匹配（比如多了hierarchical前缀、大小写不一致），命令会静默跳过。所以我建议rule里的net匹配尽量用通配符，具体处理目标交给命令行的-net指定。
最后查cell的可用性。-cell指定的单元库型号，如果当前floorplan的lib库里没有这些cell，或者这些cell被标记为dont use，工具会找替代型号。实在找不到就直接放弃插入，而且不一定报warning。所以命令行里多给几个同功能但不同驱动强度的cell，能大幅提高插入成功率。
5.2 cell选型与驱动能力匹配
cell选型是addRepeaterByRule最容易“能用但不优”的环节。典型错误是只给一个大驱动力的cell，比如只写BUFX20，工具确实把所有插入点都用了BUFX20，但靠近负载端的几级根本不需要那么强的驱动，白白浪费面积和功耗，还增加漏电。
正确做法是在rule里给2到3个驱动档位，让工具自己搭配。我常用的组合是X4、X8、X12，具体看这条net的负载情况。负载很重的高扇出net，起点给X12，中间分支用X8，末端用X4；负载一般的长线，X8配X4就够。
另外一个容易忽略的点是inverter和buffer的选择。Cutting长线时，用inverter切分在延迟上略优于buffer，因为inverter本身延迟更小、输入电容更低。但inverter会翻转逻辑，所以必须在rule里用preferInverter之类的选项或者手动控制cell列表。如果你不希望在逻辑上引入额外翻转，直接只用buffer最稳妥，至少不会出现功能问题。这个取舍没有标准答案，看项目对timing面积功耗哪个更敏感。
5.3 与dontTouch、blockage、partition的冲突
除了一开始说的net dontTouch，还有几种情况会让命令执行得“扭扭捏捏”，或者插入位置奇奇怪怪。
placement blockage是最常见的捣乱者。如果net走线穿过一个hard blockage区域，而区域里没有可用的row，工具找不到合法插入点，就会把buffer往blockage边界挤，结果可能在边界处形成局部congestion。遇到这种情况，我一般先裁剪blockage范围，留出一条走线通道，或者改用-Halo更小的值，让工具能在blockage边缘找到位置。
partition boundary也会制造麻烦。如果这条net跨越了两个partition，两个partition各自有独立的floorplan和power规划，工具在跨boundary处插buffer，有时会因为两侧的boundary pin没有定义好而失败。处理思路是先把net在partition内部可处理的部分处理好，跨boundary的中继buffer单独手动加，不要完全依赖规则自动处理。
最后是macro旁边的placement keepout。memory等macro周围通常有keepout margin，buffer不能插在keepout里，但工具计算插入点时如果不考虑keepout，就会反复尝试失败。我在跑命令前，会用setPlaceMode -place_global_keepout相关设置确认keepout区域定义完整，避免白跑一轮。
5.4 我踩过的坑清单
经验都是用时间换的，下面几条是我在项目里实际踩过的坑，写出来给大家当参考。
第一条，别在高频时钟net上乱用。addRepeaterByRule处理普通信号毫无问题，但时钟树net的buffer是CTS阶段精心平衡过的，你在post-CTS阶段贸然往时钟路径里塞buffer，会直接打乱各branch的延时差，skew立刻爆炸。如果时钟树里某段确实需要修，应该走clock tree eco的流程，而不是用这个命令硬来。
第二条，rule里的maxRouteLen不能拍脑袋定。设得太小，一条net被切成七八段，插入几十个buffer，面积和功耗起飞；设得太大，切了等于没切，违规依旧。我的经验是先看report_net -net $net里的net length，如果整条线500um违规，那么把maxRouteLen设在250到300之间，切两段通常就够了，不要一上来就设100。
第三条，批量跑多条net前先在单条net上试。addRepeaterByRule虽然可以配合-net *一次处理整组net，但我是从来不敢这么干的。因为不同net的负载分布、走线绕行差异巨大，一份rule很难同时适配几十条net，一次全跑完，可能一半net修好了、另一半被插得乱七八糟。稳妥的做法是先在代表性net上试跑、检查分布、微调参数，确认没问题后再用通配符批量处理。
第四条，也是最重要的一条，跑完一定要重新提取寄生参数。命令执行后工具报告timing改善，那是基于增量估算，不是真实走线后的结果。只有extractRC重新提参再做一轮STA，才能在signoff前真正确认这波操作有效。省略这一步，后面timing signoff多半会让你把同样的事重做一遍。
写在最后的实操体会
玩这个命令这么长时间，我最大的体会是：addRepeaterByRule不是用来替代人做设计的，它是用来把人从重复劳动里解放出来的。你依然需要理解什么是好的buffer分布、理解的cell驱动能力怎么匹配、理解长线为什么需要切分，但具体到“这条net在哪切、切几刀、用什么cell切”，让工具按规则去算，比人肉估算高效得多也稳定得多。另外，每做完一个项目，我都会把用过的rule文件按场景分好类存档，复位信号一份、长线中继一份、hold修复一份，新项目遇到类似问题，改几个net名和参数直接复用。这个习惯帮我省过很多次返工的时间，强烈建议你也试试。
