verification-testpoint

name	verification-testpoint
description	"verification_workflow 流水线的第 2 步。将验证目标（来自第 1 步）分解为完整的、按类别划分的测试点列表——回答"需要验证什么"，而不关心"怎么验证"。测试点来源包括：Spec 显式要求、隐式推断、行业/协议规范、历史教训。触发条件：由 verification_workflow 在第 2 步调用，或用户直接需要为某个 IP/模块分解测试点时触发。"

测试点分解（第 2 步）

概述

本 skill 是 verification_workflow 流水线的第 2 步。

目标：将所有验证目标分解为完整的、按类别划分的具体测试点列表——每条测试点回答的问题是："需要验证哪个具体行为或属性？"

关键约束：本 skill 只输出验证什么，而不涉及如何验证。

• ✅ "验证当 FIFO 计数达到最大深度时，full 标志正确拉高。"
• ❌ "编写一个定向测试用例将 FIFO 填满到最大深度。" ← 这属于策略层（第 3 步）。

输入：

• DUT Spec 文档
• RTL 源代码
• verification-targets.md（来自第 1 步的输出）

输出：verification-testpoints.md —— 编号、分类的测试点列表

---

测试点来源

从以下四个来源中提取测试点，一条也不能遗漏。

来源 1：Spec 中的显式要求

逐节阅读 Spec，提取所有明确陈述的要求：

• "该模块应（SHALL）……"
• "当信号 X 拉高时，输出 Y 必须（MUST）……"
• Spec 中的任何真值表、状态转移表、时序图

规则：每条独立需求 → 至少一条测试点。

来源 2：隐式推断

超越文字，对每个 feature 追问：

• 复位时发生什么？每个输出的复位值是什么？
• 边界条件下会怎样？（最小值、最大值、全零、全一）
• 多个事件同时发生时会怎样？
• 传输过程中背压（back-pressure）拉高会怎样？
• 满负载 / 压力场景下会怎样？
• 是否存在 FIFO 溢出 / 下溢场景？
• 是否存在流水线 flush / bubble 场景？
• 从激励到响应的延迟是多少？

规则：每个不显而易见的隐式行为 → 一条测试点。

来源 3：行业 / 协议规范

若 DUT 实现了标准接口或协议（AXI、AHB、APB、PCIe、USB、I2C、SPI 等），需包含以下测试点：

• 协议握手正确性（例如 VALID/READY 配对）
• 乱序响应（若协议支持）
• 错误响应码
• Burst 行为（若适用）
• 空闲 / 背靠背传输切换
• 协议强制约束（例如 AXI：AWVALID 不能依赖 RREADY）

规则：引用相关标准；对每条强制合规要求添加测试点。

来源 4：历史教训

针对此类 IP 类型，应用已知常见故障模式：

• 计数器、指针、深度计算中的差一错误（off-by-one）
• 跨时钟域（CDC）：缺少同步器、同步级数错误
• 复位同步问题（异步复位主张、同步去主张）
• 流水线 flush 后残留的旧数据
• 仲裁器中的优先级反转
• 集成不匹配（数据宽度错误、字节顺序、位端序）
• 上电状态机无法正确到达 IDLE 状态

规则：对每条适用于本 DUT 类型的历史教训，添加一条测试点。

---

测试点分类

每条测试点归入以下分类之一：

类别标签	覆盖内容
[FUNC]	来自 Spec 的核心功能行为
[INTF]	接口协议合规性（AXI、APB、自定义总线等）
[CLK_RST]	时钟 / 复位行为、同步器正确性
[CORNER]	边界/极端条件及隐式边缘行为
[PERF]	性能：吞吐量、延迟、带宽（仅当存在性能验证目标时）
[LOW_PWR]	Power gating、clock gating、retention 行为
[SAFETY]	错误注入、ECC 奇偶校验、故障检测
[INTEG]	集成 / 连通性（来源于连通性验证目标）

---

完备性检查清单

在最终输出之前，逐项过一遍以下检查清单：

• verification-targets.md 中的每条功能目标至少对应一条测试点
• RTL 中每个子模块的接口至少有一条接口测试点
• 所有寄存器输出的复位状态均有对应测试点
• Spec 中所有状态机跳转都有对应测试点
• 所有边界条件（最小值、最大值、全零、全一）已覆盖
• 所有并发/同时发生的事件场景均已列出
• 与本 IP 类型相关的历史故障模式已处理
• 所有性能目标（若有）均有可量化的测试点及判定标准

---

输出格式

生成 verification-testpoints.md，结构如下：

# 验证测试点 — <DUT 名称>

## 摘要
测试点总数：<N>
各类别分布：FUNC(<n>)、INTF(<n>)、CLK_RST(<n>)、CORNER(<n>)、PERF(<n>)、LOW_PWR(<n>)、SAFETY(<n>)、INTEG(<n>)

## 测试点列表

### 功能类 [FUNC]

| ID | 测试点描述 | 来源 | 关联目标 |
|----|-----------|------|----------|
| TP-FUNC-001 | <需要验证什么> | Spec §<章节> | FT-001 |
| TP-FUNC-002 | <需要验证什么> | 隐式推断 | FT-001 |
...

### 接口类 [INTF]

| ID | 测试点描述 | 来源 | 关联目标 |
|----|-----------|------|----------|
| TP-INTF-001 | <需要验证什么> | AXI4 规范 §... | FT-002 |
...

### 时钟/复位类 [CLK_RST]
...

### 极端条件类 [CORNER]
...

### 性能类 [PERF]
...

### 低功耗类 [LOW_PWR]
...

### 功能安全类 [SAFETY]
...

### 集成类 [INTEG]
...

---

输出交接

本步骤完成后：

1. 向用户展示测试点汇总表供审阅。
2. 询问："是否需要增加、删除或修改任何测试点？是否有来自历史流片的已知故障模式需要补充？"
3. 确认后，保存为 verification-testpoints.md。
4. 告知工作流编排器（或用户）：第 2 步已完成，可进入第 3 步（verification-strategy）。