Week 4 · Day 20 · 7 hours

Verilog Verification – Integration

Testbenches, self-checking, regression, debugging

Daily plan

What you will learn and practise

Complete the stages in order and retain the requested evidence.

Theory · 2h

Verification planning
Requirements-to-tests mapping
Regression discipline
Review and coding quality

Guided lab · 2h

1. Integrate timer/register/IRQ blocks
2. Build top-level TB
3. Directed smoke tests
4. Negative tests
5. Boundary tests

Independent lab · 2h

6. Random test loop
7. Regression script
8. Waveform debug
9. Clean PASS/FAIL report
10. Code review and lint-style checklist

Debug and assignment · 1h

Week-4 practical assessment
Mini-project demonstration

Expected deliverable

Verified Verilog mini-system + regression report

Practical work

Integrate the Week 2–3 Timer, Register Block and IRQ RTL into a Verilog mini-system, verify it with a reusable self-checking top-level testbench and regression, and close Week 4 with requirements-to-tests evidence.

Setup
  1. Create project_workspace/week4_verilog_verification/day20_integration with rtl, tb, sim, logs, waves, scripts and reports directories.
  2. Reuse previously verified Timer, Register Block and IRQ RTL; do not redesign frozen Week 2 or Week 3 source requirements.
  3. Use Verilog, Icarus Verilog, GTKWave and shell automation only; SystemVerilog, SVA, coverage and UVM remain outside Week 4.
Execution steps
  1. Write a compact verification plan listing mini-system requirements, test IDs, expected results and required evidence.
  2. Integrate Timer, Register Block and IRQ blocks under a small top-level wrapper with explicit reset, configuration, status and interrupt connections.
  3. Build a top-level Verilog testbench with deterministic clock/reset generation, reusable stimulus tasks and automatic PASS/FAIL counters.
  4. Run a smoke test proving reset, basic configuration and one nominal timer-to-IRQ path.
  5. Run negative tests for disabled/masked interrupt behavior and invalid or non-triggering operating conditions defined by the reused RTL.
  6. Run boundary tests around timer terminal count, status/clear behavior and IRQ assertion/deassertion timing.
  7. Add a repeatable multi-test loop with a recorded seed/configuration where pseudo-random values are used.
  8. Execute the complete Day 20 regression from one shell command and retain one log per test.
  9. Generate VCD only for failing/debug runs or retain a selected integration waveform as closure evidence.
  10. Produce a clean regression summary containing test ID, requirement, result and PASS/FAIL totals.
  11. Review failures using the Day 19 reproduce -> log -> waveform -> root cause -> patch -> rerun discipline.
  12. Create a requirements-to-tests closure matrix and mark every Day 20 requirement PASS, FAIL or BLOCKED with evidence links.
  13. Perform a code/review checklist covering warnings, reset behavior, deterministic checking, file organization and unresolved limitations.
  14. Package the verified Verilog mini-system, testbench, logs, waveform evidence and regression/closure reports as the Day 20 deliverable.
Written assignment
  1. Create reports/day20_verification_plan.md with requirement IDs, test IDs, expected behavior and evidence location.
  2. Explain why a passing smoke test alone is insufficient for verification closure and identify the negative and boundary tests used here.
  3. Document one integration failure using symptom, reproduction command, log/waveform evidence, root cause, patch and passing rerun.
  4. Create reports/day20_requirements_traceability.md mapping every mini-system requirement to at least one executed test and final status.
  5. Write a short closure statement listing regression totals, unresolved limitations (if any) and whether the Day 20 mini-system is ready for Week 4 review.
Debug challenge

Inject or preserve one deterministic integration defect, prove it through the Day 19 evidence chain, patch it without changing unrelated frozen RTL behavior, rerun the affected test and then rerun the full Day 20 regression to closure.

Evidence to retain
  • rtl/ containing the integrated Timer/Register/IRQ Verilog sources or controlled copies
  • tb/tb_day20_integration.v with self-checking top-level verification
  • logs/ with per-test and final regression logs
  • waves/ with selected failing/corrected integration waveform evidence
  • reports/day20_verification_plan.md and reports/day20_requirements_traceability.md
  • reports/day20_regression_summary.txt and reports/day20_closure.md
