第4章：芯片产品需求文档（PRD）撰写

PRD，说白了就是芯片的「出生证明」。

我见过太多项目，需求文档写得像天书，研发看不懂，测试没法测，最后流片回来一堆问题。嗯，今天我们就聊聊怎么把PRD写清楚、写到位。

4.1 PRD核心要素：功能、性能、功耗、面积

芯片PRD和软件PRD最大的区别在哪？

软件可以随时打补丁，芯片不行。一次流片几百万甚至上千万，错了就是真金白银打水漂。所以芯片PRD必须把四个核心要素说透：功能、性能、功耗、面积。业内常说的PPA（Performance, Power, Area），加上功能，就是完整的FPPA。

4.1.1 功能（Function）

功能描述要精确到每个接口、每个寄存器、每个状态机。

我个人习惯的做法是：先画系统框图，再画数据流图，最后写详细的接口时序。别嫌麻烦，这一步省了，后面全是坑。

功能描述清单（建议包含）：
  • 芯片顶层功能概述（一句话说清楚芯片是干嘛的）
  • 各模块功能分解（每个子模块负责什么）
  • 接口定义（协议类型、信号列表、时序要求）
  • 寄存器列表（地址、位宽、读写属性、默认值、功能描述）
  • 工作模式说明（正常模式、低功耗模式、测试模式等）
  • 异常处理机制（超时、错误、复位等场景）

我在项目中遇到过最典型的翻车案例：某个接口的时序图画错了，研发按图设计，测试按图验证，结果联调时发现根本对不上。最后查出来，是PRD里少画了一个时钟周期。所以我现在写接口时序，一定会让验证工程师和系统工程师一起评审。

4.1.2 性能（Performance）

性能指标必须可量化、可测试。别写「高性能」「低延迟」这种废话。

性能维度 示例描述（好） 示例描述（差）
工作频率 典型工作频率 500MHz，最高 600MHz 芯片速度很快
数据吞吐量 支持 10Gbps 线速转发，64字节小包不丢包 数据处理能力强
延迟 端到端延迟 ≤ 5μs（典型值） 延迟很低
并发能力 支持 1024 个并发会话 支持大量并发

你想想看，如果PRD里写「延迟很低」，研发怎么设计？测试怎么验收？最后只能扯皮。所以性能指标一定要写清楚：典型值、最大值、测试条件。

4.1.3 功耗（Power）

功耗现在越来越重要，尤其是IoT和移动设备芯片。

功耗指标要分场景写：

  • 工作功耗：典型工作场景下的功耗
  • 待机功耗：芯片空闲时的功耗
  • 峰值功耗：最恶劣情况下的功耗（用于电源设计）
  • 功耗模式：支持哪些低功耗模式，切换时间是多少
我的经验：功耗指标一定要留余量。我曾经做过一个项目，PRD写的峰值功耗是1W，结果流片回来实测1.2W。虽然只超了20%，但客户电源方案是按1W设计的，最后只能降频使用。从那以后，我写功耗指标都会加一句「含20%设计余量」。

4.1.4 面积（Area）

面积直接决定芯片成本。晶圆是按面积收费的，面积每大一点，成本就高一大截。

面积指标通常写：

  • 目标面积：比如 ≤ 25mm²
  • 面积分配：各模块预估面积占比
  • 工艺节点：比如 28nm HPC+
  • 封装形式：比如 BGA 256

这里有个坑要注意：PRD里的面积目标，一定要和工艺、性能、功耗做trade-off。你不可能在28nm工艺上，既要跑1GHz，又要功耗低于100mW，还要面积小于10mm²。这不科学。

4.2 PRD模板与最佳实践

说了这么多理论，直接上模板。这是我多年打磨出来的PRD结构，你可以直接套用。

4.2.1 PRD标准模板

# 芯片产品需求文档（PRD）

## 1. 文档信息
- 文档编号：PRD-2024-001
- 产品名称：XX智能感知芯片
- 版本号：V1.0
- 编写人：XXX
- 日期：2024-XX-XX

