📚 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.

💡 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.

📋 All Library Cell Types

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.

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