Reference-tool flows and process-design kits, part one
Reference-tool flows and process-design kits have been the basis of chip design since the start of the semiconductor industry. Although these files provide adequate information, they alone do not represent all of the issues.
By Pallab Chatterjee, Contributing Technical Editor -- EDN, 9/17/2009
Most of the advanced process technologies from wafer foundries include RTFs (reference-tool flows) to aid in tool selection. In addition, PDKs (process-design kits) describe the electrical, yield, and performance aspects of the process. These two pieces of support documentation have been the basis of chip design since the start of the semiconductor industry. Although these files provided adequate information for engineers to complete designs on process geometries as small as 0.25 micron, they alone do not represent all of the issues that lithographic and advanced processing variation introduces.
An RTF is usually a sequence of recommended tools that identify all of the steps—with the associated EDA tools—you need to verify that a physical-design view of a circuit meets all of the quality criteria to ensure manufacturability. The RTF also ensures that the chosen EDA tool will operate with the information the foundry provides and produce a "correct" result. Most of these tool flows involve timing closure and detailed placement and routing of the circuits—capabilities that all of the major EDA vendors provide. Supplementary tools include device simulators; parasitic RC (resistance/capacitance) extractors; physical verification, including DRC (design-rule checking), LVS (layout versus schematic), and ERC (electrical-rule checking); package modeling; high-capacity simulation; noise modeling; power analysis; and custom layout. The addition of these supplementary tools allows customers who want analysis outside their all-in-one flow to add independent checks or advanced analysis.
|
A key misunderstanding about the tools in RTFs is that the foundry advocates them. Rather, the RTF is a list of tools with known interoperability with each other. Furthermore, the foundry believes that these tools can produce a result from a certain level of publicly released information on the process within an acceptable amount of error that the wafer foundry determines. Participation in an RTF does not guarantee correct answers from any EDA tool for an arbitrary circuit application, so don't blindly trust the tools on the list. As a corollary, omission from the list merely indicates that the foundry has not established vendor-to-vendor interoperability from a menu level or that, to achieve higher accuracy or performance, the tool requires supplemental information that is not available to the general design community but may be available on a case-by-case basis. Typically, mixed-signal, RF, memory, imaging, telecom, very-high-speed, multiprocessor-core, DSP, and low-power designs do not use RTFs.
The basics of RTFs are the technology files that describe the masking and design layers for the process and their functions. This technology also contains a naming convention and information for operating a custom physical-design tool, or layout editor. The technology file also has the rudimentary minimum-design-rule information for the process, so physical-system designers can use the rules as guidelines. There is also a place-and-route control file, which dictates device-to-device and wire-to-wire spacing on the design and is written in the dialect of the EDA vendor's tools.
The last major component is the physical-verification files. These files include the DRC deck, which comprises minimum rules, recommended rules, DFM (design-for-manufacturing) "increased-yield" rules, memory rules, I/O rules, power-supply rules, ESD (electrostatic-discharge) rules, analog rules, and special-device rules. A similar format is available for ERC-, LVS-, and parasitic-extraction-rule decks. As a result, most fabs try to maintain more than 2000 control files for a commercial-foundry offering, so updates take time, and the customer must verify them.
Contact me at pallabc@siliconmap.net.
















