Reference-tool flows and process-design kits, part two
As a result of the shift to global design centers and the reduction in time designers spend on each process node, it is no longer always accurate to assume that experienced designers will be working with PDKs.
By Pallab Chatterjee, Contributing Technical Editor -- EDN, November 12, 2009
In design support for the fabless or foundry-based semiconductor-design model, the main mechanism for circuit-design information is the PDK (process-design kit). The PDK describes the electrical, yield, and performance aspects of the process. There are generally two types of PDKs: one for device-level or custom design and one for logic-level design. The device-level PDK typically comprises Spice-level device models for all of the active devices available on the process; Spice-level device models for all of the designable passive elements, including resistors, capacitors, and inductors; a schematic-symbol library for these primitive elements; and information on how to build the device in layout.
The Spice models are fairly universal in the semiconductor industry and useful with a variety of simulators, including those for IR (current/resistance) drop; electromigration analysis; postlayout-extraction, high-capacity, mixed-mode simulators such as VHDL-AMS (very-high-speed-integrated-circuit hardware-description-language-analog/mixed-signal) and Verilog-AMS; ac or harmonic-balance RF simulators; and cell-characterization simulators. Spice-level subcircuit models are available for some processes that involve complex elements, such as high-voltage or high-current transistors and metal-insulator-metal capacitors.
The second design view for the custom-design level is for the physical design. It includes the layer list and the technology file for the layout editor and generally references either layouts of the devices to show how to construct a device or an automated program to build the devices from parameterized cells in the language of the layout editor. These parameterized cells are for individual devices, device pairs, and other configurations that the process supports and are available for both passive and active components.
|
The parameterized cells tend to be version-specific for a given layout editor and are generally in the design database as “generate-as-needed” elements. Using parameterized cells maintains design flexibility but involves a revision-control risk for the context around the dynamic device. It is common that PDKs omit the reference layouts and parameterized cells for the layouts’ nondevice objects, such as guard rings, substrate and well taps, dummy devices, polysilicon or diffusion interconnect, via and contact farms, field plates, line shields, and high-current or high-voltage corner designs.
The next level in the design includes the logic-level PDK. This PDK comprises descriptions for how to set up place-and-route tools, block-to-block-assembly rules, maximum-device-size rules for buffers and repeaters that insert automatically in a design, some schematic symbols for primitive logic elements, and I/Os. The I/Os tend to be special cells that incorporate ESD (electrostatic-discharge)-protection devices, which are process-specific elements. Information for designing these ESD elements is generally proprietary to the foundry. The I/O cells also contain the core and peripheral power-interface circuits. The PDK not only provides these cells but also identifies the proper use and density of the cells a design requires.
First-generation PDKs assumed that a designer using the kits had sufficient design experience and knowledge to properly apply the design information over multiple applications. As a result of the shift to global design centers and the reduction in time designers spend on each process node, it is no longer always accurate to assume that experienced designers will be working with these kits. A proposed method of addressing this issue is to shift to the Python programming language and the use of that language’s multidevice PyCells.
The PyCell device builders include the advantages of adjacent partner devices and their associated nondevice elements. Less-experienced designers may use PyCells with an automated placer to build the device-level IP (intellectual property) and associated cells without requiring the help of senior designers for anything but cell sign-off.
