一颗芯片的旅程：规格、架构、RTL、GDSII 到硅片

一颗芯片从想法到硅片，本质上是被“翻译”了七次。起点是一段自然语言写成的市场需求——“续航要长、拍照要快、发热要低”；终点是一组只含多边形坐标的几何数据，晶圆厂看不懂这些多边形“想做什么”，只会忠实地把它们一层一层做出来。中间每一次翻译，都对应一个明确的工程阶段，都产出一种特定格式的交付物，也都可能引入一类只有该阶段才会暴露的错误。

这篇文章沿着抽象层级递进这条主线，把端到端流程拆成七个阶段：规格 → 架构 → 微架构 → RTL → 网表 → 版图 → GDSII → 硅片。每个阶段回答三个问题：输入是什么，核心任务是什么，交出什么、交给谁。

一、先看全景：同一颗芯片的七种“语言”

在展开细节之前，先建立一张压缩地图。集成电路设计通常被划分为前端设计和后端设计两大段：前端从规格走到门级网表，后端从网表走到GDSII。但“前端/后端”的分界线本身并不重要，重要的是理解每跨过一条线，设计的描述方式就发生一次不可逆的抽象转换。

这张表的用法不是背诵，而是定位：当你在任何一个阶段拿到一份文件时，你能立刻知道它处在哪一层抽象，以及下一层的人需要从你这里得到什么，才能继续往下走。

二、规格：把“想要”翻译成“必须做到”

输入：市场需求、应用场景、竞品分析、成本目标。

核心任务：明确芯片的功能边界、性能指标、接口标准、功耗预算、面积上限和成本约束。规格阶段不回答“怎么做”，只回答“做到什么程度才算成功”。一颗手机SoC的规格可能写着“CPU峰值功耗不超过3W、LPDDR5接口速率6400Mbps、典型场景续航指标X小时”；一颗车规MCU的规格则可能把“−40°C到150°C全温区功能安全ASIL-D”放在比性能更优先的位置。

输出与交付物：产品规格书。 它通常包含功能列表、性能表格、接口协议版本、封装形式、功耗模式定义、可靠性等级和验收标准。规格书是整条链的“宪法”——后续所有阶段出现的争议，最终都要回到这里裁决。

这个阶段最常见的失败，不是写得太少，而是写得不可验证。“响应要快”不是规格，“从请求有效到响应有效的延迟不超过20个时钟周期”才是规格。规格中的每一条约束，都应该能在后续某个阶段被测量或证明。

三、架构：在“做什么”和“怎么搭”之间切一刀

输入：产品规格书。

核心任务：把规格中的系统级需求，分解为若干功能子系统，并定义它们之间的交互方式。架构回答的是：用几个CPU核？要不要NPU？总线用什么拓扑？存储层次怎么分？高速接口IP是自研还是外购？时钟域和电源域如何划分？

架构阶段的核心产出不是某段代码，而是一组边界清晰的决策。一个好的架构文档，应该让一个没有参与讨论的工程师读完后，能够画出系统框图、列出每个模块的接口信号、说出数据从输入到输出的主要路径。

输出与交付物：架构规格书。 典型内容包括：系统框图、模块划分与职责、地址映射、中断分配、时钟与复位架构、电源域划分、性能估算（带宽/延迟/吞吐）、接口协议选型、IP复用清单。

这里有一个容易被低估的工程事实：架构阶段的错误，修复成本远高于RTL阶段的错误。一个时钟域划分失误如果在架构阶段被发现，改的是文档和框图；如果在后端发现，可能意味着重新做时钟树综合，甚至重新流片。

四、微架构：把“模块”拆到可写的粒度

输入：架构规格书。

核心任务：对架构划分出的每个模块，定义其内部实现结构。微架构回答的是架构没有回答的那一层问题：这个模块里有几个流水级？状态机有几个状态、怎么编码？FIFO多深？数据通路位宽多少？控制逻辑和运算逻辑如何分离？

架构说“这里需要一个AXI-Lite从设备来配置寄存器”，微架构说“这个从设备用一个三段式FSM实现写响应，寄存器文件用32×32-bit的寄存器堆，地址译码在组合逻辑中完成，写操作在第三个周期提交”。架构说“支持突发传输”，微架构说“突发长度为1—16，不支持未对齐地址，不支持out-of-order返回”。

输出与交付物：微架构规格文档 + 单元级设计文档。 对于复杂模块，还可能包含时序图、状态转移图、流水线时空图、FIFO深度计算过程和接口时序参数表。微架构文档是RTL工程师的直接输入，它的质量决定了RTL是一次写对，还是写三遍才对。

五、RTL：把结构写成可综合的行为

输入：微架构规格文档、架构规格书中的接口定义、可用的IP交付件。

核心任务：用Verilog或SystemVerilog把微架构描述为寄存器传输级代码。RTL描述的是“每个时钟沿到来时，寄存器如何更新，组合逻辑如何响应”，它必须同时满足两个看似矛盾的要求：行为上正确，结构上可综合。不是所有能仿真的Verilog都能变成真实的门电路；latch推断、不完整的敏感列表、不可综合的延时语句，都会在综合阶段变成障碍。

RTL本身不是终点。在RTL被交给综合之前，必须经过功能验证：搭建testbench，运行定向测试和随机测试，收集功能覆盖率和代码覆盖率，确认设计在所有预期场景和边界条件下行为正确。验证不是“RTL写完之后的收尾工作”，而是与RTL设计并行推进的独立工程活动。一个验证不充分的RTL设计，即使代码风格完美，也不能进入综合。

