企业官网建设流程全解析

简介：这份PDF技术资料面向数字IC设计与综合工程师，聚焦Cadence Genus平台的iSpatial Flow，帮助读者理解如何通过统一物理优化引擎缩小前端综合与后端布局布线之间的鸿沟。内容围绕iSpatial Flow的核心机制展开，涵盖统一物理优化引擎、早期时钟树流程、关键区域重构（CRR）以及直接调用Innovus GigaOpt等关键特性，并对比传统Spatial Flow的局限，结合CPU、AI、DSP等设计案例说明WNS与TNS的提升效果。资源包内共1个PDF文件，约2.14MB，篇幅精炼，适合作为快速上手的参考模板。目前已有242人学习，读者可借此建立对物理综合流程的整体认知，掌握提升PPA预测准确性与缩短设计周期的思路，为实际项目中的综合策略选择提供依据。

1. 从一次时序收敛翻车说起：Genus iSpatial 到底解决了什么

去年帮一个团队看 12nm 的 AI 加速器设计，综合阶段 WNS 收得挺漂亮，-30ps 左右，大家都觉得稳了。结果网表丢进 Innovus 跑完 place，WNS 直接掉到 -290ps，TNS 从 -20ns 炸到 -400ns 量级。整个组被迫回头改 RTL、加约束、重跑综合，来回折腾了三轮，两周就这么没了。这种「综合看着行、布局一跑就崩」的翻车，做数字前端的多少都遇到过。

Genus 的 iSpatial Flow 就是冲着这个鸿沟来的。它把 Innovus 的 GigaPlace、GigaOpt 物理优化引擎直接集成进 Genus 综合阶段，让综合工具在 syn_opt -spatial 时就能调用与后端完全一致的布局和优化引擎。这意味着综合阶段拿到的时序、拥塞、功耗预测，跟 Innovus 布局后的结果高度重合，前端不用再靠猜来评估网表质量。适合正在用 Genus 做综合、又苦于前后端一致性差的数字 IC 设计工程师，尤其是先进工艺节点下对 PPA 有硬要求的项目。

2. iSpatial 流程拆解：统一引擎怎么接、脚本怎么写

2.1 统一物理优化引擎的调用逻辑

传统 Spatial Flow 里，Genus 调用的布局引擎和 Innovus 用的不是同一套。Genus 有自己的 placement 引擎，Innovus 用 GigaPlace，两者对标准单元摆放、线延迟估算、绕线阻塞的判断存在偏差。你在 Genus 里看到的时序报告，到了 Innovus 里就是另一回事。iSpatial 的做法很直接：把 Innovus 的 GigaPlace 和 GigaOpt 引擎嵌入 Genus，在 syn_opt -spatial 阶段就调用同一套物理优化引擎。

具体来说，Genus Mapper 负责逻辑映射，GigaPlace 负责布局，GigaOpt 负责布局后的优化。这三个组件在 iSpatial 流程里是串联工作的，而且跟 Innovus 里用的是同一套代码。所以你在 Genus 里跑完 syn_opt -spatial 拿到的网表，已经经过了物理感知的布局和优化，Innovus 接手后只需要做增量优化（Physical Incr Opt），不需要从头 place。

这个流程还引入了两个关键能力：一是早期时钟树流程（Early Clock Flow, ECF），在综合阶段就把时钟偏移、门控时钟、带偏移的宏单元考虑进去；二是关键区域重构（Critical Region Restructuring, CRR），在布局完成后对关键路径所在的区域进行网表重构，用布局后的精确时序环境来指导重构决策，而不是回到 RTL 层面盲目过约束。

2.2 从 RTL 到网表的脚本骨架

下面是一套 iSpatial 流程的 Genus 脚本骨架，基于常见做法整理，具体路径和库名需要按项目替换。脚本分三段：读入设计、syn_gen -phys 做物理感知的综合准备、syn_opt -spatial 做物理优化。

