PDK Engineering & QA

PDK Development and Qualification Services

PDK setup gets a foundry kit installed; PDK development creates and extends the kit itself. SkyCadEda authors and qualifies PDK content for custom IC platforms: technology files and layer maps built from the foundry design rule manual, PCell and CDF libraries, DRC, LVS, and PEX runsets validated against known-good structures, and QA regression suites that keep devices, models, and verification decks consistent across Cadence Virtuoso and Synopsys Custom Compiler. Every deliverable ships as a versioned release with documented changes, so CAD teams can deploy, audit, and roll back with confidence.

Engagement focus

  • PDK content that matches the foundry design rule manual, with rule-by-rule test evidence.
  • QA regression coverage that catches kit regressions before they reach design teams.
  • Consistent device behavior across Virtuoso and Custom Compiler environments.
  • Versioned, documented PDK releases that deploy cleanly and roll back safely.

Capabilities

Engineering scope

01

Techfile and Layer-Map Development

We author technology files directly from the foundry design rule manual rather than adapting a template: layer and purpose definitions, GDSII and OASIS layer maps for stream in and stream out, via and contact definitions, constraint groups, minimum width and spacing rules, display resources, and color maps. Where a process adds options such as thick metal, MIM capacitors, or high-voltage devices, we structure the techfile so option layers activate cleanly without forking the kit. Deliverables include matched techfiles for Cadence Virtuoso and Synopsys Custom Compiler plus the layer-map files needed by verification and extraction tools, all cross-checked so a polygon streamed out of one environment streams back into the other on the same layer, every time.

02

PCell and CDF Authoring

SkyCadEda develops parameterized cells in SKILL and in Python-based frameworks such as PyCell, covering MOS, BJT, resistor, capacitor, inductor, and specialty devices. Each PCell is paired with a complete CDF definition: parameter ranges tied to the design rule manual, callbacks that snap invalid entries to legal values, netlisting procedures for Spectre, HSPICE, and Eldo, and symbols wired for simulation and LVS. We build PCells to be layout-versus-schematic clean by construction, so the geometry a parameter set produces is the geometry the extraction deck expects. Abutment, stretch handles, auto-generated guard rings, and multi-finger devices are implemented and regression-tested against the full legal parameter space, not just default values.

03

DRC, LVS, and PEX Runset Validation

A PDK is only as trustworthy as its verification decks. We develop and validate DRC, LVS, and PEX runsets for Calibre, Pegasus, PVS, and IC Validator, checking every coded rule against the design rule manual with paired pass and fail test structures so each check is proven to flag real violations and accept legal geometry. LVS decks are validated device by device across the PCell parameter space, and extraction runsets are correlated against foundry reference data where the foundry provides it. The output is a runset qualification report that maps each DRM rule to its implementation and its test evidence, which is exactly the documentation design teams and auditors ask for at tape-out.

04

PDK QA Regression and Cross-Tool Consistency

We build automated QA regression suites that exercise the entire kit: QA cell libraries that instantiate every device across its legal parameter range, stream-out and stream-in round trips, schematic-to-layout generation, DRC and LVS runs on generated cells, and netlist comparison across simulators. For teams running both Cadence Virtuoso and Synopsys Custom Compiler, we add cross-tool consistency checks: the same device with the same parameters must produce equivalent geometry, netlists, and verification results in both environments. Regressions run on every kit change, so a techfile edit that silently breaks a PCell or a callback is caught in the pipeline instead of being discovered by a designer three weeks into a block.

Expected outcomes

A deployment-ready result

  • 01PDK content that matches the foundry design rule manual, with rule-by-rule test evidence.
  • 02QA regression coverage that catches kit regressions before they reach design teams.
  • 03Consistent device behavior across Virtuoso and Custom Compiler environments.
  • 04Versioned, documented PDK releases that deploy cleanly and roll back safely.
Request ConsultationView All Services

Authoring and Qualifying PDK Content, Not Just Installing It

Most PDK services stop at integration: take the foundry kit, install it, configure the tools. PDK development goes further. When a device is missing, a runset lags the current design rule manual, an internal process has no kit at all, or two EDA platforms disagree about the same transistor, someone has to write and qualify the content itself. That is the work this service covers: techfile and layer-map authoring, PCell and CDF development, verification runset creation and validation, and the QA regression infrastructure that keeps all of it correct release after release.

The lifecycle runs from the design rule manual to a qualified, versioned release. We start by building or auditing the techfile and layer maps, then implement devices as parameterized cells with complete CDF definitions, then bring the DRC, LVS, and PEX runsets into agreement with both the DRM and the devices. QA cell libraries and automated regressions tie the pieces together, so any future change to any layer of the kit is checked against everything that depends on it.

Cross-Tool Consistency: Virtuoso and Custom Compiler