## 2. 产品概述
- 一句话描述
- 目标市场
- 竞品对标

## 3. 功能需求
- 系统框图
- 模块功能描述
- 接口定义
- 寄存器列表
- 工作模式

## 4. 性能需求
- 工作频率
- 吞吐量
- 延迟
- 并发能力

## 5. 功耗需求
- 工作功耗
- 待机功耗
- 峰值功耗
- 功耗模式

## 6. 面积需求
- 目标面积
- 面积分配
- 工艺节点
- 封装形式

## 7. 测试需求
- 测试策略
- 测试用例
- 测试覆盖率目标
- 测试硬件要求

## 8. 交付物清单
- GDSII文件
- 测试报告
- 应用笔记
- 参考设计

## 9. 风险评估
- 技术风险
- 进度风险
- 供应链风险

## 10. 版本历史
注意：模板只是骨架，真正有价值的是每个章节里的具体内容。别为了填模板而填模板，每个指标都要有依据、有来源。

4.2.2 最佳实践

写PRD这么多年，我总结了几条铁律：

  1. 需求必须有来源：每个需求都要写清楚「为什么」。是客户要求的？是竞品有的？还是你自己拍脑袋想的？
  2. 需求必须有优先级：P0（必须有）、P1（应该有）、P2（可以有）。研发资源有限，先做最重要的。
  3. 需求必须可验证：写清楚怎么测、用什么测、测到什么程度算通过。
  4. 需求必须评审：至少经过系统、研发、测试三方评审。
  5. 需求必须版本管理：改需求可以，但要走变更流程，别口头说改就改。

4.3 需求可量化与可测试性

这是PRD里最容易出问题的地方。

我见过最离谱的PRD，性能需求写的是「芯片处理能力要强」。什么叫强？强到什么程度？没法测，没法验收。

4.3.1 如何把需求写可量化

记住一个公式：指标 + 条件 + 容差。

不可量化写法 可量化写法
芯片功耗要低 典型工作场景下，芯片功耗 ≤ 500mW（含10%余量）
接口速度要快 SPI接口支持最高 50MHz 时钟频率，全双工模式
存储容量要大 片上SRAM容量 ≥ 512KB，支持ECC
启动时间要短 从复位释放到进入正常工作状态 ≤ 10ms

4.3.2 可测试性设计（DFT）

可测试性不是测试工程师一个人的事。PRD阶段就要考虑：

  • 测试点插入：关键信号是否拉出了测试点？
  • 扫描链设计：是否支持全扫描测试？覆盖率目标是多少？
  • BIST（内建自测试）：内存、逻辑是否支持BIST？
  • 边界扫描：是否支持JTAG边界扫描？
  • ATE测试：测试向量怎么生成？测试时间预算是多少？
避坑指南：我曾经做过一个项目，PRD里完全没提DFT需求。结果后端做测试插入时发现，有些关键节点根本没法加测试点，因为PRD里没留测试接口。最后只能改版，多花了两周时间。所以我现在写PRD，一定会单独列一节「可测试性需求」。

4.3.3 测试用例设计原则

好的PRD，应该让测试工程师看了就知道怎么测。

我建议在PRD里直接给出关键测试用例的框架：

测试用例编号：TC_FUNC_001
测试名称：SPI接口读写测试
测试目的：验证SPI接口功能正常
测试条件：芯片处于正常工作模式，SPI时钟频率50MHz
测试步骤：
1. 主机通过SPI写入0x55到寄存器0x00
2. 主机通过SPI读取寄存器0x00
3. 检查读取值是否为0x55
预期结果：读取值等于写入值
通过标准：连续测试1000次，无错误

你看，这样写出来，研发知道要设计什么，测试知道要测什么，评审时大家也能快速发现问题。

4.4 写在最后

PRD写得好不好，直接决定芯片项目能不能顺利推进。

我个人觉得，PRD不是写完了就完事的。它应该是一个活文档，随着项目推进不断更新。但核心原则不变：可量化、可测试、可追溯。

嗯，今天就聊到这。下一章我们聊聊需求评审和变更管理，那又是另一门学问了。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →