Choosing the Methodology Mix

No single methodology wins

Each verification methodology has a sweet spot, and a senior engineer assigns methodologies per feature class , not per project. Constrained-random is the workhorse for state-rich datapaths; formal proves small, deep properties exhaustively; directed tests nail bring-up and specific scenarios; emulation buys raw cycles for software and long-running scenarios.

METHODOLOGY DECISION MATRIX

  Feature class            │ Directed │ Random  │ Formal  │ Emulation
  ─────────────────────────┼──────────┼─────────┼─────────┼──────────
  Bring-up / smoke         │   ●●●    │    ○    │    ○    │    ○
  Datapath w/ many states  │    ○     │   ●●●   │    ○    │    ●
  Arbitration fairness     │    ○     │   ●●    │   ●●●   │    ○
  CDC handshakes           │    ○     │    ●    │   ●●●   │    ○
  FIFO/counter properties  │    ●     │   ●●    │   ●●●   │    ○
  Register access          │   ●●     │   ●●    │    ●    │    ○
  Error injection          │   ●●●    │   ●●    │    ●    │    ○
  Performance / QoS        │    ○     │   ●●    │    ○    │   ●●●
  SW boot / long scenarios │    ○     │    ○    │    ○    │   ●●●

  ●●● primary   ●● strong   ● useful   ○ poor fit

  Rule of thumb: formal where state is deep but logic is small;
  random where the input space is wide; directed where the
  scenario is exact; emulation where you need millions of cycles.

Why each fits where it fits

• Directed — exact control, fast to write, zero discovery power. Use for bring-up, spec-mandated sequences, and bug reproduction.

• Constrained-random — discovers scenarios you did not think of, but needs a scoreboard and coverage to mean anything. Use for wide input spaces.

• Formal — exhaustive over all inputs, but capacity-limited (state explosion). Use for handshakes, arbiters, FIFO control, CDC protocols.

• Emulation — MHz instead of kHz, but poor visibility and expensive debug. Use for software bring-up and performance scenarios random sim cannot reach.

Block vs subsystem vs top — who verifies what

The same feature should be verified once, at the cheapest level that can see it . Block-level testbenches have full controllability and observability — exhaustive corner work lives there. Top-level testbenches are slow and clumsy — they verify integration (connectivity, address decode, cross-block flows), not block internals.

LEVEL RESPONSIBILITIES

  BLOCK level (this course's FIFO capstone)
    - All corner cases: full/empty boundaries, reset mid-traffic
    - Full constrained-random with per-block coverage closure
    - Bound assertion modules on internal signals
    └─ cheapest debug, fastest sims, full control

  SUBSYSTEM level (e.g. memory controller + arbiter + FIFOs)
    - Inter-block protocols, backpressure propagation
    - Realistic traffic patterns block TBs cannot generate
    - Re-uses block agents in passive/monitor mode

  TOP level (full chip)
    - Connectivity, address map, clocks/resets/power
    - End-to-end flows: DMA writes memory, CPU reads it
    - NOT the place to chase a FIFO boundary bug
    └─ slowest sims, debug costs 10x block level

Reuse strategy — write once, run everywhere

Reuse is planned, not hoped for. Monitors, scoreboards, assertion modules, and coverage written at block level should run unmodified at subsystem and top level in passive mode — they keep checking even when the block TB's drivers are gone. This is why checkers must never depend on driver-side knowledge: at top level, there is no driver, only DUT traffic.

• Interfaces and bound assertion modules attach to RTL instances — they follow the block to every level for free.

• Monitors/scoreboards keyed off pins (not driver intent) work passively at any level.

• Sequences/generators are block-TB-only — plan separate stimulus per level.

• Vertical reuse is a plan-review item: "which checkers ride up to top level?" should have a written answer.

Key takeaways

• Assign methodology per feature class — the decision matrix, not fashion.

• Formal for deep-state/small-logic; random for wide input spaces; directed for exact scenarios; emulation for raw cycles.

• Verify each feature at the cheapest level that can observe it.

• Design monitors, checkers, and assertions for passive vertical reuse from day one.

Common pitfalls

• "100% constrained-random" dogma — some features need one directed test, not a week of constraint tuning.

• Attempting formal on a wide datapath — state explosion, weeks lost, no proof.

• Verifying block corners at top level — 10x debug cost for the same bug.

• Scoreboards that peek at driver intent — break the moment you reuse them passively.