PDK Setup and Enablement Guide

Every custom IC design begins with a Process Design Kit. The PDK is the bridge between a foundry's manufacturing process and the EDA tools that engineers use to design chips. It contains everything the design environment needs to know: which layers are available, what design rules must be obeyed, how transistors and passive devices behave electrically, and how the layout should be verified before tapeout. A misconfigured PDK does not just slow down design — it can cause silicon failures that cost months and millions of dollars. Yet PDK setup remains one of the most underestimated and error-prone tasks in semiconductor CAD engineering.

What Is a Process Design Kit?

A Process Design Kit is a comprehensive package delivered by a semiconductor foundry to its design partners. Think of it as the foundry's instruction manual for how to use its manufacturing process in EDA software. The PDK contains several categories of files, each serving a specific purpose in the design flow.

The technology file (techfile) is the heart of the PDK. It defines the process layers, their purpose (routing, implant, metal, via, etc.), design rules (minimum width, spacing, enclosure), and layer relationships. In Cadence Virtuoso, the techfile is loaded by the Virtuoso technology file manager and drives the constraint system, design rule checking, and layer display. In Synopsys Custom Compiler, the equivalent data is loaded through its technology setup.

Device models are SPICE-compatible simulation models for transistors, resistors, capacitors, diodes, and inductors. These models (usually in SPICE, Spectre, or Eldo format) capture the electrical behavior of each device across voltage, temperature, and process corners. Model files are referenced by the simulation environment — Virtuoso ADE, Synopsys Custom Explorer, or standalone SPICE simulators like Spectre and HSPICE.

Verification rule decks contain the physical verification rules for DRC (Design Rule Checking), LVS (Layout vs. Schematic), and ERC (Electrical Rule Checking). These decks are written in the rule language of the target verification tool — SVRF or TVF for Calibre, rule files for Pegasus, or Assura rule files for Cadence verification flows. The rules encode the foundry's manufacturing constraints and must match the techfile exactly.

Additional PDK components include display resource files (.drf) that control how layers render in layout editors, parameterized cell (PCell) libraries that provide pre-built layout generators for standard devices, CDF (Component Description Format) data that defines device parameters and callbacks in Virtuoso, and extracted view rules for parasitic extraction tools like StarRC or Quantus.

Why PDK Setup Is Critical

A PDK that is not set up correctly introduces silent errors into the design flow. These errors are particularly dangerous because they do not always produce immediate failures. An incorrect layer mapping might not be caught until tapeout review. A mismatched model library might produce simulations that pass but do not reflect real silicon behavior. A missing design rule constraint might allow a layout that violates foundry manufacturing limits.

The cost of these errors compounds downstream. A design team that works for months on a chip with an improperly configured PDK may discover at tapeout that entire blocks need to be re-laid out. Simulation results from mismatched models may lead to circuit specifications that do not hold in silicon. And verification runs against incorrect rule decks may pass designs that should have failed, or reject designs that are actually correct.

Beyond correctness, PDK setup directly affects engineering productivity. When a PDK is properly configured, designers spend their time designing. When it is not, they spend hours debugging tool errors, layer display issues, simulation failures, and verification mismatches that all trace back to configuration problems. A well-set-up PDK is invisible — it just works. A poorly set-up PDK is a constant source of friction.

The PDK Setup Process

Setting up a PDK for a design team involves several sequential steps, each with its own pitfalls. The exact process varies by foundry and EDA tool vendor, but the general workflow is consistent.

Step 1: Environment and Directory Structure

Before touching any PDK files, establish a clean directory structure and environment configuration. Most foundries provide a recommended directory layout, and deviating from it causes path resolution failures later. The PDK root directory typically contains subdirectories for techfiles, models, rules, displays, PCells, and documentation.

Environment variables are the single largest source of PDK setup errors. Each EDA tool reads specific environment variables to locate PDK files — CDS_SITE and TECH_FILE for Cadence, SNPSLMD_LICENSE_FILE and technology search paths for Synopsys, and various Calibre-specific variables for Siemens tools. When multiple PDK versions coexist (common during node migration), environment variable conflicts are almost inevitable without careful management.

Step 2: Techfile Configuration

