What is multi-corner multi-mode timing analysis?

A corner is a set of physical conditions such as process, voltage, temperature and interconnect variation. A mode is an operating configuration such as functional, scan test, or a low-power state. Every combination of corner and mode is a scenario, and both setup and hold must be verified in each one. A design with four corners and three modes therefore has twenty-four checks, not one.

What does LVS actually compare?

Layout versus schematic extracts a transistor-level netlist from the final layout geometry and compares it against the netlist the design flow produced. It confirms that every device exists, that connectivity matches, and that device sizes agree. It catches shorts between nets, opens, unconnected macro power pins, swapped supply connections, and any place where an abstract view disagreed with the real geometry.

Why is metal density checked before tape-out?

Chemical mechanical polishing planarises each metal layer, and it removes material unevenly if the pattern density varies too much across the die. Regions with too little metal dish, and regions with too much can leave residue that shorts neighbouring wires. Foundries therefore specify both minimum and maximum density per layer, and metal fill shapes are added in sparse regions to satisfy the rule.

Volume 06 Advanced 5 sub-modules ~55 min read

Sign-Off: STA, DRC & LVS

Sign-off is where you stop improving the design and start proving things about it. Three questions, three independent tools, and no partial credit: is it fast enough under every condition it will ever see, can the foundry physically build it, and is the thing on the mask actually the circuit you designed? A mask set costs real money and takes weeks. There is no patch release.

6.1 Multi-corner, multi-mode

Volume 01 introduced PVT corners. Sign-off needs the full matrix, because a chip is not one circuit - it is one circuit under many conditions, in several operating configurations.

Figure 6.1 - The MCMM matrix. Notice that tt is a sanity check, not a sign-off condition - real sign-off happens at the extremes.

On-chip variation

Corners capture variation between chips. But two cells on the same die also differ - from dopant fluctuation, lithography gradients, local temperature and local IR drop. This is OCV, and it is handled by derating: make the launch path pessimistic and the capture path optimistic simultaneously, even though no single die is both.


# Simple flat derating. Setup: slow the data path, speed the clock path
# that captures it - the worst combination for setup.
set_timing_derate -early 0.95
set_timing_derate -late  1.05

# The common part of the two clock paths cannot vary against itself, so
# removing that shared pessimism recovers real, legitimate margin. On a
# deep clock tree this is often worth 100-200 ps.
set_clock_uncertainty -setup 0.10 [get_clocks clk]
set timing_remove_clock_reconvergence_pessimism 1

# Advanced flows replace the flat 5% with distance- and depth-dependent
# derating (AOCV) or a statistical model (POCV), because a flat number is
# far too pessimistic on short paths and not pessimistic enough on long
# ones.

6.2 OpenSTA and the sign-off loop

Sign-off STA differs from the timing you have been reading during implementation in three ways: it reads real parasitics, it runs every scenario, and it is run by a tool that had no hand in creating the design.


# One scenario. A real sign-off script loops over all of them.

# ---- 1. the library for THIS corner ---------------------------------
read_liberty $::env(PDK_ROOT)/sky130A/libs.ref/sky130_fd_sc_hd/lib/\
sky130_fd_sc_hd__ss_100C_1v60.lib

# ---- 2. the final routed netlist ------------------------------------
read_verilog results/final/counter.v
link_design counter

# ---- 3. real parasitics from Volume 05 ------------------------------
# Without this line you are timing a design with no wires.
read_spef results/final/counter.spef

# ---- 4. constraints, plus propagated clocks -------------------------
read_sdc src/counter.sdc
set_propagated_clock [all_clocks]

# ---- 5. the checks --------------------------------------------------
report_checks -path_delay max -corner ss -group_count 20  ;# setup
report_checks -path_delay min -corner ss -group_count 20  ;# hold

# Everything the design must NOT have, in one command.
report_check_types -max_slew -max_capacitance -max_fanout -violators

# The number that goes in the report to your manager.
report_worst_slack -max
report_tns

The check that catches missing constraints report_checks only reports on paths it was told to analyse. Before believing a clean result, run check_setup - it lists unconstrained endpoints, undefined clocks, ports with no input delay and combinational loops. A design with zero violations and 300 unconstrained endpoints has not been signed off; it has been partially ignored. This is the same discipline as the FPGA course's insistence on reading check_timing before WNS.

6.3 Design rule checking with Magic

DRC asks one question: can the foundry actually manufacture this geometry? It knows nothing about your logic. It compares every polygon on every layer against a rule deck supplied by the foundry, and the rules exist because lithography, etch and polishing all have physical limits.

Rule family	Checks	Why the process needs it
Minimum width	No shape thinner than the limit	Thinner lines do not print reliably, or open
Minimum spacing	Gap between shapes on one layer	Closer shapes merge during lithography
Enclosure / overlap	Metal must extend past a via by a margin	Layer-to-layer misalignment between masks
Density	Metal coverage per layer, both a floor and a ceiling	CMP polishes unevenly where density varies
Antenna	Metal-to-gate area ratio	Charge damage during plasma etch (§5.3)
Latch-up / well	Tap spacing, well contact rules	Parasitic thyristor turn-on (§3.4)

Density fill is not cosmetic Chemical mechanical polishing planarises each metal layer by grinding it flat. Where a region has very little metal, the polish dishes - it removes too much and the layer above sits at the wrong height. Where there is too much, residue can be left behind and short adjacent wires. So foundries specify a minimum and a maximum density per layer, and sparse regions get filled with floating metal rectangles that connect to nothing. Fill adds capacitance to nearby signals, which is why it is inserted before the final extraction and not after.


