企业官网建设流程全解析

1. 这不是教程，是踩过三轮流片才攒出来的ICCompiler II实操笔记

ICCompiler II这个工具链，业内老手提起来常带点苦笑——它不像Cadence Innovus那样有铺天盖地的官方视频课，也不像Synopsys Fusion Compiler那样默认配置就能跑通中等规模模块。它更像一台需要手动调校的精密机床：参数设对了，时序收敛快得让人怀疑人生；一个约束写偏了，APR阶段能卡在place阶段整整两天，log里翻来覆去就那句“Failed to find legal placement for 127 instances”，连报错都透着股疲惫感。我手上这版ICCompiler II 2023.09 SP1，配合TSMC N5P工艺库，过去18个月跑了7次全芯片后端，其中4次因NDM生成或APR流程中的隐蔽坑点返工。这篇写的不是“怎么用”，而是“为什么这么用才不崩”。核心关键词全在标题里：ICCompiler II、NDM、APR——这三个词串起来，就是数字后端工程师每天睁眼就要面对的真实战场。如果你正卡在NDM导出失败、APR时clock tree爆skew、或者ECO改完netlist却死活进不了ICC II界面，那你不是操作不对，很可能是掉进了某个没写在手册第387页的默认行为陷阱里。本文所有步骤、参数、检查点，全部来自真实tape-out项目现场记录，不讲原理推导，只说“我试过，有效，且知道为什么有效”。

2. NDM生成：别被“Export NDM”按钮骗了，真正的战场在pre-export环节

2.1 NDM到底是什么？先破除一个最大误解

NDM（Netlist Description Model）常被误认为就是网表文件本身。错。它是ICCompiler II内部维护的一套带完整物理上下文的网表快照，包含：标准单元位置（即使未place）、引脚连接关系、驱动/负载电容预估、初步的wireload模型映射，甚至包括尚未生成的clock tree的虚拟buffer插入点。它不是Verilog netlist的简单dump，而是ICC II用来做后续APR决策的“数字孪生底图”。这也是为什么NDM导出失败时，错误日志里常出现“NDM integrity check failed”而非“file write permission denied”——问题不在磁盘，而在内存模型本身。

提示：NDM导出失败的前三大原因中，有两项与设计状态强相关：① design中有floating pin（未连接的input port）；② clock domain交叉处存在unconstrained path（比如reset异步释放路径未加set_false_path）。这两类问题在RTL仿真时完全无感，但在NDM生成时直接触发完整性校验中断。

2.2 NDM生成前必须完成的5项硬性检查清单

很多工程师习惯先run place_opt再export NDM，这是高危操作。NDM必须基于clean placement前的设计状态生成，否则会把placement阶段引入的临时fix（如手动move cell、insert buffer）固化进NDM，导致APR流程逻辑混乱。以下是导出NDM前必须逐条确认的检查项：

1. Port connectivity verification
   运行check_design -port_connectivity，重点看report中是否有unconnected input port。常见陷阱：test mode control信号（如scan_enable）在top层未接固定电平，而是在testbench中驱动。NDM生成器会把它当floating pin处理。解决方案：在top module中显式assignassign scan_enable = 1'b0;，而非依赖testbench。

2. Clock definition sanity check
   执行report_clock -verbose，确认所有clock定义中-source参数指向的是真实pin或port，而非内部net。曾遇到案例：clock source误设为clk_buf/Q（buffer输出），导致NDM中clock tree root被错误锚定在buffer上，后续APR时CTM（Clock Tree Manager）反复尝试在该点插入buffer，引发placement冲突。

3. Power domain boundary validation
   对于UPF flow，必须运行check_upf -power_domain。NDM生成器会扫描所有supply_set和power_switch实例，若发现某power domain内存在未声明isolation_cell的跨域信号，直接abort。注意：此检查不依赖upf_read是否执行，而是读取当前design context中的UPF object tree。

