This example presents the usage of PIF in the VISTA Simulation Flow Controller (SFC) in a complete process simulation of a quarter-micron CMOS process. Although this example is not related to VLSICAP it demonstrates the advantages of PIF as a framework interchange format, and it shows how the data level features are used in a TCAD framework to drive the various TCAD tools to produce a consistent wafer state. For simplicity, only the data relevant for the NMOS devices are presented.
Figure 8.17: Simplified quarter-micron CMOS process flow
Fig. 8.17 shows the simplified process flow of a recessed-well
quarter-micron CMOS process with 
employing a silicide
metalization. The steps which do not affect the intrinsic devices have been
omitted. The actual simulation flow executed by the SFC includes also
device simulation steps for the electrical characterization of the device
following the process simulation.
Figure 8.18: Boron, phosphorus, and arsenic
doping concentrations of a 
micron NMOS device
Fig. 8.18 shows the boron, phosphorus and arsenic doping concentrations of the NMOS device as a result of the CMOS process run with the SFC. The doping profiles of the silicon segment are shown, since these are the ones of interest for a device simulator. Each of the doping profiles is defined on a triangular grid, each consisting of about 500 triangles. The final ASCII PIF file including all process steps is about 8.2 MB in size, whereas the binary PIF file is 1.8 MB in size.
The SFC uses one PIF binary file which holds the complete information about each step, including the physical and logical input parameters the simulators were started with, and a consistent wafer state of each step. Each step produces three PIF logical binaries in the physical PIF binary file, which therefore consists of a total of 60 PLBs. One logical binary of each step is devoted to the actual input used by a specific simulator. This is not a correct wafer state in most cases see Section 2.3. The tool writes its output into a second separate PIF logical binary, which usually does not conform to the wafer-state definition either. Therefore the SFC uses the wafer-state of the previous state (defined in a separate PLB) and the generated output PLB of the tool, to create a new consistent wafer-state, which is finally stored in the third PLB after each step. All these PIF logical binaries are uniquely identified through their names and the step number, which is appended to the step name.
Although the intermediate steps can be optionally discarded by the SFC, storing them all in the same PIF binary file gives a complete and compact documentation of a fabrication process including the wafer states after each step, the tool names invoked at each step, dates and location of the tool invocation, information about which tool has created or modified which objects, and the physical and logical parameters the tool was invoked with. The inability of other interchange formats, to store this additional information about a fabrication step, makes them not well suited to serve as a TCAD framework interchange format. On the other hand, a single PIF file is sufficient to give a complete and interchangeable documentation of a fabrication process including electrical characterizations resulting from a device simulation. This is a major advantage of PIF compared to other interchange formats: PIF is able to to serve as a TCAD framework interchange format, not only as a mere tool data interchange format.
Only through storing the complete fabrication history, it is possible to
execute complex queries on the database, like which step used a specific
energy for the source-drain implant of a specific device. This querying
capability, however, is indispensable when deriving RSM see Chapter 2
models from the simulation, so search performance in object queries is
crucial. This is where the binary structure of PIF binary files with its
object name hash tables plays an important role in providing fast and direct
object access, regardless where an object is located in a PBF. Where
conventional interchange formats like TIF or SSF would have to read
and search the whole ASCII file
, the PAI's
inquiry routines just need a few pointer dereferences to locate the object
opaquely in the cache or on the PIF binary file. For example, locating the
segments referenced by certain attributes, or searching all impurities defined
on a certain segment requires many object queries, which have to be executed
by the SFC by calling the PAI inquiry functions. This is necessary, if
information bypassing for a specific tool see Section 2.3 has to be
performed by the SFC, in order to prepare the input data for a
TCAD tool. This kind of ``data surgery'' is only possible using the
PAI's single object manipulation services, which can not be implemented
efficiently for conventional interchange formats.
The uncompromising use of a wafer state see Section 2.1.2 inside the SFC is a precondition for a standardized treatment of the simulation results of each fabrication step. One important aspect of this wafer state is the geometry conformance of the grids and attributes contained in the PIF binary file. Each grid has to reference exactly one segment, and has to conform to the geometrical shape of this segment. This is an indispensable precondition for the representation of quantities that have discontinuities at segment interfaces, as it is the case for, e.g., heterojunction devices. Since other interchange formats allow just one grid which always spans all segments, it is not possible to represent these devices with such formats.