# ============================================================ # Genus iSpatial Flow 脚本骨架 # 适用场景：先进工艺节点下的物理综合 # ============================================================ # --- 第一段：库与设计读入 --- set_db init_lib_search_path {./libs ./lef} set_db init_hdl_search_path {./rtl} # 读入时序库和物理库（LEF） read_libs {slow.lib fast.lib} read_physical -lef {tech.lef stdcell.lef macro.lef} # 读入 RTL read_hdl -sv {top.sv sub_a.sv sub_b.sv} # elaborated 设计 elaborate top set_db hdl_error_on_blackbox false # --- 第二段：约束与综合准备 --- read_sdc ./constraints/top.sdc # 设置综合模式为物理感知 set_db syn_generic_effort high set_db syn_map_effort high set_db syn_opt_effort high # 指定物理综合流程 set_db flow_physical true # 运行 syn_gen -phys：生成物理感知的通用逻辑 syn_gen -phys # --- 第三段：物理优化 --- # syn_map -phys：映射到工艺库并做物理感知的映射 syn_map -phys # syn_opt -spatial：调用 GigaPlace/GigaOpt 做布局与优化 syn_opt -spatial # 输出网表与 DEF write_hdl > ./outputs/top_netlist.v write_sdc > ./outputs/top.sdc write_def > ./outputs/top.def

这段脚本的关键点在于syn_gen -phys、syn_map -phys、syn_opt -spatial三个命令的配合。-phys标志告诉 Genus 在综合过程中读入物理信息（LEF），-spatial则触发 GigaPlace/GigaOpt 引擎的调用。如果你跳过syn_gen -phys直接跑syn_opt -spatial，工具会因为缺少物理信息而报错或退化成普通综合。

2.3 关键参数怎么调

iSpatial 流程里几个参数直接影响 QOR 和运行时间，需要根据设计阶段调整。

spatial_opt_effort是 iSpatial 特有的参数，控制 GigaOpt 引擎在布局后的优化强度。设成 high 时，工具会对关键路径做更激进的 buffer 插入和尺寸调整，WNS 改善明显，但运行时间会增加 15%～25%。如果设计处于早期探索阶段，可以先设 medium 快速拿到反馈，签核前再切 high。

2.4 与 Innovus 的交接方式

iSpatial 跑完后，输出网表、SDC 和 DEF 给 Innovus。Innovus 端不需要重新跑完整的 place 流程，而是用-physical模式读入 DEF，直接做增量优化。

# Innovus 端：读入 iSpatial 输出 read_netlist ./outputs/top_netlist.v read_sdc ./outputs/top.sdc read_def ./outputs/top.def # 指定增量物理优化模式 set_db place_global_ignore_scan true set_db opt_effort high # 直接进入增量优化，跳过全局布局 place_opt_design -incremental # 后续 CTS 和 route ccopt_design route_design

这里place_opt_design -incremental是关键。因为 iSpatial 已经完成了布局和初步优化，Innovus 只需要在已有布局基础上做增量调整。如果误用了完整的place_opt_design，工具会重新做全局布局，把 iSpatial 的优化成果覆盖掉，前后端一致性就白费了。

3. 避坑与排查：iSpatial 落地时最容易翻车的五个点

3.1 现象：syn_opt -spatial 报错「physical library not found」

原因：LEF 文件没有正确读入，或者init_lib_search_path里没有包含 LEF 所在目录。iSpatial 依赖 LEF 获取标准单元的物理尺寸和引脚位置，缺少 LEF 时 GigaPlace 无法工作。

解决：检查read_physical -lef的路径是否正确，确认 LEF 文件版本与工艺库匹配。如果 LEF 和 Liberty 的单元名不一致，也会报类似错误，需要用set_db lef_lib_cell_name_map做映射。

3.2 现象：iSpatial 综合后 WNS 很好，但 Innovus 增量优化后反而变差

原因：Innovus 端误用了完整的 place 流程，或者 SDC 约束在交接时发生了变化。常见情况是 Genus 输出的 SDC 里包含了set_clock_uncertainty等约束，Innovus 读入后又叠加了自己的约束，导致过约束。

解决：确认 Innovus 端使用place_opt_design -incremental，并且 SDC 只读入一次。可以在 Innovus 里用report_timing对比 iSpatial 阶段的时序报告，定位偏差来源。

3.3 现象：CRR 重构后网表功能仿真失败

原因：CRR 在布局后对关键区域做网表重构，涉及逻辑等价变换。如果 RTL 里存在dont_touch或dont_use属性没有正确传递，重构可能改动了不该改的逻辑。

