Module 1: Getting Oriented
What SystemVerilog Is, and Why It Feels Like Two Languages
Two languages wearing one name
The single most useful thing to understand on day one is that SystemVerilog is not one language. It is a hardware description language with a second, much larger, software-like language bolted onto it, and the two halves are used by different people for different jobs.
The synthesizable subset describes hardware. When you write
it, you are not writing instructions that run — you are describing gates and
flip-flops that a synthesis tool will build. It is a small language: module,
port, always_ff, always_comb, assign,
some types, some operators. Almost everything else in the standard is
off-limits, because there is no pile of silicon that corresponds to a
queue.
The verification subset is where the rest of the standard lives: classes, inheritance, dynamic arrays, queues, mailboxes, randomisation, assertions, coverage. This code never becomes hardware. It runs in the simulator, on your workstation, and its job is to poke the hardware description and check what comes back.
Nearly every beginner's worst afternoon comes from crossing that line
without noticing — putting a queue in an RTL module, or expecting
always_comb to behave like a function call. Whenever something is
inexplicable, the first question is worth asking out loud: am I writing
hardware here, or am I writing a program?
Where it came from, and why that still shows
Verilog was standardised in 1995 and revised in 2001. It was a design language with just enough testbench capability to be frustrating. Through the early 2000s the verification side grew up separately in proprietary languages, and in 2005 the two streams were merged: SystemVerilog became IEEE 1800, a strict superset of Verilog-2005. The current revision is IEEE 1800-2023.
"Strict superset" is the part that shows. Every legal Verilog file is a legal SystemVerilog file, which means the language carries three decades of history in it. There are two ways to declare almost everything, and the older way is usually the worse one:
| Old Verilog | Modern SystemVerilog | Why the new one |
|---|---|---|
reg | logic | Same 4-state type, without the lie that it means "register" |
always @(*) | always_comb | The tool checks you actually described combinational logic |
always @(posedge clk) | always_ff @(posedge clk) | States the intent, and the tool enforces it |
integer | int | 2-state and 32-bit, matching C rather than 4-state Verilog |
| Verilog-1995 port lists | ANSI-style port lists | Declare direction and type in one place |
You will meet the old spellings constantly, because real codebases are old. Read them fluently; write the new ones.
What a simulator actually is
A logic simulator is an event-driven program. It holds a model of your design, a current simulation time, and a queue of things due to happen. It picks the earliest event, runs whatever that wakes up, collects any new events that produces, and repeats. When nothing is left at the current time, it jumps forward to the next time with an event in it.
Two consequences matter from the beginning. First, simulation time is not wall-clock time — a nanosecond of simulated time might take a millisecond or a minute of your afternoon. Second, and more important, a great deal happens at a single simulation time. Statements that are all "at 10 ns" still execute in a definite order, and that order is the subject of most testbench race conditions. Module 5 takes this apart properly; for now, just hold on to the idea that "the same time" does not mean "simultaneously".
What this course covers, and what it does not
Modules 2 through 4 are the type system and operators. This is unglamorous and it is where the course spends its first big block of time on purpose, because type confusion is the root cause of a startling share of real SystemVerilog bugs.
Modules 5 through 10 are the procedural language: processes and scheduling,
arrays and queues, tasks and functions, module hierarchy and parameters,
interfaces, and fork...join.
Module 11 introduces classes, which is the doorway into verification. Modules 12 to 14 walk through the three pillars you will use every day afterwards — assertions, constrained randomisation, and functional coverage — at an introductory depth. Module 15 is the capstone.
What this course deliberately does not cover: UVM, formal verification, gate-level simulation, and the deeper end of SVA. The advanced course picks up several of those. UVM in particular is worth resisting until the language underneath it is comfortable — a great many people learn UVM as a set of incantations because they never learned the object model it is built from.
What you need
A simulator, and that is genuinely it. Any of these will run everything in this course:
- A commercial simulator — Synopsys VCS, Cadence Xcelium, or Siemens Questa. If you are at a company that does chip design, you have one of these.
- Verilator — free and very fast, but it is a compiler to C++ rather than an event simulator, and its support for the verification subset is partial. Fine for the RTL half of this course, limiting for the class and randomisation modules.
- An online simulator — EDA Playground runs several commercial tools in the browser at no cost for small examples. This is the lowest-friction way to follow along, and everything in the early modules fits comfortably.
Type the examples rather than reading them. The failure modes this course keeps pointing at are ones you will only really believe once you have watched your own code do them.