Introduction to Calibre SVRF and TVF Rule Decks

Calibre is Siemens EDA's industry-leading physical verification platform, used by virtually every semiconductor foundry and design house for Design Rule Checking, Layout vs Schematic comparison, and reliability verification. At the heart of every Calibre verification run lies a rule deck written in one of two languages: SVRF, the Standard Verification Rule Format, or TVF, the Tcl Verification Format. SVRF is the traditional, declarative rule language that has been the backbone of Calibre verification for decades. TVF is a newer, Tcl-based alternative that offers procedural programming constructs, dynamic variable scoping, and easier integration with external data sources. Understanding both formats is essential for any physical verification engineer working at advanced process nodes.

SVRF: The Standard Verification Rule Format

SVRF is a declarative, rule-based language specifically designed for physical verification. A typical SVRF rule deck consists of layer definitions, derived layer operations, DRC checks, and output statements. Layer definitions map GDSII layer numbers to logical names using the LAYER statement. Derived layers are created through boolean and geometric operations, including AND, OR, NOT, XOR, SIZE, GROW, SHRINK, and DRC CHECK operations that test specific design constraints. SVRF uses a non-procedural evaluation model where the order of statements does not affect the logical result, though it can affect performance. The language supports variables, arithmetic expressions, and conditional execution through IF-ELSE constructs, but it remains fundamentally a rule-description language rather than a general-purpose programming language.

TVF: Tcl Verification Format for Procedural Control

TVF extends Calibre with full Tcl programming capabilities, allowing rule deck developers to use loops, procedures, file I/O, regular expressions, and dynamic data structures. A TVF rule deck uses standard Tcl syntax: variables set with the set command, procedures defined with proc, conditional logic with if and switch, and looping with for and foreach constructs. TVF also provides Calibre-specific commands that mirror SVRF operations, such as drc, lvs, and extract commands, while adding the flexibility of Tcl's string manipulation and math expression capabilities. TVF is particularly valuable for advanced-node rule decks that require complex rule generation based on parametric inputs, process corner data, or look-up tables. Many foundries now provide hybrid rule decks that use TVF for procedural logic while calling SVRF-style rule blocks for the actual verification operations.

SVRF vs TVF Quick Reference

The table below condenses the practical differences between the two formats so you can decide quickly which one fits a given rule deck task. Most production environments end up using both: SVRF for the bulk of geometric checks, and TVF wherever procedural logic pays for itself.
AspectSVRFTVF
Language ParadigmDeclarative rule description; statement order does not change logical resultsProcedural Tcl programming with loops, procedures, and dynamic data structures
Typical UseStandard DRC and LVS decks, foundry baseline rules, straightforward geometric checksPERC reliability decks, parametric rule generation, corner-dependent checks, external data lookups
Syntax StyleKeyword-based statements such as LAYER, AND, EXTERNAL, INTERNAL, and DENSITYStandard Tcl constructs such as set, proc, if, and foreach, plus Calibre-specific commands
When to ChooseWhen readability and maintainability matter most and rules map directly to the design rule manualWhen rules must be generated programmatically, traverse connectivity graphs, or adapt to runtime conditions

DRC Rule Deck Structure and Organization

A production DRC rule deck is organized into distinct functional sections for maintainability and performance. The preamble section defines technology constants, layer definitions, and global variables. The derived-layer computation section creates all intermediate layers needed for checks, such as pin-to-pin spacing layers, density calculation layers, and antenna diode layers. The main DRC check section contains individual rule checks organized by category: spacing, width, enclosure, density, antenna, and pattern-matching checks. Each check typically includes a rule statement, an error description, and severity level. The output section configures how results are reported, including RVE-compatible database output for Siemens Calibre RVE, text reports, and hierarchical result databases. Advanced rule decks also include per-cell or per-block rule parameters for mixed-signal and multi-voltage designs.

Common DRC Checks in SVRF and TVF

