数字 IC 设计课程初级：从需求到 GDSII 的完整入门

一块数字芯片从想法走到实物，通常要经历几年、几十个团队角色和成千上万次检查。初学者最容易把这件事理解成"写 Verilog，然后让工具生成版图"，但真正的数字 IC 设计更像一次受控的抽象层级下降：

先把模糊的产品需求变成可测量的指标；
再把指标变成系统架构和算法模型；
再把架构写成可综合的 RTL；
再把 RTL 综合成门级网表；
最后把网表变成满足时序、功耗、可测性和制造规则的版图。

每一步都在降低抽象层级，同时增加一类新的约束。每一步也都需要独立证据，证明自己没有把上一层的意图做错。

先记住三句话

功能正确只是入场券。 芯片还要在指定工艺、电压、温度下跑得够快，功耗和面积在预算内，能被测试，能被制造，能稳定量产。
设计是正向流，验证是反向证据流。 RTL、综合、后端在往前推进；仿真、形式验证、STA、DFT、DRC/LVS 在反复证明"还没有跑偏"。
错误发现得越晚，代价越高。 规格阶段的歧义可能只改几行文档；流片后的功能错误可能意味着重新做掩膜、重新流片和几个月的时间损失。

1. 一张图看懂完整流程

课件把流程概括为四个阶段：需求与指标、系统级设计、前端设计、后端设计。这个划分是对的，但实际项目里更值得记住的是每个阶段之间的"门禁"：上一阶段的输出如果没有达到可验收状态，就不要急着进入下一阶段。

|--------|-----------------|-----------------------------|------------------------|
| 阶段 | 核心问题 | 主要输出 | 进入下一阶段的条件 |
| 需求与指标 | 到底要解决什么问题？ | 芯片规格书、场景清单、接口定义、验收标准 | 指标可测量，边界和优先级明确 |
| 架构与模型 | 用什么结构实现？ | 架构规格、算法黄金模型、设计规格、测试计划 | 接口、预算、存储和时钟方案基本冻结 |
| 前端设计 | RTL 是否正确地描述了架构？ | RTL、SDC 约束、验证报告、覆盖率、门级网表 | 功能、等价性、时序可达性和 DFT 检查通过 |
| 后端实现 | 网表能否变成可制造版图？ | 最终版图、GDSII/OASIS、签核报告、流片数据包 | 时序、功耗、物理验证和可测性全部签核 |

这张图里有一条很容易被忽略的虚线：后端发现问题时会回头迭代。时序不收敛、拥塞严重、DRC 不过、LVS 对不上，都可能要求重新摆放、重新布线，甚至回到 RTL 修改流水线。所谓"前端"和"后端"不是两个互不相关的部门，而是同一条收敛回路上的两个位置。

2. 需求定义：把"想要一块芯片"变成可验收指标

需求阶段最常见的失败不是"没想到某个功能"，而是写下来的需求无法验收。例如"支持高速接口、功耗要低、面积尽量小"不能直接指导设计，因为不同人对"高速""低功耗""尽量小"的理解完全不同。

2.1 五类指标

一份可执行的芯片规格，至少要把指标分成五类：

功能指标：实现哪些模式、协议版本、数据宽度、算法精度、寄存器行为、异常处理和调试能力。
性能指标：最高时钟频率、吞吐率、延迟、抖动、并发数、队列深度、模式切换开销。
物理指标：工艺节点、金属层数、芯片面积、标准单元规模、SRAM/IP 宏数量、封装和引脚数。
可靠性与测试指标：工作温度、电压范围、ESD、闩锁、老化、DFT 覆盖、JTAG、安全启动和故障恢复。
成本与进度指标：NRE、量产单价、IP 授权、工具和人力、流片窗口、封装测试周期。

这五类指标之间通常互相拉扯。更先进的工艺可以换来更高频率和更小面积，但掩膜、IP 和设计成本更高；增加并行度可以降低时钟频率，但面积、拥塞和功耗会上升；增加流水线可以改善时序，但延迟和寄存器数量会增加。所谓 PPA（Performance、Power、Area）优化，本质上是在给定约束下做取舍，而不是把三个指标同时推到极限。

