1. 为什么我把ICC II全流程先当作一张地图来学刚接触ICCompiler II的时候我犯了一个几乎所有新人都容易犯的错误打开工具手册从第一条命令开始背参数希望照着教程把一份设计从网表跑到GDS就算学会。结果可想而知——命令记住了不少工具能跑起来了但换个设计、换个工艺我又懵了因为根本不知道每个步骤之间到底在传递什么、某个报错为什么会在这个阶段出现。后来我才想明白一个简单但重要的道理ICC II的“全流程”不是一条命令流水线而是一张有逻辑递进关系的地图。你只有先把地图上的节点和连接关系看清楚再去研究每个节点里的细节学习效率才会真正上来。1.1 从后端“大流程”看ICC II的定位数字芯片从RTL到GDS业内习惯拆成前端逻辑设计和后端物理设计两大部分。前端把verilog变成功能正确的门级网表后端负责把网表变成可以送去流片的真实版图。ICC II就是后端物理设计中最核心的布局布线工具英文叫Place and Route简称PR。如果你对芯片设计流程还不太熟可以这样理解前端的综合工具比如Design Compiler是“把图纸变成零件清单”而ICC II则是“拿着零件清单在有限的地皮上盖楼”。地皮就是芯片面积零件就是标准单元、宏单元、IO单元楼就是最终版图。盖楼过程中你不仅要考虑楼能不能盖起来还要考虑每层楼的信号能不能按时到达、耗电会不会超标、楼与楼之间会不会打架这些就是ICC II全流程要解决的问题。从工具链位置看ICC II的上游是逻辑综合下游是Signoff验证工具。Signoff工具包括PrimeTime做时序签核、StarRC做寄生参数提取、IC Validator做DRC/LVS物理验证。ICC II和它们之间的衔接全靠数据文件综合来的网表和SDC约束是ICC II的输入ICC II输出的GDS、SPEF、更新后的网表和SDC则是Signoff工具的输入。任何一个环节的数据不干净都会导致后续工具疯狂报错。理解这个上下游关系你就明白为什么很多经验丰富的工程师整天强调“数据审查”。从工具代际看ICC II和上一代ICC最大的区别是它采用了统一的数据库模型和更先进的优化引擎。ICC时代前端综合数据和物理数据之间的转换比较割裂不同阶段要倒腾好几种中间格式而ICC II把逻辑信息、物理信息、时序信息、功耗信息都放进同一个数据模型里工具在优化的每个阶段都能同时看到这些维度收敛效率确实提升了一个量级。1.2 先画地图再谈优化这篇学习笔记是第一篇所以我给自己定的目标是先把overview讲清楚而不是把每条命令、每个变量的细节都塞进来。整个全流程的主线一句话就能说完数据准备 → 设计初始化 → 布图规划 → 标准单元放置 → 时钟树综合 → 布线 → 时序与DRC修复 → 结果输出。这条主线看起来简单但每条边上都挂满了细节。布图规划阶段要不要考虑macro的pin direction放置阶段是做congestion优化还是先做时序优化时钟树综合阶段要控制多少skew布线阶段遇到DRC违例是让工具自动修还是手动干预这些选择题会在你正式做完一个设计后反复出现。我的建议是先把主线记住然后在自己的头脑里生成一张“流程地图”每个节点旁边标上三样东西——输入是什么、输出是什么、这个阶段主要优化什么。比如Floorplan的输入是网表和物理库输出是宏单元位置、电源网络、布局区域约束主要优化的是芯片面积、拥塞预估和电源供给。这样你后面看任何教程、脚本都能迅速知道作者讲的属于地图上的哪一段不至于被各种细节绕晕。如果你已经从旧版ICC转到ICC II那这篇笔记同样有价值。工具升级带来的不只是命令名称变化更是流程理念的变化——多场景多角分析、层次化数据管理、统一物理数据模型这些概念旧流程里体验并不明显但ICC II把它们做成了主线的组成部分。后面的笔记我会逐段深入这篇先把框架立起来。2. 开工之前梳理ICC II的数据输入与检查清单很多新人拿到一个ICC II工程第一反应是赶紧敲命令但真正的老工程师第一反应是先做数据检查。ICC II工程启动需要的输入数据远比你想的多也远比你想的容易出错。2.1 准备一套完整的库文件和网表数据ICC II启动前要准备的第一大类是工艺相关的库文件。具体包括逻辑库Logic Library描述每个标准单元和宏单元的功能、时序、功耗、转换时间等逻辑特性常见格式是.db或.lib。综合工具和PR工具都要读它。物理库Physical Library描述单元在版图上的形状、大小、引脚位置、金属层信息常见格式在ICC II里主要是NDM数据库体系。工艺文件Tech File包含金属层定义、通孔规则、设计规则等物理工艺信息常见格式是.tf或类似描述。寄生参数表描述工艺在不同金属层、不同温压条件下对应的电阻电容模型用于RC抽取和时序计算。如果你的设计用了特殊工艺模块可能还需要额外的库比如模拟模块的抽象库、IO单元库等。第二大类是设计数据本身。门级网表是必须的它是所有逻辑连接关系的载体SDC约束文件也是必须的它告诉工具时钟周期是多少、输入输出延迟是多少、哪些路径是虚假路径如果是低功耗设计还要带上UPF文件描述电源域怎么划分、电平转换单元放在哪里。我用一个表格把这些数据和它们的作用整理出来方便你对照检查数据类别常见格式作用逻辑库.db / .lib单元功能和时序功耗特性物理库NDM / Milkyway单元几何形状和引脚位置工艺文件.tf / techfile金属层、通孔、DRC规则寄生参数表.tlup / .captblRC抽取建模门级网表.v / .sgdc逻辑连接关系时序约束.sdc时钟、IO时序、异常路径定义低功耗约束.upf电源域和低功耗策略物理约束.def初始布局、电源网络等物理信息库房环境脚本.tcl启动流程、公共设置、报告脚本第二类数据里还有一种不太起眼但很容易坑人的东西库房环境脚本。ICC II几乎完全基于Tcl脚本驱动所以团队的启动脚本、公共设置、报告脚本是否规范直接决定了你后面debug是不是方便。很多新人卡在流程跑不通最后发现是Tcl环境变量拼写错误这种低级错误其实可以通过公共脚本封装来规避。2.2 启动前一定要做的四项检查数据准备完之后别急着直接进入实现流程。我强烈建议按下面的顺序做一轮“体检”第一检查库文件完整性。用工具读取所有库文件确认库里面没有缺失的单元、没有损坏的视图尤其是macro单元它们的物理库和逻辑库必须版本匹配。我遇到过一种情况前端综合用的逻辑库版本比物理库新里面多了一个PIN定义结果ICC II在放置阶段一直报找不到物理引脚查了半天才发现库版本没对齐。第二检查网表与SDC的一致性。具体说就是所有时钟定义必须能在网表里找到对应的端口或pinSDC里约束的输入输出端口在网表顶层必须存在不要有约束了但不存在的时钟也不要有实际存在但完全没有约束的时钟。这一步用check_timing基本能看到初步结果但报出来的warning一定要逐个看不要放过。第三检查电源地连接。确认顶层所有电源地引脚已经声明所有标准单元的VDD/VSS在后续电源规划时能正确连通。电源地连接问题最坑的是它会潜伏很久Floorplan阶段完全不报错等你做完PG规划才发现单元根本没有电源连接重新定义电源网络会导致所有标准单元的物理位置全部重来损失以小时甚至天为单位。第四检查层次化连接和断链。如果你的设计有黑盒子、有跨域模块引用要提前确认边界连接都完整不要有悬空net或者双向pin连接错误。这些检查不一定每次都能发现所有问题但至少能把一些常见的低级错误挡在流程外面。我一直跟团队里的人说一句话在ICC II里前期花1小时做数据审查永远比后期花两天重跑整个flow划算。这个理念放在所有EDA工具上都成立但在ICC II这种重流程工具上尤其明显。3. 全流程主线Floorplan、Placement、CTS、Routing如果说数据准备是“战前物资”那这一章就是“正式作战”的主线。ICC II全流程最核心的四步就是Floorplan、Placement、CTS和Routing我一个个说。3.1 Floorplan像画毛坯房一样规划芯片Floorplan布图规划是物理设计的第一道分水岭也是最考验经验的一步。它决定了芯片面积如何划分、哪些区域放什么单元、电源网络的基本骨架怎么搭。有一个很贴切的比喻装修一套房子之前你不可能先决定沙发怎么摆你得先确定哪里是承重墙、哪里是卧室、哪里是客厅、水电线路从哪走。Floorplan就是画这套“毛坯房图”。在ICC II里Floorplan阶段的核心动作包括定义芯片core面积和形状摆放IO单元或IO端口摆放宏单元macro比如SRAM、PLL、模拟IP规划电源网络power stripes、power rings、pg straps创建placement blockages限制标准单元的摆放区域设定模块边界和层级结构Floorplan质量最重要的量化指标是利用率utilization。利用率等于标准单元总面积除以可用面积。一般来说设计会控制在50%到70%之间具体取决于工艺节点和设计类型。利用率太高意味着后面place的时候标准单元会把布线通道挤满产生大量congestion利用率太低又意味着die面积浪费芯片成本直线上升。新人在这一步很容易纠结我的建议是第一版先按60%左右的目标做跑一遍流程看拥塞情况再决定要不要加面积或降密度。Floorplan阶段还有一个容易被忽略的动作早期拥塞预估。ICC II在floorplan阶段就能做一些congestion预估虽然精度不如route阶段但用来发现区域性的热点问题足够用了。我第一次做项目时为了好看把两组大宏单元对称摆放结果发现它们之间的布线通道成了拥塞重灾区。后来把其中一组逆时针旋转90度热点立刻缓解。这种调整放在Floorplan阶段只需要几分钟放到placement之后就要动一大片区域重新摆放成本完全不是一回事。3.2 Placement与CTS从摆标准单元到插时钟树Floorplan确定了大格局之后就进入标准单元放置阶段也就是Placement。Placement的目标很简单把网表里成千上万、甚至上百万个标准单元放进芯片的可用区域里并且让它们的位置有利于时序收敛和布线畅通。ICC II里的Placement相关核心命令通常会对单元摆放和时序做联合优化它会一边放单元一边评估关键路径的线长和延迟必要时调整单元大小、插入缓冲器、重新映射逻辑门。这意味着Placement阶段做完了你其实已经完成了一轮“隐性的时序优化”只不过此时时钟网络还是理想状态所以结果不能作为最终时序。Placement完成后我会习惯性地跑一次congestion分析和early global route看看有没有区域的布线密度明显过高。如果发现有congestion热点一般有几种处理方式一是调整floorplan把热点区域旁边的宏单元挪开二是加placement blockage禁止标准单元在这个区域过度堆积三是设置regional density limit。这些方案各有优劣需要根据实际布局选择。但核心原则是必须在进入CTS之前解决掉明显拥塞因为CTS会插入大量时钟缓冲器进一步加剧拥塞。CTS时钟树综合是整个后端流程里最需要“手感”的环节。你要理解它的核心矛盾时钟信号要从时钟源出发同时送到成千上万个触发器的时钟端但是金属导线的延迟不可能让所有信号“同时”到达所以需要通过缓冲器逐级复制信号像树枝一样分叉扩散最终让所有端点的时钟到达时间尽量接近。CTS阶段要关注的关键指标有三个时钟偏斜skew、插入延迟latency、转换时间transition。Skew是指不同触发器时钟端到达时间的差异太大会导致时序边界变得极端Latency是指时钟从源端到终点端的总延迟太大会影响输入输出时序Transition是指时钟边沿的陡峭程度太慢会额外增加延迟和功耗。ICC II的CTS工具会自动在这些指标之间做权衡但你要通过约束设置告诉它优先级。我个人的经验是不要为了追求极致的skew而牺牲太多面积和功耗很多设计并不需要绝对零偏斜只要满足时序收敛条件即可。CTS做完之后时钟网络不再是理想状态了工具会把时钟树当作真实网络处理插入的缓冲器也带上了真实的RC延迟。所以从CTS阶段往后时序结果就已经具备很高的可信度。这时候你应该做一个阶段性的时序评估看看setup和hold是不是有大范围违例如果有继续往route冲大概率也是白费时间不如先回placement阶段调整。3.3 Routing与ECO布线收尾和快速修正Routing布线是把信号通道真正落实到金属线层的过程。和placement相比routing更像一场“疏通交通”每条信号路径都要在两个端点之间找到一条合法的、满足设计规则的走线路径同时不能占用太多绕线资源不能让信号之间串扰过大。ICC II的Routing流程一般分三个阶段全局布线、详细布线、布线后优化。全局布线把整个芯片划分成网格在每个网格里规划出大致的信号走向不做具体几何实现详细布线在网格路径的基础上为每条信号分配具体的金属层、线宽、通孔布线后优化则会检测时序、DRC、信号完整性等指标尝试通过插入缓冲器、调整线宽、修改绕线等方式修复问题。在先进工艺节点Routing阶段最容易爆发的问题就是信号完整性和天线效应。比如长距离平行走线会导致相邻信号之间的寄生电容变大产生串扰严重的时候信号可能被干扰到错误翻转。ICC II内置了多种修复机制比如自动加大线间距、插入屏蔽线、调整绕线层次但这些修复都会消耗面积和绕线资源所以你会看到工具不断在“优化目标”和“工艺限制”之间找平衡。Routing之后工具会报告DRC违例数量这些数字是否收敛到比较低的位置直接关系到后面Signoff工具的压力。如果在Routing结束之后仍有一些路径不满足时序条件或者是DRC还是有小部分违例这时候不会选择全量重跑而是用ECOEngineering Change Order做局部修正。ECO的思路是只修改必要的地方比如把某个单元的驱动强度调大一点、在关键路径上插入一个缓冲器、或者手动调整一小段走线。ICC II支持增量式ECO它会保留未受影响区域的布线结果只对改动部分做重新布局或重新布线。我在实际项目里曾经有过这样的经历整体route要跑四五个小时而一个setup违例的ECO修复只需半小时而且基本不影响附近区域的稳定性。这就是全流程里“成本控制”意识的体现——不是每一步都要推倒重来能用最小代价解决的问题就不要大动干戈。4. ICC II流程层面的几个重要设定多模式、层次化与约束管理这一章的内容不会直接出现在命令流水线上但它们会影响你对全流程的理解深度。如果你只是照着脚本跑流程这些概念可能一辈子都用不上但只要你打算真正调优一个设计它们就是绕不开的底层设定。4.1 多角多模式MMMC不是可选项传统后端流程里我们通常把工艺角这个概念挂在嘴边。芯片在不同温度、电压、工艺偏差下晶体管的快慢特性会不同通常用SS慢工艺角慢电压、高温、TT典型工艺角、FF快工艺角快电压、低温来定义边界情况。做setup分析时通常看SS角做hold分析时通常看FF角。所以老流程里大家往往会把setup和hold分开在不同corner下分别run一遍再分别修。ICC II原生支持MMMCMulti-Mode Multi-Corner也就是在一个流程里同时定义多个分析场景。所谓“场景”是“耦合的一组工艺角RC寄生条件约束文件功耗状态”的组合。你可以同时定义setup场景和hold场景工具在place、CTS、route的每一步都会同时评估所有场景下的时序做优化决策时也会尝试让每个场景都满足要求。这对流程改造的意义非常大。设想一下你在SS corner下把setup全部收敛了结果切到FF corner下一看hold violation满天飞。如果是分开跑流程你得再调一轮hold然后再回过来重新看setup是不是又被破坏了反复迭代非常痛苦。而MMMC模式让工具一次性看到所有边界在优化一开始就会做折中处理最终结果通常比分开跑要均衡得多。所以我建议所有用ICC II的人从最开始学流程就要按MMMC的思路来做不要偷懒只定义单场景。4.2 层次化设计的规划要前移ICC II全流程还有一种极端情况设计规模太大几亿门甚至几十亿门flat地跑一次place和route运行时间可能要按天计算而且内存开销巨大。这时候就必须做层次化Hierarchical设计。层次化设计的思路很简单把芯片拆成多个模块每个模块独立完成自己的物理设计最后在顶层做集成。这样一来每个模块的规模降下来了跑起来速度快得多多个模块还能并行推进项目周期能压缩不少。但代价也很明显模块之间的接口时序怎么分配、每个模块的物理边界怎么定、模块的抽象模型怎么做这些都要在项目早期就规划好。ICC II在层次化流程里提供了不少工具来辅助决策。比如Block Abstraction模型可以让顶层把所有子模块当成一个黑盒子来处理只关心它的引脚位置和时序行为比如budgeting功能可以把顶层的时序约束拆分到每个子模块再比如interface logic placement决定模块边界上的逻辑单元放在哪一侧。这些概念我在刚学ICC II时没有理解到位直到第一次做hier项目才体会到原来大多数顶层集成问题都不是顶层本身的问题而是各个子模块的物理边界、时序预算、电源供电连接没协调好。所以学习阶段一定要建立“全局协调”的观念不要觉得hier flow只是“把设计拆开来做”这么简单。4.3 约束和SDC的管理SDC约束文件是连接逻辑综合和物理设计的“契约”。里面定义了时钟周期、生成时钟、输入延迟、输出延迟、虚假路径、多周期路径等约束。ICC II从网表读入开始到最终输出时序报告全程都在参考SDC。所以SDC的质量和一致性直接影响全流程的成败。一个很重要的事实是ICC II在不同阶段对时钟的处理方式不同。在placement之前的阶段时钟网络还没有真实布线工具会按照理想时钟来处理——认为时钟到达所有触发器的时间一致但到了CTS之后时钟网络被实际创建出来了工具就切换到传播时钟模式此时时钟的延迟和偏斜都会真实计算。这会导致同一个设计在CTS之前和CTS之后的时序结果有较大差异你需要理解并接受这种变化而不是看到结果变差就慌。从管理角度看SDC经常不是单独一个文件。一个复杂设计里可能有一个顶层的SDC还有每个子模块的SDC还有专门给DFT测试模式用的约束文件。ICC II的Tcl环境支持一次性source多个SDC文件你需要用合理的脚本结构把不同场景、不同模块的约束分开管理。我见过不少新手图省事把所有约束写在一个大文件里结果模块复用时牵一发动全身。反过来维护良好的SDC脚本会让你做ECO和版本迭代时舒服很多只改该改的部分不会误伤其他模块。5. 第一版结果拿到之后报告、检查与数据交付很多人以为place和route跑完工具没有报fatal error工程就算“大功告成”了。但真正的项目里第一版flow跑通只是开始。ICC II会生成大量报告你要学会从中快速找到真正的问题而不是被满屏的数字吓到。5.1 时序报告怎么排查时序报告是所有报告里的核心。跑到每一个里程碑节点placement后、CTS后、route后都应该输出一份时序摘要来看WNS和TNS。WNS是最差负裕量Worst Negative Slack代表最差的一条关键路径还有多少余量TNS是总负裕量Total Negative Slack代表所有违例路径的负裕量总和。记住这两个指标它们会贯穿你整个后端生涯。如果WNS很差比如负了很大通常说明有“硬伤”可能是SDC约束定义错了比如时钟周期写到了根本不可能实现的频率也可能是某个关键模块被放在了芯片角落物理距离太长导致信号延迟爆炸。如果WNS看起来还行但TNS很大说明违例路径数量很多可能是整体驱动强度不足或者拥塞导致布线长度超标。看时序报告不要光看最终的违例表格要往上一层去找根因。我的习惯是先把违例路径按时钟域分组再按模块分组看看它们是否有空间聚集性。如果大量违例集中在某个宏单元附近那很可能是这个宏单元的引脚布局和周围逻辑不协调如果违例都发生在横跨整个芯片的长路径上那大概率是floorplan阶段没有把相关的逻辑放得足够近。事出必有因关键在于你是否愿意多问几个“为什么”。5.2 DRC检查与LVS协作时序收敛了不代表设计就能送去流片。你还要过DRC设计规则检查和LVS版图与原理图一致性检查这两关。DRC检查是最基础的物理规则检查比如金属线最小宽度够不够、线与线的间距够不够、通孔重叠是否符合工艺要求。ICC II在布线后会做in-design DRC但受限于工具优化能力先进工艺下完全不报DRC的情况很少见。你需要在流程里加上DRC修复的步骤让工具尽可能自动修复。如果自动修复之后仍然有少量DRC违例就需要结合具体违例类型决定是修改局部绕线还是手动调整。我建议定期检查DRC违例的趋势如果在迭代过程中违例数量持续下降说明优化方向是对的如果反复维修仍然居高不下那可能要回头审视floorplan或工艺文件是否设置有问题。LVS是验证版图连接关系和原理图网表是否一致。这一步通常交给专门的物理验证工具来做ICC II的输出GDS或DEF为LVS提供版图数据。LVS常见问题包括电源地网络连接不完全、宏单元引脚连接错误、filler和decap单元遗漏等。ICC II在流程里保持完整的电源网络连接信息非常重要否则你输出到后期工具的网表和版图对不上LVS就会报一堆错。记住一句经验LVS问题的根因往往不是下游验证工具“太严”而是后端流程里某些设计信息没有完整保留。5.3 数据交付要按清单走ICC II全流程跑完输出物不是一个单一文件而是一套数据。至少要包括最终版图GDS或OASIS用于物理验证和流片最终网表用于LVS和形式验证更新后的SDC尤其是时钟树综合之后生成的时钟约束SPEF寄生参数文件用于PrimeTime做signoff时序时序报告、功耗报告、拥塞报告等标志报告电源供电网络信息供IR drop分析工具使用这里我要特别强调数据一致性。GDS可能是从某个时间点导出的网表是另一个时间点修改过的SDC又是更早一版的三个数据来自不同版本——这种情况在复杂项目里并不少见而且每次都会折腾人。解决方式就是建立交付清单每项输出都标注来源、版本、时间、使用的约束文件版本这样下游工具拿到数据时你能快速判断它是不是同一套逻辑。6. 个人建议学ICC II时怎么提高效率以及我踩过的几个坑到了最后一部分我想说点更贴近实战的经验。这些东西在官方文档里不太容易学到但往往是最影响你实际工作效率的。6.1 推荐的实操顺序如果你是个完全的新手不要一开始就啃文档。找一份最小示例设计几十个标准单元就够了拿到库和网表之后从create_floorplan开始一步步做到route完成先把主干跑通。跑的过程中不用追求每个选项的最优解先让工具默认参数运行你要做的是看日志理解每一步发生了什么。第一次跑通之后再做三件事第一给流程加报告脚本用report_qor、report_timing、report_congestion这些命令把关键指标汇总出来第二尝试改变几个参数比如利用率调高或调低看看对结果的影响趋势第三练习看时序报告把WNS、TNS的变化和物理布局的变化联系起来。这套方法论一旦形成你后续学任何EDA工具都会很快。还有一点是关于Tcl的。ICC II的整个交互环境都是Tcl如果你对Tcl不熟建议先补一补基础语法变量、列表、foreach循环、proc封装、正则表达式。不需要成为Tcl大师但至少要能看懂团队现有脚本的逻辑。6.2 几个我踩过的坑第一个坑setup和hold场景混在一起优化。我早期做MMMC设置时把setup和hold场景一股脑放进同一组优化目标里结果工具花费大量时间在同时满足两个场景的矛盾约束上两边都没收敛好。后来我把场景按主次区分先保证关键场景收敛再在这个基础上兼顾其他场景效果好很多。第二个坑Floorplan阶段没给电源网络留够空间。为了省面积我把核心区域排得很满结果placement做完之后电源网络无处可走PG router反复报警最后只能手动切开一片区域重新布置。那一次的教训让我明白floorplan阶段的“利用率”一定要把电源网络、布线通道、时钟树资源都算进去不能只盯着标准单元面积。第三个坑CTS阶段盲目追求零skew。有一段时间我总觉得skew越小越好于是把时钟树约束设得非常紧结果时钟缓冲器数量爆炸面积和功耗严重超标而且导致局部拥塞。后来才明白skew只要满足时序要求就够了工具真正需要的是一棵平衡且低功耗的时钟树而不是一棵数学上完美的树。说到底ICC II的全流程本质上是一连串目标权衡的过程。你先把地图记住知道每个阶段管什么、输出什么、和前后阶段如何衔接后面填细节的时候就会很有底气。这篇overview作为系列第一篇先写到这里后续我会按floorplan、placement、CTS、routing这些主题分别整理更细的实操笔记把每一步的内部机制和调参思路都掰开揉碎地讲清楚。希望这些经验能帮你少踩几个坑早一点从“能跑流程”进化到“会调流程”。 ICC II后端物理设计全流程详解：从数据准备到布线优化
1. 为什么我把ICC II全流程先当作一张地图来学刚接触ICCompiler II的时候我犯了一个几乎所有新人都容易犯的错误打开工具手册从第一条命令开始背参数希望照着教程把一份设计从网表跑到GDS就算学会。结果可想而知——命令记住了不少工具能跑起来了但换个设计、换个工艺我又懵了因为根本不知道每个步骤之间到底在传递什么、某个报错为什么会在这个阶段出现。后来我才想明白一个简单但重要的道理ICC II的“全流程”不是一条命令流水线而是一张有逻辑递进关系的地图。你只有先把地图上的节点和连接关系看清楚再去研究每个节点里的细节学习效率才会真正上来。1.1 从后端“大流程”看ICC II的定位数字芯片从RTL到GDS业内习惯拆成前端逻辑设计和后端物理设计两大部分。前端把verilog变成功能正确的门级网表后端负责把网表变成可以送去流片的真实版图。ICC II就是后端物理设计中最核心的布局布线工具英文叫Place and Route简称PR。如果你对芯片设计流程还不太熟可以这样理解前端的综合工具比如Design Compiler是“把图纸变成零件清单”而ICC II则是“拿着零件清单在有限的地皮上盖楼”。地皮就是芯片面积零件就是标准单元、宏单元、IO单元楼就是最终版图。盖楼过程中你不仅要考虑楼能不能盖起来还要考虑每层楼的信号能不能按时到达、耗电会不会超标、楼与楼之间会不会打架这些就是ICC II全流程要解决的问题。从工具链位置看ICC II的上游是逻辑综合下游是Signoff验证工具。Signoff工具包括PrimeTime做时序签核、StarRC做寄生参数提取、IC Validator做DRC/LVS物理验证。ICC II和它们之间的衔接全靠数据文件综合来的网表和SDC约束是ICC II的输入ICC II输出的GDS、SPEF、更新后的网表和SDC则是Signoff工具的输入。任何一个环节的数据不干净都会导致后续工具疯狂报错。理解这个上下游关系你就明白为什么很多经验丰富的工程师整天强调“数据审查”。从工具代际看ICC II和上一代ICC最大的区别是它采用了统一的数据库模型和更先进的优化引擎。ICC时代前端综合数据和物理数据之间的转换比较割裂不同阶段要倒腾好几种中间格式而ICC II把逻辑信息、物理信息、时序信息、功耗信息都放进同一个数据模型里工具在优化的每个阶段都能同时看到这些维度收敛效率确实提升了一个量级。1.2 先画地图再谈优化这篇学习笔记是第一篇所以我给自己定的目标是先把overview讲清楚而不是把每条命令、每个变量的细节都塞进来。整个全流程的主线一句话就能说完数据准备 → 设计初始化 → 布图规划 → 标准单元放置 → 时钟树综合 → 布线 → 时序与DRC修复 → 结果输出。这条主线看起来简单但每条边上都挂满了细节。布图规划阶段要不要考虑macro的pin direction放置阶段是做congestion优化还是先做时序优化时钟树综合阶段要控制多少skew布线阶段遇到DRC违例是让工具自动修还是手动干预这些选择题会在你正式做完一个设计后反复出现。我的建议是先把主线记住然后在自己的头脑里生成一张“流程地图”每个节点旁边标上三样东西——输入是什么、输出是什么、这个阶段主要优化什么。比如Floorplan的输入是网表和物理库输出是宏单元位置、电源网络、布局区域约束主要优化的是芯片面积、拥塞预估和电源供给。这样你后面看任何教程、脚本都能迅速知道作者讲的属于地图上的哪一段不至于被各种细节绕晕。如果你已经从旧版ICC转到ICC II那这篇笔记同样有价值。工具升级带来的不只是命令名称变化更是流程理念的变化——多场景多角分析、层次化数据管理、统一物理数据模型这些概念旧流程里体验并不明显但ICC II把它们做成了主线的组成部分。后面的笔记我会逐段深入这篇先把框架立起来。2. 开工之前梳理ICC II的数据输入与检查清单很多新人拿到一个ICC II工程第一反应是赶紧敲命令但真正的老工程师第一反应是先做数据检查。ICC II工程启动需要的输入数据远比你想的多也远比你想的容易出错。2.1 准备一套完整的库文件和网表数据ICC II启动前要准备的第一大类是工艺相关的库文件。具体包括逻辑库Logic Library描述每个标准单元和宏单元的功能、时序、功耗、转换时间等逻辑特性常见格式是.db或.lib。综合工具和PR工具都要读它。物理库Physical Library描述单元在版图上的形状、大小、引脚位置、金属层信息常见格式在ICC II里主要是NDM数据库体系。工艺文件Tech File包含金属层定义、通孔规则、设计规则等物理工艺信息常见格式是.tf或类似描述。寄生参数表描述工艺在不同金属层、不同温压条件下对应的电阻电容模型用于RC抽取和时序计算。如果你的设计用了特殊工艺模块可能还需要额外的库比如模拟模块的抽象库、IO单元库等。第二大类是设计数据本身。门级网表是必须的它是所有逻辑连接关系的载体SDC约束文件也是必须的它告诉工具时钟周期是多少、输入输出延迟是多少、哪些路径是虚假路径如果是低功耗设计还要带上UPF文件描述电源域怎么划分、电平转换单元放在哪里。我用一个表格把这些数据和它们的作用整理出来方便你对照检查数据类别常见格式作用逻辑库.db / .lib单元功能和时序功耗特性物理库NDM / Milkyway单元几何形状和引脚位置工艺文件.tf / techfile金属层、通孔、DRC规则寄生参数表.tlup / .captblRC抽取建模门级网表.v / .sgdc逻辑连接关系时序约束.sdc时钟、IO时序、异常路径定义低功耗约束.upf电源域和低功耗策略物理约束.def初始布局、电源网络等物理信息库房环境脚本.tcl启动流程、公共设置、报告脚本第二类数据里还有一种不太起眼但很容易坑人的东西库房环境脚本。ICC II几乎完全基于Tcl脚本驱动所以团队的启动脚本、公共设置、报告脚本是否规范直接决定了你后面debug是不是方便。很多新人卡在流程跑不通最后发现是Tcl环境变量拼写错误这种低级错误其实可以通过公共脚本封装来规避。2.2 启动前一定要做的四项检查数据准备完之后别急着直接进入实现流程。我强烈建议按下面的顺序做一轮“体检”第一检查库文件完整性。用工具读取所有库文件确认库里面没有缺失的单元、没有损坏的视图尤其是macro单元它们的物理库和逻辑库必须版本匹配。我遇到过一种情况前端综合用的逻辑库版本比物理库新里面多了一个PIN定义结果ICC II在放置阶段一直报找不到物理引脚查了半天才发现库版本没对齐。第二检查网表与SDC的一致性。具体说就是所有时钟定义必须能在网表里找到对应的端口或pinSDC里约束的输入输出端口在网表顶层必须存在不要有约束了但不存在的时钟也不要有实际存在但完全没有约束的时钟。这一步用check_timing基本能看到初步结果但报出来的warning一定要逐个看不要放过。第三检查电源地连接。确认顶层所有电源地引脚已经声明所有标准单元的VDD/VSS在后续电源规划时能正确连通。电源地连接问题最坑的是它会潜伏很久Floorplan阶段完全不报错等你做完PG规划才发现单元根本没有电源连接重新定义电源网络会导致所有标准单元的物理位置全部重来损失以小时甚至天为单位。第四检查层次化连接和断链。如果你的设计有黑盒子、有跨域模块引用要提前确认边界连接都完整不要有悬空net或者双向pin连接错误。这些检查不一定每次都能发现所有问题但至少能把一些常见的低级错误挡在流程外面。我一直跟团队里的人说一句话在ICC II里前期花1小时做数据审查永远比后期花两天重跑整个flow划算。这个理念放在所有EDA工具上都成立但在ICC II这种重流程工具上尤其明显。3. 全流程主线Floorplan、Placement、CTS、Routing如果说数据准备是“战前物资”那这一章就是“正式作战”的主线。ICC II全流程最核心的四步就是Floorplan、Placement、CTS和Routing我一个个说。3.1 Floorplan像画毛坯房一样规划芯片Floorplan布图规划是物理设计的第一道分水岭也是最考验经验的一步。它决定了芯片面积如何划分、哪些区域放什么单元、电源网络的基本骨架怎么搭。有一个很贴切的比喻装修一套房子之前你不可能先决定沙发怎么摆你得先确定哪里是承重墙、哪里是卧室、哪里是客厅、水电线路从哪走。Floorplan就是画这套“毛坯房图”。在ICC II里Floorplan阶段的核心动作包括定义芯片core面积和形状摆放IO单元或IO端口摆放宏单元macro比如SRAM、PLL、模拟IP规划电源网络power stripes、power rings、pg straps创建placement blockages限制标准单元的摆放区域设定模块边界和层级结构Floorplan质量最重要的量化指标是利用率utilization。利用率等于标准单元总面积除以可用面积。一般来说设计会控制在50%到70%之间具体取决于工艺节点和设计类型。利用率太高意味着后面place的时候标准单元会把布线通道挤满产生大量congestion利用率太低又意味着die面积浪费芯片成本直线上升。新人在这一步很容易纠结我的建议是第一版先按60%左右的目标做跑一遍流程看拥塞情况再决定要不要加面积或降密度。Floorplan阶段还有一个容易被忽略的动作早期拥塞预估。ICC II在floorplan阶段就能做一些congestion预估虽然精度不如route阶段但用来发现区域性的热点问题足够用了。我第一次做项目时为了好看把两组大宏单元对称摆放结果发现它们之间的布线通道成了拥塞重灾区。后来把其中一组逆时针旋转90度热点立刻缓解。这种调整放在Floorplan阶段只需要几分钟放到placement之后就要动一大片区域重新摆放成本完全不是一回事。3.2 Placement与CTS从摆标准单元到插时钟树Floorplan确定了大格局之后就进入标准单元放置阶段也就是Placement。Placement的目标很简单把网表里成千上万、甚至上百万个标准单元放进芯片的可用区域里并且让它们的位置有利于时序收敛和布线畅通。ICC II里的Placement相关核心命令通常会对单元摆放和时序做联合优化它会一边放单元一边评估关键路径的线长和延迟必要时调整单元大小、插入缓冲器、重新映射逻辑门。这意味着Placement阶段做完了你其实已经完成了一轮“隐性的时序优化”只不过此时时钟网络还是理想状态所以结果不能作为最终时序。Placement完成后我会习惯性地跑一次congestion分析和early global route看看有没有区域的布线密度明显过高。如果发现有congestion热点一般有几种处理方式一是调整floorplan把热点区域旁边的宏单元挪开二是加placement blockage禁止标准单元在这个区域过度堆积三是设置regional density limit。这些方案各有优劣需要根据实际布局选择。但核心原则是必须在进入CTS之前解决掉明显拥塞因为CTS会插入大量时钟缓冲器进一步加剧拥塞。CTS时钟树综合是整个后端流程里最需要“手感”的环节。你要理解它的核心矛盾时钟信号要从时钟源出发同时送到成千上万个触发器的时钟端但是金属导线的延迟不可能让所有信号“同时”到达所以需要通过缓冲器逐级复制信号像树枝一样分叉扩散最终让所有端点的时钟到达时间尽量接近。CTS阶段要关注的关键指标有三个时钟偏斜skew、插入延迟latency、转换时间transition。Skew是指不同触发器时钟端到达时间的差异太大会导致时序边界变得极端Latency是指时钟从源端到终点端的总延迟太大会影响输入输出时序Transition是指时钟边沿的陡峭程度太慢会额外增加延迟和功耗。ICC II的CTS工具会自动在这些指标之间做权衡但你要通过约束设置告诉它优先级。我个人的经验是不要为了追求极致的skew而牺牲太多面积和功耗很多设计并不需要绝对零偏斜只要满足时序收敛条件即可。CTS做完之后时钟网络不再是理想状态了工具会把时钟树当作真实网络处理插入的缓冲器也带上了真实的RC延迟。所以从CTS阶段往后时序结果就已经具备很高的可信度。这时候你应该做一个阶段性的时序评估看看setup和hold是不是有大范围违例如果有继续往route冲大概率也是白费时间不如先回placement阶段调整。3.3 Routing与ECO布线收尾和快速修正Routing布线是把信号通道真正落实到金属线层的过程。和placement相比routing更像一场“疏通交通”每条信号路径都要在两个端点之间找到一条合法的、满足设计规则的走线路径同时不能占用太多绕线资源不能让信号之间串扰过大。ICC II的Routing流程一般分三个阶段全局布线、详细布线、布线后优化。全局布线把整个芯片划分成网格在每个网格里规划出大致的信号走向不做具体几何实现详细布线在网格路径的基础上为每条信号分配具体的金属层、线宽、通孔布线后优化则会检测时序、DRC、信号完整性等指标尝试通过插入缓冲器、调整线宽、修改绕线等方式修复问题。在先进工艺节点Routing阶段最容易爆发的问题就是信号完整性和天线效应。比如长距离平行走线会导致相邻信号之间的寄生电容变大产生串扰严重的时候信号可能被干扰到错误翻转。ICC II内置了多种修复机制比如自动加大线间距、插入屏蔽线、调整绕线层次但这些修复都会消耗面积和绕线资源所以你会看到工具不断在“优化目标”和“工艺限制”之间找平衡。Routing之后工具会报告DRC违例数量这些数字是否收敛到比较低的位置直接关系到后面Signoff工具的压力。如果在Routing结束之后仍有一些路径不满足时序条件或者是DRC还是有小部分违例这时候不会选择全量重跑而是用ECOEngineering Change Order做局部修正。ECO的思路是只修改必要的地方比如把某个单元的驱动强度调大一点、在关键路径上插入一个缓冲器、或者手动调整一小段走线。ICC II支持增量式ECO它会保留未受影响区域的布线结果只对改动部分做重新布局或重新布线。我在实际项目里曾经有过这样的经历整体route要跑四五个小时而一个setup违例的ECO修复只需半小时而且基本不影响附近区域的稳定性。这就是全流程里“成本控制”意识的体现——不是每一步都要推倒重来能用最小代价解决的问题就不要大动干戈。4. ICC II流程层面的几个重要设定多模式、层次化与约束管理这一章的内容不会直接出现在命令流水线上但它们会影响你对全流程的理解深度。如果你只是照着脚本跑流程这些概念可能一辈子都用不上但只要你打算真正调优一个设计它们就是绕不开的底层设定。4.1 多角多模式MMMC不是可选项传统后端流程里我们通常把工艺角这个概念挂在嘴边。芯片在不同温度、电压、工艺偏差下晶体管的快慢特性会不同通常用SS慢工艺角慢电压、高温、TT典型工艺角、FF快工艺角快电压、低温来定义边界情况。做setup分析时通常看SS角做hold分析时通常看FF角。所以老流程里大家往往会把setup和hold分开在不同corner下分别run一遍再分别修。ICC II原生支持MMMCMulti-Mode Multi-Corner也就是在一个流程里同时定义多个分析场景。所谓“场景”是“耦合的一组工艺角RC寄生条件约束文件功耗状态”的组合。你可以同时定义setup场景和hold场景工具在place、CTS、route的每一步都会同时评估所有场景下的时序做优化决策时也会尝试让每个场景都满足要求。这对流程改造的意义非常大。设想一下你在SS corner下把setup全部收敛了结果切到FF corner下一看hold violation满天飞。如果是分开跑流程你得再调一轮hold然后再回过来重新看setup是不是又被破坏了反复迭代非常痛苦。而MMMC模式让工具一次性看到所有边界在优化一开始就会做折中处理最终结果通常比分开跑要均衡得多。所以我建议所有用ICC II的人从最开始学流程就要按MMMC的思路来做不要偷懒只定义单场景。4.2 层次化设计的规划要前移ICC II全流程还有一种极端情况设计规模太大几亿门甚至几十亿门flat地跑一次place和route运行时间可能要按天计算而且内存开销巨大。这时候就必须做层次化Hierarchical设计。层次化设计的思路很简单把芯片拆成多个模块每个模块独立完成自己的物理设计最后在顶层做集成。这样一来每个模块的规模降下来了跑起来速度快得多多个模块还能并行推进项目周期能压缩不少。但代价也很明显模块之间的接口时序怎么分配、每个模块的物理边界怎么定、模块的抽象模型怎么做这些都要在项目早期就规划好。ICC II在层次化流程里提供了不少工具来辅助决策。比如Block Abstraction模型可以让顶层把所有子模块当成一个黑盒子来处理只关心它的引脚位置和时序行为比如budgeting功能可以把顶层的时序约束拆分到每个子模块再比如interface logic placement决定模块边界上的逻辑单元放在哪一侧。这些概念我在刚学ICC II时没有理解到位直到第一次做hier项目才体会到原来大多数顶层集成问题都不是顶层本身的问题而是各个子模块的物理边界、时序预算、电源供电连接没协调好。所以学习阶段一定要建立“全局协调”的观念不要觉得hier flow只是“把设计拆开来做”这么简单。4.3 约束和SDC的管理SDC约束文件是连接逻辑综合和物理设计的“契约”。里面定义了时钟周期、生成时钟、输入延迟、输出延迟、虚假路径、多周期路径等约束。ICC II从网表读入开始到最终输出时序报告全程都在参考SDC。所以SDC的质量和一致性直接影响全流程的成败。一个很重要的事实是ICC II在不同阶段对时钟的处理方式不同。在placement之前的阶段时钟网络还没有真实布线工具会按照理想时钟来处理——认为时钟到达所有触发器的时间一致但到了CTS之后时钟网络被实际创建出来了工具就切换到传播时钟模式此时时钟的延迟和偏斜都会真实计算。这会导致同一个设计在CTS之前和CTS之后的时序结果有较大差异你需要理解并接受这种变化而不是看到结果变差就慌。从管理角度看SDC经常不是单独一个文件。一个复杂设计里可能有一个顶层的SDC还有每个子模块的SDC还有专门给DFT测试模式用的约束文件。ICC II的Tcl环境支持一次性source多个SDC文件你需要用合理的脚本结构把不同场景、不同模块的约束分开管理。我见过不少新手图省事把所有约束写在一个大文件里结果模块复用时牵一发动全身。反过来维护良好的SDC脚本会让你做ECO和版本迭代时舒服很多只改该改的部分不会误伤其他模块。5. 第一版结果拿到之后报告、检查与数据交付很多人以为place和route跑完工具没有报fatal error工程就算“大功告成”了。但真正的项目里第一版flow跑通只是开始。ICC II会生成大量报告你要学会从中快速找到真正的问题而不是被满屏的数字吓到。5.1 时序报告怎么排查时序报告是所有报告里的核心。跑到每一个里程碑节点placement后、CTS后、route后都应该输出一份时序摘要来看WNS和TNS。WNS是最差负裕量Worst Negative Slack代表最差的一条关键路径还有多少余量TNS是总负裕量Total Negative Slack代表所有违例路径的负裕量总和。记住这两个指标它们会贯穿你整个后端生涯。如果WNS很差比如负了很大通常说明有“硬伤”可能是SDC约束定义错了比如时钟周期写到了根本不可能实现的频率也可能是某个关键模块被放在了芯片角落物理距离太长导致信号延迟爆炸。如果WNS看起来还行但TNS很大说明违例路径数量很多可能是整体驱动强度不足或者拥塞导致布线长度超标。看时序报告不要光看最终的违例表格要往上一层去找根因。我的习惯是先把违例路径按时钟域分组再按模块分组看看它们是否有空间聚集性。如果大量违例集中在某个宏单元附近那很可能是这个宏单元的引脚布局和周围逻辑不协调如果违例都发生在横跨整个芯片的长路径上那大概率是floorplan阶段没有把相关的逻辑放得足够近。事出必有因关键在于你是否愿意多问几个“为什么”。5.2 DRC检查与LVS协作时序收敛了不代表设计就能送去流片。你还要过DRC设计规则检查和LVS版图与原理图一致性检查这两关。DRC检查是最基础的物理规则检查比如金属线最小宽度够不够、线与线的间距够不够、通孔重叠是否符合工艺要求。ICC II在布线后会做in-design DRC但受限于工具优化能力先进工艺下完全不报DRC的情况很少见。你需要在流程里加上DRC修复的步骤让工具尽可能自动修复。如果自动修复之后仍然有少量DRC违例就需要结合具体违例类型决定是修改局部绕线还是手动调整。我建议定期检查DRC违例的趋势如果在迭代过程中违例数量持续下降说明优化方向是对的如果反复维修仍然居高不下那可能要回头审视floorplan或工艺文件是否设置有问题。LVS是验证版图连接关系和原理图网表是否一致。这一步通常交给专门的物理验证工具来做ICC II的输出GDS或DEF为LVS提供版图数据。LVS常见问题包括电源地网络连接不完全、宏单元引脚连接错误、filler和decap单元遗漏等。ICC II在流程里保持完整的电源网络连接信息非常重要否则你输出到后期工具的网表和版图对不上LVS就会报一堆错。记住一句经验LVS问题的根因往往不是下游验证工具“太严”而是后端流程里某些设计信息没有完整保留。5.3 数据交付要按清单走ICC II全流程跑完输出物不是一个单一文件而是一套数据。至少要包括最终版图GDS或OASIS用于物理验证和流片最终网表用于LVS和形式验证更新后的SDC尤其是时钟树综合之后生成的时钟约束SPEF寄生参数文件用于PrimeTime做signoff时序时序报告、功耗报告、拥塞报告等标志报告电源供电网络信息供IR drop分析工具使用这里我要特别强调数据一致性。GDS可能是从某个时间点导出的网表是另一个时间点修改过的SDC又是更早一版的三个数据来自不同版本——这种情况在复杂项目里并不少见而且每次都会折腾人。解决方式就是建立交付清单每项输出都标注来源、版本、时间、使用的约束文件版本这样下游工具拿到数据时你能快速判断它是不是同一套逻辑。6. 个人建议学ICC II时怎么提高效率以及我踩过的几个坑到了最后一部分我想说点更贴近实战的经验。这些东西在官方文档里不太容易学到但往往是最影响你实际工作效率的。6.1 推荐的实操顺序如果你是个完全的新手不要一开始就啃文档。找一份最小示例设计几十个标准单元就够了拿到库和网表之后从create_floorplan开始一步步做到route完成先把主干跑通。跑的过程中不用追求每个选项的最优解先让工具默认参数运行你要做的是看日志理解每一步发生了什么。第一次跑通之后再做三件事第一给流程加报告脚本用report_qor、report_timing、report_congestion这些命令把关键指标汇总出来第二尝试改变几个参数比如利用率调高或调低看看对结果的影响趋势第三练习看时序报告把WNS、TNS的变化和物理布局的变化联系起来。这套方法论一旦形成你后续学任何EDA工具都会很快。还有一点是关于Tcl的。ICC II的整个交互环境都是Tcl如果你对Tcl不熟建议先补一补基础语法变量、列表、foreach循环、proc封装、正则表达式。不需要成为Tcl大师但至少要能看懂团队现有脚本的逻辑。6.2 几个我踩过的坑第一个坑setup和hold场景混在一起优化。我早期做MMMC设置时把setup和hold场景一股脑放进同一组优化目标里结果工具花费大量时间在同时满足两个场景的矛盾约束上两边都没收敛好。后来我把场景按主次区分先保证关键场景收敛再在这个基础上兼顾其他场景效果好很多。第二个坑Floorplan阶段没给电源网络留够空间。为了省面积我把核心区域排得很满结果placement做完之后电源网络无处可走PG router反复报警最后只能手动切开一片区域重新布置。那一次的教训让我明白floorplan阶段的“利用率”一定要把电源网络、布线通道、时钟树资源都算进去不能只盯着标准单元面积。第三个坑CTS阶段盲目追求零skew。有一段时间我总觉得skew越小越好于是把时钟树约束设得非常紧结果时钟缓冲器数量爆炸面积和功耗严重超标而且导致局部拥塞。后来才明白skew只要满足时序要求就够了工具真正需要的是一棵平衡且低功耗的时钟树而不是一棵数学上完美的树。说到底ICC II的全流程本质上是一连串目标权衡的过程。你先把地图记住知道每个阶段管什么、输出什么、和前后阶段如何衔接后面填细节的时候就会很有底气。这篇overview作为系列第一篇先写到这里后续我会按floorplan、placement、CTS、routing这些主题分别整理更细的实操笔记把每一步的内部机制和调参思路都掰开揉碎地讲清楚。希望这些经验能帮你少踩几个坑早一点从“能跑流程”进化到“会调流程”。