Configuration Libraries in SystemVerilog — Complete Guide

📚 What Configuration Libraries Do

Large designs often have multiple versions of the same module — a behavioural model and a gate-level netlist both named alu, for example. Without a way to specify which version to use where, the simulator simply uses whichever it finds first. Configuration libraries solve this by making the binding explicit and controllable per-instance.

Three constructs work together:

A library is a named collection of cells. A library map file (passed as a tool invocation option) specifies which source files belong to which library.
A cell is any named design unit that can be stored in a library — modules, primitives, interfaces, and so on.
A configuration (config...endconfig) specifies which library cell to bind to which instance in the design hierarchy, with optional instance-level and cell-level overrides.

Why this matters. Configurations let you say: “use the alu from rtl_lib everywhere, except use the gate-level version from gates_lib at exactly top.cpu.alu.” This is how mixed-level simulations, verification IP injection, and regression variants are assembled cleanly — without touching the source files of the design itself.

💡 The One Change SV Makes

SystemVerilog extends the definition of a cell to include the new SV constructs. In Verilog-2001, only modules, macromodules, primitives, and configurations were valid cells. SystemVerilog adds:

interface — can now be stored in a library and bound through a configuration.
program — can now be stored in a library and bound through a configuration.
package — can now be stored in a library and bound through a configuration.

All existing configuration syntax and semantics are unchanged. The config/endconfig keywords, design, default liblist, instance override, and cell override work exactly as before — the only extension is that more things can appear as cells.

Nothing in the configuration language itself changed. If you already know Verilog-2001 configurations, there is nothing new to learn syntactically. The benefit is that you can now organise testbench interfaces and program blocks into libraries and swap them just like you would swap module implementations.

📋 All Library Cell Types

module

Standard hardware description module

macromodule

Module variant for accelerated simulators

primitive

User-defined primitive (UDP)

configuration

A configuration is itself a valid cell

interface

SV interface — new cell type

program

SV program block — new cell type

package

SV package — new cell type

Green = new cell types added by SystemVerilog

📋 How a Configuration Works

A configuration declaration names the top-level design unit, sets a default library search order, and can then override that default for specific instances or for all uses of a specific cell name.

// Library map file (passed to the tool as an invocation option):
// library rtl_lib   ./rtl/*.sv;
// library gates_lib ./netlist/*.v;
// library tb_lib    ./tb/*.sv;

config cfg_sim;
  design rtl_lib.top;               // top-level design unit from rtl_lib
  default liblist rtl_lib;           // all instances default to rtl_lib

  // Instance override: use gate-level alu at this specific path
  instance top.cpu.alu liblist gates_lib;

  // Cell override: all uses of 'mem' use gates_lib (regardless of path)
  cell mem liblist gates_lib;
endconfig

// With SV, tb_lib can contain interfaces and programs as cells
config cfg_full;
  design rtl_lib.top;
  default liblist rtl_lib tb_lib;
  cell bus_ifc liblist tb_lib;   // interface cell from the testbench library
  cell test    liblist tb_lib;   // program block cell from the testbench library
endconfig

📋 Configurations in the SV Compilation Model

In SV’s compilation model, constructs visible across all compilation units include modules, macromodules, primitives, programs, interfaces, and packages. Configurations build on top of this: they choose which version of any of these constructs to bind during elaboration.

Without configuration

The tool uses whatever version of a named unit it finds first, according to its own file-search order. Works for small single-library designs but breaks down when multiple library versions or mixed-level simulation is needed.

With configuration

The tool follows explicit binding rules. Every version of every cell used at every hierarchy level is precisely specified. Enables gate-level substitution, testbench IP injection, and regression variants without touching design source files.

Practical use cases

Mixed RTL/gate-level simulation — gate-level models for timing-critical paths, RTL everywhere else.
Verification IP swapping — swap a full bus-functional interface model for a simple wire model without touching the DUT.
Regression variants — run the same testbench against RTL, gate-level, and power models by selecting a different configuration.
Testbench component libraries — with the SV extension, interfaces and programs can be packaged and swapped just like design modules.

📋 Quick Reference

Term	Definition
Library	A named collection of cells. Source files are mapped to libraries via a library map file passed to the tool.
Cell	A named design unit: module, macromodule, primitive, configuration, interface (SV), program (SV), or package (SV).
Configuration	A `config...endconfig` block that explicitly binds cell names to specific library versions for a given design hierarchy.
Library map file	A file (passed as a tool option) that lists which source files belong to which library.
SV addition	Interfaces, programs, and packages are now valid cell types in addition to the original Verilog types. No syntax changes.

Coming next: SV-23 covers System Tasks and System Functions — elaboration-time $typeof and $typename, $bits for bit-stream sizing, array dimension query functions, assertion severity and control tasks, random number functions, and enhancements to file read/write tasks.