1. 流片交付全景与Cadence工具链定位

数字芯片从一行RTL代码到可送交晶圆厂的GDSII版图，中间要跨越功能验证、逻辑综合、可测性设计、布局布线、时序与物理验证等多道关卡。每一道关卡都有明确的输入交付物、输出交付物和判定标准，任何一环的交付物不达标，都会在下一环被放大成难以收敛的问题。理解这条链路的全貌，以及Cadence工具链在其中的位置，是后续所有实操章节的认知基础。

一、从RTL到GDSII的交付链路

整条链路可以按“抽象层级”划分为三个大阶段：行为级（RTL与验证）、门级/网表级（综合、DFT、形式与静态时序）、物理级（布局布线、寄生提取、物理验证与签核）。阶段之间传递的不是“感觉”，而是具体文件：

• RTL阶段交付：可综合的 .v/.sv 源码、验证平台、覆盖率报告、约束初稿 .sdc。
• 综合阶段交付：门级网表 .v、标准单元与宏单元的 .lib 时序库、综合后 .sdc、面积与功耗初报。
• DFT阶段交付：插入扫描链后的网表、扫描协议文件、ATPG 测试向量与覆盖率。
• 物理阶段交付：布局布线后的 DEF、SPEF 寄生参数、最终 GDSII、DRC/LVS/ERC 报告、签核时序报告。

这些交付物之间存在严格的依赖方向：RTL决定网表结构，网表决定物理实现的可布性，物理实现又反过来暴露时序与拥塞问题，需要回到约束甚至RTL修改。因此流片交付不是单向流水线，而是带反馈的迭代收敛过程。

二、Cadence工具链在链路中的定位

Cadence在数字实现领域提供了一条覆盖主要环节的工具链，常见对应关系如下：

需要强调的是，工具只是执行者，真正决定流片成败的是约束、库、规则文件这三类“非代码输入”。约束写错，综合和布局布线都会朝错误目标优化；库选错工艺角，签核结论就不可信；规则文件版本不匹配，DRC会报出大量假错。因此工具链定位的本质，是明确每个工具“吃什么、吐什么、依据什么判断”。

三、交付全景与反馈关系

下图给出从RTL到GDSII的主链路、Cadence工具位置，以及三条关键反馈路径：时序不收敛回退到综合或约束、拥塞或DRC问题回退到布局或网表、功能覆盖不足回退到RTL。理解这些反馈方向，才能在项目延期时快速定位该改哪一层。

四、交付物验收的通用判断依据

每个阶段的输出都需要可判定的验收标准，而不是“看起来没问题”。以下给出常见阶段的判断依据示例：

• RTL阶段：功能覆盖率与代码覆盖率是否达到项目设定阈值（示例：功能覆盖率≥95%，行覆盖率≥90%）；是否存在未约束的时钟域。
• 综合阶段：综合后时序违例数量与WNS（最差负裕量）是否在可接受范围；面积是否超出预算；是否有未映射的单元或锁存器推断。
• DFT阶段：扫描链数量与长度是否符合测试机台限制；ATPG覆盖率是否达标（示例：固定故障覆盖率≥98%）。
• 物理阶段：DRC违例数是否为0；LVS是否完全匹配；时序签核在目标工艺角下WNS与TNS是否满足签核标准。

五、本节小结与实操起点

流片交付的本质是一条带反馈的收敛链路：RTL定义功能，综合把功能映射为门级结构，DFT让结构可测，布局布线把结构变成物理版图，物理验证与时序签核确认版图可制造且满足时序。Cadence工具链覆盖了这条链路的主要环节，但工具只是执行者，约束、库、规则文件才是决定结果正确性的前提。