A netlist is a structural description of an electronic circuit that enumerates the circuit's components (cells, gates, or primitives) and the logical connections (nets) between their pins, without specifying physical placement or routing. It is the primary handoff format between logic synthesis and downstream implementation steps such as place-and-route.
In practice
In an FPGA or ASIC design flow, synthesis tools (Xilinx Vivado, Intel Quartus, Synopsys Design Compiler, Yosys, etc.) read RTL source (VHDL or Verilog/SystemVerilog) and produce a netlist mapped to a target technology library. For FPGAs, that library consists of vendor primitives such as LUTs, flip-flops, DSP blocks, and block RAMs. For ASICs, it consists of standard cells from a foundry-specific library. The netlist is then consumed by the place-and-route tool, which assigns each cell to a physical location and routes the interconnect.
Netlists appear in several forms depending on the stage of the flow. A generic or technology-independent netlist uses abstract gates (AND, OR, DFF) and is produced early in synthesis. A technology-mapped netlist references specific vendor or foundry primitives and is typically the form passed to the place-and-route engine, though some flows perform additional optimization passes or use intermediate representations between synthesis and implementation. A post-place-and-route (post-PnR) netlist, sometimes called a gate-level netlist, reflects the fully implemented design and is used for gate-level simulation to verify functional and timing correctness after implementation; timing information is supplied separately via a Standard Delay Format (SDF) file for back-annotation.
Common file formats include EDIF (Electronic Design Interchange Format), Verilog structural netlists (.v), VHDL structural netlists, and vendor-specific formats (for example, Xilinx's legacy .ngd intermediate format or Intel's .qxp export). Tools frequently read and write multiple formats; for example, Vivado can export a post-synthesis netlist as a structural Verilog file for simulation or third-party sign-off tools.
A frequent source of confusion is the difference between a behavioral simulation model and a gate-level netlist simulation. Passing RTL simulation does not guarantee passing gate-level simulation: the netlist may expose initialization issues, glitches, or hold-time violations that the RTL model did not capture. The post-PnR netlist combined with an SDF file is among the most accurate pre-silicon simulation artifacts available, though its accuracy depends on model quality, simulation setup, and the aspects of behavior under scrutiny. As discussed in "Inside the Spartan-6: Using LUTs to optimize circuits," understanding how synthesis maps logic onto LUT primitives helps designers interpret and audit netlists to catch unexpected resource usage or logic restructuring.
Frequently asked
What is the difference between a netlist and RTL source code?
RTL (Register Transfer Level) source code describes circuit behavior algorithmically, leaving implementation details to the
synthesis tool. A netlist is a structural artifact produced by synthesis: it names specific gates or primitives and explicitly lists every connection between them. RTL is human-authored and technology-independent; a netlist is tool-generated and tied to a target library or device family.
Can I simulate a netlist, and why would I want to?
Yes. Gate-level
simulation (GLS) runs a structural
Verilog or
VHDL netlist through a simulator (ModelSim, Xcelium, and similar tools) using timing models from an SDF file. GLS catches issues that
RTL simulation misses: uninitialized
flip-flops resolving to 'X', combinational glitches, and setup/hold violations under realistic delays. It is especially valuable before tapeout on ASICs and for critical
FPGA designs where timing closure is tight.
What does it mean when a tool says it cannot find a cell in the netlist?
This usually means the
synthesis tool inferred or instantiated a primitive that the target library does not contain, or that a manually instantiated component has a name mismatch. Common causes include targeting the wrong device family (e.g., a Spartan-6 primitive in a 7-series project), using unresolved
IP core outputs, or hand-editing a netlist and introducing a typo. Checking the synthesis log for unresolved references is the first debugging step.
What is a 'flattened' versus a 'hierarchical' netlist?
A hierarchical netlist preserves the design's module boundaries from the
RTL source, making it easier to read and correlate with the original code. A flattened netlist dissolves all hierarchy into a single level of primitives. Flattening enables more aggressive cross-boundary optimizations during
synthesis and place-and-route but produces larger, harder-to-navigate files. Most tools let you control hierarchy preservation per-module using synthesis attributes.
Is EDIF still commonly used as a netlist interchange format?
EDIF was the dominant interchange format for decades and is still accepted by many tools, including older Xilinx and Intel flows. However, structural
Verilog has largely replaced EDIF as the practical interchange format in modern flows because simulators and third-party tools handle it more readily. Vendor-specific binary formats are also common internally within a single toolchain but are not portable across vendors.
Differentiators vs similar concepts
A netlist is often confused with a schematic and with
RTL source. A schematic is a graphical representation of connectivity, typically drawn by hand for small analog or mixed-signal blocks; a netlist is the text-based, tool-readable equivalent of that connectivity data and is usually machine-generated. RTL source describes what the circuit should do; a netlist describes what the synthesizer built to do it, in terms of specific gates or device primitives. The distinction matters during debug: a bug visible in a netlist but not in RTL often points to a
synthesis inference issue rather than a coding bug.
