聊到数字IC后端尤其是先进工艺7nm以下的物理实现IC Compiler II也就是ICC II是个绕不开的名字。我自己第一次认真接触ICC II是接手一个从ICC一代迁移过来的项目当时既要理解新工具的数据模型又要保证原有流程的时序和物理签核结果不回退前期花了不少精力。现在回过头看那段“边踩坑边跑通”的经历反而帮我把整个PRPlace and Route布局布线流程重新梳理了一遍。这篇笔记是整个学习系列的第一篇重点做一个ICC II使用全流程overview它是什么、为什么值得学、从netlist到GDSII完整流程分几个阶段、每个阶段的输入输出长什么样以及一个最小可运行的脚本骨架。内容主要面向刚入门数字后端、准备接触ICC II的同学也适合从其他PR工具转过来的工程师参考。1. 工具定位ICC II 到底是个什么东西1.1 一句话理解ICC IIIC Compiler II是Synopsys推出的新一代布局布线工具核心任务只有一个把逻辑综合比如Design Compiler输出的门级网表netlist结合时序约束SDC、物理库、寄生参数模型等一堆输入文件经过布图规划、电源规划、标准单元放置、时钟树综合、布线、可制造性修复这一整套步骤最终生成能送去物理验证和流片的版图数据GDSII或DEF。用个不太严谨但很好懂的类比逻辑综合像是建筑设计院把需求画成施工图PR则更像施工现场的按图施工和现场协调。设计院给了房间功能划分和承重结构netlistSDC你要决定墙砌在哪、水电管线怎么走、家具怎么摆——这就是floorplan、placement、CTS和routing要解决的问题。工具输出的是最终能施工验收的“实体工程”对应到芯片上就是GDSII。1.2 为什么值得学它真的不是ICC一代的“升级版”很多刚接触的人会很自然地把ICC II理解为ICC一代的大版本更新这个认知需要纠正。虽然Synopsys把两款工具都命名为“IC Compiler”但ICC II是基于全新架构重写的工具内核、数据模型、命令体系都和一代有本质区别。它更像是换了发动机和底盘的换代车型只是沿用了品牌名。具体来说ICC II的几个核心亮点是多线程并发优化ICC II在设计时就把并行计算作为基本能力布局、布线、优化过程可以充分利用多核CPU在很多大模块上跑起来比ICC一代快很多。不过前提是机器内存要足够否则并发反而会受限。统一数据模型NDMICC II不再像老工具一样靠Milkyway LDB两套数据库来回切换而是使用统一的NDM数据模型把时序库、物理库、抽取数据整合在一起。这个改动对流程稳定性和数据一致性帮助很大。先进工艺节点的主力选择在7nm及以下节点ICC II是目前主流设计公司普遍使用的place route工具之一。很多新工艺的DFM规则、多重曝光multi-patterning约束、复杂电源网络在ICC II里都有对应的处理方式。层次化物理实现对大规模芯片ICC II支持block-level和chip-level流程之间的数据抽象、抽象化abstract和复用这在大芯片设计里几乎是刚需。我把ICC一代、ICC II和另外一家主流工具Innovus放在一起做了一个粗略对比帮助大家建立坐标系对比维度ICC一代ICC IIInnovus架构代际老架构单线程为主全新架构并发优化学新架构并发支持较好数据模型MW LDB混合统一NDMOpenAccess 自有数据库先进工艺支持28nm以下吃力完整支持完整支持主要生态PrimeTime/StarRC/ICVPrimeTime/StarRC/ICVTempus/Quantus/PVS学习曲线相对平缓陡峭命令体系全新陡峭类似这里要特别说明工具没有绝对的好坏选哪款更多取决于公司已有流程、工艺库支持、团队熟悉度。但如果你所在的公司或者目标公司用的是Synopsys流程那么ICC II基本是绕不开的核心工具。所以这篇文章的流程拆解和脚本主要基于ICC II展开。2. 全流程总览从netlist到GDSII到底经历什么2.1 全流程九大阶段ICC II的完整PR流程我习惯划分为九个阶段数据准备与库配置准备好netlist、SDC、物理库、tech file、TLU等文件创建Milkyway/NDM library读入设计。布局规划Floorplan确定芯片尺寸、IO位置、宏单元macro摆放、标准单元区域划分。电源规划Power Planning创建power ring、power stripe完善core区域的电源网络为后续标准单元PG接入做准备。标准单元放置Placement把门级网表中的标准单元放到core区域合适的位置同时做时序和congestion优化。时钟树综合CTS为所有触发器构建时钟网络插入buffer/inverter目标是满足skew、latency、transition等要求。布线Routing先做global routing规划资源再做detail routing实际走线最后修DRC。可制造性与填充DFM Metal Fill根据代工厂规则插入dummy metal、修复天线效应、处理DFM规则。签核数据写出Signoff Data Out输出GDSII、DEF、SPEF、网表等文件交接给后续工具。一致性检查与交付汇总整理报告确认时序收敛、物理验证干净做最终交付。流程上看起来清晰实际上每个阶段都可能因为时序、拥塞、DRC等问题返工。做后端的人要有心理准备PR本质上是个多目标迭代优化过程不是一蹴而就的流水线。2.2 输入输出数据全解析搞明白“哪些文件喂给工具、工具吐出什么”是掌握流程的第一个关键点。ICC II的主要输入输出我整理成了下面这张表类型文件作用输入netlist.v逻辑综合产出的门级网表包含单元连接关系输入SDC.sdc时序约束包括时钟定义、IO约束、false path等输入逻辑库.db标准单元、IO、宏单元的时序和功耗模型输入物理库MW/NDM reference lib单元几何信息、pin位置、routing blockage输入tech file.tf工艺文件定义金属层、通孔、设计规则输入TLU / ITF寄生参数模型用于RC计算输入UPF / CPF低功耗设计意图多电压域、power switch等输出GDSII / DEF最终版图数据交给物理验证或下一级集成输出SPEF / SPF寄生参数文件交给PrimeTime做签核STA输出netlist.v布局布线后的网表可能含时钟树单元输出SDF标准延迟格式文件用于动态仿真输出QoR / timing报告各阶段质量和时序报告用于分析和归档很多新手会忽略UPF文件的重要性。低功耗设计在先进工艺下几乎是标配UPF定义了多个电源域、常开单元、level shifter和isolation cell的需求ICC II需要这些信息才能正确处理电源切换逻辑。如果项目不是single power domain建议一上来就把UPF流程纳入主流程不要后续单独补。2.3 一个形象化的流程类比用装修房子类比PR流程理解起来非常直观netlist SDC 设计师出的施工图告诉你每个房间是什么功能、门开在哪、哪里需要承重。Floorplan 现场测量后确定墙体位置哪里做卧室、哪里做客厅、哪里放卫生间。Power Planning 水电改造先布好强电弱电管线后面所有用电设备才能接入。Placement 家具摆放目的是让常用动线最短、空间利用率最高同时不能挡住门窗。CTS 给所有插座和灯位拉好供电线保证每个点位都能稳定可靠地拿到时钟信号。Routing 把所有设备之间的连线都接好水管、电线、网线走向清晰且不打架。DRC/LVS 装修验收检查有没有漏电风险、管道有没有接错、承重结构有没有被动过。这个类比能帮你快速理解每个阶段的目标和产物也能解释为什么时序问题会贯穿整个流程就像装修中改一个插座位置可能影响整面墙的线路走向。PR也一样floorplan阶段的macro摆放会直接影响后面CTS和routing的质量。3. 核心环节拆解每一步都在做什么3.1 库准备与设计读入ICC II里创建库和读入设计的核心命令逻辑如下create_mw_lib design_lib \ -technology $TECH_FILE \ -mw_reference_library $MW_REFS \ -bus_naming_style {[%s]} \ -hierarchy_separator / open_mw_lib design_lib read_verilog $NETLIST current_design top link_design read_sdc -echo -verbose $SDC read_parasitics -format spef $SPEF ;# 可选如果已有寄生参数 read_upf $UPF几个容易踩坑的点reference library的版本要和准备用于signoff的标准单元库版本一致不然后面PR的时序报告和PT对不上。hierarchy separator和bus naming style必须和综合时保持一致否则点名pin或net时会找不到对象。link_design必须无error如果报了unresolved reference先查target_library和link_library的路径设置。读入SDC后建议第一时间跑一次report_constraints确认约束都被正确解析时钟有没有丢失。库阶段做得越规范后面查问题时越省力。我在项目中会把所有库文件、变量设置固定成一个setup.tcl每个分步脚本都source这个公共配置避免各家脚本写法不一致带来的低级错误。3.2 布图规划与电源规划Floorplan的核心目标是确定die size和macro位置。die size的估算通常用这个思路先汇总所有标准单元的面积总和可以通过DC或ICC II读入门级netlist后用工具报告拿到std cell area。根据预估的congestion和routing resource确定core utilization一般是0.5到0.75之间。逻辑简单、布线资源充裕时利用率可以高一点逻辑复杂、metal layer较少时利用率要保守。估算公式core area ≈ (std cell area macro area) / utilization。这个结果还要再加上power stripe占用的channel面积、blockage、halo等余量。Macro摆放是整个floorplan最影响全局的一步。我一般先看数据流方向memory靠近数据通路模块之间尽量走短连线同时留好macro周围的halo和routing channel。特别要避免memory把标准单元区域切得太碎否则会出现局部congestion热点。电源规划方面先进工艺下IR drop要求通常很严格比如动态压降目标在3% VDD以内power ring和power stripe的宽度、间距、层数需要根据电流密度和EM rule核算。ICC II里有create_power_straps命令可以做stripe规划也可以在GUI里直观编辑power mesh。比较实用的做法是先用一个粗略的stripe方案跑一遍placement再用RedHawk或Voltus做静态IR分析根据结果再迭代调整stripe pitch和width。3.3 标准单元放置与优化Placement阶段ICC II的主命令是place_opt它会同时做布局和时序优化place_opt -congestion -effort high-congestion开关会在布局时考虑布线拥塞提前把单元分散开。要注意place_opt是逻辑和物理同时优化的过程中间会做buf/inv插入、单元面积优化、pre-CTS setup修复。所以place_opt之后一定要看report_qor和report_congestion不要只盯着timing。一个常见的误区是为了timing把utilization压得很低结果密度太低导致绕线距离变长反而时序更差。利用率和congestion、时序三者之间是三角制约关系没有绝对最优解只能在迭代中找平衡。经验上如果congestion map显示某个局部热点超过105%就要考虑调macro位置、加blockage或降低整体利用率而不是一味加约束去硬压。3.4 时钟树综合CTS阶段在ICC II里通常用clock_opt命令它会根据时钟约束自动插入buffer/inverter构建时钟树。CTS的核心指标是skew和latency其中setup要求时钟到达时间尽量一致skew小hold则可以通过useful skew策略来帮助收敛。我在实际项目中CTS阶段的关注顺序是先确认clock tree的specificationclock root、max fanout、max transition、target skew是否合理。transition目标太激进会插入大量buffer功耗和面积飙升。查看report_clock_timing的skew。如果skew过大优先检查时钟路径上有没有和data path的交错干扰以及时钟是否穿了太多层cell。处理hold violation。CTS之后出现hold问题很常见特别在clock skew较大时。ICC II支持set_clock_tree_options -useful_skew允许工具通过调整不同sink的延迟来改善hold这是比较高效的做法。很多人对CTS有个误解觉得CTS只是“把时钟树插出来”实际上CTS对时序收敛、功耗、噪声的影响非常大是PR流程中技术含量很高的阶段。尤其是低功耗设计里CTS还会和UPF里的power domain交互需要确认level shifter、isolation cell是否对clock path造成额外延迟。3.5 布线布线分为全局布线和详细布线两步。ICC II里通常这么做route_auto route_opt -effort highroute_auto做全局路径规划把每个net的资源请求分配到各金属层和通道同时输出congestion预估。route_opt则执行详细布线并在布线后做DRC修复和时序优化。这个阶段我最关注这几个点congestion map如果存在congestion超过100%的区域说明布线资源不够需要返回placement或floorplan阶段解决靠route_opt硬修是很痛苦的。DRC修复先进工艺下DRC规则多且复杂route_opt只能修掉大部分剩余的需要通过调整布线策略或手工处理。antenna效应长走线在制造过程中会积累电荷可能损伤栅氧化层。ICC II可以在布线时检查天线规则必要时通过跳层或插入antenna diode修复。DFM规则比如双曝光double patterning的着色问题、线端间距规则这些都需要代工厂的DFM rule deck配合建议在布线时就把rules读进去。布线结束后的report_qor要重点看routing DRC数量、violating nets数量和total negative slack。这个阶段的目标是把violation清零而不是“看起来差不多”。3.6 数据写出与签核交接PR的最终产出不只是GDSII而是成套的数据。ICC II侧主要会执行write_verilog -no_partition_mw -pg -include_pwr_gnd top.v write_parasitics -format spef top.spef write_sdf -version 3.0 top.sdf write_def -version 5.8 top.def write_gds -merge_files {...} -strip_path top top.gds签核交接最容易出问题的点是数据一致性交出去给PrimeTime做STA的netlist和SPEF必须是同一个ICC II session生成的不能拿旧版本网表配新版本寄生参数。另一个常见坑是GDSII里没有包含fill cell或者decap cell导致物理验证时density不满足代工厂要求。建议每个block在data out之前用report_ndm或者对比工具做一次完整性和一致性检查。4. 最小可运行的ICC II脚本骨架4.1 环境变量与库配置实际项目中ICC II流程一般都拆成多个脚本分步运行但最核心的骨架是固定的。下面给一个最小可运行的TCL脚本框架环境变量部分根据你本地的库路径调整# 公共配置部分 set TCH_FILE /path/tech/tsmc7ff_9T.tf set MW_REF_LIB /path/stdcell.ndm set TLUPLUS_MAX_FILE /path/rcmax.tluplus set TLUPLUS_MIN_FILE /path/rcmin.tluplus set LAYER_MAP_FILE /path/star.map set NETLIST_FILE /path/design_netlist.v set SDC_FILE /path/design.sdc set UPF_FILE /path/design.upf set target_library /path/stdcell.db set link_library * $target_library set_min_library $target_library -min_version /path/stdcell_ccs.db # 创建并打开库 create_mw_lib work -technology $TCH_FILE \ -mw_reference_library $MW_REF_LIB \ -bus_naming_style {[%s]} -hierarchy_separator / open_mw_lib work # 读入设计 read_verilog $NETLIST_FILE current_design top link_design read_sdc -echo -verbose $SDC_FILE read_upf $UPF_FILE # 寄生参数设置 set_tlu_plus_files -max_tluplus $TLUPLUS_MAX_FILE \ -min_tluplus $TLUPLUS_MIN_FILE \ -tech2itf_map $LAYER_MAP_FILE这里特别说明一下set_tlu_plus_files这一步TLU文件是后面所有RC计算的依据包括CTS阶段估算时钟树延迟都要用到。如果TLU设置错后面所有时序报告都不可信。刚开始学的时候如果不想被TLU文件版本折磨可以直接用库厂商提供的标准配置并让check_tlu_plus_files通过。4.2 主流程脚本从floorplan到写出下面这段是主流程的核心命令每步我都加了注释说明意图# 1. Floorplan initialize_floorplan -control_type aspect_ratio \ -core_aspect_ratio 1.0 -core_utilization 0.7 \ -core_offset {5 5 5 5} # 手动摆放macro根据数据流方向自行调整 set_fp_macro_options -halo {5 5 5 5} -allow_overlap false create_fp_macro_ordering -type left_to_right -group {macro_a macro_b} # 2. Power Planning常用方案core ring stripe create_power_rings -nets {VDD VSS} -around core \ -layer_list {M5 M6} -width 2 -spacing 0.5 -offset 1 create_power_straps -nets {VDD VSS} -direction vertical \ -layer M6 -width 0.8 -spacing 1.0 -configure step_and_stop \ -step 40 -stop 20 # 3. Placement place_opt -congestion -effort high # 4. CTS clock_opt -no_clock_route # 如果需要手动控制CTS spec可在clock_opt前用set_clock_tree_options调整 # 5. Routing route_auto route_opt -effort high -only_drc # 6. 金属填充dummy metal insert_metal_fill -master cell_fill_metal # 7. 数据写出 save_mw_lib work write_verilog -pg -include_pwr_gnd top_icc2.v write_parasitics -format spef top_icc2.spef write_sdf -version 3.0 top_icc2.sdf write_def -version 5.8 top_icc2.def write_gds -strip_path top top_icc2.gds注意initialize_floorplan里的core_utilization是初始值后面时序和congestion分析后大概率还要迭代调优。core_offset的单位是um代表core区域距离die边缘的距离具体值要和封装、IO规划配合。整个脚本跑完如果没出error恭喜你这套最小流程算是打通了。实际项目中每个步骤之间还会有很多report_*命令和GUI检查但骨架就是上面这些命令。对新手来说先在简单testcase上把这条链路跑通比一次研究透几十个命令更有价值。4.3 常用报告与GUI检查跑完流程后一定要主动看报告不要只看log结尾有没有“completed successfully”。我常用的检查组合是# QoR总览 report_qor -summary report_qor # 时序 report_timing -nworst 5 -max_paths 100 -slack_max 0 report_clock_timing -type skew # 拥塞分析 report_congestion -verbose # 功耗 report_power # 检查DRC report_physical -drv -verboseGUI方面gui_start后可以直观看到floorplan、placement、congestion map、clock tree等。我强烈建议新手在跑完每个阶段后都用GUI把版图打开看一遍对照报告理解“为什么这里congestion高”“为什么这里时序差”。工具的报告是宏观数字GUI能帮你把数字落到图像上记忆会深刻得多。5. 踩坑实录与常见问题排查5.1 启动和环境类问题ICC II启动阶段最常见的报错集中在三个方面license、库文件、内存。License问题通常表现为启动时报feature不可用排查方式很简单先在命令行跑一下license检查工具确认feature是否被checkout如果是license server的问题等一会儿重试或联系管理员。库文件问题常见的是路径写错、reference lib版本不一致报错信息一般会明确指出哪个库找不到按路径修正即可。内存问题在新手机器上很常见ICC II跑大设计非常吃内存如果32G内存以下跑中等规模block建议用set_host_options -max_cores 4限制并发核数否则swap一多反而更慢。5.2 布局规划与放置阶段的高频问题macro摆放导致congestion是我遇到最多的问题。有些设计把memory集中放在一起看起来整齐但memory之间的走线通道被堵死导致周边standard cell区域routing利用率爆炸。解决方式通常是给macro加halo、调整macro间距、或者把部分macro移到core边缘。另一种情况是利用率估算偏差太大placement后congestion超过110%这时候需要回到floorplan重新调整core尺寸或utilization。Placement阶段时序不过负slack多先区分是setup还是hold问题。pre-CTS阶段主要是setup工具可以通过面积换性能去修如果还是修不完要考虑是不是约束问题比如假的multi-cycle path没设。用report_constraints反复check约束是我的习惯动作。5.3 CTS与布线阶段的典型问题CTS阶段最典型的症状是skew不收敛。排查skew问题时我建议先把时钟路径上的delay拆开看是sink数量太多导致fanout过大还是clock path上串了太多高latency的cell还是和data path有交叉干扰。对应手段分别是增大buffer尺寸、限制max fanout、调整CTS spec。布线阶段最让人头大的是“DRC修不完”。遇到这种情况我先看DRC violation集中在什么层、什么类型。如果是同一类violation大量出现大概率是布线策略参数设置不当比如min area规则、线宽线距设置需要调整如果是零星violation可以通过route_opt -only_drc再修一轮如果还不行就得到GUI里看具体位置手动调整附近走线。5.4 常见问题速查表问题现象可能原因排查/解决方向启动报license异常license feature缺失或server问题检查license工具和server状态link_design有unresolvedlink_library路径不全补全.db路径确保版本一致placement后congestion 105%macro摆放不合理加halo、调整macro位置、回收利用率pre-CTS setup大量violation约束或库问题检查SDC、确认时序库选择正确skew不收敛fanout过大或时钟路径过长调CTS spec、限制max fanoutDRC反复修不掉布线参数或rule配置问题检查DRC rule、调整布线策略GDSII缺fill cell忘insert_metal_fill补跑fill确认density达标SPEF与netlist不匹配数据写出顺序/版本不一致同一session重新写出做一致性检查5.5 后续学习路线与系列预告这套笔记会按流程顺序往下走第二篇我计划单独写floorplan和power planning的实操细节包括macro摆放策略、power mesh设计参数计算、IR drop与EM trade-off第三篇写CTS的底层原理和useful skew分析方法第四篇写布线和DRC修复的实操技巧。每篇都会配具体的命令片段和真实项目中的取舍过程。学流程工具最忌讳“看完就忘”我的建议是边看边跑一个小testcase把命令在工具里真正执行一遍才能形成肌肉记忆。6. 一点个人体会学习ICC II这段时间我最大的感受是它确实和ICC一代完全不同但底层物理设计的逻辑是共通的——布局布线本质都是在面积、时序、功耗、可制造性之间做多目标权衡。工具命令可以查help、查doc但为什么要在这一步做这个选择、换了参数会带来什么连锁反应还是得靠对整个流程的理解和实际项目试错。刚开始跑全流程时我的习惯是每个阶段都停下来反复看报告和GUI宁可慢一点也要搞清楚工具每一步都做了什么。长期看这种习惯比追求“把脚本跑通”要值得多。希望这篇overview能帮你在ICC II这条路上少走一些弯路也欢迎有经验的朋友留言说说你们在项目中积累的独家技巧互相补补课总是好的。