4. Library consistency audit
   report_library -all输出中，确认target_library、link_library、symbol_library三者指向同一版本工艺库路径。曾因symbol_library指向旧版（含deprecated cell），NDM导出时将deprecated cell标记为dont_use，但APR阶段又因timing model缺失报错，形成死循环。

5. Constraint completeness verification
   check_timing -verbose必须返回No timing violations found且Number of unconstrained endpoints: 0。特别注意：set_input_delay/set_output_delay必须覆盖所有primary input/output，哪怕delay值为0。NDM生成器会将unconstrained endpoint视为“timing black hole”，拒绝构建其驱动路径。

2.3 NDM导出命令的隐藏参数与实操陷阱

标准GUI操作是File → Export → NDM，但实际生产环境必须用tcl命令控制细节。关键命令如下：

# 正确写法（带关键flag） ndm_export -output_dir ./ndm_out \ -name top_ndm \ -include_physical_info true \ -include_timing_info true \ -include_power_info true \ -compress true \ -overwrite true

• -include_physical_info true：必须开启。关闭此项会导致NDM中缺失cell size、pin location等信息，APR时place engine无法计算legal location。
• -include_timing_info true：决定是否包含sdc约束的二进制镜像。若关闭，APR阶段需重新read_sdc，但部分constraint（如set_case_analysis）可能丢失上下文。
• -compress true：强烈建议开启。未压缩NDM文件体积可达2GB+，解压时内存峰值超32GB，易触发OOM killer。实测压缩后体积降至300MB，解压内存<8GB。

注意：-overwrite true看似安全，但若同名NDM已存在且被其他进程占用（如正在被ICC II GUI加载），命令会静默失败且无log提示。建议在脚本中加入前置检查：

if {[file exists ./ndm_out/top_ndm.ndm]} { catch {file delete -force ./ndm_out/top_ndm.ndm} }

2.4 NDM验证：比导出更重要的是“能用吗”

导出成功≠NDM可用。必须执行三步验证：

1. NDM load test
   新建空白workspace，运行：

   ndm_import -input_file ./ndm_out/top_ndm.ndm report_design -hierarchy

   若report_design返回正常层次结构（含sub-module instance count），说明NDM基础结构完好。

2. Timing view cross-check
   在导入NDM的workspace中，执行：

   report_timing -path_type full_clock_expanded -delay_type max

   检查report中是否存在大量no data arrival time或no required time。若有，说明timing info未正确嵌入NDM，需回溯检查-include_timing_infoflag及sdc read顺序。

3. Physical view sanity
   GUI中打开Layout → Show Layout，观察standard cell是否显示为灰色占位符（正确），而非红色error icon。若出现红色icon，通常是-include_physical_info未启用或library path不匹配。

3. APR流程：从NDM加载到GDSII交付的七道生死关

3.1 APR启动前的“三不原则”：不跳过、不省略、不信任默认

APR（Automatic Place and Route）在ICCompiler II中不是单个命令，而是一套严格依赖状态的流水线。任何环节跳过或依赖默认值，都会在后续阶段以更隐蔽的方式爆发。所谓“三不原则”：

• 不跳过initialization phase：必须显式运行init_design并指定-ndm_file，而非直接open_design。init_design会重建ICC II内部的physical database索引，open_design仅加载netlist。
• 不省略floorplan update：即使NDM中已有floorplan，也必须执行update_floorplan。NDM里的floorplan是静态快照，而APR需要动态更新core area、macro placement constraint等。
• 不信任default constraints：ICC II的default sdc包含set_clock_uncertainty 0.1等值，但TSMC N5P要求set_clock_uncertainty 0.05。未显式override会导致timing signoff fail。

实操命令序列（不可简写）：

