What Verilog Really Is

A hardware description language is not a programming language

A C program runs one statement after another, on one processor, one instruction at a time – that order is the whole point, and the processor executes it literally. A piece of digital hardware does not work this way at all. A real chip is thousands of gates and flip-flops, all physically present at once, all reacting to their inputs at the same time, all the time. Verilog exists to describe that kind of system: a hardware description language (HDL) models concurrency – many things happening simultaneously – as its default assumption, not as a special case bolted onto a sequential language. This single difference is the reason Verilog code that looks almost like C can behave in ways a C programmer would not expect, and it is worth holding onto through every lesson in this path.

Before HDLs existed, a digital designer built a circuit the way the earlier lessons in the Digital Electronics path describe: draw a schematic, place gates by hand, check timing by hand. That approach stopped scaling once a chip held more than a few hundred transistors. Verilog, which originated in 1983, let a designer write a textual description of what a circuit should do and leave the actual gates to a program. Two different programs, in fact – and understanding that there are two is the single most useful idea in this lesson.

The same code, two tools, two meanings

Every piece of Verilog code in this course is read by at least one of two very different programs, and often both:

• A simulator (Icarus Verilog, Verilator, and similar tools) executes the code to predict what the real hardware would do, cycle by cycle, so a designer can check correctness before anything is built. A simulator will happily run code that describes something physically impossible – a ten-nanosecond delay, an infinite loop that waits for a condition that never happens – because its job is only to follow the language's rules, not to build real wires.
• A synthesis tool (Yosys, and its commercial equivalents) reads a restricted subset of the same language and turns it into an actual netlist of logic gates and flip-flops. A synthesis tool quietly ignores anything that has no physical meaning – a `#10` delay, for instance – and refuses, or produces something unintended, for constructs that do not map onto real hardware.

The practical consequence shows up constantly in this course and in real design work: a block of Verilog that simulates perfectly can still be unsynthesizable, or worse, synthesizable into hardware that does not match what the simulation showed. Lesson 11 of this path is built entirely around that gap – what synthesis tools accept, what they silently drop, and how to write code that means the same thing to both tools. For now, the only thing to remember is that "it works" has two different, independently checkable meanings for every piece of code in this course, and this course will verify both wherever a lesson's examples are synthesizable at all.

Where Verilog sits in the chip-design flow

A chip does not go from an idea directly to silicon. It passes through a sequence of representations, each one more detailed and more physically real than the last, and Verilog's job is concentrated at one particular point in that sequence.

RTL stands for register transfer level – a style of description that talks about how data moves between registers (storage elements) on each clock edge, and what combinational logic computes the values in between, without saying anything about individual gates. Writing at RTL is the entire reason HDLs took over chip design: a designer who worked at the gate level had to redraw a schematic every time the target manufacturing technology changed, while RTL Verilog can be re-synthesized onto a new technology library automatically, with the synthesis tool handling every gate-level decision. This course teaches Verilog at the RTL level almost exclusively, because that is the level a working digital designer actually writes by hand.

Why an interviewer asks about this

Three things about Verilog explain most of what shows up in an interview, and each one maps directly onto a lesson in this course. First, Verilog models concurrency and time explicitly – lessons 5 through 9 are about writing combinational and sequential logic correctly inside that model. Second, a surprising amount of Verilog's own syntax exists purely for simulation and has no synthesis meaning at all – lesson 11 draws that line precisely. Third, the language has a scheduling model underneath its concurrency that produces real, famous bugs when misunderstood – lesson 8, on blocking versus non-blocking assignment, is built entirely around that problem, because it is one of the most commonly asked topics in a Verilog interview and one of the most commonly misunderstood by self-taught designers.