3. 回归验证平台需求分析
回归验证平台不是先选工具再找用途，而是先把“要跑什么、跑多少、多久跑完、跑完看什么、谁来维护”讲清楚，再决定平台需要哪些能力。需求分析的核心，是把项目约束翻译成平台可执行的功能与非功能指标。若跳过这一步，平台往往会出现两种典型失败：一是功能过剩，做了大量无人使用的报表和调度能力；二是关键能力缺失，例如无法按覆盖率增量挑选用例，导致每晚回归只能全量重跑，验证周期被无限拉长。
一、四类输入约束：规模、周期、覆盖率、资源
需求分析的输入可以归纳为四个维度，它们彼此制约，必须一起看。
- 项目规模：RTL 代码行数、模块数量、验证环境（UVM/SystemVerilog/C 模型）数量、用例总数、编译单元数。规模决定平台需要支持多少并行任务、多少编译缓存、多少结果数据量。例如一个中等规模 SoC 项目可能有 40 个验证环境、8000 条用例、单次全量编译 25 分钟。
- 验证周期：从 RTL 冻结到流片签核的月数，以及每个回归轮次的允许时长。周期决定平台必须支持多快反馈。若签核前只有 6 周，且每晚只能跑 8 小时，则平台必须能在 8 小时内完成一轮有意义的回归，而不是 20 小时。
- 覆盖率目标：代码覆盖率、功能覆盖率、断言覆盖率的收敛目标与收敛曲线。目标决定平台必须支持覆盖率数据库合并、增量分析、覆盖率驱动的用例筛选，而不仅是“跑完即止”。
- 资源约束：可用计算节点数、单节点 CPU/内存、EDA 许可证数量与类型、存储容量、网络带宽、预算。资源决定并行度上限和调度策略。例如只有 200 个 VCS 许可证，却想同时跑 500 个仿真，调度器必须排队而不是盲目并发。
这四类约束不是并列的，而是相互换算的。项目规模与覆盖率目标决定“需要跑多少”，验证周期与资源约束决定“能跑多快”。平台需求就是在这两者之间找到可执行的平衡点。
二、把约束换算成可执行指标
需求分析不能停留在“支持并行”“支持覆盖率”这类口号，而要给出可验证的数字。以下是一组示例换算，用于说明方法，数值为合理假设，并非实测结果。
假设某 SoC 项目有 8000 条回归用例，单条用例平均仿真时间 6 分钟，可用计算节点 120 台，每台 16 核，VCS 许可证 200 个，每晚回归窗口 8 小时（480 分钟）。若每条用例占 1 个许可证、1 个核，则理论并行度为 min(120×16, 200) = 200。总机时需求为 8000×6 = 48000 分钟。在 200 并行下，理想墙钟时间为 48000/200 = 240 分钟，即 4 小时，看似满足 8 小时窗口。但实际还要扣除编译时间、排队抖动、失败重跑和覆盖率合并开销。若编译占 30 分钟、失败重跑占 15%、合并占 20 分钟，则实际约 240×1.15 + 30 + 20 = 326 分钟，仍小于 480 分钟，说明该配置可行。若用例数增长到 15000 条，则 15000×6/200 = 450 分钟，加上开销必然超窗，此时平台必须支持覆盖率增量筛选，只跑受本次 RTL 变更影响的用例，把每轮实际执行量压到 5000 条以内。
这个换算直接导出两条功能需求：第一，平台必须能根据代码变更和覆盖率数据库计算“受影响用例集”；第二，平台必须记录每条用例的历史通过状态与覆盖率贡献，否则无法做增量。同时导出非功能需求：调度器在 200 并发下的排队延迟必须可控，且许可证不足时要能降级排队而不是报错退出。
三、功能需求与非功能需求的边界
功能需求回答“平台能做什么”，非功能需求回答“做得多好”。两者必须成对出现，否则需求不可验收。例如“支持并行调度”是功能需求，但如果没有“在 200 并发下任务排队时间不超过 5 分钟”的非功能指标，就无法判断平台是否达标。再如“支持覆盖率合并”是功能需求，配套的非功能指标可以是“8000 条用例的覆盖率数据库合并时间不超过 15 分钟”，否则合并本身会成为新的瓶颈。
四、需求优先级与平台分期
资源约束通常不允许一次性实现全部需求，因此需要排优先级。建议按“阻塞回归执行 > 影响反馈速度 > 提升覆盖率收敛 > 改善使用体验”排序。第一优先级是能跑起来：用例管理、编译、调度、结果归档。第二优先级是跑得快：增量编译、并行优化、失败重试。第三优先级是跑得准：覆盖率合并、增量筛选、覆盖率驱动签核。第四优先级是跑得舒服：可视化报表、一键复现、权限与审计。
以某项目为例，第一期只做“提交触发 + 全量夜间回归 + 通过率报告”，先让团队每天有稳定回归结果；第二期加入编译缓存和许可证感知调度，把回归墙钟时间从 11 小时压到 7 小时；第三期加入覆盖率合并与增量筛选，把每轮执行用例从 8000 条降到 4500 条，同时保证覆盖率不下降。每一期都有明确的验收指标，而不是“功能做完就算完成”。
五、需求文档的最小结构
需求分析的交付物不必复杂，但必须可执行。建议至少包含以下字段，形成一份可评审的需求表：需求编号、需求描述、来源约束、类型（功能/非功能）、验收指标、优先级、依赖项。例如：
| 编号 | 需求描述 | 来源约束 | 类型 | 验收指标 | 优先级 |
|---|---|---|---|---|---|
| R-01 | 支持按模块/特性/优先级筛选用例 | 项目规模 | 功能 | 可按标签选出目标用例集并导出清单 | P0 |
| R-02 | 编译产物按环境缓存复用 | 验证周期 | 功能 | 未变更环境的编译时间≤2分钟 | P0 |
| R-03 | 许可证感知的并行调度 | 资源约束 | 功能 | 许可证耗尽时任务排队而非失败 | P0 |
| R-04 | 覆盖率数据库自动合并 | 覆盖率目标 | 功能 | 8000条用例合并≤15分钟 | P1 |
| R-05 | 基于变更的增量用例筛选 | 验证周期+规模 | 功能 | 每轮执行量≤5000条且覆盖率不降 | P1 |
| R-06 | 回归墙钟时间可控 | 验证周期 | 非功能 | 目标回归集在8小时内完成 | P0 |
| R-07 | 调度器故障可恢复 | 资源约束 | 非功能 | 重启后未完成任务自动重新入队 | P1 |
这张表的价值在于：它把“项目规模、验证周期、覆盖率目标、资源约束”四个输入，逐条映射为可验收的平台能力。评审时不再争论“要不要做”，而是检查每条需求是否有来源、有指标、有优先级。后续平台建设、工具选型和验收测试，都以此表为基准。需求分析做得越扎实，平台建设阶段返工越少，回归验证才能真正成为签核的可信依据。