The data level concept of an interchange format is - at one hand - targeted
at avoiding file-format conversions between tool invocation inside a TCAD
framework. Consider the two cases of simulator coupling depicted in
Fig. 3.2. The upper figure shows conventional simulator coupling
through converters between several incompatible and disjunct simulator input
and output data formats. As can easily be seen, the number of converters
necessary in such a ``framework'' rises with 
, where 
is
the number of simulators. With each new simulator which has to be integrated,
converters would have to be written for both input and output data
formats. Besides from the fact that this large number of converters (or
wrappers) will be virtually unmanageable, it is inefficient and tedious to
integrate a TCAD tool this way. The obvious solution to this problem is to
force a TCAD tool to understand and write a common framework format used by
all tools - the interchange format.
The second case in Fig. 3.2 shows this situation: Each integrated
tool reads and writes the interchange format either directly or via a
wrapper. Integrating a new tool is only a matter of creating just one new
wrapper which converts the tool's individual data formats to the interchange
format and vice versa. The number of converters just rises by the number
of integrated simulators .
But it is not only this fact that makes the interchange format approach an intriguing data level concept:
These issues are the reason why the vast majority of existing data level implementations uses the interchange file approach. However, there exist a number of TCAD frameworks which do not provide a central interchange format. As becomes obvious from above, this is only a viable solution if the number of simulators and hence the number of converters can be kept small. Virtually all of those systems at least use a central data management tool which is responsible for the appropriate data conversions.
Figure: Tool coupling without and with usage of an
interchange format. Data paths between the process simulator
PROMIS [Pich85], the device simulator MINIMOS [Thur90][Kosi94], the
capacitance simulator VLSICAP [Stra86], and the graphical
postprocessor POST (internal tool) are shown.
The MECCA system of AT& [Lloy93][Lloy90] uses UNIX system tools like awk and sed to perform the necessary conversions and prepare data files prior to tool invocation. The IBM TCAD system [Knep93] provides a database manager called VATS/DB which is responsible for simulation data preparation. Both systems provide a task level using the popular TCL extension language [Oust90], and a user interface based on the TCL/TK X11 toolkit [Sche88][O'Re90][Oust91].
The SIEMENS SATURN framework [Jaco90][Jaco93] is based on the UNIX shell environment and its commands, but already provides a simple interchange format mainly used for visualization purposes. Through the MEDLEY data controller the P& WORKBENCH [Tana93] of NEC prepares simulator input and processes output data. The UNISAS [Nish93] system of OKI exhibits at least a common graphics file format called VSRF.