# Magic reads the DRC rules straight out of the PDK tech file.
tech load $::env(PDK_ROOT)/sky130A/libs.tech/magic/sky130A.tech

gds read results/final/counter.gds
load counter

# Check the whole cell hierarchy, not just the top level.
drc euclidean on          ;# proper diagonal distances, not Manhattan
drc style drc(full)       ;# the strict deck - use this for sign-off
select top cell
drc check
drc catchup

set count [drc list count total]
puts "DRC violations: $count"

# Write them out so they can be loaded and located in a layout viewer.
drc listall why

6.4 LVS: layout versus schematic

DRC proves the layout is manufacturable. It does not prove it is your circuit. A layout with two nets accidentally shorted can be perfectly DRC clean.

LVS closes that gap by extracting a transistor-level netlist from the final geometry and comparing it, node by node and device by device, against the netlist the design flow produced.

Figure 6.4 - LVS. Both sides are reduced to transistors and compared as graphs. This is the check that catches a LEF whose pin rectangle never matched its GDS.

Common LVS failure	Usual cause
Shorted nets	Two wires on the same layer touching - often the router working around an obstruction
Open nets	A missing via, or a pin the router connected to the LEF rectangle but not to the real GDS shape
Unconnected macro power	The PDN reached the macro's outline but never dropped a via onto its supply pin. Extremely common
Property mismatch	Transistor width or length differs - usually a stale cell view
Port name mismatch	Top-level pin named differently in the two sides. Cosmetic, but it blocks the run
Missing tap connections	Tap cells placed but their well contacts never tied to the rails

6.5 The tape-out checklist

Tape-out is the moment the GDS is sent to the mask shop. Everything below has to be green, with a name against it, before that happens.

#	Check	Passing means
1	Setup timing, every corner and mode	WNS ≥ 0 in all scenarios, with propagated clocks and SPEF
2	Hold timing, every corner and mode	WHS ≥ 0, checked especially at the fast corner
3	`check_setup` clean	No unconstrained endpoints, no undefined clocks, no loops
4	Max transition, capacitance, fanout	Zero DRV violations against real parasitics
5	DRC clean	Zero violations under the sign-off rule deck
6	LVS clean	"Circuits match uniquely" - no shorts, opens or property mismatches
7	Antenna clean	Every ratio within the PDK limit
8	Density fill inserted and re-extracted	Fill counted in the parasitics timing was signed off with
9	IR drop within budget	Static and dynamic, both under the limit from Volume 03
10	Gate-level simulation passes	The post-route netlist is functionally correct with real delays
11	GDS merged and XOR-checked	Standard cell GDS merged in; XOR against the previous version shows only intended changes
12	Scan chains verified	DFT coverage met and the chains actually connect end to end

Item 10 is the one teams skip Gate-level simulation on the final netlist with back-annotated delays is slow, awkward and frequently dropped when the schedule tightens. It is also the only check in the list that verifies function rather than a property. STA proves the design is fast enough; DRC proves it is buildable; LVS proves the layout matches the netlist. None of them proves the netlist does the right thing. An X propagating from an uninitialised register, a reset that never reaches part of the design, a scan chain left in test mode - all of these pass 1 through 9 and fail in silicon.

Interview grilling - "You have one week and three failures: 12 DRC errors, an LVS mismatch, and -80 ps of setup slack. Order them."

The question is about judgement under a deadline, and the ordering is not by severity - it is by how much other work each one invalidates.

LVS first. An LVS mismatch means you do not know what circuit you have. If it turns out to be a real short, every timing and DRC result computed on that database is describing a different design. Nothing else is trustworthy until this is resolved, and it is often a five-minute fix (an unconnected macro power pin) hiding behind an alarming report.
DRC second. Twelve violations is a small, bounded number - likely localised, likely fixable with a targeted ECO. Critically, fixing DRC changes geometry, which changes parasitics, which changes timing. Doing it after closing timing means re-closing timing.
Setup last. -80 ps is small and there are many levers: an ECO buffer, a cell upsize, useful skew on that one path. And it must be done last anyway, because the two fixes above will move it.

The sentence that earns the offer: "I would also ask whether the -80 ps is at the slow corner with a signal-integrity-aware run and final fill included. If it is a preliminary number, I might be optimising against a target that is about to move anyway."

Volume 06 recap

Concept	The one thing to remember
MCMM	corners × modes × {setup, hold}. Typical is a sanity check, not sign-off.
OCV derating	Launch pessimistic, capture optimistic - a combination no single die has.
Sign-off STA	SPEF + propagated clocks, or you are timing an imaginary design.
`check_setup`	Zero violations with 300 unconstrained endpoints is not clean.
DRC	Manufacturability only. Says nothing about your circuit.
Density fill	Required by CMP, and it changes your parasitics. Extract after.
LVS	"Match uniquely" or it does not ship. Macro power pins fail most often.
Gate-level sim	The only check that verifies function. Do not skip it.

That is the whole Academy Three courses and twenty-four volumes: RTL that describes hardware rather than software, FPGA implementation that lands on real fabric, and the full RTL-to-GDSII flow on an open-source PDK. You now have the complete path from an always block to a GDSII file a foundry will accept. The obvious next step is to run it - take a design you already wrote, push it through OpenLane, and see which of these volumes you end up re-reading. Subscribe on YouTube for what comes next.