2.2 一条好指标应该长什么样

好的指标通常包含四个要素：数值、条件、边界、验收方法。

不推荐：

SPI 要快，功耗要低，支持常见模式。

更可执行：

SPI Master 支持 mode 0/1/2/3；在 SS/0.9 V/125 ℃ 条件下，SCLK 最高不低于 50 MHz；连续传输 4 KB 数据时平均功耗不超过 18 mW；空载时时钟可关闭；所有模式必须通过回环和协议断言测试。

后一条并不一定适用于所有项目，但它展示了规格书应有的形态：仿真和测试人员可以直接据此写出用例，后端可以据此建立约束，项目经理可以据此判断是否延期。

2.3 规格冻结与变更控制

项目推进到 RTL 之后，需求变更不会消失，但必须被管理。一个实用做法是维护三类清单：

已冻结项：接口、时钟、寄存器地址、关键性能指标；
待定项：有明确负责人和关闭日期的开放问题；
变更项：每次变更都记录原因、影响范围、需要重跑的验证和后端任务。

最危险的情况不是需求变化，而是需求变化只存在于聊天记录里，RTL、验证平台和后端约束各自按不同版本推进。

3. 系统架构与算法建模：决定性能上限的地方

架构阶段要回答的不是"这个功能能不能做"，而是"用哪种结构做，代价是多少"。同一个功能可以用纯软件实现，也可以用硬件加速；可以做成一个大的状态机，也可以拆成流水线；可以共享存储，也可以每个通道独立缓冲。架构选择通常决定了后续能优化到什么程度。

3.1 架构决策清单

软硬件划分：哪些功能交给 CPU/固件，哪些必须硬件加速？
模块划分：按数据流、控制流还是接口边界拆分？模块之间谁依赖谁？
数据通路：流水线、并行度、复用方式、位宽、握手和反压。
存储层次：寄存器、SRAM、缓存、FIFO 的容量、端口数和访问冲突。
总线与互连：主从关系、仲裁、带宽、延迟和 QoS。
时钟与复位：同步域、异步域、CDC/RDC、复位释放顺序。
功耗与物理：电源域、时钟门控、宏单元位置、布线通道预留。
可测性与调试：扫描链、MBIST、JTAG、观测点、错误注入。

这些决策最后都要落成预算。比如说"这个模块延迟不超过 20 个周期"，就要进一步拆成接口握手几个周期、计算几级流水、存储访问几个周期、跨时钟域几个周期。没有预算的架构描述，到了 RTL 阶段很容易变成"先写出来再想办法"。

3.2 算法模型不是"伪代码"

对于包含信号处理、通信协议、图像或 AI 运算的芯片，算法团队通常会先做可执行模型。模型至少有三种用途：

功能黄金模型：给出逐位一致的参考结果，供验证平台比对；
定点/误差模型：确定位宽、舍入、饱和和溢出策略；
性能模型：估算周期、带宽、队列长度和存储需求。

模型最好从项目早期就能运行。一个能在几秒内复现问题的 C/Python 模型，比在 RTL 仿真里追波形高效得多。模型和 RTL 必须是两个独立实现，否则同一个理解错误会同时出现在两边，验证就失去了意义。

3.3 设计规格：从架构到每个周期

架构规格回答"系统怎么分工"，设计规格回答"每个周期每个信号怎么动"。一份设计规格通常包括：

模块层次和接口列表；
寄存器映射、复位值、访问权限和中断；
接口时序图、握手规则、反压行为；
状态机状态、转移条件、异常和恢复；
存储映射、FIFO 深度、满/空/水位；
时钟域、复位域、CDC 方案；
延迟/吞吐预算和资源预算；
验证计划、测试模式和调试观测点。

3.4 一个微型案例：UART-to-SPI 桥

假设产品需求是"做一个低成本的 UART 转 SPI 桥"。把它落到工程上，可以这样展开：