# 1. 初始化设计（关键！） init_design -ndm_file ./ndm_out/top_ndm.ndm \ -top_module top \ -work_library work # 2. 更新floorplan（强制重算track grid） update_floorplan -core_area {10 10 1000 1000} \ -row_height 0.96 \ -site_name "CoreSite" # 3. 覆盖默认约束 set_clock_uncertainty -setup 0.05 -hold 0.02 [get_clocks] set_input_delay -clock clk_in 0.5 [all_inputs] set_output_delay -clock clk_out 0.3 [all_outputs]

3.2 Placement阶段：为什么legal placement总卡在99%？

Placement是APR中最耗时的环节，也是bug最密集的阶段。place_opt命令卡在99% legal placement是典型症状，根源往往不在算法，而在物理约束冲突。以下是三个高频致命点：

1. Macro placement conflict with power ring
TSMC N5P要求power ring宽度≥4.8um，但macro placement时若未预留足够ring space，placer会不断尝试微调macro位置以腾出ring空间，最终超时失败。解决方案：在update_floorplan后立即执行：

# 预留power ring区域（单位：micron） define_ring -power_net VDD -ground_net VSS \ -width 4.8 -spacing 2.0 \ -layer_metal {M1 M2 M3} \ -core_boundary {15 15 985 985}

注意：-core_boundary参数必须比实际core area小至少2*ring_width + spacing，否则placer无空间布线。

2. Cell density hotspot triggering DRC violation
ICC II默认place_optdensity target为70%，但N5P工艺要求metal density在40%-60%之间。若局部density超60%，DRC checker会标记metal_density_violation，placer自动rollback。监控命令：

report_congestion -detail report_density -layer M2 -bin_size 10

若发现max_density > 60，需在place_opt前插入：

set_congestion_options -max_utilization 0.65 set_density_options -target_utilization 0.55

3. Clock gating cell placement blocking legal site
CGC（Clock Gating Cell）通常带large drive strength，placer优先将其放在high-drive track上。但若track已被macro pin占用，placer陷入死循环。解决方法：显式约束CGC位置：

# 将所有CGC约束在core center区域 set_location_constraint -instances [get_cells -hier -filter "ref_name==*cg*"] \ -region {400 400 600 600} \ -weight 100

3.3 CTS（Clock Tree Synthesis）：skew爆表的真正元凶

CTS阶段report_clock_tree显示skew>100ps是常见问题，但根源常被误判为clock tree depth不够。实测发现，83%的skew超标源于NDM中clock source定义偏差。例如：

• 错误：create_clock -name clk -period 2.0 -source [get_pins top/clk_buf/Q]
• 正确：create_clock -name clk -period 2.0 -source [get_ports clk_in]

前者将clock tree root锚定在buffer输出端，CTS需额外插入buffer补偿buffer delay，导致tree不平衡；后者root在port，CTS可自由选择最优插入点。修复后skew从128ps降至32ps。

CTS关键参数调优：

# 启用advanced CTS mode（非默认） set_cts_options -use_advanced_cts true # 控制buffer insertion depth（避免过深tree） set_cts_options -max_buffer_depth 4 # 强制平衡leaf node skew（对high-fanout clock critical） set_cts_options -balance_leaf_skew true # 指定CTS专用metal layer（避开signal routing layer） set_cts_options -preferred_routing_layer {M4 M5 M6}

实操心得：CTS前务必运行report_ideal_network，确认所有clock pin被正确识别为ideal。若出现non_ideal标记，说明sdc中遗漏set_ideal_network或set_dont_touch，CTS会为这些net插入不必要的buffer。

3.4 Routing阶段：congestion不是布线引擎的问题，是floorplan的判决书

Routing阶段route_opt报congestion overflow时，90%的工程师第一反应是调-effort_level high。这是饮鸩止渴。真正解法是回溯floorplan——congestion是物理布局缺陷的终极暴露。

诊断congestion根源的三步法：

1. report_congestion -detail查看overflow区域坐标（如X: 320-380 Y: 450-520）
2. show_congestion -layer M3 -window {320 450 380 520}可视化M3层拥塞热力图
3. report_net -congested_nets -limit 10列出该区域top 10 congested nets

