DB Format
How the .db Binary Encodes a Cell Library
The .db format emerged from the Synopsys synthesis flow as a way to avoid re-parsing the same Liberty text on every tool invocation. A Liberty (.lib) file is a human-readable, deeply nested ASCII description: it declares operating conditions, wire-load models, and one cell group per standard cell, with each cell holding pin groups, timing groups, and lookup tables for delay and power. For a single signoff corner that text can span hundreds of megabytes once nonlinear delay model (NLDM) or composite current source (CCS) tables are present. Reading and validating that structure is computationally expensive, so Synopsys defines a binary serialization of the in-memory representation and writes it out with a .db extension.
When a tool such as Design Compiler, Fusion Compiler, or PrimeTime links a .db, it deserializes the data structure directly into memory and skips lexing, syntax validation, and semantic checks entirely. The data content is identical to the Liberty source; only the encoding differs. Because the layout of that internal structure can change between major tool releases, a .db produced by one version family is not guaranteed to load in another, and it cannot be opened by Cadence or Siemens EDA tools, which read Liberty natively. This is why a disciplined library team treats the ASCII .lib as the golden source of record and regenerates the .db per tool version as part of its build flow.
Compiling and Reading a .db
The round trip is symmetric. Library Compiler reads a .lib, builds the model, and writes a .db; the same tool can read a .db back and write a .lib for inspection or diffing. The example below shows the canonical Synopsys command sequence and the rough load-speed relationship that motivates using the binary at all.
read_lib sc9_tt_1p0v_25c.lib
write_lib sc9_tt_1p0v_25c -format db -output sc9_tt_1p0v_25c.db
Link the binary in a timing run (PrimeTime):
set link_library "* sc9_tt_1p0v_25c.db"
Approximate load-time benefit:
tdb ≈ tlib / k, where k ≈ 5 to 20×
The .db skips ASCII lexing and semantic validation, so deserialization is roughly 5 to 20× faster than parsing the equivalent Liberty text and uses lower peak memory. Exact k depends on table density (NLDM vs CCS) and corner count.
Library Format Comparison
| Format | Encoding | Human-readable | Primary tools | Portability | Typical role |
|---|---|---|---|---|---|
| .db | Binary (Synopsys) | No | DC, Fusion, PrimeTime | Version-locked, vendor-locked | Fast runtime link |
| .lib (Liberty) | ASCII text | Yes | All major EDA | Open, interoperable | Golden source of record |
| Cadence cache | Binary (internal) | No | Genus, Tempus | Cadence-only | Runtime cache of Liberty |
| .lef | ASCII text | Yes | Place and route | Open | Physical abstract (not timing) |
| .lib (CCS variant) | ASCII text | Yes | All major EDA | Open, interoperable | Current-source timing/noise data |
Frequently Asked Questions
How do I convert a Liberty .lib file into a .db file?
Compile it in a Synopsys tool: read_lib my_lib.lib then write_lib my_lib -format db -output my_lib.db. The reader parses and validates the Liberty syntax, builds the in-memory model, and serializes it to the binary .db. PrimeTime and Fusion Compiler consume the .db directly via read_db or set link_library. The reverse, write_lib -format lib, regenerates ASCII Liberty from a loaded .db for inspection or diffing.
Why do tools prefer .db over reading the .lib directly every time?
A single-corner Liberty file can run from tens of megabytes to several gigabytes with NLDM or CCS tables, and parsing that ASCII is slow. The .db is a pre-parsed, pre-validated binary snapshot, so loading is roughly 5 to 20× faster and uses less peak memory because lexing and semantic checks are skipped. Across a multi-corner signoff with dozens of linked libraries, the saved parse time adds up. The cost: a .db is tied to a tool version and is not human-readable.
Is a .db file portable between tool versions and vendors?
No. The .db is a proprietary Synopsys serialization and only loads reliably in the version family that wrote it; major releases can change the internal schema and force a recompile from the .lib. It is not readable by Cadence or Siemens EDA tools, which use Liberty or their own binary caches. Keep the ASCII Liberty .lib as the source of record and regenerate .db per tool version rather than treating the binary as the master.