Organizations increasingly run Cadence Virtuoso and Synopsys Custom Compiler side by side, and a kit that behaves differently in each is a silent source of silicon risk. Our QA regressions instantiate identical devices in both platforms and compare streamed geometry, netlists, and verification results, so divergence is caught and fixed in the kit before designers ever see it. The same discipline applies across simulators and across physical verification engines: one design rule manual, one answer, regardless of tool.

Quarterly Foundry Updates and Versioned Deployment

Foundry kits are moving targets. Quarterly updates change rule values, add and deprecate devices, and revise model cards, and every local extension you have built must survive each transition. We manage this as a repeatable engineering process: baseline diff, impact classification, extension porting, full QA regression, and a published delta report. Releases are tagged in version control and deployed through your existing infrastructure, so projects pin the version they taped out with while new work starts on the current one. If you need that deployment infrastructure built first, our PDK setup service handles it, and the two services are designed to hand off cleanly.

FAQ

Questions before engagement

What is the difference between PDK setup and PDK development?+

PDK setup takes an existing foundry kit and integrates it into a team environment: installation, tool configuration, model hookup, and validation that the kit behaves as delivered. PDK development creates or extends the kit content itself: authoring techfiles and layer maps, writing PCells and CDF definitions, building DRC, LVS, and PEX runsets, and qualifying all of it with regression suites. Choose setup when the foundry kit already contains what you need; choose development when devices, rules, or tool support are missing, incomplete, or need to be built for an internal or specialty process. SkyCadEda offers both as separate services because the skill sets and deliverables differ.

What does PDK qualification involve?+

Qualification is the evidence that a kit is correct. For each release we run QA cell libraries that instantiate every device across its legal parameter range, verify DRC and LVS cleanliness of the generated layouts, stream data out and back in to confirm layer-map integrity, compare netlists across simulators, and diff results against the previous release to catch regressions. Runsets are qualified separately, with paired pass and fail structures for each coded rule. The output is a qualification report tied to a specific kit version, and that report becomes part of the permanent release record.

Can you develop PDK content for an internal or specialty process?+

Yes. IDMs, specialty foundries, and research fabs often need kits for processes that have no commercial PDK: BCD, SiC, GaN, silicon photonics, or mature nodes being extended with new device options. Working from the design rule manual, device list, and model files, we author the techfile, layer maps, PCells, CDF, and verification runsets, then stand up the QA regression around them. Where documentation is incomplete, we work directly with process and device engineers to close the gaps, and we record those decisions in the kit documentation so it remains maintainable after handoff.

How do you validate DRC and LVS runsets against the design rule manual?+

Every coded check gets a pair of test structures: one that violates the rule by the smallest meaningful margin and one that passes at the legal limit. The runset must flag the first and accept the second, which proves both that the check exists and that its dimensions are correct. For LVS, each device is extracted across its parameter space and compared against the schematic netlist, including property checks on width, length, multiplier, and finger count. The rule-to-test mapping is delivered as a traceability matrix so any individual rule can be audited later.

How do you keep a PDK consistent between Virtuoso and Custom Compiler?+

Cross-tool consistency is a first-class QA target, not an afterthought. We maintain a single source of truth for layer definitions, device parameters, and rule values, and generate or cross-check the tool-specific files from it. The regression suite then instantiates the same devices with the same parameters in both environments and compares the streamed geometry, the netlists, and the DRC and LVS results. Differences are triaged to root cause, whether that is a callback divergence, a layer-map mismatch, or a netlisting procedure, and fixed in the kit rather than papered over in documentation.

How do you handle quarterly foundry PDK updates?+

Foundries ship kit updates on a regular cadence, and each one can move rule values, deprecate devices, or change model cards. We run a structured integration: diff the incoming release against the current baseline, classify changes by impact, port local extensions and PCell customizations onto the new base, rerun the full QA regression, and publish a delta report that tells design teams exactly what changed and whether anything requires action on active designs. Teams that adopt this cadence integrate updates in days instead of stalling on a kit version several quarters old.

How are PDK releases versioned and deployed?+

Every kit lives in version control with tagged releases, changelogs, and the QA report that qualified each tag. Deployment uses the mechanism your site already trusts, whether that is environment modules, read-only central installs, or container images, so a project can pin a specific kit version for its full tape-out cycle while new starts pick up the latest release. Rollback is a pointer change, not a rebuild. If your organization does not yet have this infrastructure, our PDK setup service puts it in place; the development service then delivers releases into it.

How long does a typical PDK development engagement take?+

Scope drives schedule, and the ranges here are illustrative rather than quotes. Adding a device family to an existing kit, including PCell, CDF, symbols, runset updates, and QA coverage, typically runs a few weeks. Building runset validation and QA regression around an existing kit is commonly a 4-8 week effort. Full kit development for an internal process, from design rule manual to qualified release, typically runs several months depending on device count and tool coverage. We scope fixed milestones after reviewing the DRM and existing collateral, so deliverables and checkpoints are agreed before work starts.

Related capabilities

PDK Setup & IntegrationPCell DevelopmentPhysical Verification