Barcelona Abroad · Optional Self-Study  🤖 Capstone AI verification

SystemVerilog for Verification

Not on the Barcelona calendar — part of the "Keep Going" self-study track (baseline D14)

HDL for Digital System Design · UCF ECE · Barcelona Summer 2026

CRAFT

Today at a Glance

PhaseTimeActivity
🌍 Contextualize10 minAssertions = executable specs · verif eng writes them before RTL
⚠️ Reframe15 minTesting isn't at the end · assertions live inside the design
🛠 Assemble70 minAssertions on UART TX · parity via generate if · 🤖 AI TB for project module
🛡 Fortify45 minBug injection · coverage analysis · structured PPA report
🔗 Transfer10 minHow this fits the required course · Keep Going track
Most packed day of the course. Escape valve: parity (Ex 2) is skippable if you're behind on your project — use the time for AI TB + PPA.

▸ Phase 1 of 5  ·  ~10 min

🌍 Contextualize

In industry, verification writes the spec

Assertions Are the Spec

  • Semidynamics — their verification team writes SVA properties for the vector unit before the RTL designer writes a line of code. The assertions are the spec.
  • Apple, Intel, NVIDIA — verification engineers outnumber RTL designers ~3:1. The bottleneck on every chip tapeout is verification.
  • Barcelona Metro signalling — every interlock is encoded as a safety property. Violations are physically impossible by construction.

The industry secret

Most chips are 70%+ verification cost. The verif engineers who write good assertions are the ones who keep the line moving.

Today you take the first step into that role.

An assertion that never fires might mean your design is correct — or that your TB never exercised that path. Coverage tells you which.

▸ Phase 2 of 5  ·  ~15 min

⚠️ Reframe

Assertions live inside the design

⚠️ "Testing Is the Last Step"

❌ Wrong Model

"I'll finish the RTL, then write a TB at the end. If sim passes, I ship."

✓ Right Model

Assertions are inline with your RTL. They fire the instant something violates the contract. They're not "tests at the end" — they're contracts that ride with the design forever.

Assertions tell you what broke and where. Waveforms tell you how it looks. Assertions are faster.

Immediate Assertions in 60 Seconds

always_ff @(posedge clk) begin
    // Contract: TX line idles high
    assert (state != IDLE || tx_out == 1'b1)
        else $error("TX low while IDLE at t=%0t", $time);

    // Contract: bit_idx in range during DATA state
    assert (state != DATA || bit_idx < 8)
        else $fatal("bit_idx overflow: %0d", bit_idx);

    // Contract: no new tx_start accepted while busy
    assert (!(tx_busy && tx_start))
        else $error("tx_start while busy — protocol violation");
end
  • $error = sim continues, fail recorded. Good for non-fatal contract violations.
  • $fatal = sim stops. Good for "we cannot continue — something is corrupt."
  • Lives in the RTL file — code review sees them, regressions run them.

The Verification Maturity Ladder

LevelWhat it looks likeYou at…
1 · Manual"Looks right in GTKWave" → shipDay 1
2 · Self-checkingTB with PASS/FAIL printoutDay 5/6
3 · AI-scaffoldedAI generates TB; you correct + auditDay 6 onward
4 · Assertion-enhancedContracts inline in RTLToday (Ex 1)
5 · Constraint-drivenConstrained random + AI stimulusToday (Ex 3)
6 · Coverage-drivenCoverpoints + bins + closureIndustry / preview today
By end of class today, every student is at level 5. That's the Barcelona arc.

▸ Phase 3 of 5  ·  ~70 min  ·  Contracts · parity · project TB

🛠 Assemble

Three deliverables · capstone Fortify

Build Plan

  1. Ex 1 · 25 min  Assertion-enhanced UART TX — add ≥5 immediate assertions (idle high, busy semantics, bit-idx range, start=0/stop=1, no re-start while busy). Rerun TB; all pass.
  2. Ex 2 · 20 min  Constraint-based parity (generate if)PARITY_EN & PARITY_TYPE parameters. Conditionally insert a parity bit in the frame. Skippable if you're behind on your project.
  3. Ex 3 · 25 min  🤖 AI constraint-based TB for your project module — write the constraint spec, prompt, audit, correct.
Ex 4 (capstone Fortify): structured PPA report — sequential vs combinational multiplier, PARITY_EN=0 vs 1, your project module. Comparison table + 2 analysis paragraphs.

Bug Injection — Watch the Assertion Catch It

// Intentionally swap start/stop polarity
START: begin tx_out <= 1'b1;        // ❌ was 1'b0 — START should be LOW
             // …
       end

Re-run the existing TB. Assertion fires:

"START bit must be 0 at t=170 — got 1"
ASSERTION FAILED in uart_tx.sv:34
$finish called from sim — 1 error, 0 warnings
  • Before assertions: you'd see garbage on the terminal and dig through 5000 cycles of waveform.
  • With assertions: the message points to the exact line, the exact time, the exact violation. 2 seconds vs 20 minutes.
  • Fix, re-run, watch all assertions pass. Commit the assertions to git, not just the fix.

Parity via generate if

module uart_tx_sv #(
    parameter int  CLKS_PER_BIT = 217,
    parameter bit  PARITY_EN    = 0,
    parameter bit  PARITY_TYPE  = 0      // 0=even, 1=odd
)(/* ports */);

    logic parity_bit;
    generate
        if (PARITY_EN) begin : gen_parity
            // Even parity: XOR reduction; flip if odd
            always_comb parity_bit = (^tx_data) ^ PARITY_TYPE;
            // FSM: IDLE → START → DATA(8) → PARITY → STOP
        end else begin : gen_no_parity
            assign parity_bit = 1'b0;    // unused, optimized away
            // FSM: IDLE → START → DATA(8) → STOP
        end
    endgenerate
