GLS · Chapter 2 · Netlists & Standard-Cell Libraries

Inside a Standard-Cell Library (.lib)

A standard-cell library describes each cell twice, and keeping the two descriptions straight is essential for gate-level simulation. The Liberty file defines a cell's function, pins, timing arcs, setup and hold constraints, and power, and it is what synthesis and static timing analysis consume. The Verilog simulation model is a separate description of the same cells that gate-level simulation actually runs, and by default it carries no timing. Gate-level simulation does not read the Liberty file at all. Instead, the Liberty timing is characterised into an SDF file that is later back-annotated onto the Verilog models to give the simulation real delays. This lesson dissects a representative Liberty snippet, fixes the split between Liberty, Verilog model, and SDF firmly in your mind, and breaks the common trap of assuming a gate run has timing just because the library contains delays.

Foundation12 min readGLSLiberty.libStandard CellsSDF

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

Project thread — 2.1 taught you to spot the cells in the counter's ancestors; 2.2 is where those cells are defined. The .lib timing here becomes the SDF you annotate in Chapter 4, and the setup/hold constraints become the timing checks of 2.5.

1. Why Should I Learn This?

Half of all gate-level confusion comes from mixing up the library's two faces: engineers see delays in the .lib and assume GLS 'has timing,' or expect GLS to match STA cycle-for-cycle. Knowing that the .lib feeds synthesis and STA, while GLS runs separate Verilog models whose timing comes only from SDF, is what lets you reason correctly about why a GLS run is zero-delay, where its timing comes from, and how it relates to STA — without which you will chase phantom mismatches.

This lesson defines the cells 2.1 taught you to spot, and it is the origin of the rest of the chapter: the Verilog simulation models (2.3), their specify/timing arcs (2.4), and their setup/hold checks (2.5) all realise what the .lib characterises — and the SDF (Chapter 4) is the bridge.

2. Real Silicon Story — the delays that were in the library but not in the sim

An engineer opens the .lib, sees detailed pin-to-pin delays and setup/hold numbers for every cell, and concludes their GLS is a full-timing run — after all, 'the timing is right there in the library.' They report timing-dependent behaviour as verified. Later, a post-layout, SDF-annotated run behaves differently, and a timing-sensitive bug is found that the earlier run 'should' have shown.

The earlier run had no timing at all. GLS does not read the .lib — it runs the cells' Verilog simulation models, which by default are zero-delay (0.4). The rich delays in the .lib are consumed by synthesis and STA, and they only reach a simulation by being characterised into an SDF and back-annotated — a step that had not been done. So the .lib being full of delays said nothing about whether the simulation had timing; the two are separate faces of the library reaching different tools by different paths. Once an SDF (derived from that .lib, for the right corner) was annotated, the simulation showed the real timing behaviour. The post-mortem lesson: a library has two faces — the Liberty (.lib) model (for synthesis/STA) and the Verilog simulation model (for GLS) — and GLS does not read the .lib; the .lib's delays reach GLS only via an SDF characterised from it and back-annotated, so a .lib full of delays does not mean the simulation has timing.

3. Concept — the library's two faces, and how timing reaches GLS

A standard-cell library describes each cell twice, for two different consumers:

The Liberty (.lib) model — for synthesis and STA. Per cell: function, pins (direction, capacitance), timing arcs (pin-to-pin delays, as lookup tables over load/slew), timing constraints (setup/hold/recovery/removal for sequential cells), and power. Characterised per corner (process/voltage/temperature).
The Verilog simulation model — for GLS. A separate description of the same cells that the simulator runs (2.3): the cell's function (primitives/UDPs) and its specify block (timing arcs and checks, 2.4/2.5). By default it carries no timing (zero/unit-delay).
GLS does not read the .lib. It runs the Verilog models. The .lib timing does not auto-apply to GLS.
How timing reaches GLS: .lib → SDF → back-annotation. The tools characterise the .lib timing into an SDF (per-instance delays), which is back-annotated onto the Verilog models' specify arcs to give the simulation real timing (Chapter 4).
The map: .lib → synthesis/STA (static timing); .lib → SDF → GLS (dynamic, simulated timing, once annotated). ASIC context: use models/SDF matching the corner STA signed off.