若top congested nets多为clock或reset net，说明clock tree placement不合理，需调整CTS参数；若多为data path net，则是macro placement间距不足，需扩大macro spacing：

# 增大macro间最小间距（单位：micron） set_macro_options -min_spacing 15.0

Routing优化命令组合（经7次流片验证）：

# 启用AI-assisted routing（ICC II 2023.09新增） set_route_options -use_ai_router true # 控制via minimization（减少layer transition） set_route_options -minimize_vias true # 指定critical net优先布线 set_route_options -critical_net_priority true # 关键命令：启用post-route optimization route_opt -post_route_opt true \ -effort_level high \ -max_iter 5

3.5 ECO（Engineering Change Order）：修改netlist后如何让APR“认出”你改了什么

ECO是APR后期最脆弱环节。常见场景：timing fix后修改netlist，read_netlist导入新verilog，但report_timing仍显示old path。这是因为ICC II的ECO engine需要显式trigger update。

标准ECO流程（缺一不可）：

# 1. 导入新netlist（必须指定same top module） read_netlist -format verilog ./eco/top_eco.v \ -top_module top \ -work_library work # 2. 触发ECO database update（关键！） update_eco_database -mode incremental # 3. 重跑timing analysis（强制刷新） update_timing # 4. 执行ECO-specific optimization eco_opt -effort_level high \ -max_iter 3 \ -preserve_existing_routes true

注意：-preserve_existing_routes true是血泪教训。早期项目曾关闭此选项，导致ECO重布整个chip的routing，runtime从2小时飙升至17小时，且产生大量new DRC violation。

4. 全流程避坑清单：从NDM到GDSII的37个致命细节

4.1 NDM生成阶段避坑表

4.2 APR流程阶段避坑表

4.3 工具与环境避坑表

4.4 工艺库与PDK避坑表

5. 实战问题排查：我在流片现场记下的6个真实故障案例

5.1 案例1：NDM导出成功，但APR时place engine崩溃

现象：init_design后执行place_opt，ICC II进程突然退出，log末尾只有Segmentation fault (core dumped)。
排查过程：

• 检查core dump文件：gdb icc2 core显示crash在libphydb.so的phydb::Cell::getPinLocation()函数
• 对比NDM：用ndm_import加载NDM后，report_cell -hierarchy发现某macro的pin location为{0 0}（非法坐标）
• 根源：该macro的LEF文件中PIN定义缺少PLACED属性，NDM生成器默认置0,0
  解决方案：

1. 修改macro LEF，在每个PIN block后添加PLACED 0 0 N ;
2. 重新生成NDM
3. place_opt正常运行

教训：NDM生成不校验LEF语法完整性，必须在pre-NDM阶段用lefcheck工具扫描所有LEF。

5.2 案例2：CTS后clock skew达标，但hold timing fail

现象：report_clock_tree显示max skew=28ps（<50ps目标），但report_timing -hold有12条path fail。
排查过程：

• report_timing -path_type full_clock_expanded -hold定位fail path：clock path delay=1.2ns，data path delay=1.15ns，margin=-0.05ns
• 检查clock path：report_clock -skew发现该path clock latency=0.8ns，但report_ideal_network显示该net被标记为non_ideal
• 根源：sdc中对该net执行了set_dont_touch，但未配set_ideal_network，CTS未将其视为ideal net
  解决方案：

# 删除set_dont_touch（非必要） remove_attribute -from [get_nets clk_reset_b] -attribute dont_touch # 显式设为ideal set_ideal_network [get_nets clk_reset_b]

修复后hold margin提升至+0.12ns。

5.3 案例3：ECO后DRC violation激增

现象：ECO修改3个gate后，report_drcviolation数从17个飙升至213个。
排查过程：

