Custom PCell Development Services for Cadence Virtuoso

A parameterized cell, or PCell, is a programmable layout generator that produces device geometry from user-entered parameters such as width, length, and finger count. Foundry PDKs ship with standard PCells, but teams need custom development when they add proprietary devices, build an internal PDK, extend foundry cells with features such as guard rings or dummy insertion, or modernize legacy generators that break in newer tool versions. Custom PCell development is also common on specialty processes — HV, BCD, RF, silicon photonics — where the foundry kit covers only a baseline device set and the design team needs additional structures generated reliably.

Both are valid, and the right choice depends on who maintains the cells. Hand-written SKILL or SKILL++ gives complete control over conditional geometry, hierarchy, and evaluation performance, and integrates cleanly with existing PDK code — it remains the standard for high-volume production kits. Cadence PCell Designer offers a graphical, constraint-driven environment that is faster for prototyping and more approachable for engineers who do not write SKILL daily, but complex conditional behavior can become awkward to express. We frequently prototype in PCell Designer and productize in SKILL, or keep simple devices in PCell Designer while coding complex ones by hand. We advise on that split during scoping.

We start from how designers will actually use the device: which parameters belong on the property form, sensible defaults, units, and the dependencies between values. CDF callbacks then enforce that model — recomputing derived parameters when a driving value changes, snapping entries to legal grids, clamping out-of-range input, and keeping schematic, layout, and simulation views consistent. We follow defensive callback patterns so an invalid entry produces a corrected value or an explicit message instead of silent corruption, and we document the parameter contract so future maintainers understand why each callback exists. Callback behavior is covered by the same regression suite as the layout generator.

Yes. Abutment and stretch handles are common retrofit projects on cells that already generate correct geometry. For abutment we add the pin properties and protocol functions Virtuoso uses to detect touching instances, then implement the geometry changes — shared diffusion, dropped contacts, merged source and drain regions — plus correct restoration when instances are pulled apart. For stretch handles we define handle locations and the callback logic that maps a graphical drag to parameter updates such as width or finger count. Retrofits are validated against the original cell to confirm that non-abutted output is unchanged, so existing layouts are not disturbed.

Yes. FinFET and advanced planar nodes impose constraints that change how a PCell must be written: device width becomes a discrete number of fins, gates sit on a fixed pitch grid, layers may require coloring for multi-patterning, and cut shapes, forbidden pitches, and context-dependent via rules must be honored by construction. We build generators that legalize user parameters to the fin and pitch grid before drawing, emit correctly colored shapes, and produce DRC-clean output across the full parameter space. Foundry documentation and restricted design rules are treated as the specification, and the regression suite runs DRC on generated instances to prove compliance.

Every PCell we deliver ships with an automated test bench. The suite instantiates the cell across a sweep of parameter combinations — boundary values, minimum geometries, and known-difficult corners — then runs DRC on the generated layout and, where applicable, LVS against the schematic view. Callback behavior is tested by driving parameter edits programmatically and checking the resulting values. The suite is scripted so your CAD team can rerun it on every PDK release or tool version change, turning PCell validation from a manual spot check into a repeatable regression gate. We also record evaluation-time benchmarks so performance regressions are caught early.

A typical engagement delivers the PCell source code (SKILL, SKILL++, or PCell Designer databases), CDF definitions and callback code, symbol and layout views packaged for your library structure, the automated regression suite with DRC and LVS hooks, and written documentation covering the parameter contract, abutment behavior, and maintenance notes. We hand over everything your team needs to own the cells: no black boxes, and no encrypted code unless your security policy requires it. Where the work extends an existing PDK, we also deliver integration instructions and a change summary so your kit release process stays auditable.

Duration depends on device complexity and the size of the parameter space. As an illustrative range, a single straightforward device — a resistor or capacitor generator with a modest parameter set — is often a one-to-two-week effort including tests, while a family of MOS devices with abutment, stretch handles, and full regression coverage typically runs several weeks. Complete PCell libraries for an internal PDK are usually phased over a few months, with devices released in prioritized batches so design work can start before the whole library is finished. We scope fixed milestones during the initial technical review.