The binary format is closely related to the ASCII format inasmuch as the
hierarchical structure of the ASCII PIF is preserved in the binary form
through the use of LISP-like constructor nodes. However, to improve
performance and data compactness, several additional features have been
implemented, such as a symbol hash table for fast object access by name, and
provisions for a compressed array storage format of large arrays which
typically occur in TCAD applications for attributes on grids have been made
.
Due to its generality and flexibility, a PBF may hold an unlimited number of PLBs, and one PLB (conforming to one ASCII PIF) in turn may hold an infinite number of objects. Thus a PBF may contain anything from just one PLB with a few comments to hundreds of PLBs, each holding several geometries, attributes, grids and process flow descriptions. The maximum size of a PBF is limited by the addressing capability of the PAI, which in turn is affected by the machine word length. On a 32-bit machine the PAI can address one gigabyte (some bits are reserved) which is therefore the maximum PBF size, supposed the operating system's file size limitation is higher. Since the PAI is capable of opening up to 16 PLBs, an application has a maximum of 16 gigabyte of PBF data available. Typically, a single PBF holds one or two PLBs containing a geometry, attributes and grids of a single tool run. Through the special link construct objects in other PLBs or even other PBFs may be referenced.
It is important to note that, although the structure of the PAI is derived from the PIF syntax, the PAI itself is independent from the underlying database, and thus could be interfaced (probably with losses in performance and compactness) to other databases, since the TCAD application sees just the PAI procedural interface and has to know little about PIF. Thus, various different implementations of the low-level application interface routines are possible, because the applications have just to rely on the specification of the PIF Application Interface services. This is in conformance with the procedural interface approach discussed in Section 3.2.
The decision to use PIF was made in conjunction with the decision to adopt XLISP [Betz89] as the VISTA task-level extension language: PIF uses a LISP-like syntax, and XLISP as the task-level language gives way to a seamless and homogeneous fusion of data and task-level concepts. With this unique combination it is equally possible to modify simulation data in the database directly as LISP data as well as store LISP expressions (e.g. task-level programs) in the PBF. Thus a process flow representation can be directly embedded in the TCAD data level; there is no artificial separation, and homogeneous data storage, retrieval and maintenance services are available for both semiconductor wafer and process flow representations.