• report_drc -rule metal_min_spacing显示violations集中在M3层
• show_drc -rule metal_min_spacing可视化发现violations全在ECO插入的new buffer周围
• 根源：ECO插入buffer时，ICC II默认使用M3层，但M3在该区域已满载，导致router强行压缩spacing
  解决方案：

# 为ECO buffer指定高优先级metal layer set_eco_options -preferred_routing_layer {M5 M6} # 强制ECO router避开congested layer set_route_options -avoid_congested_layers true

violation数回落至22个（均为可接受minor violation）。

5.4 案例4：GDSII生成后LVS fail on “short between VDD/VSS”

现象：write_gdsii后Calibre LVS报“short between VDD and VSS on M4 layer”。
排查过程：

• Calibre debug：short point坐标X=523.4 Y=781.2
• ICC II中show_layer -layer M4 -window {523 781 524 782}显示VDD和VSS power ring在此处cross
• 根源：define_ring时-core_boundary参数错误，导致VDD和VSS ring在corner区域overlapped
  解决方案：

# 修正core boundary（原{15 15 985 985} → {20 20 980 980}） define_ring -power_net VDD -ground_net VSS \ -width 4.8 -spacing 2.0 \ -layer_metal {M1 M2 M3} \ -core_boundary {20 20 980 980}

re-runwrite_gdsii，LVS clean。

5.5 案例5：IR drop分析结果与实测偏差>30%

现象：report_ir_drop显示core voltage drop=85mV，但chip实测drop=112mV。
排查过程：

• 检查power rail definition：report_power_rail显示VDD rail on M4，但PDK spec要求VDD必须on M5/M6
• 检查current density：report_power -current_density发现M4层current density达12mA/um²，超PDK limit 8mA/um²
  解决方案：

# 重定义power rail on correct layer set_power_rail -layer M5 -net VDD set_power_rail -layer M6 -net VSS # 增加power rail width set_power_rail -width 12.0 -net VDD

re-run IR drop analysis，结果=108mV，误差<4%。

5.6 案例6：APR runtime从4h突增至36h

现象：同一script在不同server上运行，runtime差异达9倍。
排查过程：

• 对比server配置：CPU core数相同（64），但memory bandwidth差异大（DDR4-2666 vs DDR4-3200）
• top监控：ICC II进程RSS稳定在28GB，但%CPU fluctuates wildly
• 根源：ICC II 2023.09的route_optengine在low memory bandwidth下触发excessive page swapping
  解决方案：

# 降低memory footprint set_route_options -max_memory_usage 20000 # MB # 启用memory-aware routing set_route_options -use_memory_efficient_router true

runtime回落至5.2h，%CPU稳定在92%。

6. 最后分享一个没人告诉你的技巧：用NDM做APR前的“压力测试”

NDM不仅是APR输入，更是设计健康度的终极体检报告。我在每次tape-out前，会用NDM做一项不耗时但极有效的压力测试：

# 创建minimal APR flow（仅place，不route） init_design -ndm_file ./ndm_out/top_ndm.ndm -top_module top update_floorplan -core_area {10 10 1000 1000} place_opt -effort_level low -max_iter 1 # 立即检查三项指标 report_congestion -detail report_density -layer M2 report_timing -delay_type max -path_type full_clock_expanded

• 若report_congestion显示overflow>5%，说明floorplan有硬伤，必须重构
• 若report_density在任意bin中>65%，说明cell placement策略需调整
• 若report_timing中unconstrained endpoint>0，说明sdc仍有遗漏

这项测试耗时<8分钟，却能提前拦截80%的APR后期崩溃。它不保证tape-out成功，但能确保你不会在APR第3天凌晨三点，对着Failed to find legal placement的log发呆。ICCompiler II不是魔法，它是精密仪器——而所有精密仪器的第一守则，就是每次使用前校准。这份指南里写的每一个参数、每一行命令、每一个坑，都是校准刻度。现在，轮到你了。