The techfile defines the process layers and their design rules. Loading the techfile into Virtuoso involves creating a new library, attaching the techfile, and verifying that all expected layers appear in the layer palette. This is also where you configure layer purpose pairs (drawing, pin, label, net, etc.) and their display properties.

A common pitfall is layer mapping mismatch. The techfile defines layers by number and name, but the verification rule deck may use a different naming convention or numbering scheme. If these are not aligned, DRC and LVS runs will produce errors on every rule because the layers do not correspond. Always validate layer mapping between the techfile and the verification deck as the first step after loading the techfile.

Step 3: Display Configuration

The display resource file (.drf) controls how each layer renders in the layout editor — its color, fill pattern, stipple, and visibility. While display issues seem cosmetic, they have a practical impact on design quality. A designer who cannot distinguish between two similar layers visually will make layout errors. Proper display configuration also affects Virtuoso's layer filtering, selection behavior, and DRC marker display.

Step 4: Device and Model Setup

Configuring devices involves loading SPICE models into the simulation environment, creating or validating CDF parameters for each device, and ensuring that the schematic symbols, layout PCells, and extracted views are all consistent. Model library paths must point to the correct corner files — typical, fast, slow, and any custom corners the foundry provides.

For analog and mixed-signal design, this step is particularly critical. Simulation results are only as good as the models they use. If the model library path points to an outdated version, or if corner definitions do not match the techfile version, simulation results will be unreliable. Automated validation — comparing model library version stamps against the PDK release notes — catches these issues before they propagate.

Step 5: Verification Deck Integration

The DRC and LVS rule decks must be configured to run against designs in this PDK. This involves setting up the rule deck paths in the verification tool, configuring the runset (which checks to run, which cells to skip, what output formats to generate), and running a known-good test layout to verify the deck produces correct results.

A critical but often skipped step is the golden layout test. Before trusting a verification deck for production use, run it against a test layout that has known intentional errors and known clean areas. If the deck does not catch the intentional errors or flags the clean areas, something is wrong with the deck configuration or the layer mapping. This test takes 30 minutes and can save weeks of debugging later.

Step 6: Parasitic Extraction Setup

For post-layout simulation, parasitic extraction tools (StarRC, Quantus, xCalibrate) need their own configuration files that reference the same PDK layers and technology parameters. The extraction setup must be validated against the techfile version — an extraction deck from a previous PDK release may reference layers or rules that have changed.

PDK Automation: From Weeks to Hours

Manual PDK setup is time-consuming because it involves dozens of configuration files, environment variables, and cross-references that all must be consistent. When a foundry releases a PDK update (typically quarterly), the entire setup process must be repeated. For teams supporting multiple technology nodes, the maintenance burden multiplies.

PDK automation scripts eliminate this burden by encoding the setup process into repeatable, testable code. A well-designed PDK automation framework handles environment configuration, techfile loading, display setup, model library validation, verification deck integration, and golden layout testing in a single script execution. The script becomes the single source of truth for how the PDK should be configured, eliminating the variability that comes from different engineers setting up the PDK differently.

The most effective PDK automation uses a layered approach. A base layer handles the common configuration shared across all tools and nodes. Tool-specific layers add Cadence, Synopsys, or Siemens-specific configuration. And node-specific layers handle the unique aspects of each technology node (different design rules, different device models, different layer counts). This structure makes it straightforward to add new nodes or support new tools without rewriting the entire automation.

Common PDK Pitfalls and How to Avoid Them

After years of PDK enablement work, certain failure patterns appear repeatedly across semiconductor teams. Understanding these pitfalls upfront saves significant debugging time.

Version Mismatch Between PDK Components

Foundries sometimes release updates to individual PDK components (a model update, a rule deck fix) without bumping the overall PDK version number. If your team updates the techfile but not the verification deck, or updates models without updating the extraction setup, you will get inconsistent results that are difficult to diagnose. Always track component versions independently and validate consistency after any partial update.

Environment Variable Conflicts

When designers work with multiple PDKs (common during IP porting or multi-node projects), environment variables from one PDK can leak into another tool session. The most insidious version of this is when a variable is set in a startup file (.cshrc, .bashrc, or .cdsenv) and silently overrides the intended PDK path. Use per-project environment scripts and always verify the active environment before launching design tools.

