2. 产品需求与规格定义（PRD/Spec）里程碑：需求收集、可行性分析、规格文档评审
说实话，这个阶段是整个芯片项目最容易被低估的环节。很多人觉得写写文档嘛，能有多难？但我见过太多项目，就是因为这个阶段没做好，后面流片回来发现功能对不上，或者性能差一截，最后只能改版重来。那代价，啧啧，几百万美金打水漂都是轻的。
我个人习惯把PRD/Spec阶段看作项目的「宪法制定」。你想想看，一部宪法要是写得模棱两可，后面所有的法律、执行都会乱套。芯片也是一样，Spec写不清楚，设计、验证、后端全都会跑偏。
2.1 需求收集——别只听客户说什么
需求收集听起来简单，不就是问客户要什么吗？但我在项目中遇到过好几次，客户说「我要一个高性能的AI加速芯片」，结果一细问，他对「高性能」的理解是10TOPS，而我们的定义是50TOPS起步。你看，同一个词，理解完全不同。
所以我的做法是：
- 分层收集：从市场、产品、系统、芯片四个层面去挖需求
- 量化表达：所有需求必须带数字，比如「功耗低于5W」而不是「低功耗」
- 场景驱动：让客户画出使用场景图，而不是只给文字描述
2.2 可行性分析——别拍脑袋
需求收集完了，下一步就是可行性分析。这一步说白了就是回答三个问题：能不能做？要花多少钱？多久能搞定？
我见过最离谱的项目，销售拍胸脯说「这个功能很简单，一个月就能加上」，结果架构师一看，需要改整个总线结构，至少三个月。嗯，后来那个项目延期了半年。
可行性分析我一般分三块来看：
- 技术可行性：现有IP能不能复用？新功能有没有成熟方案？
- 成本可行性：芯片面积、工艺节点、封装形式，这些直接决定BOM成本
- 时间可行性：按照现有团队规模和能力，能不能在deadline前完成
2.3 规格文档评审——最容易被敷衍的环节
规格文档评审，说白了就是一群人坐在一起，把Spec从头到尾过一遍。但很多团队把这个环节做成了「走过场」——文档发出去，大家回几个comment，然后就过了。
我曾经吃过这个亏。有一次我们做一款通信芯片，Spec里写「支持PCIe Gen3」，评审时没人提问题。结果到验证阶段才发现，我们对「支持」的理解是「能跑通基本功能」，而客户要求的是「全速率、全协议栈兼容」。最后只能紧急改设计，加班加点了两个月。
所以我现在对评审的要求很明确：
| 评审维度 | 检查要点 | 常见问题 |
|---|---|---|
| 功能完整性 | 所有feature是否都有对应描述 | 遗漏边界情况、异常处理 |
| 性能指标 | 是否所有指标都量化了 | 用「高性能」「低功耗」等模糊词 |
| 接口定义 | 时序、协议、电气特性是否明确 | 遗漏时序约束或协议版本 |
| 可测试性 | 是否考虑了DFT和测试覆盖 | 没有测试模式或测试点 |
| 兼容性 | 是否考虑了前后向兼容 | 忽略旧版本兼容需求 |
2.4 知识体系框架
下面这张图是我自己总结的PRD/Spec阶段的核心逻辑。你看，整个流程其实是一个闭环：从需求出发，经过可行性分析，形成Spec，再通过评审反馈回去修正需求。
2.5 一些实在的建议
最后，我分享几个这些年总结出来的实操经验：
- 文档要「可执行」：Spec不是写给别人看的，是给设计、验证、测试团队用的。每个描述都要能直接转化为测试用例。
- 评审要有「否决权」：评审不是走过场，要有明确的「通过/不通过」标准。我见过最好的做法是：评审不通过，项目不能进入下一阶段。
- 版本控制要严格：Spec一旦基线化，任何修改都要走变更流程。别让设计师拿着V1.0的文档，验证团队却在看V2.3。
嗯，PRD/Spec阶段说难不难，说简单也不简单。关键就一句话：前期多花一分功夫，后期少花十分代价。这个道理，做芯片的人都懂，但真正能做到的，不多。
公众号:蓝海资料掘金营，微信deep3321