功能：APB 配置寄存器；UART 收发；SPI Master；8 字节 TX/RX FIFO；中断输出；回环测试模式。
性能：系统时钟 50 MHz；UART 支持 115200 bps 到 3 Mbps；SPI SCLK 最高 25 MHz；单字节转发延迟不超过 20 个系统时钟。
物理：单时钟域；目标面积小于 0.05 mm²；外部引脚尽量少。
测试：扫描链、FIFO 满/空边界、奇偶校验错误、SPI 四种模式、回环。

架构上可以拆成 apb_regs、uart_rx、uart_tx、baud_gen、tx_fifo、rx_fifo、spi_master 和 interrupt。算法模型只需要描述寄存器和字节流行为；设计规格则要明确 FIFO 在什么条件下置满、UART 帧错误如何上报、SPI 在空 FIFO 时是保持时钟还是产生 underrun 标志。

这个例子说明：架构不是画一张漂亮的框图，而是把"功能、性能、接口、异常、测试"逐项分配到具体模块和具体周期。

4. 前端设计：RTL 是硬件，不是软件

RTL（Register Transfer Level）描述的是寄存器之间的数据传输和组合逻辑。它看起来像代码，但执行模型和软件完全不同：所有时序逻辑在时钟沿并行更新，组合逻辑在每个时刻连续传播。写 RTL 时最重要的不是"语法能不能过"，而是"综合出来是不是你想要的硬件"。

4.1 RTL 设计的几条硬规则

同步设计优先：一个模块尽量只有一个主时钟；跨时钟域必须显式处理，不能靠"应该能采到"。
一个 always****块只描述一种逻辑：时序逻辑和组合逻辑分开，避免把锁存器、寄存器和组合逻辑混在一起。
避免意外锁存器 ：组合逻辑在所有分支都要赋值，case 要有 default。
避免组合环和多驱动：组合环会让仿真和静态时序都失去意义，多驱动会造成综合歧义。
复位策略统一：明确同步复位还是异步复位、复位释放是否同步、哪些寄存器需要复位。
接口优先：先定义 valid/ready、start/busy/done、error 等握手语义，再写内部数据通路。
可综合性：可综合 RTL 里不要依赖延时语句、初始化块、动态内存或仿真专用结构。
命名和层次清晰：模块名、信号名、位宽和方向要能直接表达意图，避免靠注释解释。

4.2 三种常见结构

流水线 用寄存器把长组合路径切开，提高吞吐率，但会增加延迟和寄存器面积。状态机 负责控制流程和异常处理，关键是状态完整、转移互斥、默认路径明确。FIFO/握手负责跨模块的数据传输，关键不是"能传"，而是满、空、反压、溢出和复位时的行为都可验证。

4.3 静态检查先于仿真

Lint 可以在几秒钟内发现位宽不匹配、锁存器、多驱动、未初始化、死代码等问题。CDC（Clock Domain Crossing）检查发现缺少同步器的跨时钟域路径，RDC（Reset Domain Crossing）检查复位域之间的相互影响。这些问题如果等到仿真里偶发失败再查，成本会高很多。

4.4 前端闭环

前端不是一个单向的"写代码"动作，而是两个闭环：

功能闭环：设计规格 → RTL → 静态检查 → 单元仿真 → 集成仿真 → 回归和覆盖率；
实现闭环：RTL → 综合 → 门级仿真 → 等价性检查 → STA → DFT。

两个闭环共享同一份设计规格和同一批测试场景。功能正确不代表时序正确，时序正确也不代表可制造；每一类结论都需要独立的证据。

5. 验证：让机器自动证明"这次没有错"

验证不是"多写几个 test"，而是建立一个能自动驱动、观测、比对、统计和定位问题的系统。一个最小的验证平台通常包括：

激励生成：定向场景、随机约束、异常注入、可复现的随机种子；
Driver：把事务翻译成引脚级时序，遵守协议和反压；
Monitor：被动采样接口，把引脚行为还原成事务；
Reference Model：独立的黄金模型，给出期望结果；
Scoreboard：按事务配对，比较实际值和期望值；
Coverage：统计代码、功能、断言、翻转和交叉覆盖；
Assertions：检查协议不变量、互斥关系、握手和边界条件；
Regression：批量运行、自动分类失败、保存波形和复现命令。

5.1 验证计划比测试用例更重要

