Many of the existing TCAD systems couple tools in a rigid way by means of point-to-point data converters to translate between the different data formats.
The minority of TCAD systems provide a framework-like data level which facilitates tool integration. Early implementations of explicit data levels, like the DAMSEL system from CNS/CNET [41] or the topography-oriented Toshiba system [30], feature two-dimensional geometries and common data structures for a fixed set of simulators.
More mature data levels are explicitly designed for multi tool integration, most of them use an interchange-format approach. The term Profile Interchange Format [42] is entirely misleading as the format is mostly used to store and exchange the entire static TCAD design information, not just impurity profiles. The most prominent examples are EASE, which uses an early ASCII PIF predecessor; CAFE, which uses PIF/Gestalt (featuring object-orientedness) from MIT[43]; IDDE [19] and PRIDE [21], both using keyword based ASCII PIF data levels; VISTA, which uses a binary PIF implementation as exchange and storage format [44]; and finally the BPIF implementation [37] from the University of California at Berkeley used in PROSE.
Two notable framework data level implementations, PREDITOR from Carnegie Mellon University (based on CDB/HCDB [10]) and PROSE (based on the OCT chip database from the Univerity of California at Berkeley), provide a strong link to horizontal layout, as they use systematic extensions of ECAD data levels as ingredients for the TCAD data level.
A recent approach to data level standardization is the SWR 1.0 specification [45] [46] (issued by the Semiconductor Wafer Representation technical subcommittee of the CAD Framework Initiative (CFI), an international standardization committee for electronic CAD) which defines an object-oriented application interface for TCAD data access and suggests the use of a client-server framework architecture. The motivating vision of this definition is to separate the physical modeling completely from tedious tasks such as grid generation, interpolation, or geometry handling by providing these functions through an opaque server which is accessed by the simulation clients via a procedural interface. This method is very well-suited for, e.g., the simulation of topography formation, however, it may be suspected that it is detrimental to applications with high data throughput or applications which exhibit performance advantages thanks to a tight coupling between physical models and numerical techniques. Furthermore, the definition of a rather high-level interface - which implicitly requires an impressive functionality - is, in combination with the opacity of a server concept, an impediment to gradual implementation and to maintenance since there is no architectural layering that would provide milestones for implementation and verification.