IC 项目 Spec 规格书编写：九段式结构、逐段要点与可复制模板
芯片项目里最常见的一种浪费，不是 RTL 写错，而是「Spec 没写清」：架构师口头说了一遍，设计工程师按自己的理解写了三个星期，验证工程师又按第三种理解搭了 testbench，三方在 review 会上对不上，返工比重写还贵。Spec（设计规格书）就是用来消灭这种浪费的合同文档——它是架构、设计、验证、后端、软件五方之间唯一可信的事实来源。本文是 RTL 设计方法 与 芯片验证流程 的前置篇，回答「一份能落地执行的 IC Spec 到底长什么样」。
本文要回答的问题
- 一份合格的 IC 项目 Spec 应该包含哪几个章节，各自回答什么问题？
- 寄存器表、接口时序这些「重灾区」章节，写到什么粒度才算够？
- 评审 Spec 时最常见的几类缺陷（歧义、漏写、过度设计）长什么样，怎么在写作阶段就规避？
- 有没有一份可以直接复制、按项目裁剪的 Markdown 模板？
上面这张概念卡给出了全文的主线：九个章节不是并列的九块内容，而是沿着「给谁看 → 对外承诺什么 → 内部怎么做到 → 落地约束 → 怎么证明做对了」五个逻辑分区组织的。评审时只要按这五个分区问五个问题，就能快速定位 Spec 的短板在哪一层。
一、为什么 Spec 值得单独写、单独评审
先算一笔账。一个中等复杂度的 IP（比如一个 DMA 控制器），RTL 大约 8000 行，验证环境 15000 行，软件驱动 3000 行。如果 Spec 里「通道仲裁策略」只写了一句「支持优先级仲裁」，那么设计可能实现成固定优先级，验证按轮询（round-robin）建 scoreboard，驱动假设可以动态改优先级——三份产出各自自洽，但拼不到一起。这类分歧在 RTL 冻结后才发现，修复成本是 Spec 阶段改一行字的几十倍。
Spec 的另一个作用是冻结接口。SoC 集成团队需要根据你的接口定义提前做顶层集成和时序约束（详见 SDC 约束编写），软件团队需要根据寄存器表提前写驱动。Spec 晚交付一周，下游所有团队就晚开工一周。
因此 Spec 的生命周期应当是：评审通过 → 基线化（baseline）→ 之后任何修改走变更流程并通知所有干系人。评审通过之前，它只是一份草稿；基线化之后，它才是合同。
二、九段式总览：每章回答什么问题
这张分层图表达的核心观点是：九个章节之间有明确的依赖方向。概览层让读者建立边界感；契约层（接口 + 寄存器）是整个 Spec 里唯一对外冻结的部分，变动成本最高，所以要写得最细；实现层是对契约层的支撑，允许在开发过程中调整；约束层则是贯穿全程的验收标准。写 Spec 的顺序建议也按这个依赖走：先定契约，再写实现，最后补约束与验收。
各章节的写作对象与「写到什么粒度算够」可以浓缩成一张清单表：
| 章节 | 主要读者 | 核心内容 | 合格粒度判据 |
|---|---|---|---|
| 1 概述与范围 | 全体 | 目标、非目标、术语表、参考文档 | outsider 读完知道本模块做什么、不做什么 |
| 2 系统上下文 | 集成/软件 | SoC 顶层框图、本模块边界、上下游数据流 | 集成工程师能据此画顶层连线 |
| 3 功能特性清单 | 设计/验证 | 特性逐条编号（F-001 起），每条可测 | 每条特性能写出至少一条测试用例 |
| 4 接口规格 | 集成/验证 | 信号表、协议引用、握手时序图 | 验证能据此写 interface 与 monitor |
| 5 寄存器规格 | 软件/验证 | 地址映射、位域、复位值、访问属性 | 软件能据此写完整驱动头文件 |
| 6 微架构 | 设计 | 数据通路框图、FSM、流水线、关键算法 | 设计工程师无需再开会对齐方案 |
| 7 时序与性能 | 后端/设计 | 频率目标、关键路径预估、延迟/吞吐指标 | 后端能据此写 SDC 初稿 |
| 8 功耗与 DFT | 后端/测试 | 电源域、时钟门控、scan/MBIST 方案 | DFT 工程师能据此规划测试架构 |
| 9 验证计划与交付物 | 验证/项目经理 | 特性-验证映射、覆盖率目标、交付清单 | 项目经理能据此排验收里程碑 |
下面逐段展开要点与反例，其中第 4、5、9 三章是出错率最高的重灾区，给得详细一些。
三、契约层细写：接口与寄存器
接口规格（第 4 章）
接口章节的最低配置是一张信号表（信号名 / 方向 / 位宽 / 时钟域 / 复位值 / 一句话功能）加每个协议的时序图或协议标准引用。协议如果是标准总线（如 AXI4-Lite、APB），直接引用协议版本号并写清「不支持哪些可选特性」即可，不要照抄协议文档；自定义协议则必须给出完整时序图与背靠背（back-to-back）行为定义。握手类接口的设计细节可以对照 valid/ready 握手协议 的写法。
常见反例一：方向歧义。 信号表只写「irq：输出」，没写是哪个时钟域、是电平还是脉冲、清中断的条件是什么。软件按电平中断写了处理函数，硬件实现成单周期脉冲，系统联调时中断丢失。
常见反例二：复位行为缺失。 接口时序图只画了正常工作波形，没有画「复位释放后第一个传输从哪一拍开始算」。两边理解差一拍，CDC 检查也抓不出来（都在同一时钟域），只能上板翻车。
寄存器规格（第 5 章）
寄存器表是软件团队唯一关心的章节，也是需求变更最频繁的章节，建议直接用结构化表格维护（甚至用 IP-XACT / SystemRDL 这类机器可读格式生成），至少包含：地址偏移、寄存器名、位域、访问属性（RO/WO/RW/W1C）、复位值、描述。访问属性里的 W1C（写 1 清零）这类语义一定要写清「读修改写是否安全」——这是状态寄存器最常见的坑。
常见反例：复位值写 TBD。 规格冻结时还有十几个寄存器复位值标着「待定」，驱动作者只能自己猜；等 RTL 定下来再补，软件已经按错的复位值写了初始化流程。寄存器表的 TBD 数量应当作为 Spec 评审的硬性准出项——一个都不许有。
如果模块是总线从设备（如 AXI4-Lite slave），寄存器访问与总线事务的对应关系（读写在哪个握手沿生效、写未对齐地址的行为、访问保留地址的返回）也要逐条定义，可参考 AXI4-Lite Slave 设计 里的错误处理约定。
四、实现层与约束层：微架构、时序、功耗、DFT
微架构章节是写给设计工程师自己看的「施工图」，核心是数据通路框图与状态机。判据很简单：拿着这张图，另一个工程师能实现出行为一致的 RTL。反过来，如果图里的模块划分和 RTL 文件结构对不上，那就是两张皮，review 时必须打回。FSM 的写法注意给出完整的状态转移表（含非法状态的恢复行为），具体方法见 FSM 设计；带跨时钟域的模块必须列出所有 CDC 路径与同步方案，对照 CDC 基础。
时序与性能章节要给出三个数字：目标频率、关键路径预估、端到端延迟/吞吐。它们直接决定后端的约束策略（静态时序分析报告解读 是后续验收的手段）。功耗章节对应电源域划分、时钟门控策略与 UPF 意图（深入话题见 低功耗设计与 UPF）。DFT 章节写清 scan 链数量预估、MBIST 覆盖哪些存储器、是否要做边界扫描，验收侧由 DFT 可测试性设计 展开。
这两层的共同反例是「过度承诺」：在 Spec 阶段把内部实现写死到 LUT 级别，后面任何优化都算变更。实现层的正确粒度是「行为等价类」——写清必须满足的行为与性能，留出实现自由度。
五、验证计划与交付物：让验收可执行
第 9 章的关键是一张特性-验证映射表：第 3 章的每个特性编号（F-001…），对应验证侧用什么手段覆盖（定向用例 / 约束随机 / 断言 / 形式验证），覆盖目标是什么。这样验证计划不再是「跑够 100 万随机种子」这种不可验收的表述，而是逐条可勾选的清单。覆盖率目标的设定方法见 代码覆盖率与功能覆盖率。
交付物清单同样要可勾选：RTL 源码、lint waiver 报告（口径见 lint waiver 与 sign-off）、网表、UPF、寄存器头文件、用户手册——每项写明验收人。整个 Spec 只有写到这个程度，项目经理才能拿着它排里程碑，而不是拿着一份「原则上完成」的文档去催进度。
六、可复制的 Markdown 模板
把上面九段浓缩成一份骨架模板，新项目直接复制后逐项填空；凡是写不出内容的段落，就是需求还没想清的地方：
# <模块名> 设计规格书 v0.1 YYYY-MM-DD
## 1 概述与范围
- 目标：…… 非目标：……
- 术语表：| 缩写 | 全称 | 说明 |
## 2 系统上下文
- 顶层框图（图）；上下游模块与数据流
## 3 功能特性清单
| 编号 | 特性 | 优先级 | 验收方式 |
| F-001 | …… | P0 | 定向用例 |
## 4 接口规格
- 信号表：| 信号 | 方向 | 位宽 | 时钟域 | 复位值 | 说明 |
- 协议：引用标准+裁剪说明 / 自定义协议时序图
- 复位与异常行为：……
## 5 寄存器规格
| 偏移 | 名称 | 位域 | 属性 | 复位值 | 描述 |
（TBD 数量必须为 0 才能基线化）
## 6 微架构
- 数据通路框图；FSM 状态转移表；CDC 路径清单
## 7 时序与性能
- 目标频率 / 关键路径预估 / 延迟与吞吐指标
## 8 功耗与 DFT
- 电源域 / 时钟门控策略 / scan 与 MBIST 方案
## 9 验证计划与交付物
- 特性-验证映射表；覆盖率目标；交付物清单与验收人
## 变更记录
| 版本 | 日期 | 修改点 | 通知的干系人 |模板最后一行「变更记录」别删——基线化之后，这张表就是 Spec 可信度的来源，任何口头变更不落表，等于没有变更。
这一篇在知识体系里的位置
本文位于数字芯片设计知识体系中「设计入口」的位置：向上承接 芯片设计全流程 里的规格定义阶段，向下连接三条主线——设计主线（RTL 设计方法、RTL 编码风格）、验证主线（芯片验证流程、SystemVerilog Testbench 基础）、实现主线（逻辑综合、时序分析）。Spec 里写下的每一条契约，最终都会在这三条主线上变成可检查的产出物。
一句话总结
IC 项目 Spec 规格书编写的本质是签一份五方合同：用「概述、上下文、特性、接口、寄存器、微架构、时序性能、功耗 DFT、验证与交付」九段式把「给谁看、承诺什么、怎么做到、如何验收」写清，契约层（接口与寄存器）写到零 TBD、零歧义才算基线，基线之后一切变更走记录——Spec 的可信度，就是项目的可预测度。