验证计划应该从规格书反推，而不是从 RTL 代码反推。至少要覆盖：

正常路径和所有工作模式；
空、满、最小、最大、非对齐、背靠背等边界；
错误注入、超时、复位、掉电和恢复；
跨时钟域、异步事件和并发冲突；
软件可见的寄存器、中断和状态位；
性能、延迟、吞吐和反压行为。

随机测试适合探索组合爆炸，定向测试适合覆盖明确场景，形式验证适合证明局部性质。三者不是互相替代的关系。

5.2 覆盖率不等于正确性

代码覆盖率告诉你"哪些行被执行过"，功能覆盖率告诉你"哪些场景被打到过"，断言覆盖率告诉你"哪些性质被检查过"。它们都可能达到 100%，但设计仍然是错的，因为：

参考模型和 DUT 可能犯了同一个理解错误；
覆盖率点没有覆盖真正的风险；
断言只检查了容易检查的性质；
随机约束把重要角落排除了。

验证收敛的标准不是"覆盖率数字好看"，而是"已知风险都有对应检查，未覆盖项有解释，失败可复现，回归稳定"。

5.3 形式验证、门级仿真和等价性检查

形式验证：用数学方法证明某些性质在所有输入下成立，适合协议不变量、仲裁互斥、FIFO 指针和状态机安全性质。
门级仿真：在综合后的网表上带延时模型复跑关键场景，检查综合、时钟树和复位是否改变行为。
等价性检查：证明 RTL 和门级网表功能等价，不依赖测试向量，是综合后非常重要的签核步骤。

等价性检查通过，不代表时序满足；STA 通过，也不代表功能正确。它们回答的是不同问题。

6. 逻辑综合：从行为描述到标准单元

逻辑综合把 RTL 翻译成由标准单元和宏单元组成的门级网表。综合工具会做三件事：解析和展开 RTL、在工艺库上做逻辑优化、把逻辑映射成具体的标准单元。它的输出不只是网表，还包括时序、面积、功耗报告和更新后的约束。

6.1 标准单元为什么有"四种视图"

一个二输入与非门在库里至少有几类描述：

逻辑视图：它实现什么布尔函数；
时序视图：输入变化后输出多久稳定，负载和转换时间如何影响延时；
物理视图：单元尺寸、引脚位置、布线阻挡和电源轨；
库文件视图 ：.lib/.db、.lef、.gds/.oas、.v/.cdl 等不同工具使用的文件。

这些视图必须来自同一版本、同一工艺角、同一套特征化数据。混用不同版本的库，常见后果是仿真通过、综合通过，但版图或 LVS 对不上。

6.2 综合约束不是"写给工具看的"

综合需要 SDC（Synopsys Design Constraints）描述时钟、输入输出延时、时钟不确定性、最大转换时间、最大扇出、false path 和 multicycle path。约束写得过松，工具会给出虚假的乐观结果；写得过紧，工具会过度优化，面积和功耗失控。

几条基本原则：

时钟定义要覆盖真实时钟、生成时钟和门控时钟；
输入输出延时来自外部接口的真实时序，不要凭感觉填；
false path 和 multicycle 是设计契约，不是用来"消掉违例"的橡皮擦；
跨时钟域路径要有同步方案和对应的 CDC 约束；
综合后要检查时序报告、面积报告、功耗报告和未约束路径。

6.3 综合后的检查

综合完成后至少要做：

门级仿真关键场景；
RTL 与 netlist 的等价性检查；
静态时序分析；
DFT 插入和 ATPG；
检查未约束路径、最大扇出、转换时间和时钟结构。

综合不是后端，综合通过也不等于可以流片。它只是把"行为"变成了"门"，后面的物理世界还没有开始。

7. 静态时序分析：Setup 和 Hold

STA（Static Timing Analysis）不需要测试向量，它遍历时序图中的路径，检查每一段路径在最坏和最好条件下是否满足约束。初学者最需要掌握的是两个检查：

Setup：数据必须在捕获时钟沿之前稳定足够久；
Hold：数据在捕获时钟沿之后还必须保持足够久。

7.1 直觉理解