Completion criteria
  • Timer, Register Block and IRQ integrate and compile without unresolved errors.
  • Smoke, negative and boundary tests execute automatically with objective PASS/FAIL checking.
  • One-command regression completes and produces a clean summary.
  • Every declared Day 20 requirement maps to executed test evidence and a closure status.
  • At least one integration/debug case demonstrates reproduce -> evidence -> root cause -> patch -> rerun -> full regression.
  • All Day 20 evidence remains under project_workspace/week4_verilog_verification/day20_integration/.
Technical visuals

Understand the architecture and debug flow

Integrated Verification Top
Integrated Verification Top
Timer, register block and IRQ logic are exercised and checked together at system level.
Requirements-to-Closure Flow
Requirements-to-Closure Flow
Requirement, test, expected result, actual result, evidence, debug and full-regression closure.
Executable lab

Build, run and retain evidence

project_workspace/week4_verilog_verification/day20_integration/

Required files
  • rtl/timer.v
  • rtl/register_block.v
  • rtl/irq_controller.v
  • rtl/mini_system.v
  • tb/tb_day20_integration.v
  • scripts/run_regression.sh
  • sim/
  • logs/
  • waves/
  • reports/day20_verification_plan.md
  • reports/day20_requirements_traceability.md
  • reports/day20_regression_summary.txt
  • reports/day20_closure.md
Mandatory tests
  • Smoke: reset, configuration and nominal timer-to-IRQ path.
  • Negative: disabled/masked interrupt must not assert externally.
  • Boundary: timer terminal count and expiry cycle.
  • Boundary: sticky/status clear behavior and IRQ deassertion.
  • Repeatable multi-test run with recorded configuration/seed.
  • Injected integration defect followed by repaired full-regression rerun.
Compile
iverilog -g2012 -Wall -o sim/day20_integration.vvp rtl/timer.v rtl/register_block.v rtl/irq_controller.v rtl/mini_system.v tb/tb_day20_integration.v
Run
vvp sim/day20_integration.vvp +TEST=smoke | tee logs/day20_smoke.log
Waveform
gtkwave waves/day20_integration_fail.vcd
PASS criteria
  • Compilation completes without unresolved errors and warnings are reviewed.
  • All required tests self-check and produce deterministic PASS/FAIL results.
  • Regression summary identifies each test and final TOTAL/PASS/FAIL counts.
  • Requirements-to-tests matrix contains no unexplained requirement gap.
  • Injected integration failure is detected, diagnosed, repaired and followed by a clean full regression.
  • No SystemVerilog/SVA/coverage/UVM methodology is introduced.
Knowledge check

Review before completing Day 20

  1. Verification planning

    What minimum information should connect a mini-system requirement to verification evidence?

    Review answer

    A unique requirement, one or more test IDs, expected behavior, actual PASS/FAIL result and the retained log/waveform or report location that proves the result.

  2. Integration testing

    Why are smoke, negative and boundary tests all needed before closure?

    Review answer

    Smoke proves a nominal path works, negative tests prove prohibited behavior does not occur, and boundary tests exercise transitions and limits where integration defects commonly appear.

  3. Regression discipline

    After fixing one integration failure, why rerun the full regression instead of only the failing test?

    Review answer

    The focused rerun proves the specific repair, while the full regression checks that the patch did not break previously passing behavior elsewhere in the integrated system.

  4. Closure

    When should a requirement be marked BLOCKED rather than PASS or FAIL?

    Review answer

    When the required test cannot be executed or judged because a prerequisite, environment, specification or dependency prevents valid evidence; the blocker and owner/action should be recorded explicitly.

Skills and assessment traceability

Verilog verification integration and closure

  • Translate mini-system requirements into an executable verification plan.
  • Integrate previously developed Timer, Register Block and IRQ RTL without changing frozen curriculum scope.
  • Build a self-checking top-level Verilog testbench.
  • Execute smoke, negative and boundary verification scenarios.
  • Run a repeatable one-command regression with per-test evidence.
  • Apply waveform/log debug discipline to integration failures.
  • Map requirements to tests and evidence for verification closure.
  • Produce a verified Verilog mini-system and regression/closure report.

Assessment: Week 4 automated testbench, requirements-to-tests mapping, integration debug proof, clean regression report

Weekly checkpoint

Verilog Verification

3.0 h · 100 marks · Automated testbench + report

Review Week 4 assignment →