Verilog Verification – Self-Checking

1. Create project_workspace/week4_verilog_verification/day17_self_checking with rtl, tb, sim, logs and docs directories.
2. Reuse the deterministic clock/reset and PASS/FAIL discipline established on Day 16.
3. Use plain Verilog verification constructs only; SystemVerilog classes/interfaces, SVA, coverage and UVM are outside Week 4.

1. Create a parameterized ALU DUT with arithmetic, logical and compare operations suitable for deterministic checking.
2. Define expected-result generation independently in the testbench rather than copying DUT implementation structure.
3. Create a reusable check task that compares actual and expected result and updates TOTAL/PASS/FAIL/ERROR counters.
4. Run nominal directed tests for every supported ALU operation.
5. Add boundary vectors: all-zero, all-one, maximum positive, sign-boundary and carry/overflow-relevant operands where applicable.
6. Add repeated vector execution so every check is reported consistently without manual waveform inspection.
7. Adapt the same checker pattern conceptually to counter, timer, FSM, register block, FIFO, arbiter and IRQ-controller outputs from earlier weeks.
8. Inject one intentional DUT defect, prove that the checker reports failure, save the failing evidence, restore the DUT and rerun to PASS.
9. Generate a final TOTAL/PASS/FAIL/ERROR summary and retain log/VCD evidence.
10. Write a compact timer-or-FIFO test plan mapping requirements to nominal, boundary, negative and error-oriented tests.

1. Explain the difference between DUT implementation logic and an independent reference/expected-value model.
2. Prepare a test matrix containing requirement, stimulus, expected result and evidence for at least eight cases.
3. Explain why boundary and corner tests are necessary even when nominal tests pass.
4. Document the injected defect, the exact checker failure, root cause and clean rerun result.

Inject a single functional defect into the ALU (for example, an incorrect operation selection or arithmetic result), demonstrate that the self-checker catches it without relying on visual waveform inspection, then patch and rerun with FAIL=0.

• rtl/alu.v and tb/tb_alu_selfcheck.v
• logs/day17_selfcheck_fail.log showing the injected defect was detected
• logs/day17_selfcheck_pass.log showing the corrected DUT passes
• sim/day17_selfcheck.vcd
• docs/test_plan.md mapping requirements to tests and expected results

• Expected values are generated independently from DUT implementation structure.
• Nominal and boundary/corner cases are automatically checked.
• Injected DUT bug produces at least one deterministic FAIL/ERROR result.
• Corrected DUT rerun reports TOTAL > 0 and FAIL=0.
• Test plan and simulation evidence are retained in project_workspace.

• rtl/alu.v
• tb/tb_alu_selfcheck.v
• sim/day17_selfcheck.vvp
• sim/day17_selfcheck.vcd
• logs/day17_selfcheck_pass.log
• docs/test_plan.md

• Every documented ALU operation has at least one nominal self-checking test.
• Zero, all-one and arithmetic boundary vectors are exercised.
• Expected result is computed in the testbench and compared automatically.
• TOTAL/PASS/FAIL/ERROR counters are printed at completion.
• An intentionally injected DUT bug is detected without manual waveform judgement.
• After repair, the same regression finishes with FAIL=0.
• Test-plan entries identify requirement, stimulus, expected result and evidence.

• Compile completes without errors.
• Injected-bug run records a deterministic checker failure.
• Clean run reports TOTAL > 0, PASS = TOTAL and FAIL = 0.
• Boundary/corner cases are present in the retained test list.
• Test plan, logs and waveform are retained under project_workspace.