把一条路径想成"发射触发器 → 组合逻辑 → 捕获触发器"：

Setup 关心最长路径：数据从上一拍出发，经过最慢的组合逻辑，必须在下一拍采样窗口之前到达。
Hold 关心最短路径：数据不能跑得太快，以至于在同一个采样沿之后立刻改变，破坏捕获触发器需要保持的值。

所以 setup 违例通常靠"让数据更早到"或"给数据更多时间"解决：增加时钟周期、切流水线、减少逻辑级数、upsize、缩短关键路径、调整时钟偏斜。Hold 违例通常靠"让数据晚一点到"解决：在最短路径上加延时、降驱动、绕线、加 buffer。降频不能修复 hold，因为 hold 与时钟周期无关。

7.2 工艺角与不确定性

Setup 通常在慢工艺、低电压、高温等条件下更差；hold 通常在快工艺、高电压、低温等条件下更差。实际签核会使用多工艺角、多模式（MMMC），并考虑时钟抖动、OCV/derate、电压降和寄生参数变化。

这也是为什么"仿真跑过了"不能替代 STA：仿真只跑了有限场景，STA 会检查所有被约束的路径；但 STA 也不能证明功能正确，它只检查时序。

7.3 常见错误

用 false path 掩盖真实的跨时钟域路径；
忘记生成时钟、门控时钟或测试模式时钟；
只检查一个工艺角；
忽略输入输出延时和外部负载；
看到 hold 违例就降频；
以为 CDC 路径只要"加了同步器"就自动安全，忽略同步器的时序、复位和多位总线一致性。

8. DFT：让芯片在出厂后能被测试

芯片内部有大量触发器，但从外部引脚很难直接控制或观察它们。DFT（Design for Test）的目标是把这些内部节点变成可控制、可观测的测试通道。最常见的方法是扫描链：在功能触发器前面插入一个多路选择器，测试模式下把触发器串成移位寄存器。

8.1 Shift 和 Capture

Shift ：SE=1，扫描时钟把测试向量逐位移入触发器链；
Capture ：SE=0，让功能逻辑工作一个周期，把组合逻辑结果捕获进触发器；
Shift out ：再次 SE=1，把捕获到的响应移出，与无故障响应比较。

ATPG（Automatic Test Pattern Generation）会根据故障模型生成测试向量，常见模型包括 stuck-at、transition delay 和 bridging。故障覆盖率衡量的是"被测试向量检测到的故障比例"，它和功能覆盖率不是同一个概念。

8.2 DFT 必须提前进入架构

扫描链会增加面积、布线和测试模式下的时序压力。大规模芯片还会加入扫描压缩、MBIST（存储器自测）、边界扫描（JTAG）和片上监控。DFT 工程师需要在 RTL 和综合阶段就参与，确定：

测试时钟从哪里来，测试模式如何切换；
哪些寄存器需要进入扫描链，哪些需要隔离；
异步存储器和时钟域如何处理；
测试功耗是否会导致过流或误判；
扫描链重排是否影响功能时序；
测试覆盖率目标和不可测项的解释。

"功能做完了再补 DFT"通常会导致大量返工。更好的做法是把可测性当作架构指标的一部分。

9. 后端物理实现：在约束中找可行解

后端从门级网表、SDC 约束、标准单元库和工艺规则开始，经过布局规划、摆放、时钟树综合、布线、寄生提取、签核 STA 和物理验证，最终输出 GDSII/OASIS。

课件中把自动布局布线写成 ARP ，业界更常见的缩写是 APR（Automatic Place and Route）。这不是概念差异，只是术语习惯；看到 ARP 时按"自动布局布线"理解即可。

9.1 每一步在解决什么问题

**布局规划（Floorplan）**决定 die/core 尺寸、IO 和宏单元位置、电源网格、电源域和布线通道。它往往决定后续时序和拥塞的上限，是把架构意图落实到物理世界的第一步。

**摆放（Placement）**把标准单元放到合法位置，同时考虑密度、拥塞、时序和扫描链方向。摆放不是简单地"塞进去"，而是要在局部密度和全局连接之间折中。

