Anatomy of a Synthesized Netlist

Chapter 2 · Section 2.1 · Netlists & Standard-Cell Libraries

Project thread — Chapter 1 turned the D flip-flop from RTL into gates; Chapter 2 teaches you to read those gates, building toward reading a full counter netlist in 2.6. This lesson is the alphabet; 2.2 defines the cells it uses.

1. Why Should I Learn This?

Every gate-level debug session starts by reading the netlist — finding the flop that came up X, the cell that glitched, the path that violated. If a netlist looks like an unreadable wall of U-names and n-nets, you are helpless at the exact moment GLS matters most. Learning the anatomy — module, ports, nets, cell instances, hierarchy — turns that wall into a map you can navigate, and it teaches the one setup fact that stops most first GLS runs cold: the netlist names cells, but only simulates them if their library models are linked.

This lesson is the alphabet of Chapter 2: 2.2 (the library the cells come from), 2.3 (their simulation models), 2.4 (their timing), and 2.5 (their sequential behaviour) all describe parts of the cells you first learn to spot here.

2. Real Silicon Story — the netlist that would not elaborate

A team gets the synthesized netlist and, for the first time, tries to run GLS on it. The simulator refuses to start — it errors out during elaboration with Module 'DFFRX1' not found and a stack of similar messages for other cell names. The instinct is 'the netlist is corrupt' or 'synthesis produced garbage,' and time is lost re-running synthesis.

The netlist was fine. A synthesized netlist references library cells by name (DFFRX1, NAND2X1) but does not contain their definitions — those live in the library's Verilog simulation models, a separate file the simulator must compile alongside the netlist. The team had compiled the netlist but not linked the cell library models, so every cell instance referenced a module the simulator had never seen — hence 'module not found.' It is not a netlist bug or a synthesis bug; it is a missing library in the compile command. Adding the standard-cell simulation library to the compile made the netlist elaborate immediately. The post-mortem lesson: a synthesized netlist instantiates library cells by name but does not define them — their Verilog simulation models come from the library, separately — so GLS only elaborates when the cell library models are compiled and linked with the netlist; a 'module not found' on a cell name is a missing-library setup issue, not a corrupt netlist.

3. Concept — what a netlist is made of

A synthesized netlist is structural Verilog — gates, not behaviour. Its parts:

