DRC/LVS Runset Development for Physical Verification Sign-off

A runset is the machine-readable rule deck that a physical verification tool executes to check a layout against foundry design rules (DRC) or to compare an extracted netlist against the schematic (LVS). It encodes every entry of the design rule manual as tool-specific operations in SVRF, TVF, PVL, or the native language of the platform. Runset quality directly determines sign-off quality: a rule that is miscoded, missing, or overly aggressive produces either silicon failures or weeks of false-violation debugging. Because the runset is the contract between the foundry process and the design team, it must be developed, tested, versioned, and released with the same rigor as production software.

We develop and maintain runsets for Siemens Calibre (SVRF and TVF), Cadence PVS and Pegasus (native PVL as well as Calibre-compatible input), Synopsys IC Validator (PXL), and Cadence Assura for legacy flows. Most engagements target Calibre as the primary sign-off platform, with PVS, Pegasus, or IC Validator decks maintained in parallel for license flexibility or customer deliverables. We also take on translation projects where an existing Calibre deck must be ported to Pegasus or IC Validator, using a shared QA testcase suite to demonstrate result equivalence between the source and target platforms before cutover.

Every rule receives dedicated QA testcases: at minimum one pass layout that sits exactly at the legal limit and one fail layout that violates the rule by the smallest resolvable increment, typically one manufacturing grid step. Testcases are stored with expected results, and a regression harness runs the full suite on every runset change, comparing violation counts, locations, and classifications against golden references. We track a coverage matrix that maps each design rule manual entry to its testcases, so gaps are visible and auditable. Boundary conditions — off-grid dimensions, hierarchy interactions, corner-to-corner spacing, and cell-boundary effects — receive additional targeted layouts.

Yes. Runset translation is a common engagement, usually driven by license consolidation, runtime scaling on Pegasus or IC Validator, or a customer flow requirement. We treat translation as re-implementation with proof rather than line-by-line conversion: each rule is recoded idiomatically in PVL or PXL, then validated by running the shared QA testcase suite through both the original Calibre deck and the new deck. Differences in violation count, location, or classification are triaged rule by rule until the equivalence report is clean. The deliverable includes the translated deck, the testcase suite, golden results for both platforms, and documentation of any intentional behavioral differences.

We implement waiver handling that survives audits. Depending on the platform, this uses mechanisms such as Calibre automated waivers, waiver marker layers, or cell-based waiver regions, always paired with metadata: the rule being waived, the owner, the written justification, the approval record, and an expiry or review milestone. Reporting is configured so waived violations are counted and listed separately from open violations rather than silently suppressed, and stale waivers are flagged when a design is re-verified after a DRM or layout revision. The goal is that every waived violation at tape-out can be traced to a documented, time-bounded engineering decision.

DRM updates are handled as controlled releases. We diff the new manual revision against the previous one, produce an impact analysis listing added, changed, and retired rules, and estimate which deck sections and testcases are affected. Rule code is updated, new testcases are written for new or tightened rules, and the full QA regression is rerun on every supported platform before release. Each runset release is versioned against the specific DRM revision and PDK version it implements, with release notes that let design teams see exactly what changed. Ongoing maintenance retainers keep this cycle predictable across quarterly or ad-hoc foundry updates.

Yes. Antenna decks implement the cumulative charge-collection ratio checks defined in the DRM, including per-layer accumulation across the metal stack, protection diode credit, and gate oxide class handling. ERC decks target electrical issues that standard DRC and LVS miss: floating gates, missing well or substrate ties, latch-up spacing, and ESD protection connectivity. Fill decks generate dummy metal, poly, and diffusion shapes that meet window density and gradient requirements while honoring exclusion regions around matched analog structures, inductors, and RF signal paths. These decks are developed with the same testcase-backed QA methodology we apply to core DRC and LVS runsets.