PDK Development and Qualification Services

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.

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.

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.

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.

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.

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.

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.

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.