• The module + ports. A module header with input/output port declarations — the design's boundary. No behavioural code inside.
• Nets (wires). wire declarations for the internal connections synthesis created — names like n47 are tool-generated and meaningless.
• Cell instances. The body is instances of standard-cell library cells — NAND2X1 U0 (.A(a), .B(b), .Y(n1)); — each an instance of a library cell, wired to nets by named port connections. Instance names (U0, U1) are tool-generated.
• Hierarchy. A larger design is a tree: the top module instantiates sub-modules, which instantiate cells (2.6, and Chapter 12's SoC).
• The library coupling (key for GLS). The netlist names cells but does not define them; their Verilog simulation models come from the library (2.2–2.5) and must be compiled and linked for GLS to elaborate.

Here is the anatomy — the parts you learn to spot:

4. Mental Model — a netlist is a wiring diagram; the cells are parts you must have in stock

5. Working Example — reading a representative netlist

Here is a representative synthesized netlist for a tiny design (an AND feeding a flip-flop). It is structural — spot the parts.

// NETLIST (representative — real cell names/ports vary by library): structural Verilog, no behaviour.
module top (input clk, input rst_n, input a, input b, output q);
  wire n1;                                   // NET: tool-generated internal connection
  AND2X1  U0 (.A(a),  .B(b),  .Y(n1));       // CELL INSTANCE: a library AND gate (U0 tool-generated)
  DFFRX1  U1 (.D(n1), .CK(clk), .RN(rst_n), .Q(q));   // CELL INSTANCE: a library D flip-flop with reset
endmodule

Reading it: top has ports clk/rst_n/a/b/q; n1 is an internal net; U0 is an AND cell computing a & b onto n1; U1 is a flip-flop capturing n1 on clk, reset by rst_n, output q. No behaviour — just two wired cells.

To run it in GLS, you compile the netlist and link the library's simulation models. A representative elaboration/compile log:

# Representative simulator elaboration log — netlist + LINKED library models:
Compiling  top.v (netlist)
Linking    stdcells_sim.v (library simulation models)   <- REQUIRED: defines AND2X1, DFFRX1
Elaborate  top
  instance U0 : AND2X1   (resolved from library)
  instance U1 : DFFRX1   (resolved from library)
Elaboration complete: 2 cell instances, 1 net.        <- netlist reads cleanly once the library is linked

Every cell instance resolves because the library models are linked. Omit the library, and each instance references an undefined module — the failure of the next section.

6. Debugging Session — a netlist that will not elaborate

7. Common Mistakes

• Not linking the cell library simulation models. The netlist names cells but does not define them — a 'module not found' on a cell name is a missing-library issue (link the library models).
• Reading tool-generated names as meaningful. U0, n47 are labels — read the structure (which cell, wired to which nets), not the names.
• Assuming a 'module not found' means a corrupt netlist. The netlist is usually fine; the library was not linked.
• Using the wrong library models. Link the models matching the process/corner synthesis targeted (2.2), not an arbitrary library.
• Expecting behavioural code in a netlist. There is none — only cell instances and nets; the behaviour became the gates.

8. Industry Best Practices

• Always link the standard-cell simulation library with the netlist. GLS needs the cell models to elaborate — make it part of the compile command/script.
• Match the library to what synthesis targeted. Use the correct process/corner cell models (2.2) so GLS reflects the real cells.
• Read a netlist by structure, not names. Module → ports → nets → cell instances → hierarchy; ignore the tool-generated U/n labels.
• Diagnose elaboration errors on cell names as missing-library. Not a corrupt netlist — link the models.
• Keep the netlist and its library versioned together. The netlist is only meaningful with the matching library models.

Senior Engineer Thinking

• Beginner: "GLS won't elaborate — the netlist is corrupt, re-run synthesis."
• Senior: "The error is on a cell name (DFFRX1), at elaboration. The netlist references library cells; it doesn't define them. I didn't link the library models. That is a compile-setup fix, not a synthesis re-run."

The senior reads what failed (a library cell name) and when (elaboration/link) and routes it to the library, not the netlist or synthesis.

Silicon Impact

This particular failure is a setup blocker, not a silicon escape — but its consequence is schedule: a mis-diagnosed 'corrupt netlist' can send a team re-running synthesis, chasing tool support, or delaying the entire gate-level signoff over a one-line compile fix. And the deeper skill it forces — reading the netlist — is what determines whether real gate-level bugs (the X, the glitch, the violation of later chapters) get found at all. A team that cannot read its netlist cannot debug its gate level, and the bugs GLS exists to catch (Ch0) sail through to silicon as field returns. Netlist literacy is the foundation the whole signoff rests on.

Engineering Checklist

• Compiled/linked the standard-cell simulation library with the netlist.
• Used library models matching the process/corner synthesis targeted.
• Read the netlist by structure (module/ports/nets/instances/hierarchy), not tool-generated names.
• Diagnosed any 'module not found' on a cell name as a missing-library link, not a corrupt netlist.
• Confirmed elaboration resolves every cell instance before trusting the run.

Try Yourself

1. Take the representative netlist above and try to elaborate it without the library models (compile only the netlist).
2. Observe: the simulator errors with 'module AND2X1 / DFFRX1 not found' at elaboration.
3. Change: add a tiny local stub definition for each cell (module AND2X1(...); ... endmodule) — or link a real cell library — and re-elaborate.
4. Expect: it now elaborates and resolves both instances. The netlist was always fine; the cells just needed definitions.

Any Verilog simulator works — open-source or commercial. Real standard-cell libraries are vendor-supplied; the concept (link the cell models) is tool-independent.

Interview Perspective

• Weak: "The netlist didn't work, so it's a bad netlist."
• Good: "A netlist references library cells by name; GLS needs the library's simulation models linked, or it can't elaborate."
• Senior: "I read what failed and when: a cell-name 'module not found' at elaboration is a missing-library link — the netlist is a wiring diagram, the library supplies the parts. I link the matching-corner models and move on."

9. Interview / Review Questions

10. Key Takeaways

• A synthesized netlist is structural Verilog — a module + ports, net (wire) declarations, and standard-cell instances wired by named ports, possibly a hierarchy — with no always/assign/behaviour.
• Instance and net names (U0, n47) are tool-generated — read a netlist by its structure (which cell, wired to which nets), not the names.
• The netlist names cells but does not define them — each cell's Verilog simulation model comes from the library (2.2–2.5), separately, and must be compiled/linked for GLS to elaborate.
• The signature setup failure is 'module not found' on a cell name at elaboration — a missing-library link, not a corrupt netlist or a synthesis bug; link the matching-corner cell models.
• Netlist literacy is the foundation of gate-level debug — you cannot find the X, glitch, or violation (later chapters) in a netlist you cannot read. Next: 2.2 opens the library those cells come from.

Quick Revision

A netlist is a wiring diagram of standard cells. Structural Verilog: module + ports + nets + cell instances (+ hierarchy), no behaviour; U/n names are tool-generated. The netlist names cells; the library defines them (their Verilog models) — GLS needs those models linked, or it fails to elaborate ('module not found' = missing library, not a bad netlist). Next: 2.2 — inside the standard-cell library (.lib).