Day 13 · SystemVerilog Transition

Why SystemVerilog?

Video 1 of 4 · ~9 minutes

Dr. Mike Borowczak · Electrical & Computer Engineering · CECS · UCF

Why SVlogic typealways_*enum/struct/package

🌍 Where This Lives

In Industry

Every modern ASIC and FPGA tool shop writes SystemVerilog, not Verilog. Intel, AMD, Apple, NVIDIA, Qualcomm — SV has been the industry default for design since ~2010 and for verification since ~2005 (UVM). A job posting that says “Verilog experience” means SV; nobody starts a new project in Verilog-2001 anymore. Learning SV isn't an add-on — it's the lingua franca.

In This Course

Days 13-14 transition you from the Verilog subset you've been using to the SV superset you'll need. Everything you've written compiles unchanged — SV is backwards-compatible. The new features reduce bug surface, improve readability, and unlock verification capabilities you can't get in Verilog at all.

⚠️ “SV Is a Different Language”

❌ Wrong Model

“SystemVerilog is a different language. I need to relearn HDL. My Week 1-3 Verilog will be deprecated.”

✓ Right Model

SV is a superset of Verilog-2001. Every piece of Verilog you've written is already valid SV. The IEEE 1800 standard (SV) subsumes IEEE 1364 (Verilog). You're not switching languages — you're opening up new features in the same language. It's like going from ES5 to ES2020 JavaScript: the old still works, the new is available when you need it.

The receipt: iverilog -g2012 compiles your existing Verilog and also accepts all SV features. One compiler. One language family. The transition is mostly about learning when to use SV features, not about abandoning Verilog.

👁️ I Do — The Evolution Timeline

YearStandardKey additions
1984Gateway VerilogOriginal language from Gateway Design Automation
1995IEEE 1364-1995First IEEE standard — “Verilog-95”
2001IEEE 1364-2001ANSI port lists, generate, $clog2 — what you've been writing
2005IEEE 1800-2005First SystemVerilog — logic, always_ff, assertions, classes
2009 / 2012 / 2017 / 2023IEEE 1800 revisionsIncremental refinements; modern default is SV-2017
My thinking: Verilog's last major revision was 2001 — over two decades ago. SV has become the de facto HDL standard. Modern tools default to SV; most open-source Verilog repos are actually SV. By writing Verilog-2001, you've been writing the stable base of the language. Now you're learning the modern vocabulary.

🤝 We Do — What SV Adds for Design

FeatureSolves this problemCovered in
logic typewire vs reg confusion13.2
always_ff, always_comb, always_latchAccidental latch inference13.3
enumlocalparam FSM state list verbosity13.4
typedef, struct, packed/unpackedBundled signal groups13.4
packageSharing type/constant across files13.4
interfacePort-list explosion for protocols(mentioned)
assert / assume / coverExecutable specifications14.1
Classes + UVMReusable object-oriented verification(preview)
Together: Every row maps to a bug you've either hit or seen in this course. SV didn't invent features just to be fancy — it codified 20 years of lessons learned on real chips. The features you'll use this week fix the most common Verilog pitfalls.

🧪 You Do — Which Bug Would SV Have Caught?

always @(*) begin
    if (sel)
        out = a;     // missing else — infers a latch silently
end

Which SV feature would have prevented this bug at compile time?

Answer: always_comb. Replace always @(*) with always_comb and the compiler flags the latch inference as a warning or error — the block is declared combinational, and latches aren't combinational, so the tool complains. Same logic, different declared intent, bug caught.
Why this matters: Intent-based coding. always @(*) means “execute whenever inputs change,” which permits latches as a side effect. always_comb means “I want combinational logic,” which forbids them. Saying what you want lets the tool check whether you got it.

🔧 What Tool Support Looks Like

$ iverilog -g2012 -o sim my_design.sv  # SV-2012 mode

# always_comb with latch: compiler complains
my_design.sv:14: warning: always_comb process inferred latch for 'out'

# always_ff with multiple clocks: error
my_design.sv:22: error: always_ff process sensitive to multiple edges

# logic type: no wire/reg bugs possible
my_design.sv: [no warnings about assignment-from-always-to-wire]
What to notice: The SV compiler isn't just permissive — it's stricter, in the ways that matter. Classic Verilog permits all manner of ambiguity (is out a wire or reg? what does always @(posedge clk or sel) synthesize to?). SV asks you to declare intent, then enforces it. Stricter where ambiguity bites, looser where Verilog was needlessly pedantic.

🤖 Check the Machine

Ask AI: “Convert this Verilog-2001 module to idiomatic SystemVerilog-2012. Use logic, always_ff, always_comb, enum for states, and typedef as appropriate.”

TASK

AI modernizes Verilog-2001 to SV-2012.

BEFORE

Predict: wire/reg → logic; always @(*)always_comb; always @(posedge clk)always_ff; state localparams → enum.

AFTER

Strong AI uses typedef enum and logic consistently. Weak AI leaves wire/reg mixed in.

TAKEAWAY

AI is excellent at mechanical Verilog→SV conversion. Great for modernizing legacy code.

Key Takeaways

 SystemVerilog is a superset of Verilog. Your Week 1-3 code already works.

 Modern industry writes SV, not Verilog-2001. It has been standard for 20 years.

 Every SV design feature maps to a class of Verilog bugs it prevents.

 Intent-based declarations (always_comb, always_ff) let tools check your intent.

Say what you want. Let the tool prove you got it.

🔗 Transfer

The logic Type

Video 2 of 4 · ~8 minutes

▸ WHY THIS MATTERS NEXT

Every student this semester has written reg where they meant wire (or vice versa) at least once. Video 2 introduces logic — one type that replaces both, removes the confusion entirely, and prevents a category of bugs that plagues Verilog-2001 code.