The Semiconductor Flow & What a PDK Contains
An FPGA hands you a finished grid and asks you to fit into it. An ASIC hands you a library of cells and a rulebook, and then you place every single transistor-level object yourself, decide where the power comes from, and build the clock tree by hand. Nothing is pre-built. That is the cost, and it is also the entire reason an ASIC is ten times faster at a tenth of the power.
1.1 Front-end and back-end
The industry splits chip design into two halves at the point where the design stops being logic and starts being geometry. Job titles, tools and even buildings follow that split, so it is worth knowing exactly where the line sits.
| Front-end (RTL / logic design) | Back-end (physical design) | |
|---|---|---|
| Input | A specification | A gate-level netlist |
| Output | Verified, synthesizable RTL | GDSII ready for masks |
| Question answered | Does it compute the right thing? | Can it be built, and will it run at speed? |
| Units | Bits, cycles, states | Microns, femtofarads, milliwatts |
| Covered by | Course 01 | This course |
1.2 Anatomy of a standard cell
A standard cell is a small, pre-drawn, pre-characterised piece of layout implementing one logic function at one drive strength. The library holds a few hundred of them, and your entire chip - apart from memories and analogue - is built from nothing else.
The defining property is that every cell has the same height. Width varies with complexity; height never does. That single constraint is what makes automated placement possible.
hd library); width grows with complexity and drive strength.
Rows are mirrored vertically so neighbouring rows share a rail.
Reading a cell name
Sky130 cell names are systematic, and once you can decode one you can read a netlist without looking anything up:
sky130_fd_sc_hd__nand2_4
| | | | | |
| | | | | +--- drive strength (4x the unit inverter)
| | | | +--------- function: 2-input NAND
| | | +-------------- library variant: hd = high density
| | +----------------- sc = standard cell
| +-------------------- fd = foundry (SkyWater's own)
+--------------------------- process: SkyWater 130 nm
Common hd cells you will see everywhere:
inv_1 inv_2 inv_4 inv_8 inverters, increasing drive
buf_1 .. buf_16 buffers
nand2_1 nor2_1 and2_1 basic gates
aoi21_1 oai22_1 and-or-invert - cheaper than the
equivalent AND + OR + INV chain
dfxtp_1 D flip-flop, positive edge, no reset
dfrtp_1 D flip-flop with async reset
clkbuf_4 clkinv_1 clock-tree-only cells
decap_4 fill_1 tapvpwrvgnd physical-only: no logic function
hd (high
density) is the default and the right starting point. hs (high speed) is
faster and larger. hdll (high density, low leakage) uses higher-threshold
transistors - slower, but dramatically less static power. ms (medium speed)
sits between. You pick one per design, or mix them per block if your flow supports it, and
the choice moves your area, speed and leakage numbers before you have written a single
constraint.
1.3 Liberty: how timing and power are modelled
A .lib file is the timing and power model of an entire cell library, in ASCII.
It is the file static timing analysis actually reads, and understanding its structure changes
how you think about delay - because the single most important thing it tells you is that
a gate does not have a delay.
A gate has a delay function, of two variables: how fast its input arrived (input transition, or slew) and how much capacitance it has to drive (output load). Liberty stores that function as a two-dimensional lookup table - the NLDM, non-linear delay model.
library (sky130_fd_sc_hd__tt_025C_1v80) {
time_unit : "1ns";
voltage_unit : "1V";
capacitive_load_unit (1, pF);
leakage_power_unit : "1nW";
nom_voltage : 1.80; nom_temperature : 25.0; nom_process : 1.0;
cell (sky130_fd_sc_hd__nand2_1) {
area : 5.0016;
pin (A) { direction : input; capacitance : 0.00224; }
pin (B) { direction : input; capacitance : 0.00234; }
pin (Y) {
direction : output;
function : "!(A & B)";
max_capacitance : 0.3; /* design rule: exceed and DRV fails */
timing () {
related_pin : "A";
timing_sense : negative_unate; /* A rises => Y falls */
cell_rise (delay_template) {
index_1 ("0.01, 0.06, 0.24, 0.90"); /* input transition, ns */
index_2 ("0.00, 0.02, 0.08, 0.30"); /* output load, pF */
values ("0.089, 0.128, 0.281, 0.899",
"0.104, 0.143, 0.296, 0.914",
"0.152, 0.191, 0.344, 0.962",
"0.318, 0.357, 0.510, 1.128");
}
rise_transition (slew_template) { /* ... same 4x4 shape ... */ }
cell_fall (delay_template) { /* ... */ }
fall_transition (slew_template) { /* ... */ }
}
internal_power () { related_pin : "A"; /* rise_power, fall_power */ }
}
leakage_power () { value : 0.0022; when : "A & B"; }
}
}
cell_rise table for a
nand2_1, in nanoseconds. The same gate takes 89 ps in the best corner of
the table and 1128 ps in the worst - a factor of twelve, decided entirely by what it
drives and what drives it.
max_transition is a
hard design rule and not a suggestion - beyond it, the NLDM is extrapolating, and the
timing numbers stop meaning anything.
Sequential cells carry constraint tables instead of delay tables - setup_rising
and hold_rising, each a 2-D table indexed by data slew and
clock slew. This is where the Tsu and Th
of Course 01's timing
equations physically come from: not constants, but numbers interpolated out of a table
for the exact conditions at that flop.
1.4 LEF, GDS and the abstract views
One cell is described by five or six different files, each holding the slice of truth one particular tool needs. Knowing which view answers which question saves a great deal of confusion when a tool complains about a cell that "works fine" everywhere else.
| View | Contains | Read by |
|---|---|---|
.lib (Liberty) |
Delay, slew, setup/hold, power, DRV limits - per corner | Synthesis, STA, CTS |
.lef (cell / macro) |
Outline, pin shapes, metal blockages - no transistors | Floorplan, placement, routing |
.tlef (technology) |
Layer stack, routing pitch, min width and spacing, via rules | Routing, DRC-aware placement |
.gds |
Complete mask geometry, every layer, transistors included | Final assembly, DRC, mask writing |
.v (behavioural) |
A functional model of the cell | Gate-level simulation |
.spice / .cdl |
Transistor-level netlist | LVS, analogue simulation |
MACRO sky130_fd_sc_hd__nand2_1
CLASS CORE ;
ORIGIN 0.000 0.000 ;
SIZE 1.380 BY 2.720 ; # width x FIXED row height
SITE unithd ;
PIN Y
DIRECTION OUTPUT ; USE SIGNAL ;
PORT
LAYER li1 ; # local interconnect - the router
RECT 0.930 1.085 1.155 1.815 ; # must land a via here
END
END Y
PIN VPWR
DIRECTION INOUT ; USE POWER ;
PORT LAYER met1 ; RECT -0.240 2.480 1.620 2.960 ; END
END VPWR
OBS # "do not route through here"
LAYER li1 ;
RECT 0.075 0.255 0.865 0.935 ;
END
END sky130_fd_sc_hd__nand2_1
1.5 Inside the Sky130 PDK
SkyWater's 130 nm process, open-sourced with Google in 2020, is the first PDK you can clone from GitHub. It is a mature node - not leading-edge, but genuinely manufacturable, and every concept in this course transfers directly to a 7 nm flow you will meet under NDA.
$PDK_ROOT/sky130A/
+-- libs.tech/ # tool configuration, not cells
| +-- magic/ # .tech file: layers + DRC rules
| +-- netgen/ # setup file for LVS comparison
| +-- klayout/ # layer properties for viewing
| +-- openlane/ # default flow config per library
|
+-- libs.ref/
+-- sky130_fd_sc_hd/ # high density standard cells
| +-- lib/ # .lib, ONE PER CORNER
| | sky130_fd_sc_hd__tt_025C_1v80.lib typical
| | sky130_fd_sc_hd__ss_100C_1v60.lib slow: setup limit
| | sky130_fd_sc_hd__ff_n40C_1v95.lib fast: hold limit
| +-- lef/ # cell LEF + technology LEF
| +-- gds/ # full mask geometry
| +-- verilog/ # behavioural models for gate sim
| +-- spice/ + cdl/ # transistor netlists for LVS
| +-- mag/ # Magic layout views
|
+-- sky130_fd_sc_hs/ # high speed - bigger, faster
+-- sky130_fd_sc_hdll/ # high density low leakage
+-- sky130_fd_io/ # I/O pads
+-- sky130_sram_macros/ # a few fixed-size SRAMs
# NOT included, and worth knowing before you plan a project:
# * no SRAM compiler - use OpenRAM, or the fixed macros above
# * no PLL, no ADC - analogue IP is separate and mostly custom
# * no DDR PHY - and you would not want to write one
Corners: one library is not enough
The same silicon behaves differently depending on manufacturing variation, supply voltage and temperature. Liberty files are characterised at a fixed PVT corner, and you need at least two because setup and hold fail in opposite directions.
| Corner | P / V / T | Cells are | Catches |
|---|---|---|---|
ss_100C_1v60 |
Slow-slow, 1.60 V, 100 °C | Slowest | Setup - data arrives too late |
tt_025C_1v80 |
Typical, 1.80 V, 25 °C | Nominal | Sanity, area and power estimates |
ff_n40C_1v95 |
Fast-fast, 1.95 V, -40 °C | Fastest | Hold - data races through |
tt tells you almost nothing. Setup must be
proven at the slow corner, where gates are sluggish and the clock period is
effectively shorter; hold must be proven at the fast corner, where a short path
can beat the clock edge to the next flop. Signing off only on typical is the single most
expensive mistake available in this course - the chip comes back, works on the bench at
room temperature, and dies in a hot enclosure.
# Minimal OpenLane configuration. Everything else has a sensible default,
# and the defaults live in $PDK_ROOT/sky130A/libs.tech/openlane/.
set ::env(DESIGN_NAME) "picorv32"
set ::env(VERILOG_FILES) "./designs/picorv32/src/picorv32.v"
set ::env(SDC_FILE) "./designs/picorv32/src/picorv32.sdc"
set ::env(CLOCK_PORT) "clk"
set ::env(CLOCK_PERIOD) "24.0" ;# ns - about 41 MHz on sky130
# Floorplan: how tightly to pack. See Volume 03 for why 0.35 and not 0.8.
set ::env(FP_CORE_UTIL) 35
set ::env(PL_TARGET_DENSITY) 0.40
# Which standard cell library. Changing this line changes your area,
# speed and leakage before you have written a single constraint.
set ::env(STD_CELL_LIBRARY) "sky130_fd_sc_hd"
# Run it:
# docker run -it -v $(pwd):/openlane ... efabless/openlane
# ./flow.tcl -design picorv32
Interview grilling - "What is actually in a PDK, and what is not?"
The question is testing whether you have ever opened one. Answer in three layers:
- Rules and physics. The DRC deck (what geometry is manufacturable), the LVS deck (how to compare layout to schematic), SPICE models of the transistors, and the technology LEF describing the metal stack.
- Cells. The standard cell library in all its views - Liberty per corner, LEF, GDS, behavioural Verilog, SPICE - plus I/O pads and whatever hard macros the foundry ships.
- Tool setup. Configuration for the specific EDA tools: Magic tech files, Netgen setup, default flow parameters.
Then the part that shows judgement - what is missing: a PDK is not a design. There is normally no SRAM compiler (memory is a separately licensed generator), no PLL, no ADC, no high-speed SerDes. On a real project the gap between "we have a PDK" and "we can build our chip" is mostly IP procurement, and it has a budget.
A strong closing line: "And the PDK is versioned. Two tape-outs on nominally the same process with different PDK revisions are not the same design environment - the sign-off decks change, and results move."
Volume 01 recap
| Concept | The one thing to remember |
|---|---|
| Front vs back end | The line is where logic becomes geometry. |
| Standard cell | Fixed height, variable width. That is what makes rows work. |
| Cell naming | library__function_drive. The suffix is drive strength. |
| Liberty / NLDM | Delay is a 2-D table of input slew × output load, not a number. |
| Slew propagation | A slow input makes a slow output. This is why buffers help. |
| LEF vs GDS | LEF hides the transistors so the router can scale. |
| Corners | Setup at ss, hold at ff. Never sign off on tt. |
| Sky130 | Real, free, manufacturable. No SRAM compiler included. |