Here is the library structure — Liberty nesting, and the two paths out:

Figure 1 — the standard-cell library and its two faces (representative). The Liberty (.lib) model nests LIBRARY -> CELL -> PIN -> timing/power GROUPS (function, timing arcs = pin-to-pin delays, setup/hold constraints, power). The .lib feeds SYNTHESIS and STA (static timing). Separately, each cell has a VERILOG simulation model that GLS RUNS — but by default it has NO timing. The .lib timing reaches GLS ONLY by being characterised into an SDF and back-annotated onto the Verilog specify arcs (Chapter 4). GLS does not read the .lib; a .lib full of delays does not mean the simulation has timing.

4. Mental Model — the library is a spec sheet read by two different tools two different ways

Mental Model — the .lib is the parts spec sheet (read by synthesis/STA); GLS reads a different 'behaviour manual', and timing crosses over only via SDF

A standard-cell library is like a part's documentation with two documents: a spec sheet full of numbers (the .lib — delays, setup/hold, power) that the engineering/analysis tools (synthesis, STA) read, and a behaviour manual (the Verilog model) that the simulator reads. The numbers on the spec sheet do not automatically appear in the simulator — they cross over only when someone copies them into a timing addendum (the SDF).

Picture the part (a standard cell) coming with two documents. The spec sheet (.lib) lists precise numbers — 'this arc has this delay at this load, setup is this, hold is this, power is this' — and it is written for the analysis tools: synthesis uses it to pick cells and meet timing, STA uses it to check every path statically. The behaviour manual (the Verilog simulation model) describes what the cell does logically, and it is written for the simulator (GLS). Crucially, the simulator reads the behaviour manual, not the spec sheet — so all those beautiful numbers on the spec sheet are, to the simulator, invisible. By default the behaviour manual says nothing about timing (zero-delay). The only way the spec-sheet numbers reach the simulation is if someone produces a timing addendum — the SDF — by characterising the spec sheet, and staples it onto the behaviour manual (back-annotation, Chapter 4). So a spec sheet full of delays tells you nothing about whether the simulation has timing — that depends entirely on whether the addendum (SDF) was made and attached. This dissolves the common confusion: 'the .lib has delays, so my GLS has timing' is a category error — the .lib and the simulation are read by different tools, and timing only crosses between them via SDF. It also frames the relationship to STA: STA and GLS are not redundant reads of the same document — STA reads the spec sheet exhaustively and statically; GLS reads the behaviour manual dynamically on stimulus, timed only if the addendum is attached.

Two anchors:

GLS reads the Verilog model, not the .lib. The .lib's delays feed synthesis/STA; they reach GLS only via SDF characterised from the .lib and back-annotated (Ch4).
A .lib full of delays does not mean the simulation has timing. Timing in GLS depends on whether an SDF was made and annotated — not on the .lib being rich.

5. Working Example — a representative Liberty cell, and where its numbers go

Here is a representative Liberty (.lib) fragment for a flip-flop cell — the shape, not exact tool output.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

/* Liberty (.lib) — REPRESENTATIVE (shape only; real .lib is far larger, per corner) */
cell (DFFRX1) {
  ff (IQ, IQN) { next_state : "D"; clocked_on : "CK"; clear : "!RN"; }
  pin (CK) { direction : input;  clock : true; capacitance : 0.003; }
  pin (D)  { direction : input;  capacitance : 0.002;
             timing () { related_pin : "CK"; timing_type : setup_rising; /* setup constraint -> 2.5 */ } }
  pin (Q)  { direction : output; function : "IQ";
             timing () { related_pin : "CK"; timing_type : rising_edge;  /* CK->Q arc (delay) -> SDF */ } }
}