**时钟树综合（CTS）**插入缓冲器，平衡时钟到达时间，控制 skew、转换时间和时钟功耗。时钟树的质量会直接影响 setup、hold、功耗和噪声。

**布线（Routing）**分全局布线和详细布线，处理层分配、拥塞、串扰、天线效应和设计规则。布线完成后，导线的电阻和电容才真正确定。

**寄生提取（RC Extraction）**把版图几何转换成寄生电阻、电容和耦合参数，再送回 STA、功耗和噪声分析。此时的分析才接近真实芯片。

签核 STA 在多工艺角、多模式下检查 setup、hold、最大电容、最大转换时间、跨时钟域约束和噪声。物理验证则包括 DRC、LVS、ERC、天线、密度和 DFM。

9.2 DRC 和 LVS 分别在查什么

DRC（Design Rule Check）：版图是否满足晶圆厂的几何规则，例如线宽、间距、包围、密度、通孔规则。
LVS（Layout Versus Schematic）：从版图提取出的网表是否与源网表一致，包括器件、连接、端口和参数。
ERC（Electrical Rule Check）：电源、地、衬底、阱、浮空节点等电气连接是否合法。

DRC 通过不代表 LVS 通过，LVS 通过也不代表时序和功耗没问题。签核是一个多维度的联合检查。

9.3 后端的反馈回路

后端最耗时的不是"第一次跑完"，而是"把问题收敛掉"。STA 不收敛时可能需要 ECO、重摆放、重布线，甚至回到 RTL 调整流水线；DRC/LVS 失败时需要修版图、改电源网络或调整宏单元；DFT 插入后可能需要重排扫描链，重新检查测试模式时序。

因此，后端必须和前端、验证、DFT 共享同一套版本、配置和约束。任何"手工改一下版图但没回到网表"的操作，都要有明确的 ECO 记录和验证闭环。

10. 版图是三维结构，不是平面图

初学者容易把版图想成一张俯视图，但真正的芯片是多层金属、通孔、扩散区、多晶硅和钝化层叠起来的三维结构。标准单元的高度通常是固定的，宽度按工艺网格对齐；金属层通常交替使用水平/垂直优先方向，越往上层线宽越大，适合电源和长距离信号，但通孔电阻、层间电容和布线资源竞争也随之增加。

同一根信号线换一层金属，延时、电容、串扰、拥塞和制造风险都会变化。后端的每一次"挪动"，都同时改变时序、功耗、噪声和可制造性。这就是为什么物理实现必须迭代，而不是一次成功。

11. 流片不是终点

所有签核通过后，最终版图会以 GDSII/OASIS 等形式交给晶圆厂，经过掩膜制作、晶圆制造、封装和测试，最后进入硅后验证。流片（Tape-out）原本有"把数据写到磁带"的历史含义，现在更多指"冻结并提交最终版图数据"。

流片数据包通常包含：

最终 GDSII/OASIS 和层映射；
网表、SDC、库版本和工艺角配置；
时序、功耗、DRC/LVS/ERC、天线、EM/IR 报告；
DFT 测试模式、ATPG 向量和覆盖率报告；
封装、引脚、ESD 和可靠性信息；
版本说明、已知限制、豁免项和复现脚本。

硅后验证同样需要计划：先测电源、时钟、复位和 JTAG，再测存储器、接口和功能，最后做性能、功耗、温度和可靠性测试。流片成功不等于量产成功，量产还涉及良率、测试时间、封装和供应链。

12. 团队角色：同一份规格的不同视角

|------------|----------------|-------------------------|
| 角色 | 主要关注 | 典型交付物 |
| 产品/市场 | 场景、成本、上市时间 | 产品需求、竞品分析、商业目标 |
| 系统架构师 | 软硬件划分、模块、接口、预算 | 架构规格、接口定义、性能预算 |
| 算法工程师 | 精度、定点、黄金模型 | C/Python/MATLAB 模型、测试向量 |
| RTL 设计师 | 微架构、可综合性、时序可达性 | RTL、设计说明、集成指南 |
| 验证工程师 | 场景、覆盖率、自动比对 | 验证计划、测试平台、回归报告 |
| DFT 工程师 | 可控制性、可观测性、覆盖率 | 扫描链、ATPG 向量、测试方案 |
| 综合/STA 工程师 | 约束、时序、面积、功耗 | 网表、SDC、时序报告 |
| 后端工程师 | 布局布线、时钟、物理验证 | 版图、GDSII、签核报告 |
| CAD/工具工程师 | 流程、版本、自动化 | 脚本、回归环境、数据库 |
| 测试/固件工程师 | 硅后验证、量产测试 | 测试程序、Bring-up 报告 |

