rtl-specification-consistency-checker

name rtl-specification-consistency-checker description Check behavioral consistency between high-level hardware specifications and RTL implementations. Use when asked to check RTL consistency, verify RTL against spec, check hardware specification compliance, validate RTL implementation, find spec violations in RTL, check behavioral consistency, or when working with hardware designs that need verification against protocol specifications, timing requirements, or functional specifications in Verilog, VHDL, or SystemVerilog. RTL-Specification Consistency Checker Overview This skill enables systematic checking of behavioral consistency between high-level hardware specifications and RTL implementations. It extracts requirements from specifications, maps them to RTL logic, and classifies each requirement as satisfied, violated, underspecified, or uncheckable. Consistency Checking Workflow Follow this sequential process to check RTL-specification consistency: 1. Parse and Understand Inputs Read and analyze both the specification and RTL code: Specification Analysis: Identify the format (natural language, tables, timing diagrams, protocol rules) Extract all behavioral requirements Note any assumptions or constraints Identify ambiguous or incomplete sections RTL Analysis: Identify the HDL language (Verilog, VHDL, SystemVerilog) Locate key modules and their interfaces Identify state machines, registers, and control logic Note clock domains and reset strategies 2. Extract Behavioral Requirements Formalize each requirement from the specification: Requirement Types: Functional Requirements: Input-output relationships State transitions Data transformations Protocol sequences Timing Requirements: Setup/hold times Latency constraints Throughput requirements Clock cycle counts Safety Properties: Invariants that must always hold Forbidden states or transitions Mutual exclusion constraints Data integrity conditions Liveness Properties: Progress guarantees Eventual responses Fairness conditions For each requirement, document: Requirement ID Description in natural language Formalized property (if possible) Source location in specification Priority/criticality 3. Map Requirements to RTL Identify RTL constructs corresponding to each requirement: Signal Mapping: Map specification signals to RTL signals Identify relevant registers and wires Note signal widths and types Logic Mapping: Identify modules implementing each requirement Locate state machines and control logic Find combinational and sequential logic blocks Note line numbers and code locations State Mapping: Map specification states to RTL state encodings Identify state registers and transition logic Document state machine structure 4. Check Consistency For each requirement, verify RTL behavior: Verification Methods: Static Analysis: Check signal connectivity Verify state machine completeness Analyze control flow paths Check for missing cases or conditions Trace Analysis: Construct example execution traces Check if traces satisfy requirements Look for counterexamples Verify timing constraints Pattern Matching: Compare RTL patterns against specification patterns Check for common implementation errors Verify protocol compliance 5. Classify Requirements Assign each requirement to one of four categories: ✅ Satisfied: RTL correctly implements the requirement All test cases pass No violations found ❌ Violated: RTL behavior contradicts the requirement Counterexample exists Clear mismatch identified ⚠️ Underspecified: Specification is ambiguous or incomplete Multiple valid interpretations exist Missing details prevent verification ❓ Uncheckable: Missing environmental assumptions Depends on external components Requires information not provided 6. Document Violations For each violated requirement, provide detailed analysis: Violation Report Structure: Requirement ID: REQ-XXX Status: ❌ VIOLATED Description: [What the requirement specifies] RTL Location: Module: [module_name] File: [file_path] Lines: [line_numbers] Mismatch Explanation: [Clear explanation of how RTL differs from spec] Example Trace: Cycle | Signal1 | Signal2 | State | Expected | Actual ------|---------|---------|-------|----------|------- 0 | 0 | 1 | IDLE | IDLE | IDLE 1 | 1 | 1 | IDLE | BUSY | IDLE <- Violation 2 | 1 | 0 | IDLE | DONE | IDLE Root Cause: [Analysis of why the violation occurs] Suggested Fix: [Proposed correction to RTL] 7. Generate Consistency Report Produce a structured report with all findings: Report Structure Executive Summary Total Requirements: X ✅ Satisfied: Y (Z%) ❌ Violated: A (B%) ⚠️ Underspecified: C (D%) ❓ Uncheckable: E (F%) Critical Violations: G Detailed Findings For each requirement, include: REQ-001: [Requirement Name] Status: [✅/❌/⚠️/❓] Priority: [High/Medium/Low] Category: [Functional/Timing/Safety/Liveness] Specification: [Requirement description from spec] RTL Mapping: Module: [module_name] Signals: [signal_list] Lines: [line_numbers] Analysis: [Detailed consistency check results] [If violated] Violation Details: [Explanation, trace, root cause, suggested fix] [If underspecified] Clarification Needed: [What information is missing or ambiguous] [If uncheckable] Missing Assumptions: [What additional information is required] Recommendations Specification Improvements: [List of specification clarifications needed] RTL Fixes: [List of required RTL corrections] Verification Suggestions: [Additional checks or formal verification recommendations] Common Verification Patterns Protocol Compliance Specification Pattern: "When valid is asserted, data must remain stable until ready is asserted" RTL Check: // Look for: always @(posedge clk) begin if (valid && !ready) begin // data should not change assert(data == $past(data)); end end Violation Example: Data changes while valid=1 and ready=0 State Machine Verification Specification Pattern: "System must transition from IDLE to BUSY when start signal is asserted" RTL Check: // Look for: case (state) IDLE: if (start) next_state = BUSY; // Check if this transition exists endcase Violation Example: Missing transition or wrong next state Timing Constraints Specification Pattern: "Output must be valid within 3 clock cycles of input" RTL Check: Trace signal propagation through pipeline Count register stages Verify latency matches specification Violation Example: Output appears after 4 cycles instead of 3 Reset Behavior Specification Pattern: "All registers must reset to known values" RTL Check: // Look for: always @(posedge clk or negedge rst_n) begin if (!rst_n) begin // Check all registers have reset values end end Violation Example: Register missing from reset logic HDL-Specific Considerations Verilog/SystemVerilog Key Checks: Blocking vs non-blocking assignments Sensitivity list completeness Latch inference (unintended) Race conditions in always blocks X-propagation issues Common Patterns: // State machine always @(posedge clk) begin state <= next_state; end // Combinational logic always @(*) begin case (state) // Check all states covered endcase end VHDL Key Checks: Process sensitivity lists Signal vs variable usage Incomplete case statements Uninitialized signals Clock edge detection Common Patterns: -- Sequential process process(clk, rst) begin if rst = '1' then -- Reset logic elsif rising_edge(clk) then -- State updates end if; end process; Tips for Effective Checking Start with critical requirements : Focus on safety-critical and high-priority items first Use concrete examples : Create specific test scenarios for each requirement Check edge cases : Verify boundary conditions and corner cases Trace signal flow : Follow signals through the design hierarchy Verify completeness : Ensure all specification requirements are addressed Check for unintended behavior : Look for RTL functionality not in spec Document assumptions : Make all implicit assumptions explicit Suggest improvements : Recommend specification or RTL enhancements Reference Materials For detailed HDL syntax and common patterns: See references/hdl_patterns.md for HDL-specific verification patterns See references/common_violations.md for typical spec-RTL mismatches