That .lib is consumed by synthesis and STA. GLS, separately, runs the cell's Verilog model — which by default has no timing. The .lib numbers reach GLS only via SDF:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# WHERE THE .lib NUMBERS GO (two paths):
.lib  ->  SYNTHESIS  (pick DFFRX1, meet timing)        # analysis tool reads .lib
.lib  ->  STA        (check setup/hold on every path)  # analysis tool reads .lib  (EXHAUSTIVE, static)
.lib  ->  SDF        ->  back-annotate  ->  GLS         # ONLY way .lib timing reaches the simulation (Ch4)
# GLS itself runs the VERILOG model (2.3) — zero-delay until the SDF is annotated. GLS never reads .lib.

The .lib is the origin of the CK→Q delay (which becomes an SDF number) and the D-vs-CK setup constraint (which becomes a timing check in the model, 2.5). But none of it is in the GLS run until the SDF path is used — the trap of the next section.

6. Debugging Session — "the .lib has delays, so my GLS has timing"

A gate-level run is assumed to be full-timing because the .lib is full of delays — but GLS runs zero-delay Verilog models and only gets timing from an annotated SDF, so the run had no timing at all

.lib FEEDS STA/SDF; GLS TIMING COMES FROM SDF

Symptom

An engineer runs GLS, notes that the .lib contains detailed delays and setup/hold numbers for every cell, and reports the run as full-timing ('the timing is in the library'). A later SDF-annotated run behaves differently, and a timing-sensitive bug appears that the earlier run 'should' have caught.

Root Cause

A category error about the library's two faces. The .lib (Liberty) model — full of delays and setup/hold constraints — is consumed by synthesis and STA, not by the simulator. GLS runs the cells' Verilog simulation models (2.3), which are separate and, by default, zero-delay (0.4/1.4). GLS does not read the .lib, so the .lib's delays are invisible to the simulation unless they are characterised into an SDF and back-annotated onto the models' specify arcs (Chapter 4) — a step that was not performed. So the earlier run had no timing at all: it was a zero-delay functional run, and the rich .lib said nothing about whether the simulation was timed. The two faces of the library reach different tools by different paths, and the .lib being detailed does not put timing into a simulation that never received an SDF. It is not a library bug or a simulation bug; it is a misunderstanding of where GLS timing comes from — the SDF path, not the .lib directly.

Fix

For a timing gate-level run, characterise an SDF from the .lib (for the correct corner, matching STA signoff) and back-annotate it onto the netlist's Verilog models (Chapter 4) — only then does GLS carry the .lib-derived delays and setup/hold checks. For a functional run (netlist equivalence, X/reset), zero-delay is fine and expected — just do not call it full-timing. The lesson: a library has two faces — Liberty (.lib) for synthesis/STA and the Verilog model for GLS — and GLS does not read the .lib; its timing comes only from an SDF characterised from the .lib and back-annotated, so a .lib full of delays does not mean the simulation has timing. And to be precise about scope: even a full-timing GLS is not a substitute for STA — STA checks all paths statically and exhaustively, while GLS exercises only stimulated paths dynamically (0.3); the .lib feeds both, by different routes.

7. Common Mistakes

Assuming GLS reads the .lib. It does not — GLS runs the Verilog models; the .lib feeds synthesis/STA, and reaches GLS only via SDF (Ch4).
Thinking a .lib full of delays means a timed simulation. Timing in GLS depends on an annotated SDF, not on the .lib being rich.
Calling a zero-delay run 'full-timing.' Without SDF, GLS is zero/unit-delay regardless of how detailed the .lib is.
Using models/SDF from the wrong corner. Match the process/voltage/temperature corner STA signed off (ASIC context).
Treating GLS as a replacement for STA. STA is static and exhaustive; full-timing GLS is dynamic and stimulus-limited — complementary, not interchangeable (0.3).

8. Industry Best Practices

Keep the library's two faces distinct. .lib → synthesis/STA; Verilog models → GLS; SDF bridges .lib timing into GLS.
Characterise and annotate SDF for timing GLS. GLS timing comes from an annotated SDF derived from the .lib (Ch4) — not from the .lib directly.
Match the corner across STA, models, and SDF. Use the process/voltage/temperature corner STA signed off, for an ASIC-consistent picture.
Label your run by its timing mode. Zero-delay functional vs SDF full-timing — do not conflate them (0.4).
Reason about STA and GLS as complementary. Static-exhaustive (STA) vs dynamic-stimulus (GLS); the .lib feeds both.