输出与交付物：验证通过的RTL源代码 + 验证环境 + 覆盖率报告。 在团队协作中，交付给综合阶段的“RTL包”通常还包括：设计文件清单、SDC约束初稿、UPF电源意图文件（如果是低功耗设计）、以及一份记录已知限制和例外情况的说明文档。

RTL阶段的核心纪律是可综合性优先：写下的每一行代码，都要能回答“综合工具会把它变成什么样的硬件”。

六、网表：从“行为”坠入“元件”

输入：验证通过的RTL、标准单元库（Liberty格式）、时序约束（SDC）、工艺库信息。

核心任务：逻辑综合。综合工具把RTL中的行为描述翻译为通用电路块（加法器、多路器、触发器），进行逻辑化简和资源共享，然后映射到目标工艺库中真实存在的标准单元上，并根据时序约束为每条路径挑选合适驱动能力的单元。

综合的结果是门级网表：一份列出电路中所有标准单元实例、以及它们之间如何连线的文件。网表通常仍然用Verilog格式书写，但里面已经没有 if 和 +，只剩元件和连线——它描述的是结构，不是行为。

综合阶段最关键的输入不是RTL，而是约束。时钟频率定义在哪个引脚上、输入输出延迟是多少、哪些路径是false path、哪些是多周期路径，这些全部写在SDC中。约束写错了，综合工具会“完美地”优化一个错误的目标；时序报告再漂亮也没有意义。

网表生成后，还需要经过门级仿真和形式等价性检查，确认综合没有改变RTL的功能意图。到此为止，前端设计的标志性终点达成：一个功能正确、时序基本收敛、形式验证通过的门级网表。

输出与交付物：门级网表 + SDC约束 + 综合时序/面积报告 + 形式等价性检查报告 + DFT插入后的扫描网表（如适用）。

七、版图：从“元件”坠入“几何”

输入：门级网表、SDC约束、标准单元和宏单元的物理库（LEF）、工艺技术文件。

核心任务：物理设计。后端的工作是把“哪些元件、怎么连”变成“放在哪里、走线怎么走”。流程通常包括：布图规划，确定芯片尺寸、宏单元位置、I/O摆放和电源网格；布局，把每个标准单元放到行内的具体坐标上；时钟树综合，构建低偏斜的时钟分布网络；布线，在多层金属上完成所有信号和电源的连接。

这个阶段的迭代强度远高于前端。布局改了，时序可能变差；时钟树综合之后，hold违例可能大量出现；布线完成之后，寄生参数提取出来的延迟和综合阶段的估计可能差出可观的比例。物理设计不是一条单向流水线，而是布局—时序—拥塞—功耗之间的反复权衡。

在版图数据被接受为“可签核”之前，必须经过物理验证：DRC检查版图是否符合晶圆厂的线宽、间距、密度等制造规则；LVS检查版图提取出的网表是否与原始网表一致；ERC检查电气规则。此外还需要完成寄生参数提取、签核级静态时序分析、功耗和信号完整性检查。

输出与交付物：签核通过的版图数据库（DEF/OASIS） + 寄生参数文件（SPEF） + DRC/LVS/ERC报告 + 签核STA报告 + 功耗/IR-drop/EM报告。

八、GDSII 与硅片：交出几何，等待物理

输入：签核通过的版图。

核心任务：生成GDSII（或文件更小的OASIS）并完成Tape-out。GDSII里没有“功能”，没有“信号名”，只有一层一层的多边形：哪一层、在什么坐标、是什么形状。每一层大致对应晶圆厂的一片光罩，从晶体管的形状到最上层金属和焊盘，全部以几何方式编码。

Tape-out的本质是一次版本冻结和物理移交。设计团队把GDSII交给晶圆厂，晶圆厂用自己的规则再做一次检查，进行光罩数据准备，制作光罩，然后投片。从这一刻起，设计不能再改；任何在GDSII中存在的形状错误，都会被一模一样地制造出来。

输出与交付物：最终GDSII/OASIS文件 + 与晶圆厂的Tape-out确认记录（文件版本、校验和、层映射表）。此后晶圆厂经过数月的前道制造，交付回来的是一批裸片；再经过封装和硅后测试，才成为可以焊到电路板上的芯片。

九、这张流程图的工程含义

把七个阶段串起来看，有一条隐藏的规律比任何单个阶段都重要：

下游发现的问题，返工成本沿流程指数上升。

规格里一句含糊的“低功耗”，可能在架构阶段被理解为“多电源域”，在微架构阶段被实现为复杂的电源状态机，在后端变成UPF和多电压域布线的复杂度，最终在硅片上表现为一个无法收敛的漏电指标。如果在规格阶段就把“低功耗”量化为“待机漏电不超过X毫安、典型场景动态功耗不超过Y毫瓦、支持哪几种电源模式”，整条链的决策就有了可验证的锚点。

这条规律解释了为什么验证和签核要占据如此大的工程比重：在RTL仿真中发现的错误，修复成本是小时级；在Tape-out之后发现的错误，修复成本是数百万美元和数月周期。流程中每一个“验证”“检查”“签核”环节，本质上都是在用可控的成本，拦截那些一旦流到下游就会失控的错误。

下一篇文章把镜头从“流程”转向“团队”：前端、验证、DFT、后端、签核各自在守哪一段，交接时到底交什么，以及一个RTL工程师写的代码，在离开自己电脑之后会经历什么。