Week 4 · Day 19 · 7 hours

Verilog Verification – Debug Bootcamp

Testbenches, self-checking, regression, debugging

Open supporting lesson → Week 4 assessment View in full programme
Daily plan

What you will learn and practise

Complete the stages in order and retain the requested evidence.

Theory · 2h

Compile/elaboration/simulation failures
X/Z propagation
Width/signedness issues
Race conditions
RTL vs TB root cause

Guided lab · 2h

1. Syntax bug
2. Port mismatch
3. Width mismatch
4. Signed arithmetic bug
5. Blocking/NBA bug
6. Missing combinational assignment

Independent lab · 2h

7. Reset polarity bug
8. Counter off-by-one
9. FSM lockup
10. Multiple driver
11. FIFO pointer bug
12. TB timing race
13. X-propagation analysis

Debug and assignment · 1h

For each failure: reproduce → log → waveform → root cause → patch → rerun
Prepare bug report with evidence

Expected deliverable

RTL/DV debug report

Practical work

Debug Verilog RTL and testbench failures systematically across compile, elaboration and simulation stages using logs, waveforms and controlled reproduction, then prove each repair by rerun and regression.

Setup
  1. Create project_workspace/week4_verilog_verification/day19_debug_bootcamp with rtl, tb, broken_cases, sim, logs, waves, reports and scripts directories.
  2. Carry forward the Day 18 self-checking and regression discipline so every debug case has an objective failing baseline and passing rerun.
  3. Use Verilog, Icarus Verilog, GTKWave and shell automation only; SystemVerilog classes/interfaces, constrained randomization, SVA, coverage and UVM remain outside Week 4.
Execution steps
  1. Classify each supplied defect first as compile, elaboration or simulation/runtime behavior before editing source.
  2. Reproduce and record a syntax/compile failure; use compiler diagnostics to identify the exact source location and cause.
  3. Reproduce a DUT/testbench port or parameter mismatch and distinguish elaboration/connectivity failure from RTL functional failure.
  4. Debug a width truncation or extension defect and explain the observed binary value before applying the repair.
  5. Debug a signed/unsigned arithmetic defect using explicit operand/result interpretation and a self-checking failing case.
  6. Reproduce X propagation caused by uninitialized or incompletely assigned state and trace the first source of X in the waveform.
  7. Reproduce a reset-polarity or reset-sequencing defect and correlate reset, state and output behavior in the VCD.
  8. Debug a blocking/nonblocking assignment ordering defect in sequential RTL and document why the pre-fix behavior is incorrect.
  9. Debug a missing combinational assignment/latch-style defect using failing vectors and waveform evidence.
  10. Debug a counter off-by-one or timer terminal-count defect and prove the boundary cycle before and after repair.
  11. Debug an FSM lockup/dead-transition case and identify the state/input condition that prevents forward progress.
  12. Debug a multiple-driver or conflicting-assignment problem and identify every source driving the affected signal.
  13. Debug a FIFO pointer/full-empty boundary defect using the Week 3 synchronous FIFO behavior without introducing CDC/asynchronous FIFO topics.
  14. Reproduce a testbench timing race, move stimulus/checking to an unambiguous sampling point, and prove the DUT itself did not require a functional change.
  15. For selected failures follow the complete evidence chain: reproduce -> save log -> save waveform -> state root cause -> patch -> rerun -> regression.
  16. Prepare a consolidated RTL/DV debug report that separates DUT defects from testbench defects and records final regression status.
Written assignment
  1. Create a failure-classification table for compile, elaboration and simulation failures with one Day 19 example and diagnostic clue for each.
  2. Explain how X and Z values can enter a simulation and why forcing an output to a known value can hide rather than solve the root cause.
  3. Explain width and signedness rules responsible for one reproduced arithmetic mismatch, showing the pre-fix and post-fix interpretation.
  4. Document one RTL defect and one testbench defect using symptom, reproduction command, log clue, waveform clue, root cause, patch and rerun evidence.
  5. Prepare the final debug report index mapping each repaired case to its failing evidence and passing evidence.
Debug challenge

Select at least five deterministic failures spanning different categories, and for each prove the sequence reproduce -> log -> waveform -> root cause -> patch -> rerun. At least one case must be a testbench timing race and at least one must be an RTL functional defect. Finish by rerunning the affected regression with no unresolved failure.