The most common DRC checks are implemented using straightforward geometric operations. A minimum spacing check creates a sized version of the layer being checked and looks for overlaps with the original. A minimum width check erodes then grows the layer by half the minimum width; any remaining geometry fails. An enclosure check, such as via enclosure by metal, creates a sized version of the enclosing layer and checks that it fully covers the inner layer. Density checks compute the fraction of area occupied by a layer within a sliding window and compare against minimum and maximum density targets. Antenna checks measure the ratio of gate oxide area to connected metal area to ensure plasma-induced damage during fabrication stays within limits. All of these checks can be expressed equivalently in SVRF or TVF, though TVF offers advantages for parameterized rules.

LVS Rule Deck Structure and Connectivity Extraction

LVS rule decks define how the Calibre tool extracts the connectivity graph from the layout and compares it against the schematic netlist. The extraction begins with device recognition, where specific layer combinations and geometries identify transistors, resistors, capacitors, and diodes. The LVS deck defines gate, source, drain, and bulk terminals for each device type using layer operations and connectivity tracing. The interconnect extraction uses layer-to-layer contact definitions and via recognition to build the complete netlist with parasitic resistance and capacitance. The comparison step maps layout nodes to schematic nodes and reports mismatches, shorts, opens, and parameter mismatches. Advanced LVS decks handle multiple threshold voltage variants, analog matching structures, and electro-static discharge protection devices with specialized recognition rules.

PERC Reliability Rule Decks

Calibre PERC extends physical verification beyond traditional DRC and LVS by checking circuit reliability constraints through electrical rule checking. PERC rule decks analyze the connectivity graph to identify potential reliability issues such as electro-migration hotspots, voltage stress on thin-oxide devices, ESD protection network continuity, and power domain crossings. A PERC rule deck combines device recognition, connectivity tracing through the extracted netlist, and conditional checks that flag violations based on path properties. For example, a PERC rule can trace all current paths from a high-voltage pad to low-voltage core logic and verify that appropriate level-shifter cells and voltage clamp diodes are present at each interface. PERC decks are typically written in TVF because they require procedural graph traversal and complex conditional logic that is difficult to express in SVRF.

Rule Deck Debugging and Optimization

Debugging Calibre rule decks requires systematic analysis of verification results and performance data. The Calibre RVE debugger provides interactive visualization of DRC violations with cross-probing between error markers and the layout database. For performance optimization, rule deck developers use Calibre's built-in profiling tools that report rule-by-rule execution time and memory usage. Common optimization techniques include: combining multiple spacing checks into a single operation where possible; using layer partitioning to limit check scope; avoiding unnecessary derived layer creation through direct operation chaining; and using the dbLayerAndNot and dbLayerOr commands to minimize intermediate database operations. TVF rule decks offer additional optimization opportunities through procedural flow control, allowing early exit from expensive checks when a design fails critical basic rules first.

Debugging Calibre Rule Deck Failures

When a Calibre run fails outright or produces unexpected violations, an unstructured search through the transcript wastes hours. A repeatable workflow narrows the problem in three passes: first confirm the deck compiles cleanly, then validate the results in RVE, and finally audit the rule logic itself for the pitfalls that most often produce false or missing violations.

Step 1: Resolve Rule Deck Compile Errors

Calibre parses the entire rule deck before executing any checks, so compile errors always appear near the top of the transcript with a file name and line number. Read the first error only; later errors are usually cascades from the same root cause. The most frequent culprits are a missing or misspelled INCLUDE file, an undefined variable referenced before its DEFINE statement, a layer name used before its LAYER declaration, and mismatched braces in TVF procedures. For hybrid decks, verify that the TVF wrapper actually emits the SVRF blocks you expect by dumping the generated rules to a file and inspecting them directly. Keep a minimal smoke-test layout on hand so you can confirm a deck at least compiles and runs end to end before launching a multi-hour full-chip job.

Step 2: Debug DRC Results with RVE

