Physical Verification Runsets

DRC/LVS Runset Development for Physical Verification Sign-off

SkyCadEda develops and maintains production DRC and LVS runsets for foundry PDK teams, IDM CAD organizations, and fabless companies that need custom verification checks. We write rule decks in SVRF, TVF, and PVL, with platform coverage across Siemens Calibre, Cadence PVS and Pegasus, Synopsys IC Validator, and Assura. Every runset we deliver is backed by a structured QA testcase methodology — dedicated pass and fail layout pairs for each coded rule — so verification teams can trust sign-off results. Engagements span new deck development, antenna and ERC and fill checks, waiver-flow governance, and ongoing maintenance as foundry design rule manuals evolve.

Engagement focus

  • Sign-off rule decks with per-rule QA testcases and an auditable DRM coverage matrix.
  • Consistent verification results across Calibre, PVS, Pegasus, IC Validator, and Assura.
  • Waiver flows with clear ownership, documented justification, and expiry tracking.
  • Rule decks that stay current with every foundry DRM revision and PDK release.

Capabilities

Engineering scope

01

SVRF and TVF Rule Coding for Calibre

We write production SVRF for the full range of Calibre checks: dimensional DRC such as width, spacing, enclosure, and extension; connectivity-dependent rules; multi-patterning constraints; voltage-dependent spacing driven by marker layers or net voltage propagation; and equation-based rules for advanced nodes. For LVS, we code device extraction statements, connectivity extraction, parameter measurement, and reduction and filtering logic so extracted netlists compare cleanly against schematics. Where a deck needs configurability — switchable rule groups, metal stack options, or node-specific parameters — we use TVF to generate SVRF programmatically from Tcl, keeping one maintainable source for multiple deck variants. All code follows consistent naming, header, and comment conventions so foundry reviewers and downstream CAD teams can audit each rule against the design rule manual.

02

PVL, PXL, and Assura Deck Development

Coverage does not stop at Calibre. We develop native PVL runsets for Cadence PVS and Pegasus, PXL runsets for Synopsys IC Validator, and rule decks for Assura where legacy flows still depend on it. For teams that must support multiple sign-off platforms — a common requirement for foundry PDK deliverables — we maintain parallel decks from a single rule specification and verify equivalence by running the same QA testcase suite through every platform and comparing violation results. We also handle porting projects: translating a proven Calibre deck to Pegasus or IC Validator to reduce license cost or align with a customer flow, with a documented equivalence report serving as the acceptance gate for the migration.

03

Runset QA Testcase Methodology

A runset without testcases is an untested program sitting in the most expensive position possible: tape-out sign-off. Our methodology pairs every coded rule with dedicated pass and fail layout testcases — the pass case sits exactly at the legal dimension, the fail case violates it by one manufacturing grid step. Testcases live in version control alongside the deck, with golden results captured for each target platform. A regression harness executes the full suite on every change and flags any difference in violation count, location, or classification. A coverage matrix maps every design rule manual entry to its testcases and code section, making coverage gaps, intentional exclusions, and waived rules explicit and reviewable rather than tribal knowledge.

04

Antenna, ERC, Fill, and Density Decks

Beyond core DRC and LVS, we build the supporting decks a complete sign-off flow requires. Antenna decks implement cumulative charge-collection checks across the metal stack, with correct handling of protection diode credit, gate oxide classes, and hierarchical accumulation. ERC decks catch floating gates, missing well and substrate ties, latch-up spacing issues, and ESD protection connectivity problems that neither DRC nor LVS reports on its own. Fill decks generate dummy metal, poly, and diffusion fill that satisfies density windows and gradient limits while respecting exclusion regions around sensitive analog and RF circuitry. Density check decks verify window-based and gradient rules ahead of tape-out so fill iterations converge quickly instead of surfacing as surprises at the foundry.

Expected outcomes

A deployment-ready result

  • 01Sign-off rule decks with per-rule QA testcases and an auditable DRM coverage matrix.
  • 02Consistent verification results across Calibre, PVS, Pegasus, IC Validator, and Assura.
  • 03Waiver flows with clear ownership, documented justification, and expiry tracking.
  • 04Rule decks that stay current with every foundry DRM revision and PDK release.
Request ConsultationView All Services

Rule Deck Engineering with Software Discipline

A DRC or LVS runset is source code that gates every tape-out, yet many organizations still treat rule decks as static text files that accumulate edits without tests, reviews, or versioned releases. SkyCadEda applies software engineering discipline to runset development: version control, per-rule testcases, automated regression, code review conventions, and release management tied to specific DRM and PDK versions. The result is a rule deck that design teams can trust and CAD teams can maintain long after the original author has moved on.

Engagements take several forms: full DRC and LVS deck development for a new or specialty process node, custom check development on top of an existing foundry deck, runset translation between verification platforms, QA testcase development for a deck that has none, and ongoing maintenance as the foundry releases DRM updates. Typical projects run from a few weeks for a targeted deck extension to several months for full-node bring-up, depending on rule count and platform coverage.

Waiver-Flow Governance

Every real design ships with waivers, and unmanaged waivers are a silent risk: suppressed violations that nobody can explain two tape-outs later. We build waiver handling into the runset and the surrounding flow — marker-layer or automated-waiver mechanisms appropriate to the platform, metadata capturing owner and justification and expiry, and reporting that keeps waived results visible and separately counted. Waiver review becomes a routine checkpoint in the sign-off flow instead of an archaeology exercise before each tape-out.

Foundry DRM Update Maintenance

Design rule manuals change on the schedule of the foundry, not the design team. Each DRM revision is diffed against the previous release, impacted rules and testcases are identified, deck code is updated, and the complete QA regression is rerun on every supported platform before the new runset version is released. Versioning ties each deck release to the DRM revision and PDK version it implements, so any design can state precisely which rules it was verified against.

FAQ

Questions before engagement

What is a DRC/LVS runset and why does runset quality matter?+

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.

Which physical verification platforms does SkyCadEda support?+

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.

How do you verify that a runset is correct before release?+

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.

Can you translate an existing Calibre runset to Pegasus, PVS, or IC Validator?+

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.

How does waiver-flow governance work in your rule decks?+

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.

How are runsets maintained when the foundry updates the design rule manual?+

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.

Do you develop antenna, ERC, and metal fill decks in addition to DRC and LVS?+

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.

Related capabilities

Physical VerificationPDK DevelopmentCadence SKILL Scripting