S4-4.4 Verilog HDL: Gate & Dataflow Modelling

What this is and why it exists

Schematics stop scaling somewhere around a few hundred gates; chips carry billions. The industry's answer is to DESCRIBE hardware in text and let tools build it, and Verilog is one of the two languages that do it. The mental shift is everything here: Verilog is not a program. Statements do not run one after another — they describe pieces of hardware that all exist at once, forever, in parallel. Gate-level and dataflow modelling are the on-ramp because they map one-to-one onto the circuits from earlier units, and the stimulus block matters because in real projects verifying the design is half the work.

The vocabulary

• VLSI design flow — specification, RTL description, simulation, synthesis, placement and routing, fabrication: text in, silicon out.
• Module — Verilog's unit of hardware: a named block with ports, instantiable inside other modules.
• wire and reg — the two families of data types: wires are driven connections; reg holds a value assigned inside procedural code (and does not necessarily mean a physical register).
• Gate-level modelling — instantiating primitive gates (and, or, nand…) and wiring them: the schematic, typed.
• Dataflow modelling — continuous assignments (the assign statement): the output is permanently computed from the expression, like combinational logic is.
• Delays — modelled lags between cause and effect, for simulation realism; ignored by synthesis.
• System tasks and compiler directives — simulator commands (display, monitor, finish) and source-processing controls (timescale, define), written with their dollar and backquote prefixes in code.
• Stimulus block (testbench) — a non-synthesised module that instantiates your design, drives its inputs over time, and observes outputs.

The mental model

A Verilog source file is a wiring diagram that happens to be text. When you write three assign statements, you have not written three steps of a recipe — you have soldered three permanent pieces of combinational logic that all compute continuously, and their order in the file means nothing. The question to ask of every line is never "when does this execute?" but "WHAT HARDWARE IS THIS?". That one question separates people who write synthesisable designs from people who fight the tools.

Gate-level modelling is the gentlest entry because the answer to the question is literal: each primitive instantiation is that gate. Build the full adder from and/xor/or primitives and the code IS the schematic from the combinational unit. Dataflow lifts one level: assign sum = a ^ b ^ cin describes the same adder by its Boolean truth and lets the tool choose gates. Most real combinational code is dataflow.

Simulation is where time enters. Delays annotate how long after an input change an output responds — useful for observing glitches and hazards in waveforms — but synthesis ignores them: real delay comes from real gates and wires, not from annotations. The testbench is the other half of the craft: a module with no ports that instantiates the design (the device under test), drives input patterns with timed procedural code, and prints or logs what comes out. Treat it as a first-class deliverable — in industry, verification engineers outnumber designers, and the habit of writing the testbench alongside the design is what the lab is really teaching. Writing both a gate-level and a dataflow version of one circuit and driving them with the same stimulus proves the equivalence better than any argument.

What you should now be able to explain or do

Narrate the VLSI flow from text to silicon in five steps. Answer "what hardware is this?" for any gate-level or dataflow line. Write a module both ways and a stimulus block that exercises every input combination. Say what delays model and why synthesis discards them.

Check yourself