2.1.2 Data Flows

In the following we will use the term FCT (Framework-Compliant Tool) for referring either to an intrinsic framework tool or to a conventional tool integrated directly or by wrapping.

When the framework invokes a tool, it has to ensure that the tool gets the proper input data, and, after termination of the tool, that the data produced is integrated consistently into the wafer state. This wafer state unambiguously describes at any stage of a framework task the physical and logical state of the wafer subdomain (including environmental conditions) under consideration. Now, since in the framework an FCT writes and reads already syntactically compliant data through the use of the TCAD's data level, the controlling TCAD framework or the tool itself have to ensure that this wafer state is also semantically correct.

  
Figure 2.4: Simulation flow with ``well-behaved'' FCTs

Any tool uses only a certain part of the input data offered by the wafer state. Thus there are two general cases regarding the input and output data manipulation of an FCT:

1. The FCT won't affect unused data. Fig. 2.4 shows this case, where the wafer state in a simulation flow may be passed unaffected through the FCTs.

2. The FCT will possibly affect unused data or its validity. This is also the case, when an entirely new output data file will be written, where the unused data is not transferred to.

  
Figure 2.5: Simulation flow with information bypassing

In the second case, the TCAD framework will have to bypass certain information when invoking the tool. This information has to be merged back on termination of the tool into its output data to ensure a complete and consistent wafer state after tool invocation. Fig. 2.5 illustrates this information bypassing in a simulation flow. Independent from possible input data modifications, we can further distinguish between several different ways how an FCT will behave when invoked by the framework:

1. The FCT will accept a wafer state and will also write a wafer state. Apart from possible bypassing of information, there is no additional work to do by the framework in this case; the tool can be invoked directly without any pre- or postprocessing.

2. The FCT will accept a wafer state, but won't write one. In this case the data produced by the FCT has to be post-processed to produce a correct wafer state.
3. The FCT won't accept a wafer state, but will write one. In this (rather unlikely) case preprocessing is required to adapt the wafer state to the tool's needs.

4. The FCT won't accept a wafer state and won't write one. This is the most common case, both pre- and postprocessing is required to integrate this tool also semantically correct.

  
Figure 2.6: Simulation flow with information bypassing and wafer-state maintenance

One needs tools for ensuring a consistent wafer state, which we will call WMTs (Wafer-state Maintenance Tools) in the following. For example, the VORONOI re-gridding and interpolation service [Hala94] can be used to maintain a consistent wafer state for tools writing grids and attributes not conforming to the wafer state.

Fig. 2.6 shows a simulation flow where both information bypassing and WMTs are necessary to ensure an always consistent wafer state. The reason why the bypassed information has to be merged back after the FCT run but before the WMT run is that the WMT has to make the bypassed data wafer-state consistent too. Consider the case of a topography tool manipulating the geometry: if distributed attributes and grids were contained in the bypassed information that refer to the ``old'' geometry, these would no longer be valid. Re-gridding the resulting geometry and re-interpolating the attributes has to be done to make them consistent with the new geometry.