真实项目中，一个人可能兼多个角色，但每种视角都不能消失。芯片不是某一个部门独立完成的产物，而是一组证据链共同支撑的工程结果。

13. 初学者应该怎么学

如果只按课件目录背流程，很容易"知道名词但不会做"。更有效的学习顺序是：

第一阶段：数字电路与 Verilog

组合逻辑、时序逻辑、建立/保持时间、时钟和复位；
用 Verilog 写寄存器、计数器、状态机、FIFO、UART、SPI；
学会自己写 testbench，而不是只看波形；
理解阻塞赋值和非阻塞赋值的区别。

第二阶段：验证与调试

设计随机约束和覆盖率点；
用参考模型和 scoreboard 自动比对；
学会看波形、定位 X 态、复现随机失败；
了解断言和形式验证的基本用法。

第三阶段：综合与时序

用开源或商业工具把 RTL 综合成网表；
学会写基本 SDC，读时序报告；
理解 setup/hold、工艺角、skew、uncertainty；
尝试用流水线修复一条关键路径。

第四阶段：物理与 DFT 概览

跑一次小设计的布局布线；
看 DRC/LVS 报告，理解版图与网表的关系；
了解扫描链、ATPG 和测试模式；
知道后端为什么会回头要求 RTL 修改。

一个很实用的练习项目是"带 FIFO 的 UART-to-SPI 桥"：它规模不大，但包含寄存器、状态机、FIFO、跨模块握手、时钟分频、错误处理和测试模式，几乎覆盖了初级数字 IC 设计的主要概念。

14. 一页速查

最值得记住的八个判断

规格是否可测量、可验收？
架构预算是否分解到模块和周期？
RTL 是否可综合、是否有意外锁存器和组合环？
跨时钟域和复位域是否显式处理？
验证平台是否能自动判错、自动复现？
综合约束是否真实，等价性和 STA 是否通过？
DFT 是否在架构阶段就进入，测试模式时序是否检查？
后端签核是否覆盖时序、功耗、DRC/LVS、EM/IR 和可测性？

术语速查

|---------------|--------------------------|
| 术语 | 含义 |
| RTL | 寄存器传输级，描述寄存器之间的数据传输和组合逻辑 |
| Netlist | 门级网表，由标准单元和连线组成 |
| Standard Cell | 工艺库中预先设计好的基本逻辑单元 |
| PDK | 工艺设计套件，包含器件模型、规则和库信息 |
| SDC | 时序约束文件，描述时钟、IO 延时和路径例外 |
| PPA | 性能、功耗、面积 |
| STA | 静态时序分析，不依赖测试向量检查时序 |
| CDC/RDC | 跨时钟域/跨复位域检查 |
| DFT | 可测性设计 |
| ATPG | 自动测试向量生成 |
| DRC | 设计规则检查 |
| LVS | 版图与网表一致性检查 |
| ECO | 工程变更单，通常指对网表或版图的小范围修改 |
| MMMC | 多模式多工艺角分析 |
| OCV | 片上偏差，时序分析中用于模拟同一芯片内的差异 |
| Tape-out | 冻结并提交最终版图数据，进入掩膜和制造 |

结语

数字 IC 设计的难点，不在于记住多少个工具命令，而在于始终知道当前处于哪个抽象层级、这一层的输入输出是什么、用什么证据证明它是对的。课件给出的是一条标准路线；真正做项目时，这条路线会变成许多次迭代：规格澄清、架构权衡、RTL 修改、验证收敛、综合优化、时序修复、物理实现和签核。

把每一层都做扎实，流片才不是一次赌博，而是一次有证据支撑的工程决策。