test-design-policy

Derive RTL test cases from microarchitecture specs using equivalence partitioning and boundary value analysis.

43|9|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/babyworm/rtl-agent-team --skill test-design-policy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-design-policy
Source: https://github.com/babyworm/rtl-agent-team/tree/main/skills/test-design-policy
Command: npx skills add https://github.com/babyworm/rtl-agent-team --skill test-design-policy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Codifies a repeatable methodology for deriving comprehensive RTL test cases from microarchitecture and interface specifications so verification teams avoid ad-hoc vector sets and achieve measurable coverage goals.

Core Features & Use Cases

  • Equivalence Class Partitioning (ECP): identify valid and invalid input classes and select representative values for input domains.
  • Boundary Value Analysis (BVA): enumerate boundary and corner values for signed/unsigned integers, addresses, and counters to catch off-by-one and overflow conditions.
  • State Transition & Decision Table Testing: extract FSM transitions for mandatory transition coverage and build decision tables for multi-boolean control logic.
  • Use Case: produce a prioritized test plan for a new IP block by merging ECP, BVA, FSM transitions and decision-table rows into a coverage-mapped test vector set.

Quick Start

Derive a prioritized RTL test plan by applying equivalence partitioning and boundary value analysis to each input, extracting state transitions from FSMs, and mapping generated vectors to coverage goals.

Frequently Asked Questions about test-design-policy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I derive RTL test cases from microarchitecture specifications?

RTL test cases are derived from microarchitecture specifications by applying equivalence partitioning, boundary value analysis, state transition, and decision table techniques to generate a coverage-mapped test vector set.

What is the best way to apply boundary value analysis to RTL verification?

Boundary value analysis for RTL verification enumerates boundary and corner values for signed and unsigned integers, addresses, and counters to catch off-by-one and overflow conditions in test vectors.

How do I extract FSM state transitions for RTL test planning?

FSM state transitions for RTL test planning are extracted from microarchitecture specifications to ensure mandatory transition coverage and build decision tables for multi-boolean control logic.

Can I use equivalence partitioning for both datapath and control module verification?

Equivalence partitioning applies to both datapath and control module verification by identifying valid and invalid input classes to select representative values for input domains across different module types.

Do I need an io definition and uarch spec to generate a coverage-driven test plan?

An io definition and uarch spec are required to generate a coverage-driven test plan, as they provide the necessary input domains, state machines, and control logic for systematic test vector derivation.

Why does ad-hoc RTL test generation fail to achieve measurable coverage goals?

Ad-hoc RTL test generation fails to achieve measurable coverage goals because it lacks systematic techniques like equivalence partitioning and boundary value analysis, resulting in incomplete vector sets for verification planning.