Senior Engineer Thinking

Beginner: "The .lib has all the delays, so my gate sim is timed."
Senior: "GLS runs the Verilog models, not the .lib. The .lib's delays feed STA and get characterised into SDF — my sim is timed only if I annotated that SDF. Did I? If not, this is a zero-delay run."

The senior separates the library's two faces and knows GLS timing arrives via SDF, not by GLS reading the .lib.

Silicon Impact

Confusing the two faces has a real cost. Believe a zero-delay run is 'full-timing' because the .lib is rich, and you skip the actual SDF-annotated run — letting timing-dependent functional bugs escape (the Ch0/0.3 post-layout escape), which surface as intermittent, corner-sensitive silicon failures and field returns. Or, mistaking GLS for STA, you under-run static timing coverage and miss a path no stimulus exercised. The .lib is the shared origin of both analyses, but they are different signoffs by different routes: STA (static, exhaustive) and full-timing GLS (dynamic, stimulus, via SDF). Getting the routing right is what keeps timing bugs off the tape-out.

Engineering Checklist

Kept the two faces distinct: .lib → synthesis/STA; Verilog models → GLS.
For a timing run, characterised an SDF from the .lib and back-annotated it (Ch4).
Matched the corner across STA, cell models, and SDF (ASIC signoff context).
Labelled the run correctly (zero-delay functional vs SDF full-timing).
Did not treat GLS as a replacement for STA (static-exhaustive vs dynamic-stimulus).

Try Yourself

Open (or sketch) a representative .lib cell and note its CK→Q arc delay and its D-vs-CK setup number.
Observe: run GLS on a netlist using that cell without an SDF — the CK→Q transition is instant (zero-delay); the .lib delay does not appear.
Change: back-annotate an SDF (Chapter 4) carrying that arc delay and re-run.
Expect: now Q updates a real delay after CK — proving the .lib number reached GLS via SDF, not directly. Trace the number: .lib → SDF → GLS.

Any Verilog simulator plus an SDF-capable flow demonstrates this; real .lib/SDF are vendor/PDK artifacts, but the routing (.lib → SDF → GLS) is tool-independent. No paid tool is required to understand the concept.

Interview Perspective

Weak: "The library has delays, so gate-level sim has timing."
Good: "The .lib feeds synthesis and STA; GLS runs separate Verilog models and only gets timing from an annotated SDF."
Senior: "The library has two faces reaching different tools by different paths. .lib → STA (static). .lib → SDF → GLS (dynamic). I confirm an SDF was annotated before calling a gate run 'timed,' and I never mistake GLS for STA."

9. Interview / Review Questions

10. Key Takeaways

A standard-cell library has two faces: the Liberty (.lib) model (function, pins, timing arcs, setup/hold constraints, power) for synthesis and STA, and the Verilog simulation model that GLS runs.
GLS does not read the .lib — it runs the Verilog models, which carry no timing by default (zero/unit-delay, 0.4/1.4).
The .lib's timing reaches GLS only via SDF: the tools characterise the .lib into an SDF and back-annotate it onto the models' specify arcs (Chapter 4) — so a .lib full of delays does not mean the simulation has timing.
The map: .lib → synthesis/STA (static, exhaustive) and .lib → SDF → GLS (dynamic, stimulus) — complementary signoffs by different routes; GLS is not a replacement for STA.
Use models/SDF matching the corner STA signed off (ASIC context), and label runs by timing mode (zero-delay functional vs SDF full-timing). Next: 2.3 — the Verilog simulation models GLS actually runs (and UDPs).

Quick Revision

Two faces, two paths. Liberty (.lib) = function/arcs/setup-hold/power → synthesis + STA. Verilog model = what GLS runs (no timing by default). GLS never reads the .lib; its timing arrives via SDF characterised from the .lib and back-annotated (Ch4). A rich .lib ≠ a timed simulation. STA (static/exhaustive) and GLS (dynamic/stimulus) are complementary. Next: 2.3 — cell simulation models & UDPs.