3.1.1 Textual Representation



next up previous contents
Next: 3.1.2 Binary Representation Up: 3.1 Interchange Formats Previous: 3.1 Interchange Formats

3.1.1 Textual Representation

     

The textual representation of an interchange format is mostly designed for human readability, which helps humans to get an insight into the details of a TCAD problem description, which would be almost impossible with just a binary representation. Additionally this representation is a valuable debugging aid, not only for a TCAD developer, to track down problems with e.g. geometry descriptions or doping definitions. Most important, the textual representation may function as an external - possibly standardized - format for communicating TCAD problem descriptions and solutions between institutions.

Communication of interchange formats is mostly done in electronic form via electronic mail (eMail) or the file transfer protocol (FTP). Also, different machine architectures usually use different byte ordering or floating point representations in binary formats, which is the reason why the interchange format has to have an ASCII representation. This is also useful when problems occur with a specific file, which have to be investigated by an engineer. A human-readable form facilitates tracking down problems and increases the efficiency and familiarity of engineers working with this interchange format.

  In recent years, two ASCII file formats were derived from the SUPREM [Law88][Ho83] structure format and adopted by industrial TCAD vendors as an interchange format. These are namely the MASTER system [Hopp93] of SILVACO which uses SSF (Silvaco Structure Files) as an interchange format, and the CAESAR framework [Axel93] of TMA which uses TIF (TMA Interchange Format) as the central data representation. Although these formats are ASCII, they are by far not human-readable since they use incomprehensible one-letter mnemonics. On the other hand, applications have to read the entire file - even if they do not need all the information in it and ignore those data sets which are not of interest -because of its ASCII format, where no random access is possible. Additionally, since the format is derived from the two-dimensional process simulator SUPREM, it is intrinsically just apt for two-dimensional TCAD problems, and cannot be extended to three dimensions. Thus severe syntactic and semantic limitations exist on the range of problems that can be described with this format. For example, it is only possible to define triangular unstructured meshes in a TIF file, other grid types are not supported, which is a severe shortcoming of this format, since many important simulators in TCAD use different meshes and therefore won't fit in a TCAD system working with a TIF interchange format. An excerpt of a TIF file may be found in Section 8.6.

In 1988 a paper [Duva88] first introducing PIF (Profile Interchange Format) marked the beginning of a new era of TCAD frameworks. PIF's generality and flexibility due to its LISP-like syntax and its compatibility - it was derived from EDIF [EDIF87] - made it the first widely appreciated interchange format. The VISTA implementation of PIF is described in detail in Section 4.2 and Appendix A.

Although PIF is intended to appear in both a textual and a binary representation, a number of TCAD systems used only the ASCII form of PIF as an interchange format and didn't employ a binary form. This approach is valid for small two-dimensional problems, since the data files involved are not so large that ASCII reading and writing times would be a problem.

Notable implementations of ASCII-PIF approaches are the IDDE (Integrated Device Design Environment) [Goug91][Goug93] from Philips, the PRIDE system [Simp91] and the EASE system [Mar87][Mar93] from Intel, which uses a PIF predecessor.

The IDDE environment's PIF format does not include large bulks of data (e.g. doping profiles) directly, but rather references external files by their names which contain the respective data values. This approach has the advantage that the read time of the PIF file itself is effectively minimized, which then becomes more a kind of a skeleton description. Consistency concerns may arise, however, as TCAD data is split across various files with different formats. Besides the PIF data level approach, the intuitive user interface of this environment is notable, which was derived by extensive novice and experienced user observation to increase the usability of the system.



next up previous contents
Next: 3.1.2 Binary Representation Up: 3.1 Interchange Formats Previous: 3.1 Interchange Formats



Martin Stiftinger
Tue Nov 29 19:41:50 MET 1994