ICC布线优化实战：从Route_opt到DRC修复全流程解析

1. 布线优化实战：从Route_opt到DRC修复的完整心路

做数字后端设计，最让人头疼的环节之一就是布线。你辛辛苦苦把单元摆好，时钟树也综合得漂漂亮亮，结果一到布线阶段，各种DRC违例、时序违例、拥塞问题就全冒出来了，简直让人崩溃。我刚开始接触ICC（IC Compiler）的时候，也在这个阶段踩过无数坑，经常是跑完route_opt一看报告，密密麻麻的红色错误，瞬间感觉前功尽弃。

后来我才明白，布线不是一蹴而就的“一键操作”，而是一个需要精细控制和反复迭代的流程。route_opt这个命令看起来很强大，号称能搞定全局布线、通道分配、详细布线和优化，但它更像一个“总指挥”，具体仗怎么打，还得看我们怎么给它下指令。今天，我就把自己这些年从route_opt开始，到最终把DRC违例清理干净的实战经验，掰开揉碎了跟大家聊聊。整个过程就像疏通一个复杂的下水道，你得先看清全局的拥堵点（全局布线），然后规划好每条水管的走向（通道分配），最后才是接好每一根具体的管子并处理漏水（详细布线与DRC修复）。我会尽量用大白话，结合具体的命令和踩过的坑，让你看完就能上手操作。

2. 布线前的“体检”：别让隐藏问题毁了你的布线

很多新手工程师拿到做完CTS的设计后，迫不及待地就开始跑route_opt，结果往往事倍功半。布线前的检查，就像动手术前的全面体检，至关重要。这一步没做好，后面布线工具再厉害也无力回天。

2.1 合法性检查与理想网络清理

首先，我们必须确保布局是“合法”的。运行check_legality命令，它会检查标准单元是否都规规矩矩地放在row上、有没有单元重叠、有没有和阻挡区域（blockage）交叉等等。我遇到过最诡异的一次问题是，一个宏单元（macro）的电源引脚因为坐标偏移了极小距离，导致check_legality没报错，但布线时工具就是无法连接，排查了好久。所以，这个检查一定要做。

接下来，要清理掉所有“理想网络”（ideal net）和高扇出网络。什么是理想网络？就是在布局阶段，为了加快速度，我们把一些全局信号（比如复位、测试模式使能）或者扇出极大的网络，设置成不需要考虑实际布线延迟和电阻电容的“理想”状态。但到了布线阶段，我们必须面对现实。用all_ideal_nets命令列出它们，然后用remove_ideal_network -all全部移除，让工具重新用真实的金属线来连接。

高扇出网络（比如复位信号驱动几百个触发器）也是布线拥塞和时序的杀手。用all_high_fanout -nets -threshold 50（这个阈值根据设计而定，比如50）找出来。对于这些网络，我们通常需要在CTS阶段就进行缓冲器（buffer）插入，把它“打散”成多个扇出较小的分支，而不是留到布线阶段让工具去头疼。

2.2 电源连接与布线方向确认

电源地网络的物理连接检查是另一个重灾区。运行verify_pg_nets，经常会报出一堆“floating pins”（悬空引脚）。别慌，这不一定是真错。很多时候，工具会报告一些电源形状（power shape）的连接问题，这些通常可以忽略。我们需要关注的是标准单元（std cell）的VDD/VSS引脚是否真的没连上。

怎么快速定位？用GUI界面里的Verification -> Error Browser，选择“Rail”错误类型