Once the run completes, open the results database in Calibre RVE and sort violations by check name rather than scanning them in order. A single rule reporting thousands of hits usually indicates a deck problem, not thousands of genuine layout errors: a wrong spacing value, an inverted polarity on a NOT operation, or a derived layer that selected far more geometry than intended. Cross-probe a handful of representative markers into the layout and manually measure the flagged geometry against the design rule manual. If the measurement passes but Calibre flags it, the rule is wrong; if it fails, the layout is wrong. RVE also lets you highlight the intermediate derived layers that feed a check, which is the fastest way to see exactly which geometry a rule operated on.

Step 3: Audit Common SVRF Pitfalls

  • Layer derivation order: Although SVRF is logically order-independent, a derived layer must be defined before any statement that consumes it. Redefining a derived layer later in the deck silently overrides earlier definitions and changes every downstream check that references it.
  • Connectivity before checks: CONNECT statements must establish connectivity before any NET AREA RATIO, antenna, or connectivity-dependent check runs; a missing CONNECT produces empty results rather than an error, so clean reports are not always good news.
  • INSIDE versus INTERACT confusion: INSIDE selects only shapes fully contained in the reference layer, while INTERACT selects any shape that touches it. Using the wrong operator quietly includes or excludes boundary geometry and is a classic source of false negatives at block edges.
  • Grid and precision mismatches: A PRECISION or RESOLUTION setting that disagrees with the layout database grid creates off-grid slivers during sizing operations, producing phantom spacing violations that vanish when the values are aligned.
  • Hierarchy effects: Checks that behave correctly flat can miss violations at cell boundaries in hierarchical runs. When results differ between flat and hierarchical modes, suspect the interaction between derived layers and cell placement rather than the rule arithmetic.

Integration with the Physical Verification Flow

Calibre rule decks integrate into the broader physical verification flow through command files and run scripts. A typical verification flow consists of: extraction of full-chip or block-level GDSII data; hierarchical DRC with Calibre -drc command, which applies the DRC rule deck; LVS with Calibre -lvs command for connectivity verification; RVE debugging; and optional PERC analysis. The run script, typically written in Tcl or Perl, orchestrates these steps and manages technology files, rule deck versions, and result databases. For hierarchical verification, Calibre supports cell-by-cell checking with results integration, reducing total runtime for large designs. Modern flows also integrate Calibre sign-off into the design closure loop, allowing incremental checking after engineering change orders without a full re-run of the entire deck.

Best Practices for Rule Deck Development

Developing production-quality Calibre rule decks requires rigorous methodology. Always version-control rule decks using Git or similar systems, with semantic versioning to track changes. Write detailed comments for each rule explaining its purpose, the design rule manual reference, and any process-dependent assumptions. Use consistent naming conventions: prefix derived layers with a short identifier, name checks by rule number or descriptive tag, and group related checks into named rule blocks. Maintain a regression test suite with known-good and known-bad test layouts to validate changes. Document the minimum, typical, and maximum runtime for each rule group to catch performance regressions. For foundry-delivered rule decks, never modify the original files directly; instead, create a wrapper deck that extends or customizes the base rules for your specific design and technology needs.

Future Trends: Machine Learning and Rule Automation

The future of Calibre rule deck development is being shaped by machine learning and automation. Siemens EDA's Calibre ML technology applies machine learning models to predict DRC violations during the routing phase, reducing DRC turnaround time. Rule deck developers are also exploring automated rule generation from foundry design rule manuals using natural language processing, though this remains experimental. At advanced nodes below 5nm, the number of design rules has grown exponentially, with leading-edge rule decks containing thousands of individual checks. This complexity is driving adoption of TVF for its programmatic strengths, enabling rule decks to generate checks dynamically based on context. For SkyCadEda engineers working with Calibre, mastery of both SVRF and TVF rule deck development is a key differentiator in delivering high-quality physical verification services.

Related Articles