2、需求分析与规格提取：如何阅读设计规格书、提取验证需求、需求优先级划分、需求可追溯性矩阵

好，咱们进入第二章。这一章讲的是验证的起点——需求分析。说白了，就是拿到一份设计规格书，你怎么把它变成能执行的验证计划。

我见过不少新人，上来就写testbench、搭UVM环境，结果做到一半发现漏了关键功能。为什么？因为规格书没读透。你想想看，地基没打好，房子能稳吗？

2.1 如何阅读设计规格书

设计规格书（Design Specification）是验证的圣经。但很多人把它当小说看，从头翻到尾就完了。我个人习惯是带着问题去读。

第一步：先看架构图

别急着看细节。先搞清楚这个模块的输入输出是什么，数据流怎么走。我一般会拿张白纸，把架构图手画一遍。画着画着，你就知道哪些接口需要关注了。

第二步：找功能列表

规格书里通常有个章节叫"Feature List"或"功能描述"。这里列出来的每一条，都是潜在的验证点。我会用荧光笔标出来，然后编号。

第三步：抠时序图

嗯，这里要注意。时序图是验证最容易翻车的地方。我曾经在一个项目中，规格书里时序图画得模棱两可，结果验证环境搭完了才发现握手信号少了一个周期。后来我养成了习惯——每张时序图都自己重新画一遍，标注清楚每个信号的跳变时刻。

2.2 提取验证需求

规格书读完了，接下来就是提取验证需求。这一步是把"设计要做什么"翻译成"验证要测什么"。

验证需求的分类：

• 功能需求： 模块必须实现的功能。比如"FIFO满时不能写入"。
• 时序需求： 信号之间的时序关系。比如"读使能信号必须在时钟上升沿前5ns稳定"。
• 性能需求： 吞吐量、延迟等。比如"每秒处理100万笔交易"。
• 异常处理需求： 错误情况下的行为。比如"CRC校验失败时，输出错误标志并重传"。
• 边界条件需求： 极限情况。比如"FIFO深度为1024时，写入1025个数据会怎样"。

我建议你用一个表格来整理这些需求。格式可以这样：

需求ID	需求描述	需求类型	来源章节
REQ-001	FIFO满时，写操作被忽略	功能	3.2.1
REQ-002	读使能到数据输出延迟不超过2个时钟周期	时序	4.1.3
REQ-003	CRC校验失败时，输出ERR信号并重传	异常	5.2

2.3 需求优先级划分

需求提取完了，你会发现——太多了！不可能全部验证完，尤其是时间紧的时候。所以必须排优先级。

我个人习惯用P0/P1/P2/P3四级划分：

• P0（致命）： 不验证芯片无法工作。比如时钟复位、基本读写通路。
• P1（重要）： 核心功能，但存在workaround。比如某个特殊模式。
• P2（一般）： 次要功能，可以后期补测。比如调试接口。
• P3（可选）： 锦上添花的功能。比如性能优化选项。

我曾经在一个项目中，项目经理要求所有需求都达到P0。我直接告诉他：那项目得延期半年。后来我们坐下来，把需求过了一遍，发现真正P0的只有40%。剩下的P1和P2，我们用随机测试覆盖了一部分，P3直接砍掉了。结果芯片一次流片成功。

2.4 需求可追溯性矩阵

需求可追溯性矩阵（Requirements Traceability Matrix，RTM），听起来很高大上，说白了就是一张表——把需求、测试用例、验证结果串起来。

为什么要做这个？三个原因：

1. 覆盖率分析： 一眼看出哪些需求还没测到。
2. 回归测试： 设计改了，知道哪些用例需要重跑。
3. 审计需要： 客户或质量部门要查，你能拿出证据。

RTM的典型格式：

需求ID	优先级	测试用例ID	验证状态	备注
REQ-001	P0	TC_FIFO_FULL_001	通过
REQ-002	P1	TC_FIFO_LATENCY_001	失败	时序不满足，已报bug
REQ-003	P2	未分配	未验证	待排期

你想想看，如果没有这个矩阵，你怎么知道哪些需求测了、哪些没测？靠脑子记？不现实。我见过一个团队，验证做了三个月，最后发现有一个P0需求完全没测到——因为规格书更新了，但验证计划没同步。这就是没有RTM的代价。

好了，这一章就到这里。记住：需求分析花的时间越多，后面验证踩的坑越少。下一章我们讲验证策略的制定，到时候会用到今天提取的需求列表。