Stale Cached Data

EDA tools cache technology data aggressively for performance. After updating a PDK, old cached data can persist in the tool's working directory. Virtuoso, for example, caches techfile data in the library's techfile.db. If you update the techfile source but do not clear the cache, Virtuoso continues using the old data. Always clear tool caches after any PDK update and verify the loaded data matches the expected version.

Cross-Vendor Layer Inconsistency

In multi-vendor flows (Cadence for design, Calibre for verification, StarRC for extraction), each tool has its own layer representation. The techfile, rule deck, and extraction deck must all agree on layer numbers, names, and purposes. This agreement is not guaranteed by the foundry — it must be validated as part of PDK setup. Build automated checks that compare layer definitions across all PDK components and flag any discrepancies.

PDK Management at Scale

For organizations supporting multiple technology nodes, multiple foundries, or multiple design sites, PDK management becomes an infrastructure challenge. Each combination of foundry, node, and tool version requires its own validated PDK configuration. Updates must be tested before deployment. And designers must be able to switch between PDKs without manual reconfiguration.

The solution is centralized PDK management with automated deployment. A PDK server hosts the validated, tested PDK configurations for all supported nodes. Designers reference the PDK through environment scripts that set all required paths and variables automatically. When a new PDK version is released, the CAD team validates it on the server, runs regression tests, and deploys it to all design sites simultaneously. This approach eliminates the "works on my machine" problem that plagues teams where each designer manages their own PDK setup.

Version control is equally important. Every PDK configuration change — a new environment variable, a modified layer mapping, a corrected rule deck path — should be committed to version control with a clear commit message. When a designer reports a PDK issue, the CAD team can trace exactly what changed and when. This audit trail is invaluable for debugging and for compliance with foundry partnership agreements.

How SkyCadEda Handles PDK Enablement

SkyCadEda has enabled PDKs for foundries including TSMC, GlobalFoundries, Samsung, and specialty foundries across nodes from 180nm to advanced FinFET processes. OurPDK setup services cover the full lifecycle: initial setup for new nodes, quarterly update integration, cross-vendor layer validation, and automated deployment infrastructure.

We build PDK automation that encodes your specific environment requirements — tool versions, license configurations, compute farm integration, and multi-site deployment. Every script is tested against real foundry data and validated with golden layout runs before deployment. Our goal is to make PDK setup a one-command operation that your CAD team can execute reliably, whether they are enabling a new node for the first time or integrating the latest quarterly update.

Beyond initial setup, we provide ongoing PDK maintenance through ourCAD infrastructure services. This includes monitoring foundry releases, validating updates against your design flow, deploying changes to production, and maintaining the version history your team needs for debugging and audit. Combined with ourEDA automation services, we ensure your PDK infrastructure stays current and reliable as your design needs evolve.

Getting Started

If your team is setting up a new technology node, struggling with PDK configuration issues, or spending too much time on PDK maintenance, the right automation and infrastructure can transform the experience. Start by auditing your current PDK setup — identify the manual steps, the configuration files that are managed outside version control, and the environment variables that are set ad hoc. Those are the highest-value targets for automation.

A well-managed PDK infrastructure is invisible to designers — it just works, every time, on every machine. Getting there requires investment in automation, validation, and process, but the payoff is a design environment where engineers spend their time designing chips, not debugging their tools.

Related Articles

• What Is EDA Automation?
• Cadence SKILL Scripting Guide
• CAD Infrastructure for Semiconductor
• DRC/LVS Physical Verification
• Synopsys Custom Compiler Automation
• ASIC Design Flow & Platform Support
• Tcl/Tk for EDA Automation
• Virtuoso Layout Automation
• GDSII OASIS Layout Automation
• FlexNet Licensing for EDA Tools
• Open Source EDA Tools Guide
• RISC-V EDA Tools Guide
• Advanced Node Verification
• Cloud EDA SaaS Solutions
• DFT Design for Test Automation
• Timing Closure Automation Guide
• Calibre SVRF TVF Rule Decks Guide
• Python EDA Automation Guide
• IP Porting and Migration Guide
• Mixed-Signal Verification Guide