解决：在综合脚本里显式设置set_db optimize_constant_0_flops false和set_db optimize_constant_1_flops false，避免工具在重构时优化掉常量逻辑。对关键模块加set_dont_touch保护。

3.4 现象：DFT 扫描链插入后 iSpatial 流程拥塞严重

原因：DFT 逻辑在 RTL 阶段插入后，扫描链的布线需求与功能逻辑竞争布线资源。iSpatial 虽然支持 DFT 感知的物理优化，但如果扫描链没有做物理感知的重排序，拥塞不可避免。

解决：在 iSpatial 流程中启用 Innovus Scan Reorder，让工具在综合阶段就对扫描链做物理感知的排序。脚本里加set_db dft_scan_reorder true，并在 syn_opt -spatial 之前完成扫描链插入。

3.5 现象：iSpatial 运行时间比预期长很多

原因：spatial_opt_effort设成了 high，同时syn_opt_effort也是 high，两个 high 叠加导致优化迭代次数暴增。另外，如果设计里有大量宏单元（SRAM、IP 核），GigaPlace 对宏单元的摆放优化会消耗大量时间。

解决：分阶段设置 effort。探索阶段用syn_opt_effort medium+spatial_opt_effort medium，签核阶段再切 high。对宏单元多的设计，可以先用set_db place_global_ignore_macros true跳过宏单元摆放，等功能逻辑收敛后再打开。

4. 进阶技巧：用 iSpatial 做早期 PPA 探索与签核预判

iSpatial 最大的价值不只是「跑通流程」，而是让你在综合阶段就能拿到接近签核质量的 PPA 数据。我一般会用它做两件事：早期 PPA 探索和签核预判。

早期 PPA 探索的做法是：在 RTL 还没完全稳定时，先用 iSpatial 跑一版综合，拿到 WNS、TNS、面积、功耗的基线数据。然后针对瓶颈模块做 RTL 结构调整，再跑一版 iSpatial，对比两版的 PPA 变化。因为 iSpatial 的预测与 Innovus 布局后结果高度一致，你可以用这个数据来判断 RTL 改动是否值得。具体操作上，我会在脚本里加一段自动对比逻辑：

# 跑完 syn_opt -spatial 后，导出关键指标 set wns [get_db timing_report worst_negative_slack] set tns [get_db timing_report total_negative_slack] set area [get_db design_area] set power [get_db power_total] puts "=== iSpatial PPA Summary ===" puts "WNS: $wns ps" puts "TNS: $tns ns" puts "Area: $area um2" puts "Power: $power mW" # 与上一版对比（假设上一版结果存在变量里） if {[info exists prev_wns]} { set wns_delta [expr {$wns - $prev_wns}] puts "WNS delta: $wns_delta ps" }

这段脚本把关键指标打出来，方便做版本间对比。get_db timing_report是 Genus 里获取时序报告的接口，worst_negative_slack和total_negative_slack分别对应 WNS 和 TNS。面积和功耗的获取方式类似，具体属性名可以查 Genus 的 db 属性文档。

签核预判的做法是：在 iSpatial 跑完后，把网表和 DEF 直接丢给 Innovus 做增量优化和 CTS，然后对比 iSpatial 阶段的时序报告和 Innovus post-CTS 的报告。如果两者偏差在 10% 以内，说明 iSpatial 的预测可信，你可以放心用 iSpatial 的结果做网表评估。如果偏差超过 20%，需要检查 SDC 约束是否一致、LEF 版本是否匹配、或者设计里是否有 iSpatial 不支持的逻辑结构。

还有一个实用技巧：用 iSpatial 做多版本 RTL 的快速筛选。比如你有三个 RTL 版本，分别对应不同的流水线深度或并行度，传统做法是每个版本都跑完整的综合+布局布线，耗时巨大。用 iSpatial 的话，每个版本跑一遍 syn_opt -spatial，拿到 PPA 数据做横向对比，选出最优版本再进 Innovus 做完整流程。这样能把早期探索的时间压缩到原来的三分之一左右。

从那以后我每次接手新设计，都会在 RTL 冻结前先用 iSpatial 跑一轮 PPA 探索，把瓶颈摸清楚再动手改代码，而不是等后端反馈回来才发现方向错了。希望帮到你。

本文还有配套的精品资源，点击获取