第二章：需求分析与规格定义
说实话，很多刚入行的朋友觉得这章“虚”。不就是看文档、写文档嘛，有啥技术含量？
但我得说句大实话：芯片设计里百分之八十的坑，都是需求没对齐埋下的。我见过太多项目，流片回来发现功能不对，一查，原来是PRD里某个脚位定义理解错了。嗯，那种感觉，比加班还难受。
2.1 读懂产品需求文档（PRD）
PRD是谁写的？通常是产品经理。但产品经理懂芯片吗？不一定。他们懂市场、懂用户，但未必懂你的时序收敛和面积优化。
所以，我们工程师读PRD，不能“照单全收”。你得学会翻译。
核心原则：把“产品语言”翻译成“芯片语言”。
举个例子，PRD里写：“设备需要支持快速启动，从按下按键到画面显示不超过0.5秒。” 产品经理觉得这很清晰。但作为IC工程师，你要问自己：
- 这个“快速启动”是上电复位时间？还是从休眠唤醒的时间？
- 0.5秒是包含外部DDR初始化？还是只算内部逻辑？
- 有没有温度变化下的时序余量？
你看，一个简单的需求，背后全是细节。我个人习惯，拿到PRD第一件事，就是拿红笔圈出所有“模糊词”。比如“快速”、“高可靠性”、“低功耗”——这些词在芯片规格书里必须变成具体数字。
避坑指南：我曾经接手过一个项目，PRD里写“支持多种显示分辨率”。结果流片回来发现，我们只做了固定分辨率下的时序优化，换分辨率就得重新配置PLL。产品经理说“多种”是指三种，我们理解成两种。嗯，从那以后，我要求PRD里每个“多种”后面必须跟具体列表。
2.2 撰写芯片规格书（Spec）
Spec是芯片的“宪法”。所有设计、验证、后端，都得按这个来。写Spec，说白了就是给PRD里的每个需求，定一个可测量、可验证的指标。
我一般把Spec分成几个部分：
- 功能列表（Feature List）：芯片能干什么，不能干什么。
- 性能指标（Performance Metrics）：频率、功耗、面积、延迟等。
- 接口定义（Interface Definition）：管脚、协议、时序图。
- 工作条件（Operating Conditions）：电压、温度、工艺角。
这里我重点说说功能列表与性能指标的权衡。你想想看，芯片设计本质上就是一场“三角博弈”：
说白了，功能越多，性能越高，成本就越贵。你不可能既要马儿跑，又要马儿不吃草。写Spec的过程，就是不断做选择题的过程。
2.3 功能列表与性能指标的权衡
我举个例子。假设PRD要求芯片支持“高清视频解码”，同时“功耗低于100mW”。
你作为架构师，得算一笔账：
- 如果做纯硬件解码器，面积大、功耗高，但性能好。
- 如果做软硬协同，面积小、功耗低，但需要外挂DDR，延迟大。
怎么选？没有标准答案。但我个人的经验是：先做最坏情况分析。假设所有模块同时工作，功耗会不会超标？如果超标，就得砍功能，或者降性能。
注意：千万不要在Spec里写“典型功耗”而不写“最大功耗”。我见过一个项目，Spec里写典型功耗80mW，结果客户在高温下跑全速，功耗飙到150mW，直接退货。嗯，从那以后，我要求Spec里必须有三组数据：典型、最大、最小。
下面是一个我常用的Spec表格模板，你可以参考：
| 参数 | 最小值 | 典型值 | 最大值 | 单位 | 备注 |
|---|---|---|---|---|---|
| 工作频率 | 10 | 200 | 250 | MHz | SS工艺角下保证 |
| 核心电压 | 0.9 | 1.0 | 1.1 | V | 含10%纹波 |
| 静态功耗 | - | 5 | 10 | mW | 125°C下 |
| 动态功耗 | - | 50 | 80 | mW | 全速运行 |
| 启动时间 | - | 200 | 500 | ms | 从休眠唤醒 |
你看，每个指标都有明确的边界。这样验证团队才知道怎么测，后端团队才知道怎么约束。
2.4 需求变更管理
说到这个我就来气。项目做到一半，产品经理跑过来说：“哎呀，客户又提了个新需求，加个功能呗。” 你怎么办？
我的原则是：可以加，但必须砍掉同等复杂度的功能。芯片不是软件，不能OTA升级。你加一个功能，可能意味着面积增加10%，功耗增加5%，时序收敛难度翻倍。
避坑指南：我曾经在一个项目里，被产品经理说服加了“硬件JPEG解码”。结果面积超标，不得不砍掉另一个模块。最后流片回来，JPEG解码有bug，砍掉的模块客户又急着要。嗯，从那以后，我要求所有需求变更必须走ECR（工程变更请求）流程，并且要有架构师签字。
2.5 本章小结
需求分析与规格定义，说白了就是“把话说清楚”。
- PRD是“想要什么”，Spec是“能做什么”。
- 功能、性能、成本，三者只能取其二。
- 所有指标必须可测量、可验证。
- 需求变更必须走流程，不能拍脑袋。
记住一句话：Spec里多写一行，流片后少加一个班。