What Is a Hardware Description Language?

Here is a strange fact: the chip in your phone — billions of transistors, switching billions of times a second — began life as text files. Not blueprints, not circuit diagrams drawn by hand: text, written in an editor, kept in version control, reviewed in pull requests, exactly like software. And yet the people who write it will insist, sometimes sharply, that they are not programming. They are describing hardware — and the difference between those two activities is the single most important idea in this entire course.

A hardware description language (HDL) is a language for writing down a circuit: what components exist, how they are wired, and what each one does. The two languages that matter are Verilog (born 1984) and VHDL; this course uses SystemVerilog, Verilog's modern descendant and the industry's working language. Master the mental shift in this lesson and the rest of the language is bookkeeping.

A program is a recipe; a circuit is a kitchen

A program is a sequence of steps: do this, then that, one instruction at a time, executed by one processor walking through the list. Delete a line and the steps after it still run, just differently.

A circuit is not a sequence of anything. It is a machine standing in space: thousands of logic gates, each permanently wired to its neighbours, all working at once, forever. An AND gate does not wait its turn — it computes the AND of its inputs continuously, every nanosecond of the chip's life, whether anyone is looking or not. Describing that machine in text means every statement you write is another piece of hardware bolted into place, all simultaneously active. The order of statements in the file is as irrelevant as the order in which you list the rooms of a house: the house is the same house.

This is why hardware people bristle at "programming a chip". A better verb is the one the tools use: you describe, and the description is the circuit.

First contact: a majority voter

Here is a complete SystemVerilog design — a majority voter, which outputs 1 when at least two of its three inputs are 1 (spacecraft use exactly this to let three redundant computers outvote a faulty one):

module majority ( input logic a, input logic b, input logic c, output logic y ); assign y = (a & b) | (b & c) | (a & c); endmodule

Read it as a machine, not a recipe. module … endmodule is the component's outline — a box with a name. The input/output lines are its pins. And the assign line is the entire works: three AND gates and an OR gate, permanently wired from the input pins to the output pin. Nothing "runs". The wire y simply is, at every instant, the majority of a, b, c — the way your kitchen tap simply is connected to the mains. Change an input, and the output follows a few gate-delays later, no instructions executed anywhere.

The same text, drawn as a machine

Every synthesis tool in the world would turn that assign into essentially this circuit. One line of text; four gates of permanently-wired, permanently-working silicon:

Try being the simulator

The description above is complete enough that a tool can predict the hardware's behaviour — that is called simulation, and it is how designers live-test circuits that do not exist yet. Here is the majority voter's logic transcribed into TypeScript so you can simulate it yourself — one function call per input combination, which is exactly what a truth-table sweep in a real simulator does:

// The assign line, as a function: y = (a & b) | (b & c) | (a & c) function majority(a: number, b: number, c: number): number { return (a & b) | (b & c) | (a & c); } console.log("a b c | y"); console.log("------+--"); for (let a = 0; a <= 1; a++) for (let b = 0; b <= 1; b++) for (let c = 0; c <= 1; c++) console.log(`${a} ${b} ${c} | ${majority(a, b, c)}`);

Check the output: y is 1 exactly on the four rows with two or more 1s. One caution before the habit forms: the for loops here belong to the test, not the circuit. The circuit has no loops, no steps, no time-order — it is those four gates, sitting there, being a majority voter.

One text, two lives

The same file leads a double life, and the whole industry is organised around the split:

Simulation — a program reads the description and acts it out, tracking signal changes over virtual time so you can watch waveforms and catch bugs before paying for silicon. This is the workbench where you will spend most of your design hours.
Synthesis — a compiler-like tool reads the same description and builds the actual gate network it describes, ready for an FPGA or an ASIC. Your text becomes transistors.

Everything in this course flows from taking both lives seriously: write descriptions that simulate correctly and synthesize into clean hardware. The two can disagree — a description can behave beautifully in simulation yet describe no buildable circuit at all — and learning where that trap lies is a lesson of its own at the end of this module.

an HDL describes a circuit: components, wiring and behaviour — text as schematic;
statements describe hardware that is all active simultaneously — there is no execution order to the file;
one description leads two lives: simulated (to predict behaviour) and synthesized (to become gates);
this course writes SystemVerilog, the industry's working HDL.

People try, roughly once a decade. The deep obstacle is that C's whole worldview is a single thread of time — do this, then that — while hardware's worldview is ten thousand things happening at once, every cycle. You can bolt concurrency onto C (that industry is called "high-level synthesis", and it has real niches), but designers keep returning to HDLs because the language's shape matches the machine's shape. There is also a delicious historical irony: Verilog was created in 1984 as a simulation language — a way to test chips designed by hand. Only later did synthesis tools learn to read it backwards, turning descriptions into gates, and the test harness accidentally became the blueprint. The habits of that origin (the simulation-only corners of the language, the synthesizable subset) still shape daily practice forty years on.

The classic beginner error is reading HDL like a program: "first this assign happens, then that one." No — every assign is hardware, and all of it is active at once. Two consequences will bite you early. First, reordering the statements in a module changes nothing: the netlist is the same set of gates however you list them. Second, a wire has its value continuously — asking "has this assign run yet?" is a meaningless question, like asking whether gravity has run yet. Sequencing does exist in hardware, but it comes from clocked storage elements, not from statement order — that is a later lesson, and it is the only legitimate source of "before and after" on a chip.