1.2 一颗芯片的诞生全流程
文档摘要
1.2 一颗芯片的诞生全流程：从 RTL 到 GDSII 的工序地图 本节摘要：沿着"想法如何变成可制造的几何图形"这条线，拆解芯片设计的完整工序——前端把需求固化为 RTL，后端把网表固化为 GDSII，中间每一道工序都有明确的输入、输出与负责算法。本节给出全书的流程地图，后续章节就是在这张地图上逐格放大的。 先看终点：GDSII 里到底有什么 理解一条流水线，最有效的办法是从终点倒推。芯片设计的终点交付物是一份 GDSII 文件——一种分层描述几何图形的二进制格式，里面是数以十亿计的多边形：金属线的矩形、过孔的方块、晶体管有源区的轮廓。晶圆厂拿到的就是它，光刻机照着它把图形一层层转印到硅片上。换句话说，设计芯片的最终形态是几何，而不是代码。
1.2 一颗芯片的诞生全流程：从 RTL 到 GDSII 的工序地图
本节摘要：沿着"想法如何变成可制造的几何图形"这条线，拆解芯片设计的完整工序——前端把需求固化为 RTL，后端把网表固化为 GDSII，中间每一道工序都有明确的输入、输出与负责算法。本节给出全书的流程地图，后续章节就是在这张地图上逐格放大的。
先看终点：GDSII 里到底有什么
理解一条流水线，最有效的办法是从终点倒推。芯片设计的终点交付物是一份 GDSII 文件——一种分层描述几何图形的二进制格式，里面是数以十亿计的多边形：金属线的矩形、过孔的方块、晶体管有源区的轮廓。晶圆厂拿到的就是它，光刻机照着它把图形一层层转印到硅片上。换句话说，设计芯片的最终形态是几何，而不是代码。
这个视角立刻引出本节的核心问题：工程师写的 Verilog 代码，怎么就变成了这些多边形？答案是中间隔着一条由十几个环节组成的转化链，每个环节只做"一层抽象到下一层抽象"的映射，每个映射都有算法负责。把这些环节连起来，就是所谓的 RTL-to-GDSII 流程。它长得像编译流水线，但每一环都比编译器多一个维度——编译器只需保证功能等价，芯片流程还要同时满足时序、功耗、面积、可制造性这四类物理约束。
前端三步：从需求到 RTL
流程的前端由架构师和前端工程师主导，产出是寄存器传输级（RTL）代码。第一步是架构设计：决定这颗芯片有几个核、缓存多大、总线用什么协议、算力指标怎么分解到模块。这一步的产物是一份架构规格书和一堆性能模型，通常用 C++ 或 SystemC 写成，跑一次基准测试只要几分钟——它的作用是在投入 RTL 之前用便宜的成本试错。第二步是 RTL 编码：用 Verilog 或 VHDL 把每个模块写成寄存器与组合逻辑的描述，"寄存器传输"四个字点明了抽象层级——代码描述的是"时钟沿到来时，数据从哪个寄存器流到哪个寄存器、路上经过什么运算"，而不是门电路怎么接。第三步是功能验证：写测试激励、跑仿真、比期望值，证明 RTL 行为符合规格。业界经验是功能验证吃掉前端工时的一半以上，这也是第 6 章把验证单独立章的原因——验证不是流程里的一道工序，而是一直伴随到流片的平行活动。
前端与后端的分界线是逻辑综合：RTL 代码经综合器转换成门级网表——由标准单元（与门、或门、触发器等来自工艺库的预制零件）和它们的连接关系组成的清单。网表是整个流程的枢纽交付物：它已经知道用哪些零件，但还不知道零件摆在硅片的哪个坐标上。从这个枢纽往前，进入后端。
后端流水线：从网表到 GDSII
图：RTL 到 GDSII 全流程——抽象逐层落地为几何
后端各道工序的分工可以用下表总览。注意每道工序的输出都是下一道的输入，任何一道返工都会向下游传导——这正是后端迭代以"收敛"为关键词的原因。
| 工序 | 输入 | 输出 | 背后的算法 | 本文集位置 |
|---|---|---|---|---|
| 逻辑综合 | RTL + 工艺库 | 门级网表 | 布尔优化、覆盖映射 | 第 2 章 |
| DFT | 网表 | 带扫描链网表 | 图论、覆盖问题 | 略讲 |
| 布局规划 | 网表 + 约束 | 模块轮廓坐标 | 模拟退火、表示模型 | 第 3 章 |
| 布局 | 网表 + 轮廓 | 单元精确坐标 | 解析式优化、合法化 | 第 3 章 |
| 时钟树综合 | 布局后网表 | 时钟缓冲树 | DME 零偏差算法 | 第 3 章 |
| 布线 | 布局结果 | 全部金属连线 | 迷宫搜索、协商拥塞 | 第 3 章 |
| 静态时序分析 | 布线后网表 + 寄生 | 时序裕量报告 | 图遍历、延迟传播 | 第 4 章 |
| 物理验证 | 版图 | DRC/LVS 报告 | 计算几何、图同构 | 第 4 章 |
流程为什么拆成这么多步
一种自然的疑问是：既然每步都在电脑里完成，为什么不从 RTL 一步算到 GDSII？答案藏在"问题可解性"里。一步到位意味着同时求解一个变量数为十亿级、约束互相耦合的非线性问题——任何已知算法都算不动。拆分的价值在于让每一步面对的子问题有良好的数学性质：综合在布尔空间里优化，布局在连续空间里优化，布线在离散网格里搜索，时序分析在有向图上做最长路。每一步都把上一层的自由度冻结，只优化本层的变量，这是分治思想在工程尺度上的应用。
拆分的代价是迭代。后端发现时序违例，可能要回头改综合的约束；综合发现 RTL 结构性缺陷，要回头改代码。工业界把这叫"收敛循环"，先进节点项目走完整个循环的平均次数，往往以十计。所以真实的流程不是瀑布，而是一条带回流的主线——本节的流程图为了清晰画成了单向，读第 4 章时你会看到回流的具体机理。
两个容易踩的误解
其一，"前端比后端高级"的层级偏见。从算法密度看恰恰相反：后端的布局布线、时序签核是 EDA 算法最密集的环节，第 3、4 章的数学含量会明显高于第 2 章。其二，把流程理解为串行的阶段划分。实际上大型项目里多个模块处于不同阶段——A 模块在跑布线时 B 模块还在改 RTL——所谓流程，是单个模块视角下的状态机，不是整个项目的时间表。理解了这两点，1.3 节看产业格局时就能明白：为什么工具商会按"全流程平台"与"点工具"分化，为什么签核工具的门槛比实现工具高一个量级。
流程的迭代成本再补一个真实视角。一次物理实现全流程（综合到布线再到签核级时序）在先进节点的大模块上要跑数小时到一整天，而设计迭代往往要往复十几轮才能把时序、功耗、面积同时收进目标。这就是为什么第 2 章会花力气讲综合的优化算法、第 3 章讲布局的连续化求解——每把一轮迭代的时间压缩百分之十，整个项目周期就实打实缩短几天。流程图上每个方框都对应一个算法团队的多年心血，读懂流程不只是知道先后顺序，更是知道后面每一章在优化哪个方框。
本节要点回顾
- 终点视角：GDSII 是几何图形的分层数据库，芯片设计的最终形态是几何而非代码。
- 枢纽交付物：门级网表定义"用什么零件"，布局定义"零件在哪"，两者合起来才构成完整设计。
- 前端三步：架构试错、RTL 编码、功能验证；验证吃掉前端过半工时，是平行活动而非单道工序。
- 后端七道主工序的输入输出与算法归属，见本节表格，对应第 2 至 4 章。
- 拆步的理由：让每一步的子问题有良好数学性质（布尔优化、连续优化、离散搜索、图遍历）。
- 真实流程带回流：收敛循环以十次计，流程图的单向箭头只是教学简化。
地图已经铺开，但地图上的每台"机器"——综合器、布局器、布线器、时序分析器——都不是凭空长出来的。下一节看这些机器的制造者：EDA 产业本身。