Recommended resources
The freely available resources this lesson will direct you to.
Welcome back. Last lesson followed a synthesized circuit through floorplanning, placement, clock-tree synthesis, routing, and GDSII handoff. This time we will look at the information the tools need to do that work. By the end, you should be able to identify what comes from a gate-level netlist, SDC, Liberty library, technology file, and parasitic file—and, equally important, what does not come from each one.
Allow about 40 minutes for the lesson, including the short video and readings.
The netlist: what is connected?
Recall the two flip-flops and AND gate from the previous lesson. A simplified, illustrative mapped netlist might look like this:
module example (
input wire clk, d, en,
output wire q
);
wire n1, n2;
DFF_X1 u_launch (.D(d), .CK(clk), .Q(n1));
AND2_X1 u_and (.A(n1), .B(en), .Y(n2));
DFF_X1 u_capture (.D(n2), .CK(clk), .Q(q));
endmodule
This identifies the design’s ports (clk, d, en, q), cell instances (u_launch, u_and, u_capture), their library cell types (DFF_X1, AND2_X1), and the nets connecting their pins. The names and pin conventions here are examples, not a real library specification. The implementation tool must find matching definitions for those cell types in its supplied libraries.
Watch VLSI Academy’s PD Lec 8 - Netlists for a visual-to-text example. Its first example uses generic gates; notice how that differs from a synthesized netlist that names cells from a particular library.
PD Lec 8 - Netlists | PD Inputs part-2 | VLSI | Physical Design
In PD Lec 8 - Netlists, VLSI Academy builds a circuit description from ports, wires, and gate instances, then contrasts a generic description with a synthesized one.
Watch the netlist example from the module declaration through the gate connections. Then watch the synthesis distinction: a mapped netlist refers to cells chosen for a particular technology and library.
The netlist says that u_and/Y connects to u_capture/D through n2. It does not specify either cell’s location, the metal route between them, its wire resistance, or the clock period they must meet. Those answers require other inputs—or, for the final wire properties, information generated later in the flow.
SDC: what timing must the circuit meet?
A connection can be electrically valid yet too slow for its intended use. Synopsys Design Constraints (SDC) supplies the timing assumptions and requirements against which the circuit is analyzed. For example, an SDC can define a clock on clk with a specified period. It can also state when signals arrive at input ports and when outputs must be ready for circuitry outside this block.
Cornell’s ECE 5745 Section 2: ASIC Flow Back-End gives a compact example. Read the introductory SDC passage rather than trying to learn its tool setup commands yet.
ECE 5745 Section 2: ASIC Flow Back-End
Cornell’s back-end tutorial introduces the SDC as an input to place-and-route. Read it to separate a design’s timing requirements from its connectivity.
In “Using Cadence Innovus for Place-and-Route,” find the paragraph immediately after the tutorial creates its place-and-route directory. Read the SDC introduction, stopping before the instruction to create constraints.sdc. Focus on what the clock period and input/output delays express; there is no need to reproduce the tutorial’s example command.
An SDC is built from tool commands that refer to design objects such as ports, pins, and clocks. Typical contents include clock definitions; input and output delays that model the block’s external environment; and, where justified, timing exceptions or electrical limits. An SDC describes intended operating requirements, not measured gate or wire delays. A clock period is a target to check—it is not evidence that the implemented circuit meets that target.
This distinction matters when reviewing an unfamiliar block. The netlist may contain a port named clk, but the name alone does not tell a timing tool its period or which external interface assumptions apply. Conversely, an SDC command aimed at a port that does not exist in the loaded netlist cannot constrain the intended object. Checking that constraints resolve to real design objects will become part of design initialization later in the course.
Liberty: how do the chosen cells behave?
The netlist names AND2_X1, but a tool needs more than its name to estimate timing. A Liberty library, commonly a .lib file (or a tool-specific compiled .db view), describes characterized standard cells. It provides information such as pin names and directions, logic behavior, cell area, pin capacitances, timing arcs, and often power data. For sequential cells, it also describes relevant timing requirements, including setup and hold behavior.
Cell delay is not usually one fixed number per gate. For a given operating condition, a library timing model can vary an output delay with the input transition and the load driven at the output. Thus, knowing that u_and is an AND2_X1 is necessary but not sufficient to know its delay on a particular path.
Read the “Timing library (.lib)” portion of VLSI TALKS’ INPUT FILES for a closer look at what a cell timing view supplies.
Under “Timing library (.lib),” start with the library explanation. Stop at the paragraph ending in “look-up tables,” before the separate comparison of CCS and NLDM. Focus on timing, area, power, operating conditions, and why input transition and output load matter. The model acronyms are not needed for this lesson.
Liberty describes the cell, not the completed interconnect of this design. It does not tell us where u_and has been placed or how long its connection to u_capture will be. Also, a library is characterized for particular operating conditions; selecting which library view to use is a separate configuration decision. The next lesson will examine those conditions and analysis scenarios.
Technology data: what physical resources can the tool use?
Placement and routing need a physical description beyond the netlist and Liberty. A technology file—for example, technology LEF in a LEF-based flow or a tool-specific .tf file—defines information about the manufacturing technology used by the implementation tool. Depending on the format and flow, this includes items such as layer definitions, routing-layer geometry and direction, units, and the manufacturing grid. These describe the available physical framework; they do not specify the route taken by n2.
Do not confuse technology LEF with standard-cell LEF. Cell LEF gives an abstract physical view of a particular cell: notably its size and where its pins can be accessed. Technology LEF describes the broader layer and grid framework in which those cell abstracts are placed and connected. In our example, Liberty helps the tool analyze AND2_X1 electrically, while cell LEF helps it place the cell and reach its pins.
Read Cornell’s comparison of those views and its short discussion of technology data:
ECE 5745 Section 2: ASIC Flow Back-End
Cornell’s ASIC Flow Back-End tutorial contrasts logical/timing and physical cell views, then identifies separate technology and interconnect-estimation data.
In “NanGate 45nm Standard-Cell Libraries,” begin at the paragraph explaining why detailed cell layout is not used directly by the place-and-route tools. Read the cell-view comparison through the end of the paragraph about LEF containing no transistor-level information. Continue with the technology passage, stopping before “Now that we have looked at the physical views.” Focus on the different jobs of the cell LEF, technology LEF, and the tutorial’s capacitance table; the directory paths and viewer commands are incidental.
The tutorial also supplies a .captable with metal-layer resistance and capacitance information. Such technology-dependent RC data helps a tool estimate interconnect behavior. This is not the same as a parasitic file extracted from the particular wires of your finished design: the first describes properties used for estimation or extraction, while the second records parasitics associated with actual design nets.
The diagram is an inventory, not a checklist that every project receives in exactly that form. Its .lef physical libraries and .techlef/.tf technology file play different roles. Its “MMMC view file” is a way a flow may configure analyses, not another description of circuit connectivity. Likewise, an extracted parasitic file normally becomes available after physical implementation; it is not a substitute for the early technology RC data.
Parasitics: what did the implemented wires add?
Before routing, the tool must estimate wire behavior from incomplete geometry. After routing, parasitic extraction can use the implemented interconnect to determine resistance and capacitance associated with design nets. A common exchange format is SPEF (.spef). It records extracted parasitics for nets, potentially including wire resistance and capacitance to ground or between coupled nets. These electrical effects influence signal arrival times even though the netlist’s logical connections have not changed.
Cornell’s tutorial shows SPEF being produced alongside other post-route artifacts:
ECE 5745 Section 2: ASIC Flow Back-End
Return to Cornell’s tutorial to see where an extracted parasitic file enters the flow and how it differs from a final layout file.
Near the end of “Using Cadence Innovus for Place-and-Route,” locate the commands following verifyConnectivity and verify_drc. Read the output-artifact passage, stopping before the timing, area, and power report commands. Notice that extraction writes interconnect information for later analysis, whereas GDS carries layout geometry.
SPEF is design-specific: it must correspond to the implemented net names and connections being analyzed. If optimization inserts a buffer or reroutes a connection, an older parasitic file may no longer describe the current implementation. It is also important to associate extracted parasitics with the intended analysis conditions; we will make that association precise when we study corners.
Putting the five sources together
Suppose a timing report eventually says that the path through u_and is slow. The source of each piece of evidence is different:
| Question | Information to inspect |
|---|---|
| Which cell and pins form the path? | Gate-level netlist |
| What timing requirement applies? | SDC |
| How does the AND cell behave under its modeled load and operating condition? | Liberty library |
| What physical layers and grid were available for implementation? | Technology file |
| What resistance and capacitance did the implemented connection acquire? | Extracted parasitic file, such as SPEF |
A technology file and an extracted parasitic file can both concern interconnect, but at different levels: available layer properties versus the resulting design’s nets. Similarly, Liberty and LEF can both describe the same standard cell, but Liberty provides its logical and electrical characterization while cell LEF provides its placement-and-routing abstract. Keeping these boundaries clear makes it easier to diagnose a missing input or a misleading report.
Key takeaways
The netlist specifies instantiated cells and connectivity. SDC states the timing assumptions and requirements. Liberty characterizes cell behavior; the technology file defines the physical framework used to build connections; and an extracted parasitic file describes electrical effects of the implemented interconnect. No single file answers all five questions.
Next, we will distinguish process-voltage-temperature conditions, RC corners, modes, and analysis scenarios—the choices that determine which cell and interconnect data a timing check actually uses.