Standard Cell Library Variants

The last two articles have quietly assumed there is exactly one SKY130 standard cell library. There is not. SKY130 ships several, and picking one is a real decision every design makes in its very first config file.

Same logic, different silicon

Every SKY130 library variant implements the same logical cell set, the same AND2, NAND2, DFF, MUX and every other cell name you expect, but each variant lays those cells out and characterises them differently, trading area, speed and power against each other. The three you will meet most:

• hd, high density: cells laid out to occupy the smallest area, prioritising area over raw speed. The default, general-purpose choice for most digital designs.
• hs, high speed: cells laid out and sized for faster switching, at the cost of more area and more power per cell, for designs where timing is the harder constraint.
• ls, low speed, low power: cells optimised toward minimum power, accepting slower switching, for designs where the power budget dominates.

This is the abstraction stack one level more concrete: “a NAND2 gate” is not one fixed physical thing even within one process. It is a logical specification that gets a different physical implementation depending on which library variant you build against, in the same way the same RTL can synthesize to different gates depending on constraints (Module 2).

The practical rule

You do not need deep characterisation data for a reasonable first choice:

• Default to hd for a typical digital design where area (and so cost) is the main constraint and timing is not aggressive relative to the target clock.
• Reach for hs when timing is tight: when hd-library timing analysis shows paths failing the target period and you are willing to spend area and power to close the gap.
• Consider ls when power is the binding constraint (a battery-powered or thermally limited application) and slower operation is acceptable.

More advanced flows can mix variants within one design, hs cells only on the critical paths and hd elsewhere, a technique generally called multi-Vt or mixed-library optimisation. The early modules of this course use one variant per design for clarity; mixing is a natural next step.

One config line, one decision

In OpenLane the library variant is selected with one field in the design’s config.json (the file Section 1.5 builds in full):

{
  "STD_CELL_LIBRARY": "sky130_fd_sc_hd"
}

Before running any synthesis, predict what changes if that line were instead:

{
  "STD_CELL_LIBRARY": "sky130_fd_sc_hs"
}

Synthesis (Module 2) would map the same RTL onto a different, faster but larger set of cells, so you would expect the netlist’s area to increase and its timing margin to improve, even though the logic and the RTL are unchanged. Everything downstream, the floorplan’s area estimate, placement density, even routing congestion, inherits that change, because every later stage is working with physically larger cells.

A mistake I have seen: changing STD_CELL_LIBRARY mid-project as a quick fix for a timing failure without re-running from synthesis. The netlist is built from cell instances specific to one variant. sky130_fd_sc_hd__nand2_1 does not exist in the hs library; it is a different set of physical cells, so swapping variants means re-synthesizing.

Practice Exercise

A design comfortably meets its area budget with the hd library, but OpenSTA reports several failing paths after routing. What is the first library-related change worth trying, and what trade should you expect?

In the next article, Section 1.4 stops being conceptual: installing OpenLane and the SKY130 PDK on a real machine, the setup every hands-on section from here depends on.