V-Model — Systems Engineering Methodology

The V-Model (Verification and Validation Model) is a systems engineering methodology where each development phase on the left side of the “V” has a directly corresponding testing and verification phase on the right side. It is the standard approach for safety-critical development in aerospace (DO-178C/DO-254), automotive (ISO 26262), defense, and industrial automation.

The V-Model Structure

Requirements ──────────────────── Acceptance Testing
    ↓                                      ↑
  System Design ──────────────── System Testing
      ↓                                  ↑
    Architecture Design ──── Integration Testing
        ↓                              ↑
      Detailed Design ──── Unit Testing
            ↓              ↑
         Implementation

Each left-side activity produces specifications, and the corresponding right-side activity verifies against those exact specifications — creating full traceability.

V-Model Phases

Left Side (Development)	Right Side (Verification)	Traceability
Requirements analysis	Acceptance testing	Every requirement has a pass/fail test
System design	System-level testing	System behavior validated against design
Architecture design	Integration testing	Module interfaces verified
Detailed design	Unit testing	Each component tested in isolation
Implementation	— (coding / fabrication)	—

Why V-Model for Hardware?

The V-Model is particularly suited for hardware development because:

Changes are expensive — Unlike software, hardware bugs discovered late can cost millions (ASIC respins, PCB re-layout, re-certification).
Traceability is mandatory — Safety standards (DO-254, ISO 26262) require complete traceability from requirements to verification evidence.
Early error detection — Each phase has explicit review gates that catch issues before they propagate.
Regulatory compliance — Certification authorities (EASA, FAA, TÜV) accept V-Model documentation as compliance evidence.

V-Model in FPGA Development

For FPGA projects following DO-254 or similar standards:

Phase	Activities	Deliverables
Requirements	Capture functional and performance requirements	Requirements specification (HRS)
Architecture	Partition into IP blocks, define interfaces, clock domains	Architecture document, ICDs
Detailed design	RTL microarchitecture, state machines, data paths	Detailed design document
Implementation	VHDL/SystemVerilog coding, synthesis, P&R	RTL source, netlist, bitstream
Unit testing	Block-level simulation, coverage analysis	Test reports, coverage database
Integration testing	Multi-block simulation, interface verification	Integration test report
System testing	Hardware-in-the-loop, environmental testing	System acceptance report
Acceptance	Customer acceptance, certification evidence	Compliance matrix

V-Model vs. Agile — Are They Compatible?

While Agile methodologies dominate software development, the V-Model remains essential for hardware because:

Factor	V-Model	Agile
Cost of iteration	High (physical prototypes, certification)	Low (software deployment)
Regulatory acceptance	Required by DO-254, ISO 26262	Not accepted for certification
Traceability	Built into the process	Requires additional tooling
Best for	Safety-critical hardware & firmware	Application software, UX iteration

Modern teams use a hybrid approach: V-Model for hardware and safety-critical firmware, Agile for application software and user interfaces.

Standards That Mandate V-Model

Standard	Domain	Scope
DO-254	Avionics hardware	FPGA and ASIC design for airborne systems
DO-178C	Avionics software	Flight-critical embedded software
ISO 26262	Automotive	Functional safety for road vehicles
IEC 61508	Industrial	General functional safety
EN 50128	Railway	Railway software safety
IEC 62443	Industrial cybersecurity	Secure development lifecycle

FPGA — Hardware devices developed following V-Model methodology.
RTL Design — The implementation phase of the V-Model for digital circuits.
PCB Design — Physical hardware design following V-Model review gates.

V-Model