Evidence to retain
  • broken_cases/ containing the intentionally failing sources or patches used to reproduce defects
  • logs/ containing compiler/elaboration diagnostics and pre-fix/post-fix simulation logs
  • waves/ containing failing and corrected VCD evidence for waveform-relevant cases
  • reports/day19_debug_report.md containing classification, root cause, patch and proof for each selected case
  • reports/day19_regression_summary.txt showing the repaired cases and final regression status
Completion criteria
  • Learner distinguishes compile, elaboration and simulation failures before modifying code.
  • At least five deterministic defects are reproduced and repaired with objective evidence.
  • Required coverage includes X/Z analysis, width/signedness, a race/timing issue and RTL-vs-testbench root-cause classification.
  • Every selected defect has failing evidence, stated root cause, patch description and passing rerun evidence.
  • The final affected regression passes with no unresolved Day 19 failure.
  • All evidence remains under project_workspace/week4_verilog_verification/day19_debug_bootcamp/.
Technical visuals

Understand the architecture and debug flow

Evidence-Driven Debug Loop
Evidence-Driven Debug Loop
Reproduce, log, inspect waveform, identify root cause, patch and rerun.
X/Z Propagation Root-Cause Map
X/Z Propagation Root-Cause Map
Trace unknown or high-impedance behavior back to reset, drive or incomplete-assignment defects.
Executable lab

Build, run and retain evidence

project_workspace/week4_verilog_verification/day19_debug_bootcamp/

Required files
  • rtl/
  • tb/
  • broken_cases/
  • scripts/run_debug_suite.sh
  • sim/
  • logs/
  • waves/
  • reports/day19_debug_report.md
  • reports/day19_regression_summary.txt
Mandatory tests
    Compile
    Run
    Waveform
    gtkwave waves/day19_fail.vcd
    PASS criteria
    • At least five cases are intentionally reproduced before repair.
    • Each selected case records a failure classification and objective failing evidence.
    • Waveform-relevant cases retain VCD evidence showing the symptom and corrected behavior.
    • The report identifies whether root cause is RTL, testbench, connectivity/build or stimulus/configuration.
    • Each patch is followed by a clean rerun; selected regression cases finish PASS.
    • No SystemVerilog/SVA/coverage/UVM methodology is required or introduced.
    Knowledge check

    Review before completing Day 19

    1. Failure classification

      What is the practical difference between compile, elaboration and simulation failures?

      Review answer

      Compile failures prevent source translation, elaboration/connectivity failures prevent a valid design hierarchy or binding from being formed, and simulation failures occur after a runnable model exists but produces incorrect behavior, runtime errors or failed checks.

    2. Four-state debug

      When an X appears at an output, what should be investigated before simply assigning a default value?

      Review answer

      Trace backward to the first unknown source: initialization/reset, incomplete combinational assignment, conflicting drivers, invalid indexing or an unknown control condition. A default that masks the X may conceal the real defect.

    3. Arithmetic debug

      Why can two operands with apparently correct bit patterns still produce an unexpected arithmetic comparison or result?

      Review answer

      Expression width extension/truncation and signed-versus-unsigned interpretation can change the mathematical value and comparison rules, so widths and signedness must be checked explicitly.

    4. Race debug

      How can you prove that a failing result is caused by a testbench race rather than defective DUT logic?

      Review answer

      Reproduce the failure, inspect the event/sampling relationship, move stimulus or checking to an unambiguous clock-relative point without changing DUT functionality, and show that the same functional test then passes consistently.

    Skills and assessment traceability

    Verilog verification debug bootcamp

    • Classify compile, elaboration and simulation failures.
    • Use compiler logs and simulator logs as primary diagnostic evidence.
    • Trace X/Z propagation and reset/initialization defects in waveforms.
    • Diagnose width, signedness and sequential/combinational coding defects.
    • Separate RTL defects from testbench timing/race defects.
    • Debug counter, FSM and synchronous FIFO boundary failures inherited from earlier RTL weeks.
    • Apply reproduce -> log -> waveform -> root cause -> patch -> rerun discipline.
    • Produce an RTL/DV debug report and clean regression evidence.

    Assessment: Week 4 debug evidence, injected-bug/root-cause task, automated testbench repair proof, regression and debug report