Hardware description language field guide

Verilog, from source text to working hardware

Verilog describes concurrent digital systems: signals change, processes react, time advances, and a design gradually becomes something a simulator can test or a synthesis tool can map into gates.

A language for structure, behavior, and time

A Verilog module can express several views of the same circuit. Structural code names instances and the nets between them. Register-transfer code describes how values move and transform on clock edges. Behavioral test code can generate stimulus, wait for events, and report results. The language is compact, but its meaning depends on concurrency and event scheduling. Two always blocks do not take turns like two lines in a conventional program; both participate in the same simulated system.

That distinction explains many beginner surprises. A blocking assignment updates immediately within its procedural thread. A nonblocking assignment schedules an update for a later simulation region, allowing clocked processes to sample a common prior state. Delay controls have simulation meaning but are generally not a description of physical propagation that synthesis will preserve. Four-state values help expose unknown or undriven conditions that ordinary two-state arithmetic would hide.

The working flow

A practical flow begins with a specification and a small, explicit interface. The designer writes modules, clocks, resets, and data paths. A linter or compiler catches malformed code and suspicious constructs. Simulation then executes the design with a testbench, producing messages and waveform data. Assertions and scoreboards turn intended behavior into checks rather than leaving correctness to visual inspection.

Synthesis interprets the synthesizable subset and creates a technology-independent network before mapping it to a target. Static timing analysis checks whether paths can meet the clock and interface constraints. Formal methods can prove focused properties or compare transformations. None of these stages substitutes for the others. A clean compile does not imply useful behavior; a passing simulation does not imply timing closure; a synthesizable design can still be difficult to verify.

A directory with explanations attached

Verilog.Net began as a community directory: documentation, free tools, vendors, books, engineering magazines, and verification papers arranged so a practitioner could find the next useful lead. That organizing idea remains sound, but a link alone is rarely enough. Each section here explains what a resource category is for, which stage of the flow it serves, and what a reader should verify before adopting it.

The older ecosystem mixed commercial simulators, workstation utilities, Perl preprocessors, hand-written programming-language interfaces, printed language guides, and conference papers. Some names remain recognizable; others belong to an earlier tool market. They are presented as historical context, not as claims of current availability or endorsement. Current external references are limited to pages that can be checked directly and that still contain the material described.

The language itself also evolved. IEEE 1364 standardized Verilog and received major revisions in 2001 and 2005. Its concepts were later incorporated into the SystemVerilog family under IEEE 1800. The language history page separates that standards lineage from tool behavior, while the glossary supplies a compact vocabulary for reading manuals and diagnostics.

Choose a starting point

Verilog.Net is independent. References to standards organizations, publishers, projects, and companies are descriptive and do not imply affiliation.