Games / Command flash cards / Standard-cell library / Views and characterization

Views and characterization

Each card shows a command to explain. A missed card returns later in the round and starts the schedule over. A card answered correctly moves up the schedule and next appears after 1, 3, 7, then 21 days. Keys 1 to 4 choose an option, h shows a hint, and Enter moves on. A hint keeps the card where it is on the schedule. An ordering card is answered by clicking its items in order, and one wrong click ends it. Time values are in nanoseconds. Progress is stored in this browser.

SourceThese cards describe standard-cell libraries in general, checked against the open libraries that OpenROAD-flow-scripts ships: Nangate45, sky130 high density, and ASAP7. Cell names and conventions differ between libraries, so each card says which library its example comes from. The answers link to the OpenROAD module that handles the cell in question. Reference: OpenROAD module documentation (the open libraries on GitHub).

All 10 cards in this section, with answers

NangateOpenCellLibrary_typical.lib NangateOpenCellLibrary.macro.lef NangateOpenCellLibrary.gds

Timing and power, then geometry, then the real layout.

Hint: Three files for one library. Ask which stage of the flow needs each.

The three views are timing and power, geometry, and layout. A flow reads the Liberty file to time, the LEF (Library Exchange Format) file to place and route, and merges the layout only at the end. The three must agree: a cell missing from one of them fails in whichever stage needs it. the open libraries reference
NangateOpenCellLibrary_typical.lib versus ..._slow.lib versus ..._fast.lib

The same cells characterized at different operating conditions.

Hint: One library, three files. Ask what differs, and why one is not enough.

The conditions are process, voltage, and temperature. Silicon varies, so a cell's delay is measured at several of them and the design must work at all of them. Setup is usually worst in the slow corner and hold in the fast one, which is why sign-off analyses several corners rather than picking one. the open libraries reference
max_transition : 0.2; max_capacitance : 0.1;

Limits the cell declares, which the design-rule repair must respect.

Hint: These are not measurements. Ask who has to obey them.

Beyond these values a cell's delay tables are extrapolated and its behaviour is not guaranteed. repair_design fixes violations by buffering or upsizing, and the SDC (Synopsys Design Constraints) commands set_max_transition and set_max_capacitance can tighten the limits further, never relax them. the open libraries reference
SITE FreePDK45_38x28_10R_NP_162NW_34O

The site: the smallest legal cell footprint, whose height sets the row height.

Hint: It is the unit that rows and cell widths are built from.

Every standard cell is one site high (or a whole multiple, for multi-height cells) and a whole number of sites wide. That is what makes rows and legalization possible, and it is why a library belongs to a site rather than to a process alone. the open libraries reference
set_dont_use {AOI211_X1 OAI211_X1}

Excludes cells that are legal but troublesome, often for pin access.

Hint: The cells exist and work. Ask what else makes a cell a poor choice.

A tall compound gate can have pins that the router struggles to reach, and a weak cell can be chosen too readily by sizing. Flows exclude such cells outright rather than repair the results. Nangate45's flow configuration excludes AOI211_X1 and OAI211_X1 for exactly this. the open libraries reference
a double-height cell in a single-height row

It spans two rows, so the two rows must have compatible orientation.

Hint: Rows are one site high. Ask what a cell twice that height needs.

Rows alternate orientation so that neighbouring rows share their power and ground rails. A cell spanning two rows has to match that pattern, which is why legalizers list mixed-height support as a feature, and why initialize_floorplan takes extra sites for cells that appear later. the open libraries reference
cell_rise (delay_template_5x5) { index_1 ("0.01, 0.02, 0.04, 0.08, 0.16"); /* input transition */ index_2 ("0.5, 1.0, 2.0, 4.0, 8.0"); /* output load */ }

A delay table against input transition and output load.

Hint: Two axes. Ask what the tool does when a real value lands between them.

Values between the grid points are interpolated. A cell's delay depends mostly on how fast its input arrives and how much it has to drive, so it is characterized on that grid and interpolated in between. report_dcalc prints the lookup for one arc, which is the way to see it happen. the open libraries reference
two cells of the same width and the same pin positions

Either can replace the other in place.

Hint: Ask what could be changed without moving anything else.

A threshold voltage swap is the clearest case: the cells are drawn to the same footprint on purpose, so the change touches no metal at all. Where the replacement is wider, everything to the right of it has to move, which is why late sizing is constrained to what fits. the open libraries reference
index_1 ("0.00117 ... 0.19854") /* input transition */ index_2 ("0.36562 ... 23.4000") /* output load */

The range the cell was measured over.

Hint: Ask what happens to a cell asked to work outside these numbers.

Inside the grid the values are interpolated between measured points. Outside it, they are extrapolated, and the further out the worse. This is the real reason behind the maximum transition and maximum capacitance limits: past them, nobody knows the delay. the open libraries reference
a new library arrives: .lib, .lef, .gds, .cdl, .v

Check the views agree: same cells, same pins, same sizes.

Hint: The views are built by different teams and different tools.

A pin present in the timing view and missing in the abstract, or an abstract whose size disagrees with the layout, breaks the flow far downstream and in confusing ways. This is why a library is checked view against view before any design uses it. the open libraries reference