Introduction to Verilog
Digital Design covered what to build — truth tables, minimized Boolean expressions, state diagrams — entirely on paper. Verilog is one of the two dominant languages (the other being VHDL) for actually describing that hardware in a form a computer can simulate and, eventually, turn into a real circuit. This topic is about that translation: taking the gates, registers, and state machines from Digital Design and expressing them as Verilog code, correctly enough that a simulator and a synthesis tool agree on what circuit you meant.
Not a programming language
Verilog looks like a programming language — it has modules that resemble functions, if/case statements, loops, variables — and that resemblance is exactly what causes the most trouble for anyone coming from software. A C program executes statements one at a time, in order, on a single processor. Verilog describes hardware that all exists and all operates simultaneously: every always block, every continuous assignment, every module instance is a physically separate piece of circuitry running in parallel, all the time, forever (or until power-off). The sequential look of the code inside an always block describes the behavior of one piece of hardware — it does not mean "do this, then this" the way a software function does.
Keeping that one distinction in mind — concurrent hardware description, not sequential instructions — resolves most of the confusion beginners hit in the first few weeks of learning Verilog.
Simulation vs. synthesis
Verilog code is read by two very different kinds of tools, and not every construct is legal for both:
| Simulation | Synthesis | |
|---|---|---|
| What it does | Executes the code as a model of the circuit's behavior over time, so you can verify correctness before building anything | Translates the code into an actual netlist of gates and flip-flops that can be fabricated or programmed onto an FPGA |
| Tools | Questa, VCS, Xcelium, Icarus Verilog, Verilator | Design Compiler, Genus, Vivado, Quartus |
| What it accepts | The full language — delays (#10), file I/O, $display, arbitrary timing | Only the synthesizable subset — no delays, no simulation-only system tasks, restricted timing control |
A line of Verilog that simulates perfectly can still be meaningless — or silently wrong — in hardware, if it uses a construct synthesis tools ignore or interpret differently than the simulator does. Every page in this topic will call out explicitly which constructs are synthesizable RTL and which are simulation-only conveniences, rather than leaving that distinction implicit.
A short history: from proprietary tool to IEEE standard
Verilog wasn't originally an open language at all. It was created around 1984 by engineers at Gateway Design Automation — including Phil Moorby and Prabhu Goel — as a proprietary hardware-modeling language tied to their own Verilog-XL simulator. Cadence Design Systems acquired Gateway in 1989, and the following year, under pressure from users who wanted an open, tool-independent standard, Cadence placed the language's documentation into the public domain via Open Verilog International (OVI) — the organization that later became Accellera, the same standards body responsible for UVM. That opened the door to IEEE standardization: Verilog became IEEE Std 1364-1995 ("Verilog-95"), with major revisions in 2001 ("Verilog-2001," which added many of the conveniences taken for granted today) and 2005. SystemVerilog, covered as its own topic on this site, isn't a competing language — it's a superset of Verilog-2005, standardized separately as IEEE 1800 before the two standards merged into one document (IEEE 1800-2009 onward).
Where Verilog fits in this curriculum
Digital Design is language-agnostic — it teaches the concepts (a D flip-flop, a mod-8 counter, a Moore FSM) independent of any HDL. This topic is where those concepts turn into actual, synthesizable code. SystemVerilog, Testbench, and UVM then build the verification side on top — writing code whose job is to check that the RTL you write here is correct — which is a different goal from the RTL-writing this topic covers, and is why they're kept as separate topics rather than merged into one.
A running example: the full adder
Digital Design's Combinational Logic Design page built a full adder from its truth table down to minimized gate equations:
Sum = A ⊕ B ⊕ Cin
Cout = AB + BCin + ACin
That same full adder is the running example threaded through the next few pages of this topic — module structure, data types, and operators will each be introduced by asking "how do I express this specific, already-understood circuit in Verilog?" rather than a new toy example per page. By the end of Section A you'll have a complete, working Verilog description of the full adder; later sections build on it (a 4-bit ripple-carry adder using generate, for instance) to show how the same fundamentals scale up.
What this topic covers
- Language foundations — modules and ports, data types, operators — enough vocabulary to read and write basic Verilog.
- Modeling styles — the same circuit can be described structurally (gates wired together), as dataflow (
assignequations), or behaviorally (always/initialprocedural blocks); knowing all three, and when each is appropriate, is core Verilog fluency. - Procedural constructs — the
if/case/loop vocabulary used inside behavioral blocks, and which parts of it synthesis tools actually support. - Synthesizable RTL coding — the practical rules (sensitivity lists, blocking vs. nonblocking, latch inference) that separate code that works in simulation from code that also becomes correct hardware.
- Practical essentials — system tasks for debugging, compiler directives, and a light bridge into writing a minimal testbench, before Testbench and UVM take that subject much further.
What's next
The next page starts with the basic unit everything in Verilog is built from: the module — how to declare one, give it ports, and instantiate it inside another module — using the full adder as the first real example.