endmodule

Compile two variants, run yosys stat on both. Question: how many LUTs does one parity bit cost?

🤖 AI Constraint-Based TB — The Capstone Prompt

Prompt template: "Generate a self-checking SV testbench for <your project module>. Constraint: stimulate <input X> in range [A, B], <input Y> covering <legal values>. Include ≥10 random cases per input combo. Use $urandom_range(). Add a scoreboard tracking PASS/FAIL counts. Print final coverage as `tests_run / cases_seen`."

  • Does it actually constrain? Or does it generate fully random stimulus that misses corner cases?
  • Does it self-check? A reference model in the TB compared to DUT output — that's the only way it scales.
  • Does it count coverage? Manual bin counting is fine for now (covergroups need Verilator/commercial).
  • Save to AI portfolio: spec + prompt + raw AI output + your corrected version + coverage analysis. This is the portfolio centerpiece.

▸ Phase 4 of 5  ·  ~45 min  ·  Coverage · PPA · structured report

🛡 Fortify

Numbers + paragraphs · the final-project rubric

How Do You Know When Testing Is Done?

  • Assertions all pass — the contracts hold under every stimulus you ran.
  • Coverage is closed — every important input combo + state was actually exercised. "Pass" without coverage is theater.
  • The bugs you injected were caught — your TB sensitivity is non-zero.
  • Code coverage ≥ X% — branch + toggle + FSM-state. Verilator can compute this; Icarus cannot.
For today: manually track "which input combos did my TB hit?" Make a table. That's coverage in elementary form — and it's what makes the AI prompt in Ex 3 grade-worthy.

The Capstone PPA Report

VariantLUTsFFsFmaxNotes
Mult — combinational *?0?1 cyc · D10
Mult — shift-and-add???8 cyc · D10
UART TX — PARITY_EN=0???10-bit frame
UART TX — PARITY_EN=1???11-bit · today
Your project module???baseline
+ 2 analysis paragraphs: (1) which row is the best trade-off for your project and why; (2) what would you change if Fmax target doubled. This is the format your final demo report uses on D16.

🤖 AI TB Critique — Did It Cover the Corners?

  • Boundary values — did the TB hit 0, max, and max-1 for every input?
  • Reset behavior — does the TB assert rst mid-operation and check recovery?
  • Back-to-back operations — did it test the case that broke your "HELLO" sequencer yesterday?
  • Illegal inputs — does the DUT handle them, and does the TB intentionally try?
  • Coverage numbers — print them. If the AI didn't, add a manual counter and print it yourself.
This is the AI portfolio rubric. A great AI prompt + a thoughtful correction + a coverage analysis = top marks. A "Looks Good To Me" copy/paste = bottom marks.

▸ Phase 5 of 5  ·  ~10 min  ·  Where this fits

🔗 Transfer

From this room to silicon

How This Connects to the Required Course

D5+6 You already write self-checking and AI-generated testbenches in plain Verilog — that's the required foundation.

D10 The structured PPA report (LUT/FF/Fmax + analysis paragraphs) is already part of the required arc.

SV trackAssertions, coverage, and constraint-random stimulus are the next layer up — what this deck adds on top of what you already do.

The required course gets you a working, verified, PPA-analyzed subsystem. This track makes the verification scale.

Keep Going — Where to Take This Next

UART RX + loopback16× oversampling, frame detection, TX→RX echo (baseline D12)
SPI MasterClock polarity/phase, FSM-driven shifting, talking to a real sensor
UVM & constraint-randomThe industry methodology these SV assertions and coverage lead into
Formal verificationProving a property holds for all inputs, not just tested cases
All of this lives in the "Keep Going: Beyond the Scope of This Course" self-study track — each item points at the baseline materials already in the repo.

Try It On Your Own

  • 🔁 Take a module you already built in required Verilog and refactor it to SV
  • ✅ Add 5+ assertions for its key invariants
  • 🤖 Generate an AI testbench and inject a bug — does an assertion catch it?
  • 📊 Capture a structured PPA report for the before/after

Reflection prompt

In two sentences: name one assertion that would catch a bug a directed testbench might miss. That's the value SV verification adds.

🔗 End of the SV-for-Verification self-study deck

Assertions. Constraints. Coverage.
This is how verification scales.

Not required for the Barcelona edition — but the on-ramp to UVM, formal, and a verification-engineer-shaped portfolio.
Pick it up when you're ready.

CRAFT