Utilities

Version Y-2006.06, June 2006

Copyright Notice and Proprietary Information
Copyright © 2006 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise,
without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.”
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks (®)
Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CRITIC,
CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSIM, HSPICE, Hypermodel, iN-Phase, in-Sync,
Leda, MAST, Meta, Meta-Software, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill,
PrimeTime, RailMill, RapidScript, Saber, SiVL, SNUG, SolvNet, Superlog, System Compiler, TetraMAX, TimeMill, TMA,
VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.
Trademarks (™)
Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora,
AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia,
Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, Cyclelink, Davinci, DC
Expert, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Vision, DesignerHDL,
DesignTime, DFM-Workbench, Direct RTL, Direct Silicon Access, Discovery, DW8051, DWPCI,
Dynamic-Macromodeling, Dynamic Model Switcher, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ,
Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker, FoundryModel, FPGA Compiler II, FPGA Express,
Frame Compiler, Galaxy, Gatran, HANEX, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II,
Hierarchical Optimization Technology, High Performance Option, HotPlace, HSIMplus, HSPICE-Link, iN-Tandem,
Integrator, Interactive Waveform Viewer, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme,
Liberty, Libra-Passport, Library Compiler, Libra-Visa, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture,
Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, Nova Product
Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon, Orion_ec, Parasitic View,
Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler, PowerCODE, PowerGate,
ProFPGA, ProGen, Prospector, Protocol Compiler, PSMGen, Raphael, Raphael-NES, RoadRunner, RTL Analyzer,
Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early Access,
SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC,
Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP, SWIFT,
Taurus, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice,
TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System
Simulator, VirSim, and VMC are trademarks of Synopsys, Inc.
Service Marks (SM)
MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.

SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
All other product or company names may be trademarks of their respective owners.

Utilities, Y-2006.06

ii
UTILITIES CONTENTS

Utilities
About this manual ............................................................................................................................... vii
Audience ............................................................................................................................................................ vii
Related publications........................................................................................................................................... vii
Typographic conventions .................................................................................................................................. viii
Customer support.............................................................................................................................................. viii

Chapter 1 DF–ISE .................................................................................................................................. 1

About DF–ISE ......................................................................................................................................................1
DF–ISE files .........................................................................................................................................................1
DF–ISE syntax .....................................................................................................................................................3
DF–ISE coordinate system ..................................................................................................................................4
Reference coordinate system.........................................................................................................................4
Coordinate transformation..............................................................................................................................4
Location codes .....................................................................................................................................................5
One-dimensional geometries .........................................................................................................................5
Two-dimensional geometries .........................................................................................................................5
Three-dimensional geometries.......................................................................................................................6
Properties.............................................................................................................................................................6
Layout ..................................................................................................................................................................7
Cell .......................................................................................................................................................................8
Recursive tensor ................................................................................................................................................10
Variable tensor ...................................................................................................................................................13
Boundary and grid..............................................................................................................................................15
Dataset...............................................................................................................................................................20
xyplot..................................................................................................................................................................21
Examples ...........................................................................................................................................................22

Chapter 2 The file datexcodes.txt ...................................................................................................... 25

Overview ............................................................................................................................................................25
Header ...............................................................................................................................................................25
Materials.............................................................................................................................................................25
Variables ............................................................................................................................................................26
Search strategy ..................................................................................................................................................28

Chapter 3 DFISETOOLS...................................................................................................................... 29
Overview ............................................................................................................................................................29
DFISETOOLS file...............................................................................................................................................30
Example: Obtaining a summary of a layout file ............................................................................................31
Cutting a 3D device with a plane........................................................................................................................31
Example 1: Cutting a plane through a 3D boundary ....................................................................................32
Example 2: Cutting a plane through a 3D grid .............................................................................................32
Sampling a device with a line segment ..............................................................................................................33
Example 1: Cutting a line through a 3D grid.................................................................................................33
Example 2: Cutting a line through a 2D grid.................................................................................................34
Mirroring a device through a plane.....................................................................................................................34
Example 1: Mirroring a layout.......................................................................................................................35
Example 2: Mirroring a 1D grid.....................................................................................................................35
Example 3: Mirroring a 2D boundary............................................................................................................36
Example 4: Mirroring a 2D grid.....................................................................................................................36
Example 5: Mirroring a 3D boundary............................................................................................................37
Example 6: Mirroring a 3D grid.....................................................................................................................37

iii
CONTENTS UTILITIES

Extending 2D geometry......................................................................................................................................38
Example: Extending a 2D grid......................................................................................................................38
Setting transformation on a geometry or tensor.................................................................................................39
Example: Setting a transformation of a 2D grid............................................................................................39
Applying transformation on a geometry or tensor ..............................................................................................39
Tessellating a geometry .....................................................................................................................................39
Example 1: Tessellating a 2D boundary.......................................................................................................40
Example 2: Tessellating a 3D boundary.......................................................................................................40
Using DFISETOOLS with a Tcl script ................................................................................................................41
Compressing and uncompressing datasets .......................................................................................................43

Chapter 4 Curpot ................................................................................................................................. 45

Overview ............................................................................................................................................................45
Using Curpot ......................................................................................................................................................45
Example .............................................................................................................................................................46

Chapter 5 Converter for SUPREM-4: sup2lig.................................................................................... 47

Overview ............................................................................................................................................................47
Main features .....................................................................................................................................................47
Input format ..................................................................................................................................................47
Supported commands ..................................................................................................................................48
Specialities .........................................................................................................................................................49
Layout and masks ........................................................................................................................................49
Etching .........................................................................................................................................................49
Starting sup2lig ..................................................................................................................................................50
Output ................................................................................................................................................................51
Known problems ................................................................................................................................................51

Chapter 6 Dios to Sentaurus Process converter.............................................................................. 53

Overview ............................................................................................................................................................53
Using converter ..................................................................................................................................................53
From Ligament .............................................................................................................................................53
From Ligament Flow Editor ..........................................................................................................................54
Supported commands ........................................................................................................................................54
comment.......................................................................................................................................................54
deposit..........................................................................................................................................................55
diffusion ........................................................................................................................................................55
etching..........................................................................................................................................................55
grid ...............................................................................................................................................................56
implantation ..................................................................................................................................................56
mask.............................................................................................................................................................56
substrate.......................................................................................................................................................56
title................................................................................................................................................................56
Limitations ..........................................................................................................................................................57
Customization ....................................................................................................................................................57

Chapter 7 Measure .............................................................................................................................. 59

Introduction ........................................................................................................................................................59
Command-line options .......................................................................................................................................60
Matching mechanism and templates..................................................................................................................62
Using Measure in Sentaurus Workbench...........................................................................................................67
Using Measure in Dios .......................................................................................................................................67
Limitations ..........................................................................................................................................................68

iv
UTILITIES CONTENTS

Chapter 8 Sentaurus spice2sdevice.................................................................................................. 69

SPICE circuit files...............................................................................................................................................69
SPICE models....................................................................................................................................................69
Command-line options .......................................................................................................................................72
Example .............................................................................................................................................................72

v
CONTENTS UTILITIES

vi
UTILITIES ABOUT THIS MANUAL

About this manual

Utilities

This manual describes the DF–ISE format and a number of utility programs. The main chapters are:
„ Chapter 1 provides some background information about DF–ISE and describes the organization of
DF–ISE files, the cell structure, and various tensor grids.
„ Chapter 2 describes the file datexcodes.txt.
„ Chapter 3 presents the DFISETOOLS file and provides examples of how to use the DF–ISE
functionality.
„ Chapter 4 describes the postprocessing tool and provides instructions for its use.
„ Chapter 5 describes the SUPREM-4 utility functionality.
„ Chapter 6 describes the Dios to Sentaurus Process converter.
„ Chapter 7 describes the Measure tool, which extracts values from protocols.
„ Chapter 8 describes the Sentaurus spice2sdevice converter.

Audience
This manual is intended for users of Synopsys TCAD software.

Related publications
For additional information about Utilities, see:
„ Documentation on the Web, which is available through SolvNet at
https://solvnet.synopsys.com/DocsOnWeb.
„ Synopsys Online Documentation (SOLD), which is included with the software for CD users or is
available to download through the Synopsys Electronic Software Transfer (EST) system.

vii
ABOUT THIS MANUAL UTILITIES

Typographic conventions
Convention Explanation

<> Angle brackets

Blue text Identifies a cross-reference (only on the screen).

Courier font Identifies text that is displayed on the screen or that the user must type. It identifies the
names of files, directories, paths, parameters, keywords, and variables.

Italicized text Used for emphasis, the titles of books and journals, and non-English words. It also
identifies components of an equation or a formula, a placeholder, or an identifier.

NOTE Identifies important information.

Customer support
Customer support is available through SolvNet online customer support and through contacting the
Synopsys Technical Support Center.

Accessing SolvNet
SolvNet includes an electronic knowledge base of technical articles and answers to frequently asked
questions about Synopsys tools. SolvNet also gives you access to a wide range of Synopsys online
services including software downloads, documentation on the Web, and “Enter a Call to the Support
Center.”

To access SolvNet:
1. Go to the SolvNet Web page at http://solvnet.synopsys.com.
2. If prompted, enter your user name and password. (If you do not have a Synopsys user name and
password, follow the instructions to register with SolvNet.)

If you need help using SolvNet, click HELP in the top-right menu bar or in the footer.

Contacting the Synopsys Technical Support Center

If you have problems, questions, or suggestions, you can contact the Synopsys Technical Support Center
in the following ways:
„ Open a call to your local support center from the Web by going to http://solvnet.synopsys.com
(Synopsys user name and password required), then clicking “Enter a Call to the Support Center.”

viii
UTILITIES ABOUT THIS MANUAL

„ Send an e-mail message to your local support center:

• E-mail [email protected] from within North America.
• Find other local support center e-mail addresses at
http://www.synopsys.com/support/support_ctr.
„ Telephone your local support center:
• Call (800) 245-8005 from within the continental United States.
• Call (650) 584-4200 from Canada.
• Find other local support center telephone numbers at
http://www.synopsys.com/support/support_ctr.

Contacting your local TCAD Support Team directly

Send an e-mail message to:
„ [email protected] from within North America and South America.
„ [email protected] from within Europe.
„ [email protected] from within Asia Pacific (China, Taiwan, Singapore, Malaysia,
India, Australia).
„ [email protected] from Korea.
„ [email protected] from Japan.

ix
ABOUT THIS MANUAL UTILITIES

x
UTILITIES CHAPTER 1 DF–ISE

DF–ISE
Utilities

CHAPTER 1

This chapter provides some background information about DF–ISE and describes the organization of
DF–ISE files, the cell structure, and various tensor grids.

About DF–ISE
A unique file format is used to store all information about the current status of a device. If new data items
must be exchanged between simulators, using keywords and grouping data into data records allow for
the extension of the file format without changing the tools.

DF–ISE tools use a common file that contains information about materials and functions that is shared
by different simulation tools. Generic properties (for example, materials insulator, semiconductor, and
metal) can be used to enable treatment of new materials or functions.

The detailed structures of the DF–ISE data sections are described in the following chapters. DF–ISE data
blocks contain a representation of the device geometry (that is, a representation of the regions of the
device or a spatial tessellation of the regions) or data values, defined on that tessellation.

A DF–ISE file has, at least, three main parts:

„ A header that is used to identify DF–ISE files
„ An Info section that contains general information about the data stored in this file
„ A Data section giving a detailed description of geometry, datasets, or properties

User-defined keywords and data items can be added freely after the Data section. The Synopsys tools
ignore these data records (other tools may not). A library provides basic reading and writing. The
description of the library functions with the exact calling sequences is described in the include files of
this library.

DF–ISE files
DF–ISE files are organized in sections. An overview of the top-level sections of a DF–ISE file is
presented:
DF–ISE This section identifies DF–ISE files. No comments or other sections precede
this identifier. The DF–ISE section has no arguments and no body; therefore, it
does not enclose any other section.

1
CHAPTER 1 DF–ISE UTILITIES

text | binary One of these keywords follows DF–ISE and indicates whether the remainder of
the file is readable or in binary format. Only integer and floating-point values
can be stored in binary format.
Info This section provides additional information about the stored data.
Data This section is linked to a preceding Info section. Its content depends on the type
entry of the information section. The data section types supported by the format
are:

layout Layout geometry used for patterning operations. layout file names
should have the extension .lyt.

cell Cell structures, mainly used for 3D solid modeling. cell file names
should have the extension .cel.

recursive-tensor
Recursive tensor product grids used for compact storage of some
devices. recursive-tensor file names should have the extension .ten.

boundary The geometric data in this section is a boundary description of a

semiconductor device. boundary file names should have the extension
.bnd.

grid A finite-element discretization of the device is stored in this section.

The boundary representation of regions that do not need a simulation
grid are not stored here, but in the boundary data section of the
corresponding boundary file. grid file names should have the
extension .grd.

dataset This section is used to store scalar or vector values on topological

elements of recursive-tensor, boundary, and grid files. dataset file
names should have the extension .dat.
xyplot Data that does not correspond to a simulation grid or boundary
representation is stored in this section. Data can be displayed with
x-y or x-y-z plot tools. Plot file names should have the extension
.plt.

property The global property database is stored in these data sections.

Synopsys tools use a common database that contains information
about materials and functions that need to be shared by different
simulation tools. A property file should have the extension .pro.

2
UTILITIES CHAPTER 1 DF–ISE

DF–ISE syntax
A formal definition of the DF–ISE syntax is:
file := DF–ISE text | binary <new_line> blocks

blocks := <empty> | block | blocks

block := keyword ['(' integer ')'] [body]

body := '{' [blocks | values] '}' | '=' data

data := array | values

array := '[' values ']'

values := <empty> | value | values

value := integer | float | keyword | string

A DF–ISE file comprises a sequence of blocks, which can contain further blocks. A block always has
the following structure: block_name (argument){body}.

Both the argument and the body of a block are optional. The body of a block is either a sequence of
blocks or a sequence of data values. Finally, a data value is an integer, a floating-point value, a keyword,
a string delimited by quotation marks, or an array of data values. Comments start with # and end at the
end of line.

NOTE Comments cannot precede the DF–ISE block.

Blocks without body and data values are separated by space characters or new lines. The order of the
blocks in a file is given by the DF–ISE format.

When storing a binary DF–ISE file, an application can mix readable integer and floating values with
compressed values. An application that reads a binary DF–ISE file must be able to determine whether the
next value in the file is readable or in binary format. The DF–ISE library contains all the functions
needed for reading and writing values.

NOTE The precision of readable floating-point values depends on the application that writes the file.

3
CHAPTER 1 DF–ISE UTILITIES

DF–ISE coordinate system

The DF–ISE coordinate system is always a right-handed Cartesian system. All coordinates are in
micrometers. However, the ‘up’ direction – the vector starting from the substrate floor and pointing
towards the device surface – depends on the application.

Reference coordinate system

The DF–ISE reference coordinate system is right-handed as shown in Figure 1. The z = 0 plane should
be placed on the initial substrate surface, for example, before starting process operations.
Z_REF

Initial substrate Y_REF

surface (z=0)

X_REF

Figure 1 Reference coordinate system with initial substrate example

The layout data for patterning operations on the rear side of the wafer must be defined with the same
coordinate system used for the front side. This means that users who edit mask layers are always looking
at the front side of the wafer (see Figure 2).
Front side
"L" mask

L
"T" mask

T
3D simulation
domain Simulation domain bounding box
Rear side
Figure 2 Editing layout data for front and rear sides

Coordinate transformation
A coordinate transformation can be specified in recursive-tensor, boundary, and grid files. A
transformation is used to map 1D, 2D, or 3D devices to their real place in the 3D wafer. An application
that reads devices only must apply the coordinate transformation to the vertices of the device, except if
the application uses the original 3D wafer coordinate system internally.

4
UTILITIES CHAPTER 1 DF–ISE

Nothing is assumed regarding the ‘up’ direction of the global 3D coordinate system. However, the
orientation proposed in Reference coordinate system on page 4 should be used whenever possible.

The transformation from user coordinates to the global reference coordinate system is performed as
follows:

⎛ ⎞ ⎛ ⎞ ⎛
⎜ x ref ⎟ xx xy xz ⎜ x user ⎟ ⎜ dx ⎞⎟
⎜ y ⎟ = ⎜ ⎟ +⎜
⎜ ref ⎟ yx yy yz × ⎜ y user ⎟ ⎜ dy ⎟⎟
(1)
⎜ z ⎟ zx zy zz ⎜ z user ⎟ ⎝ dz ⎠
⎝ ref ⎠ ⎝ ⎠

The translation vector and transformation matrix are given in the CoordSystem block in this way:
translate = [<dx> <dy> <dz>]
transform = [<xx> <xy> <xz> <yx> <yy> <yz> <zx> <zy> <zz>]

Location codes
Location codes identify the position of vertices, edges, or faces. For example, a location code tells
whether a face is external (or visible), or a face is on an interface between two regions, or a face is fully
inside a 3D region. Location codes must be stored in boundary and grid files.

One-dimensional geometries
For one-dimensional geometries, a location code is defined for vertices. If a vertex is shared by more
than one segment belonging to different regions, it obtains the location code f (internal interface). If the
vertex is defined only in one segment of one region, it has the location code e (external interface), and
if more than one segment of the same region share the vertex, it has the location code i (internal). For
vertices shared only by points or segments that do not belong to any region, the location code is u
(undefined).

Two-dimensional geometries
For two-dimensional geometries, the location code is defined for edges. If an edge is contained only in
one 2D element (triangle, rectangle, polygon) which belongs to a region, the edge is called ‘external
interface.’ If it is shared by more than one 2D element that belongs to different regions, it is called
‘internal interface.’ If more than one 2D elements that belong to a region share the edge, this edge is
called ‘internal’ and, if there are only elements not belonging to any region and line segments sharing
the edge, the location code of the edge is ‘undefined.’

5
CHAPTER 1 DF–ISE UTILITIES

Three-dimensional geometries
For three-dimensional geometries, the location code is defined for faces. If a face belongs to exactly one
3D element included in a region, the face is called ‘external interface.’ If the face is shared by two 3D
elements belonging to different regions, it is called ‘internal interface.’ If the face is shared by two 3D
elements all belonging to the same region, the face is called ‘internal.’ If the face is shared by 3D
elements that do not belong to any region or by 2D elements, the location code is ‘undefined.’

Properties
Properties identify and characterize datasets. A global file dfise.pro that contains a list of properties is
provided in the Synopsys TCAD distribution. A tool that needs the information contained in this file
must read it during startup. layout, cell, recursive-tensor, boundary, grid, dataset, and xyplot files
reference the properties defined in the property database. Multiple properties for one region or one
dataset are allowed. In this case, the material or function name is a list of property names concatenated
with &. For example, an interface region can have the material Silicon&Oxide. This combined material
name is identical to Oxide&Silicon, but should not be confused with SiliconOxide. The attributes of
combined properties are not defined. An application can select any of the entries for setting colors,
interpolation, and so on. Binary compression is not allowed for this file.

Two main property types are defined: Material is used to define region properties and Function defines
the property of any dataset. cell and layout files do not distinguish between Material and Function
properties. Therefore, a property name must be unique within the complete property file.

The following attributes are understood by most of the Synopsys tools:

symbol A short quoted string that identifies this property. The symbol is for display
purposes only and it does not have to be unique.
color Any valid X11 color. It is used for displaying curves or drawing regions.
style Only valid for Function. Line style when displaying curves (solid, dashed, dotted,
ldashed, ldotted).

formula Only valid for Function. It is used to compute datasets that have this property
from other datasets. A mathematical expression using property names must be
provided here. Variable or property names must be enclosed in angle brackets.
unit Only valid for Function. This is a quoted string that defines the unit of a dataset.
interpol Only valid for Function. Interpolation function (linear, log, arsinh).
DF–ISE text
Info {
version = 1.0
type = property
}
Data {
Material (SiliconOxide) {

6
UTILITIES CHAPTER 1 DF–ISE

symbol = "SiO2"
color = brown
}
...
Function (eDensity) {
symbol = "n"
unit = "1/cm^3"
interpol = arsinh
color = red
style = dashed
}
Function (TotalDopingConcentration) {
symbol = "N-tot"
unit = "1/cm^3"
interpol = arsinh
color = red
style = dashed
formula = "<BoronConcentration> + ..."
}
...
}

Layout
The layout file type stores the starting geometry (layout files) and the photolithography data (mask files)
required by all patterning operations of the process flow.

NOTE Simulation domains (a point for 1D, a line for 2D, and a polygon for 3D) can also be stored
in DF–ISE layout files. They have Sim1D, Sim2D, and Sim3D as predefined property names. The
property list is also used to find the color of the layers in the material blocks of the property
database.

A polygon entry of the Polygons block can have one or two vertices when it is used to define a 1D or 2D
simulation domain. The order of appearance of Region blocks must correspond to the regions entry list
of the Info block. The file structure is:
DF–ISE text | binary

Info {
version = 1.0
type = layout
nb_vertices = <int>
nb_polygons = <int>
nb_regions = <int>
regions = ["<region1>" "<region2>" ...]
materials = [<material1> <material2> ...]
}
Data {
Vertices (<nb_vertices>) {
<x0> <y0>
<x1> <y1>

7
CHAPTER 1 DF–ISE UTILITIES

...
}
Polygons (<nb_polygons>) {
<nb_vertices> <vertex> <vertex> ...
<nb_vertices> <vertex> <vertex> ...
...
}
Region ("<material1>") {
material = <material1>
Elements (<nb_elts>) {<elt0> <elt1> ...}
}
...
}

Cell
The ‘cell’ data structure uses a regular subdivision of the simulation domain into blocks of equal size
(cubes). Each block can be refined into groups of cells by splitting it along the x-axis, y-axis, or z-axis
(see Figure 3). The construction of general, not axis-aligned structures is achieved by defining a material
density value for each cell. Storing material densities is optional. By default, the maximal density value
1.0 is assumed. An unrefined block always has a material density of 1.0.
Z

1D Block

Block array 2D Block

Y

Cells

Base grid

X
Figure 3 Cell data structure

Geometry and datasets are stored in the same file and use the same format. Region identifiers and
material densities are considered as normal datasets. However, they have the reserved property names
regions and densities.

NOTE The refinement of the different datasets does not have to be identical, except for the material
density refinement, which must always match the region data. A property entry can either be
an entry of the material list or an entry of the function list in the property database.

8
UTILITIES CHAPTER 1 DF–ISE

The Info block defines the size of the simulation domain and refinement information. block_size is the
size in micrometers of the initial cubes building the simulation domain. The size of the simulation
domain is given by multiplying block_size by nb_xblocks, nb_yblocks, or nb_zblocks. When a block (cube)
is refined, nb_xsplits, nb_ysplits, and nb_zsplits define the number of cells for the given axis.

The numbering of blocks and cells always starts at the lowest coordinate. Indices are incremented by
traversing the structure first along the x-axis, then along the y-axis, and finally along the z-axis. In
practice, traversing the data structure is performed in this way:
for (bz = 0; bz < nb_zblocks; bz++) {
for (by = 0; by < nb_yblocks; by++) {
for (bx = 0; bx < nb_xblocks; bx++) {
if (block[bx][by][bz] is refined)
{
for (cz = 0; cz < nb_zsplits; cz++) {
for (cy = 0; cy < nb_ysplits; cy++) {
for (cx = 0; cx < nb_xsplits; cx++) {
...
}
}
}
}
}
}
}

The order of appearance of Dataset blocks must correspond to the datasets entry list of the Info block.
The structure of the file is:
DF–ISE text | binary
Info {
version = 1.0
type = cell
dimension = 1 | 2 | 3
block_size = <double>
nb_xblocks = <int>
nb_yblocks = <int>
nb_zblocks = <int>
nb_xsplits = <int>
nb_ysplits = <int>
nb_zsplits = <int>
nb_datasets = <int>
datasets = [ "<dataset1>" "<dataset2>" ... ]
properties = [ <property1> <property2> ... ]
}
Data {

Dataset ("<dataset1>") {
property = <property1>

Blocks (<nb_blocks>) {
<ref_flag> <value> ...
<ref_flag> <value> ...
...
}
}

9
CHAPTER 1 DF–ISE UTILITIES

Dataset ("<dataset2>") {
...
}
...

<ref_flag> is:
0: no refinement, only one data values follows
1: refinement along x, nb_xsplits data values follow
2: refinement along y, nb_ysplits data values follow
4: refinement along z, nb_zsplits data values follow
3: refinement along x and y, nb_xsplits * nb_ysplits values follow
...
7: refinement along x, y, and z, nb_xsplits * nb_ysplits
* nb_zsplits data values follow
}

Recursive tensor
A recursive grid is a generalization of a tensor grid. In addition to a base grid that is a tensor grid, it
allows recursive subdivision of elements. Vertices, edges, faces, and elements are defined implicitly
through the grid and its traversal rules. The tensor base grid can be:
Uniform Rectilinear grid with constant spacing in x-direction, y-direction and z-direction
(the spacing for each direction is given separately).
Rectilinear Rectilinear grid with nonconstant spacing between coordinate planes.
Warped Grid with tensor mesh topology and explicit coordinates for each vertex.

The numbering of vertices, edges, faces, and elements starts with index 0 at the lowest coordinates and
goes first through the x-axis, y-axis, and then z-axis. The entries nb_x, nb_y, and nb_z in the Info block
represent the number of vertices of the base grid in each of the dimensions. Vertices, edges, faces, and
elements are implicitly numbered as follows:
„ There are a total of ( nb_x ) ( nb_y ) ( nb_z ) nodes. Node ( i, j, k ) has the number
i + j ( nb_x ) + k ( nb_x ) ( nb_y ) , where 0 ≤ i < nb_x, 0 ≤ j < nb_y, 0 ≤ k < nb_z .
„ There are a total of
( nb_x – 1 ) ( nb_y ) ( nb_z ) + ( nb_x ) ( nb_y – 1 ) ( nb_z ) + ( nb_x ) ( nb_y ) ( nb_z – 1 ) edges. The
edges are numbered or traversed in the following way: First, the vertices are traversed in the order
given below and, for each vertex, first the edge pointing along the positive x-axis is taken, then the
one pointing along the positive y-axis, and finally the one pointing along the positive z-axis. At the
boundary of the simulation domain, the edge index is not incremented when no edge exists in the
given direction.
„ There are a total of (nb_x)(nb_y–1)(nb_z–1)+(nb_x–1)(nb_y)(nb_z–1)+(nb_x–1)(nb_y–1)(nb_z)
faces. The face numbering is analogous to the edge numbering. At each vertex, the three faces
orthogonal to the x, y, and z axes are taken.

10
UTILITIES CHAPTER 1 DF–ISE

„ There are, in principle, a total of ( nb_x – 1 ) ( nb_y – 1 ) ( nb_z – 1 ) elements. However, additional
dummy elements are added at the upper bounds of the coordinate ranges, so that total number of
elements is ( nb_x ) ( nb_y ) ( nb_z ) . Element ( i, j, k ) has, therefore, the number
i + j ( nb_x ) + k ( nb_x ) ( nb_y ) , where 0 ≤ i < nb_x, 0 ≤ j < nb_y, 0 ≤ k < nb_z .

The contents of the BaseGrid block depend on the tensor grid subtype as follows:
„ For uniform grids, it contains the spacings Δx , Δy , and Δz in the directions of the coordinate
planes. Vertex number 0 is implicitly at (0,0,0); the CoordSystem block can be used for further
moving.
„ For rectilinear grids, it contains the spacings Δx1, …, Δxnb_x–1, Δy1, …, Δynb_y–1, Δz1, …, Δznb_z–1, that
is, there are nb_x–1 entries for the x-direction, nb_y–1 entries for the y-direction, and nb_z–1 entries
for the z-direction. Vertex number 0 is implicitly at (0,0,0); the CoordSystem block can be used for
further moving.
„ For warped grids, it contains the coordinates of the grid vertices x0, y0, z0, x1, y1, z1, …, xnb_v , ynb_v ,
and znb_v where the numbering is the natural cell numbering, that is, varying fastest along the x-axis.

The CellTree block is used only if the mesh is recursively refined; if it is missing, the data structure is an
ordinary tensor mesh. Otherwise, for each macroelement including the dummy elements, the recursive
grid structure is indicated as:
<min_lev> <max_lev> <nb_el> <sub_el0> <sub_el1> ... <sub_el_nb_el>

min_lev and max_lev are the minimum and maximum refinement levels in the macroelement. A value of
0 means that the macroelement is unrefined. The number of elements nb_el gives the number of elements
in the macroelement that result in the final mesh. A value of 0 indicates that the macroelement is a
dummy element or is deleted from the mesh; a value of 1 means that it is unrefined.

If the minimum and maximum refinement levels of a macroelement are equal, the mesh can be
constructed implicitly and the mesh description within the macroelement is complete. If the refinement
levels are not equal, they are followed by a list of the subelements sub_el within the macroelement. A
simple numbering scheme is used to indicate the subelements. The numbering proceeds looping through
each parent element at a level. Figure 4 shows an example of a 2D scheme.
Level 0 Level 1 Level 2

6 7 10 11
2 3
8 9 12 13
1
14 15 18 19
4 5
16 17 20 21

Figure 4 Numbering scheme for recursively subdivided cells

The coordinates of the joints (vertices) of the refined grid are determined uniquely by the base grid and
the cell tree.

11
CHAPTER 1 DF–ISE UTILITIES

Regions are used to denote materials and boundary conditions. Regions can reference vertices, edges,
faces, and elements of the base grid (not the refined grid) through their implicitly defined number (see
above). The order of appearance of Region blocks must correspond to the regions entry list of the Info
block. The material entry can be empty.

For data on the recursive grids, the DF–ISE data file format is used.

An example of the structure of a DF–ISE recursive tensor grid file is:

DF–ISE text | binary

Info {
version = 1.0
type = recursive-tensor
subtype = uniform | rectilinear | warped
dimension = 1 | 2 | 3
extents = <int> | <int> <int> | <int int> <int>
nb_regions = <int>
regions = ["<region1>" "<region2>" ...]
materials = [<material1> <material2> ...]
}
Data {
CoordSystem {
translate = [<dx> <dy> <dz>]
transform = [<xx> <xy> <xz> <yx> <yy> <yz> <zx> <zy> <zz>]
}
BaseGrid (<nb_entries>) {
<e0> <e1> <e2>
}
CellTree (<nb_macro_elements>) {
<min_lev> <max_lev> <nb_el> <sub_el0> <sub_el1> ... <sub_el_nb_el>
...
...
}
Region ("<region1>") {
material = <material1>
Edges (<nb_edge>) {<edge0> <edge1> ...}
Faces (<nb_face>) {<face0> <face1> ...}
}
Region ("<region2") {
material = <material2>
Vertices (<nb_vert>) {<vert0> <vert1> ...}
}
Region ("<region3>") {
material = <material3>
Faces (<nb_fac>) {<fac0> <fac1> ...}
}
Region ("<region4 >") {
material = <material4>
Elements (<nb_elts>) {<elt0> <elt1> ...}
}
}

12
UTILITIES CHAPTER 1 DF–ISE

Variable tensor
A variable tensor grid is a generalization of a recursive tensor grid. The recursive subdivisions allowed
are not restricted to powers of two, and the addition of a property tree allows for property changes within
a cell of the tensor grid. In addition to a base grid that is a tensor grid, the variable tensor grids allow
recursive subdivision of elements.

Vertices, edges, faces, and elements are defined implicitly through the grid and its traversal rules. The
tensor base grid can be:
Uniform Rectilinear grid with constant spacing in x-direction, y-direction, and z-
direction (the spacing for each direction is given separately).
Rectilinear Rectilinear grid with nonconstant spacing between coordinate planes.
Warped Grid with tensor mesh topology and explicit coordinates for each vertex.

The numbering of vertices, edges, faces and elements starts with index 0 at the lowest coordinates and
goes first through the x-axis, y-axis, and then z-axis. The entries nb_x, nb_y, and nb_z in the Info block
represent the number of vertices of the base grid in each of the dimensions. Vertices, edges, faces, and
elements are implicitly numbered as follows:
„ There are a total of ( nb_x ) ( nb_y ) ( nb_z ) nodes. Node ( i, j, k ) has the number
i + j ( nb_x ) + k ( nb_x ) ( nb_y ) , where 0 ≤ i < nb_x, 0 ≤ j < nb_y, 0 ≤ k < nb_z .
„ There are a total of
( nb_x – 1 ) ( nb_y ) ( nb_z ) + ( nb_x ) ( nb_y – 1 ) ( nb_z ) + ( nb_x ) ( nb_y ) ( nb_z – 1 ) edges. The
edges are numbered or traversed in the following way: first the vertices are traversed in the order
given below and, for each vertex, first the edge pointing along the positive x-axis is taken, then the
one pointing along the positive y-axis, and finally the one pointing along the positive z-axis. At the
boundary of the simulation domain, the edge index is not incremented when no edge exists in the
given direction.
„ There are a total of (nb_x)(nb_y–1)(nb_z–1)+(nb_x–1)(nb_y)(nb_z–1)+(nb_x–1)(nb_y–1)(nb_z)
faces. The face numbering is analogous to the edge numbering. At each vertex, the three faces
orthogonal to the x, y, and z axes are taken.
„ There are, in principle, a total of ( nb_x – 1 ) ( nb_y – 1 ) ( nb_z – 1 ) elements. However, additional
dummy elements are added at the upper bounds of the coordinate ranges, so that total number of
elements is ( nb_x ) ( nb_y ) ( nb_z ) . Element ( i, j, k ) has, therefore, the number
i + j ( nb_x ) + k ( nb_x ) ( nb_y ) , where 0 ≤ i < nb_x, 0 ≤ j < nb_y, 0 ≤ k < nb_z .

The contents of the BaseGrid block depend on the tensor grid subtype as follows:
„ For uniform grids, it contains the spacings Δx , Δy , and Δz in the directions of the coordinate
planes. Vertex number 0 is implicitly at (0,0,0); the CoordSystem block can be used for further
moving.
„ For rectilinear grids, it contains the spacings Δx1, …, Δxnb_x–1, Δy1, …, Δynb_y–1, Δz1, …, Δznb_z–1, that
is, there are nb_x–1 entries for the x-direction, nb_y–1 entries for the y-direction, and nb_z–1 entries

13
CHAPTER 1 DF–ISE UTILITIES

for the z-direction. Vertex number 0 is implicitly at (0,0,0); the CoordSystem block can be used for
further moving.
„ For warped grids, it contains the coordinates of the grid vertices x0, y0, z0, x1, y1, z1, …, xnb_v , ynb_v ,
and znb_v where the numbering is the natural cell numbering, that is, varying fastest along the x-axis.

The CellTree block is used only if the mesh is recursively refined; if it is missing, the data structure is an
ordinary tensor mesh. Only those macro cells that are refined will have an entry in the CellTree. Such
entries are defined as follows:
<index> <x-refinement> <y-refinement> <z-refinement> <nb_el> <sub_el0> <sub_el1> ...
<sub_el_nb_el>

indexrefers to the cell index of the refined macro cell. x-refinement, y-refinement, and z-refinement give
the number of refinement levels in the respective direction. The number of elements nb_el gives the
number of elements in the macroelement that result in the final mesh. This is followed by a list of the
subelements sub_el within the macroelement. A simple numbering scheme is used to indicate the
subelements. The numbering proceeds looping through each of the parent elements at a level.

The coordinates of the joints (vertices) of the refined grid is determined uniquely by the base grid and
the cell tree. The numbering scheme and calculation of coordinates are performed analogously to the
case of the recursive tensor grid.

The Properties can be used to assign different properties, for example, materials, to the subcells of a
refined macro cell:
<index> <nb_el> <prop_sub_el0> <prop_sub_el1> ... <prop_sub_el_nb_el>

index refers to the cell index of the refined macro cell; it should also appear in the CellTree. The
refinements are taken from CellTree and the properties of the subcells must refer one-to-one to the
subcells of the respective entry in CellTree. Although each entry of Properties should have an entry in
CellTree, the reverse is not true. In general, single entries or the entire Properties block can be omitted,
in which case all subcells are assumed to have the same property.

Regions are used to denote materials and boundary conditions. Regions can reference vertices, edges,
faces, and elements of the base grid (not the refined grid) through their implicitly defined number (see
above). The order of appearance of Region blocks must correspond to the regions entry list of the Info
block. The material entry can be empty.

For data on the variable tensor grids, the DF–ISE data file format is used.

An example of the structure of a DF–ISE variable tensor grid file is:

DF–ISE text | binary

Info {
version = 1.0
type = variable-tensor
subtype = uniform | rectilinear | warped
dimension = 1 | 2 | 3
extents = <int> | <int> <int> | <int int> <int>
nb_regions = <int>

14
UTILITIES CHAPTER 1 DF–ISE

regions = ["<region1>" "<region2>" ...]

materials = [<material1> <material2> ...]
}
Data {
CoordSystem {
translate = [<dx> <dy> <dz>]
transform = [<xx> <xy> <xz> <yx> <yy> <yz> <zx> <zy> <zz>]
}
BaseGrid (<nb_entries>) {
<e0> <e1> <e2>
}
CellTree (<nb_macro_elements>) {
<index> <x-refinement> <y-refinement> <z-refinement> <nb_el> <sub_el0> <sub_el1> ...
<sub_el_nb_el>
...
...
}
Properties(<nb_macro_elements>) {
<index> <nb_el> <prop_sub_el0> <prop_sub_el1> ... <prop_sub_el_nb_el>
...
...
}
Region ("<region1>") {
material = <material1>
Edges (<nb_edge>) {<edge0> <edge1> ...}
Faces (<nb_face>) {<face0> <face1> ...}
}
Region ("<region2") {
material = <material2>
Vertices (<nb_vert>) {<vert0> <vert1> ...}
}
Region ("<region3>") {
material = <material3>
Faces (<nb_fac>) {<fac0> <fac1> ...}
}
Region ("<region4 >") {
material = <material4>
Elements (<nb_elts>) {<elt0> <elt1> ...}
}
}

Boundary and grid

Boundary and grid files have a similar format. However, the interpretation of the contents is different.
Each region must have one material name. Figure 5 on page 17 and Figure 6 on page 19 present the
numbering of vertices, edges, and faces. Figure 6 is only required when data must be stored on vertices
or edges locally for each element.

An index to a face is signed. When negative, the real face index is computed by face_index = –index–1.
The negative sign means that the edge order of the face as well as the edge orientation must be inverted.
Face orientation is important to obtain a consistent orientation of the object (counterclockwise
orientation of the edges when looking from outside of the solid including this face). An edge index is

15
CHAPTER 1 DF–ISE UTILITIES

signed in the same way as a face index. A negative edge sign means that the first vertex and not the
second is connected to the next edge of a loop.

NOTE The DF–ISE library provides a function to fix the orientation of the faces of a 3D boundary.

Elements have a shape code that defines the element geometry and the data following this code.
Elements of different shape can be given in any order. The following elements are predefined:

Point 0 vertex
Segment 1 vertex0 vertex1
Triangle 2 edge0 edge1 edge2
Rectangle 3 edge0 edge1 edge2 edge3
Polygon 4 nb_edges edge0 edge1...
Tetrahedron 5 face0...face3
Pyramid 6 face0...face4
Prism 7 face0...face4
Brick 8 face0...face5
Tetrabrick 9 face0...face6
Polyhedron 10 nb_faces face0 face1...

The edge and face lists of polygons and polyhedra do not have to be connected. They can be a set of
loops and shells that define the outer boundary and internal holes of an element.

An edge orientation for each element is also predefined. The edge orientation is used when storing data
on edges locally for each element. The vertex order for each edge of the elements is:

Segment: Tetrahedron:
e0: v0 v1 e0: v0 v1
e1: v1 v2
Triangle: e2: v2 v0
e0: v0 v1 e3: v0 v3
e1: v1 v2 e4: v1 v3
e2: v2 v0 e5: v2 v3

Rectangle: Pyramid:
e0: v0 v1 e0: v0 v1
e1: v1 v2 e1: v1 v2
e2: v2 v3 e2: v2 v3
e3: v3 v0 e3: v3 v0
e4: v0 v4
Polygon: e5: v1 v4
e0: v0 v1 e6: v2 v4
e1: v1 v2 e7: v3 v4
…

16
UTILITIES CHAPTER 1 DF–ISE

Prism: Brick:
e0: v0 v1 e5: v2 v5 e0: v0 v1 e6: v2 v6
e1: v1 v2 e6: v3 v4 e1: v1 v2 e7: v3 v7
e2: v2 v0 e7: v4 v5 e2: v2 v3 e8: v4 v5
e3: v0 v3 e8: v5 v3 e3: v3 v0 e9: v5 v6
e4: v1 v4 e4: v0 v4 e10: v6 v7
e5: v1 v5 e11: v7 v4

Tetrabrick:
e0: v0 v1 e6: v2 v5
e1: v1 v2 e7: v2 v6
e2: v2 v3 e8: v3 v6
e3: v3 v0 e9: v4 v5
e4: v0 v4 e10: v5 v6
e5: v1 v5 e11: v6 v4
F4 (top)

F2 (back)
E2
E2 E1
F1 (back)
E3 E1
F0

E0 E0

F3 (bottom)

F2 (back)
F2 (back)
F3 (back)

F1 F1
F0
F0

F3 (bottom) F4 (bottom)

F5 (top) F6 (top)

F4 (back)
F3 (back) F2 (back) F0 (back)
F2
F1 F3

F0 F1

F4 (bottom) F5 (bottom)

Figure 5 Edge and face numbering

17
CHAPTER 1 DF–ISE UTILITIES

The order of appearance of Region blocks must correspond to the regions entry list of the Info block.
Several regions with the same name are allowed:
DF–ISE text | binary

Info {
version = 1.0
type = boundary | grid
dimension = 1 | 2 | 3
nb_vertices = <int>
nb_edges = <int>
nb_faces = <int>
nb_elements = <int>
nb_regions = <int>
regions = [ "<region1>" "<region2>" ... ]
materials = [ <material1> <material2> ... ]
}
Data {

CoordSystem {
translate = [ <dx> <dy> <dz> ]
transform = [ <xx> <xy> <xz> <yx> <yy> <yz> <zx> <zy> <zz> ]
}
for 1d, 2d, and 3d
Vertices (<nb_vertices>) {
<x0> <y0> <z0>
<x1> <y1> <z1>
...
}
for 2d and 3d
Edges (<nb_edges>) {
<vertex0> <vertex1>
<vertex0> <vertex1>
...
}
for 3d
Faces (<nb_faces>) {
<nb_edges> <edge0> <edge1> ... <edge_n>
<nb_edges> <edge> <edge> ...
...
}
nb_vert. for 1d, nb_edges for 2d, nb_faces for 3d
Locations (<nb_vertices> | <nb_edges> | <nb_faces>) {
i (internal) | f (internal interface) |
e (external interface) | u (undefined)
...
}
Elements (<nb_elements>) {
0 <vertex>
1 <vertex0 <vertex1>
2 <edge0 <edge1> <edge2>
3 <edge0 <edge1> <edge2> <edge3>
4 <nb_edges> <edge0> <edge1> ... <edge_n>
5 <face0 ... <face3>
6 <face0 ... <face4>
7 <face0 ... <face4>
8 <face0 ... <face5>
9 <face0 ... <face6>

18
UTILITIES CHAPTER 1 DF–ISE

10 <nb_faces> <face0> <face1> ... <face_n>

...
}
Region ("<region1>") {
material = <material1>
Elements (<nb_elts>) { <elt0> <elt1> ... }
}
Region ("<region2>") {
material = <material2>
Elements (<nb_elts>) { ... }
}
}
5
e8 e7
2 3 e2 2
3 e6
4
e2 e1

e5
e1
e3

e4
e3

0 1 2
e0 0 e0 1 e2 e1

0 e0 1
3 4
e6
e5
e3

e5
e7
e4
e4

2 3 e2
2
e2 e3
e1 e1
0 e0 1 0 e0 1

7 e10 6 4 e11 6
e11 e9 e9
e8 5 5 e10
4
e4

e8

e7
e6
e7

e6
e5

e5

3 e2 0 e3
e4

e3 2 3
e0
e1 e2
0 e0 1 1 e1 2

Figure 6 Edge and vertex numbering

19
CHAPTER 1 DF–ISE UTILITIES

Dataset
The dataset files add scalar or vector values to the nodes, edges, faces, elements, or regions of a grid file.
The data location is limited to vertex, edge, face, element, or region. Two additional location codes are
used to store Voronoï data: vertex_element and edge_element. Only Sentaurus Device understands these
codes.

dimension gives the set number of data values per location (1 for scalars, > 1 for vectors). The dimension
entry has a different meaning than the geometry dimension given in the Info block. The type of a dataset
is either a scalar or vector.

validity gives the list of regions in which the dataset is defined. For consistency, data values should only
be defined for the entries belonging to these validity regions.

NOTE The DF–ISE library provides some functions to access the values of a dataset for a given
validity region. For the moment, this can only be used with datasets whose location is vertex.

Discontinuous datasets are a matter of interpretation of the data file format. Several datasets with the
same quantity can be present in a single data file. Each instance of the dataset should be defined for a
different set of regions (including the boundary points of a region). The entire dataset can, therefore, be
discontinuous across boundaries. Due to the interpretational nature of this definition of discontinuous
datasets, different tools may handle data files with such datasets differently. Refer to specific manuals
for detailed descriptions of individual tools.

Data values are given in the order predefined by the location entry. When vectors are stored, all
components are given per item (vertex, edge, ...) in the Values block.

The order of appearance of Dataset blocks must correspond to the datasets entry list of the Info block.
Functions are references to the function blocks stored in the property file. Several datasets with the same
name are allowed (with different validity regions, this may be used to define data discontinuities):
DF–ISE text | binary

Info {
version = 1.0
type = dataset
dimension = 1 | 2 | 3
nb_vertices = <int>
nb_edges = <int>
nb_faces = <int>
nb_elements = <int>
nb_regions = <int>
datasets = ["<dataset1>" "<dataset2>" ...]
functions = [<function1> <function2> ...]
}
Data {
Dataset ("<dataset1>") {
function = <function1>
type = scalar | vector

20
UTILITIES CHAPTER 1 DF–ISE

dimension = 1 (1 for scalar, > 1 for vectors or arrays)

location = vertex | edge | face | element | region
validity = ["<region0>" "<region1>" ...]
Values (<nb_values>) {<value0> <value1> ...}
}
Dataset ("<dataset2>") {
function = <function2>
...
}

xyplot
The xyplot files are used to store curves. The property list gives additional information for each data
column of the file. The x-axis is not always in the first column, since the user can select freely the dataset
mapped on the x-axis. For undefined values (discontinuities in the curve), the character ‘u’ is used as a
placeholder:
DF–ISE text | binary

Info {
version = 1.0
type = xyplot
datasets = ["<dataset1>" "<dataset2>" ...]
functions = [<function1> <function2> ...]
}
Data {
<v0_d1> <v0_d2> ... (one value for each data set)
<v1_d1> <v1_d2> ... (one value for each data set)
...
}

21
CHAPTER 1 DF–ISE UTILITIES

Examples
This section provides examples of the DF–ISE file format.
point 1

region "cathode"
property Contact
x = 1.0
location external
region "gate"
property Oxide segment 2

x = 0.0
location interface

segment 1

region "substrate"
x = -5.0
property Silicon
location internal

segment 0

region "anode"
x = -10.0
property Contact
location external

point 0

Figure 7 One-dimensional grid

region "cathode"
Eij: E <edge number> <location> segment 1
e: external
E16e E17e
f: interface (0, 1)
i: internal
E13e

E15e
E14i

rectangle 4 rectangle 3 region "gate"

E11f E12f
(0, 0)
Vertex numbering is from triangle 1
left to right and down to up:
E10e
E9i
E7e

(0, -10) rectangle 2

E8i
(5, -10)
(10, -10) triangle 0
(0, -5) (0, -5) region "substrate"
... E5i E6i
E3i

E4e
E2e

rectangle 0 rectangle 1

E0e E1e
(0, -10) (5, -10) (10, -10)

segment 0
region "anode"
Figure 8 Two-dimensional grid

22
UTILITIES CHAPTER 1 DF–ISE

Tetrahedron
Pyramid region "gate"
region "gate"
(5, 1.5, 7) V10

triangle 1
triangle 0
region "cathode"
region "cathode" V9
(front) V8
(front) V5
(12, 1.5, 0) V7
V6

(0, 3, -10) V4
V3
(0, 0, -10) V0
(12, 1.5, -10) V1 V2
(10, 0, -10)

Brick Prism Vertex numbering

region "substrate" region "substrate"
rectangle 0
region "anode"
(bottom)
F13e (back)
F10e (front)
E21
F14e (back) F11e (front)
E20
E17
E15 E18 E19 F12e (back)
E14 E13 F15i
E11 E16 F8f
F9f
E12 F6e (back)
E10 F5e (back)
E6 E9 F4e (back)
E7 E8 F7i

E4 E3
E5 E2 F3e (front)
E0
E1 F2e (front)
F0e (floor) F1e (floor)
Edge numbering Face numbering with
location codes

Figure 9 Three-dimensional grid

23
CHAPTER 1 DF–ISE UTILITIES

24
UTILITIES CHAPTER 2 THE FILE DATEXCODES.TXT

The file datexcodes.txt

Utilities

CHAPTER 2

This chapter describes the datexcodes.txt file.

Overview
The file datexcodes.txt is the Synopsys configuration database for materials, doping species, and other
quantities that are used in semiconductor process and device simulation. The database is referred to by
the various Synopsys TCAD software for different purposes. It does not contain physical properties of
materials or quantities, but configuration properties such as names, colors, and labels. The file is divided
into three sections: header, materials, and variables. Each material in the materials section and each
quantity in the variables section are described by several properties that are explained here.

Header
The first four lines in the file datexcodes.txt consist of a header:
DATEX2.1
Datacode
"$Id$"
"Data codes for semiconductor process and device simulation"

The first two lines specify the version number and type of the file. The last two lines are strings
containing comments.

Materials
A material, for example, silicon, can be specified as follows:
Silicon {
label = "Silicon"
group = Semiconductor
color = #ffb6c1
alter1 = Si
alter2 = 3
}

25
CHAPTER 2 THE FILE DATEXCODES.TXT UTILITIES

Table 1 describes the different fields.

Table 1 DATEX material specification

Field Description

alter1 Name used for translation from and to SUPREM-4a.

alter2 Name used for translation from and to SUPREM-4b.

color Color used for display (hexadecimal intensities for red, green, blue; default #b0b0b0).

group Material classification (Semiconductor, Conductor, Insulator, or All; default All).

label Name used for display purposes (default Unknown).

It is possible to declare multiple names (or aliases) for a material:

Vacuum, Gas, Ambient {
...
}

NOTE A code number such as code=22 is also recognized. Materials with the same code number are
considered aliases. This is an obsolete feature and may be discontinued in the future.

Alternative colors can be listed after the primary color, for example:
Silicon {
...
color = #ffb6c1, #ac3320, #f18010
...
}

Variables
A variable, for example, ElectricField, can be specified as follows:
ElectricField {
label = "electric field"
symbol = "E"
unit = "V/cm"
factor = 1.0e+04
arsinh = 1.0e+14
precision = 4
interpol = linear
material = All
alter1 = em
alter2 = 103
}

26
UTILITIES CHAPTER 2 THE FILE DATEXCODES.TXT

Table 2 describes the different fields.

Table 2 DATEX variable specification

Field Description

alter1 Name used for translation from and to SUPREM-4a.

alter2 Name used for translation from and to SUPREM-4b.

arsinh Scaling factor for arsinh interpolation mode (default 1014).

factor Scaling factor (default 1).

interpol Interpolation mode (linear, log, or arsinh; default linear).

label Name used for display purposes (default undefined).

material Specifies the validity of this quantity in material groups.

precision Number of significant digits (used in graphics tools; default 7).

symbol Symbol used for display (default ?).

unit Unit used for display and data exchange (default 1).

It is possible to declare multiple names (or aliases) for a variable, for example:
BoronConcentration, BoronChemicalConcentration {
...
}

NOTE A code number such as code=43 is also recognized. Variables with the same code number are
considered aliases. This is an obsolete feature and may be discontinued in the future.

The following keywords are also valid for the precision field: half, single, and double. They correspond
to the numeric values of 3, 7, and 14, respectively.

The field material can specify multiple materials or material groups:

material = Semiconductor, Insulator
material = Silicon, PolySilicon, Germanium

To support user-defined doping species, a doping field is also recognized:

doping = donor (ionized_code = 961)
doping = acceptor (ionized_code = 963)

Refer to Sentaurus Device, User-defined species on page 97 for more information.

27
CHAPTER 2 THE FILE DATEXCODES.TXT UTILITIES

Search strategy
Multiple datexcodes.txt files can be used. The following search strategy is observed:
„ $STROOT/datexcodes.txt or $STROOT/tcad/$STRELEASE/lib/datexcodes.txt if the environment variable
STROOT_LIB is not defined (lowest priority).
„ $HOME/datexcodes.txt (medium priority).
„ datexcodes.txt in local directory (highest priority).

Definitions in later files replace or add to the definitions in the earlier files. In this way, the local file only
needs to contain new materials or variables that the user wants to add.

NOTE The environment variable DATEX is no longer used.

28
UTILITIES CHAPTER 3 DFISETOOLS

DFISETOOLS
Utilities

CHAPTER 3

This chapter describes the DFISETOOLS file and provides examples of how to use the DF–ISE
functionality.

Overview
For DF–ISE layout, boundary and grid files, the following utilities are available:
„ Print general information about the file
„ Cut a 3D device with a plane
„ Sample a device with a line segment
„ Mirror a device through a plane
„ Extend a 2D geometry in 3D
„ Set or apply a transformation to a geometry
„ Tessellate a 2D or 3D geometry
„ Compress and decompress dataset files

Each operation corresponds to a dfisetools option:

-ai Adds interfaces to a boundary or grid file. This option creates a copy of the
original file, which contains interfaces.
-aid Adds interfaces to a boundary or grid file, and the corresponding .dat file. This
option creates a copy of the original files, which contain interfaces.
-compress Compresses dataset files.
-cut Cuts.
-expand Expands compressed dataset files.
-extend Extends.
-plot Plots.
-r Resumes.
-reflect Mirrors.

29
CHAPTER 3 DFISETOOLS UTILITIES

-ri Removes interfaces from a boundary or grid file. Files created by Sentaurus
Process contain interfaces between neighboring regions. Files that contain
interfaces cannot be handled by all Synopsys TCAD tools. This option creates
a copy of the original file without interfaces.
-rid Removes interfaces from a boundary or grid file, and a corresponding .dat file.
Files created by Sentaurus Process contain interfaces between neighboring
regions. Files that contain interfaces cannot be handled by all Synopsys TCAD
tools. This option creates a copy of the original files without interfaces.
-set_trans Sets transformation.
-tessellate Tessellates.
-transform Applies transformation.

DFISETOOLS can be used interactively or through a tool command language (Tcl) script file.
DFISETOOLS performs all of the operations specified by the options in the interactive mode on the
given DF–ISE files. The produced files have an operation-dependent suffix _cut for cutplane results or
_plot for plot results.

Use dfisetools option_list filename_list

When used through a Tcl script, DFISETOOLS executes each command for the specified DF–ISE files,
with the possibility to specify the suffix of the produced files (see Using DFISETOOLS with a Tcl script
on page 41).
Use dfisetools script_name

Examples on how to use DFISETOOLS can be found in the DF–ISE/dfisetools directory in the Manual
Examples Library.

DFISETOOLS file
Use dfisetools -r filename
Validity DF–ISE layout files; 1D, 2D, 3D DF–ISE boundary files; 1D, 2D, 3D DF–ISE
grid files

This function prints:

„ Type (layout, boundary, grid)
„ Dimension (1D, 2D, or 3D)
„ Number of vertices
„ Number of edges
„ Number of faces
„ Number of elements

30
UTILITIES CHAPTER 3 DFISETOOLS

„ Number of regions
„ Bounding box of the object

Example: Obtaining a summary of a layout file

dfisetools -r DF-ISE/dfisetools/layout/layout.lyt

**************
3dgrid.grd
**************

grid file
dimension = 3
number of points = 1680
number of edges = 4822
number of faces = 4620
number of elements = 1567
number of regions = 7

Bounding box:
min = 0 0 1
max = 2 6.4 9.4

Cutting a 3D device with a plane

Use dfisetools -cut filename

For a cut in a 3D grid, both .grd and .dat files are required. Several .dat files can be associated to the
same grid file.
Validity 3D DF–ISE boundary files, 3D DF–ISE grid files

For a 3D boundary, the result is a DF–ISE 2D boundary (filename_cut.bnd) that can be displayed with
Mdraw. For a 3D grid, the result is a DF–ISE 2D grid (filename_cut.grd and filename_cut.dat) that can
be examined with Tecplot SV. The user defines the cutplane by typing its origin and normal vector.

31
CHAPTER 3 DFISETOOLS UTILITIES

Example 1: Cutting a plane through a 3D boundary

dfisetools -cut DF-ISE/dfisetools/3d/3dbound.bnd

Initial object Cutplane input: [origin = (0, 3.8, 1) – normal = (0, 1, 0)]

Example 2: Cutting a plane through a 3D grid

dfisetools -cut DF-ISE/dfisetools/3d/3dgrid.grd DF-ISE/dfisetools/3d/3dgrid.dat

Initial object Cutplane input: [origin = (0, 3.8, 1) – normal = (0, 1, 0)]

32
UTILITIES CHAPTER 3 DFISETOOLS

Sampling a device with a line segment

Use dfisetools -plot filename

For a plot in a 1D, 2D, or 3D grid, both .grd and .dat files are required. Several .dat files can be
associated to the same grid file.
Validity 1D, 2D, 3D DF–ISE grid files

The result is a DF–ISE plot file (filename_plot.plt) that can be examined with Inspect. Users define the
cutline by entering its two end-points.

Example 1: Cutting a line through a 3D grid

dfisetools -plot DF-ISE/dfisetools/3d/3dgrid.grd DF-ISE/dfisetools/3d/3dgrid.dat

Initial object (see Example 2: Cutting a plane through a 3D grid on page 32)
Cutline input: [A = (1, 3, 1) – B = (1, 5, 9.36)]
DopingConcentration_0
ArsenicConcentration_1
BoronConcentration_2
2e+17

0
Y

-2e+17

2 4 6 8
X

33
CHAPTER 3 DFISETOOLS UTILITIES

Example 2: Cutting a line through a 2D grid

dfisetools -plot DF-ISE/dfisetools/2d/2grid.grd DF-ISE/dfisetools/2d/2grid.dat

Initial object Cutline input: [A = (0, –10) – B = (10, 1)]

DonorConcentration_2

1000000000

500000000

-10 -5 0

Mirroring a device through a plane

NOTE When mirroring 2D or 3D grids, DFISETOOLS creates corrupt DF–ISE files that cannot be
converted to TDR format. The data converter Sentaurus Data Explorer can be used to mirror
grids and to create DF–ISE or TDR files (see Sentaurus Data Explorer, Mirror commands on
page 14).

Use dfisetools -reflect filename

Validity DF–ISE layout files; 1D, 2D, 3D DF–ISE boundary and grid files

This function reflects an object through a given plane and creates a new object by merging the initial
object and its reflection.

NOTE If the object to reflect is a grid, the corresponding data file is accessed with the same
basename as the geometry file (with the extension .dat).

Depending on the type of the object, one or two new DF–ISE files are created:
Layout files: filename_refl_axis.lyt
Boundary files: filename_refl_axis.bnd
Grid files: filename_refl_axis.grd and filename_reflect_axis.dat
Tensor product files: filename_refl_axis.ten

34
UTILITIES CHAPTER 3 DFISETOOLS

There are six available mirror axes:

x Vertical plane at x minimum
X Vertical plane at x maximum
y Vertical plane at y minimum (for 2D and 3D only)
Y Vertical plane at y maximum (for 2D and 3D only)
z Horizontal plane at z minimum (for 3D only)
Z Horizontal plane at z maximum (for 3D only)

Example 1: Mirroring a layout

dfisetools -reflect DF-ISE/dfisetools/layout/layout.lyt

Initial object Reflect input: x

Example 2: Mirroring a 1D grid

dfisetools -reflect DF-ISE/dfisetools/1d/1dgrid.grd

Initial object

Reflect input: x

35
CHAPTER 3 DFISETOOLS UTILITIES

Example 3: Mirroring a 2D boundary

dfisetools -reflect DF-ISE/dfisetools/2d/2dbound.bnd

Initial object Reflect input: x

Example 4: Mirroring a 2D grid

dfisetools -reflect DF-ISE/dfisetools/2d/2dgrid.grd

Initial object (see Example 2: Cutting a line through a 2D grid on page 34)
Reflect input: y

36
UTILITIES CHAPTER 3 DFISETOOLS

Example 5: Mirroring a 3D boundary

dfisetools -reflect DF-ISE/dfisetools/3d/3dbound.bnd

Initial object (see Example 1: Cutting a plane through a 3D boundary on page 32)
Reflect input: y

Example 6: Mirroring a 3D grid

dfisetools -reflect DF-ISE/dfisetools/3d/3dgrid.grd

Initial object (see Example 2: Cutting a plane through a 3D grid on page 32)
Reflect input: x

37
CHAPTER 3 DFISETOOLS UTILITIES

Extending 2D geometry
Use dfisetools -extend filename
Validity 2D DF–ISE boundary files, 2D DF–ISE grid files

For a 2D boundary, the result is a DF–ISE 3D boundary (filename_ext.bnd). For a 2D grid, the result is
a DF–ISE 3D grid (filename_ext.grd and filename_ext.dat) that can be examined with Tecplot SV.

NOTE If the object to reflect is a grid, the corresponding data file is accessed with the same
basename as the geometry file (with the extension .dat).

The user defines the extension:

„ Direction of the extension (normal to the 2D plane or opposite direction)
„ Length of extension
„ Number of steps (resolution)

The extension is performed in two steps:

1. Extension of one step (length/number_of_steps).
2. Successive reflections until the chosen length is reached.

Therefore, only an odd number of steps is allowed.

Example: Extending a 2D grid

dfisetools -extend DF-ISE/dfisetools/2d/2grid.grd

Initial object (see Example 2: Cutting a line through a 2D grid on page 34)
Extension input: [direction of normal, length = 4.0, step = 2]

38
UTILITIES CHAPTER 3 DFISETOOLS

Setting transformation on a geometry or tensor

Use dfisetools -set_trans filename
Validity 2D, 3D DF–ISE boundary files; 2D, 3D DF–ISE grid files; 2D, 3D DF–ISE
tensor files

For any type of geometry, this operation results in a modification of the translation vector and
transformation matrix in the DF–ISE geometry file (filename_tsf.{grd,bnd,ten}).

Example: Setting a transformation of a 2D grid

Initial object (see Example 2: Cutting a line through a 2D grid on page 34)
-> bounding box = (0, 0, –1) (10, 0, 10)
dfisetools -set_trans DF-ISE/dfisetools/2d/2grid.grd

Set transformation input:

[translation vector = (0, 0, 1)
transformation matrix = (0, 1, 0) (1, 0, 0) (–1, 0, 2)]
-> bounding box = (–1, –10, 2) (–1, 1, 12)

Applying transformation on a geometry or tensor

Use dfisetools -transform filename
Validity 2D, 3D DF–ISE boundary files; 2D, 3D DF–ISE grid files; 2D, 3D DF–ISE
tensor files

For any type of geometry, this operation consists of applying, to the vertices of a DF–ISE geometry file,
the transformation defined in the translation vector and transformation matrix
(filename_tsf.{grd,bnd,ten}). The translation vector of the output file is set to null and its transformation
matrix is set to identity.

Tessellating a geometry
Use dfisetools -tessellate filename
Validity 2D, 3D DF–ISE boundary files

This operation consists of triangulating each polygon that defines the input geometry. It produces a new
DF–ISE boundary file (filename_tess.bnd).

39
CHAPTER 3 DFISETOOLS UTILITIES

Example 1: Tessellating a 2D boundary

dfisetools -tessellate DF-ISE/dfisetools/2d/2dbound.bnd

Initial object (see Example 3: Mirroring a 2D boundary on page 36)

Example 2: Tessellating a 3D boundary

dfisetools -tessellate DF-ISE/dfisetools/3d/3dbound.bnd

Initial object (see Example 1: Cutting a plane through a 3D boundary on page 32)

40
UTILITIES CHAPTER 3 DFISETOOLS

Using DFISETOOLS with a Tcl script

All DFISETOOLS commands can be grouped into a Tcl script and then executed in sequence without
any user input. In addition to the command inputs, a file extension is required. The examples presented
are available in each project in the DF-ISE/dfisetools directory of the Manual Examples Library. When
DFISETOOLS is started without arguments, a brief help message is printed and the Tcl shell is not
started automatically.
======================================================"
-- LAYOUT TESTS --
"======================================================"

Scripting option ‘-resume’

resume layout/layout.lyt
puts ">>> reflect layout x"
reflect layout/layout.lyt x rflx

"======================================================"
"-- 1d TESTS --"
"======================================================"

Scripting option ‘-resume’

resume 1d/1dgrid.grd

Scripting option ‘-plot’

puts ">>> plot 1d"
plot {1d/1dgrid.grd 1d/1dgrid.dat} {2 -11} plt

Scripting option ‘-reflect’

puts ">>> reflect 1d x"
reflect 1d/1dgrid.grd x rflx

"======================================================"
"-- 2d TESTS --"
"======================================================"

Scripting option ‘-resume’

resume 2d/2dgrid.grd
resume 2d/2dbound.bnd

Scripting option ‘-plot’

puts ">>> plot 2d"
plot {2d/2dgrid.grd 2d/2dgrid.dat} {0 -10 10 1} plt

41
CHAPTER 3 DFISETOOLS UTILITIES

Scripting option ‘-reflect’

puts ">>> reflect 2d grid x"
reflect 2d/2dgrid.grd x rflx
puts ">>> reflect 2d bound y"
reflect 2d/2dbound.bnd y rfly

Scripting option ‘-extend’

puts ">>> extend 2d"
extend 2d/2dgrid.grd {1 4 2} ext
extend 2d/2dbound.bnd {0 4 2} ext

Scripting option ‘-set_trans’

puts ">>> set_transform 2d grid"
set_trans 2d/2dgrid.grd {0 0 1 0 1 0 1 0 0 -1 0 2} tsf

Scripting option ‘-transform’

puts ">>> transform 2d bound"
transform 2d/2dbound.bnd tsf

Scripting option ‘-tessellate’

puts ">>> tessellate 2d bound"
tessellate 2d/2dbound.bnd

"======================================================"
"-- 3d TESTS --"
"======================================================"

Scripting option ‘-resume’

resume 3d/3dgrid.grd
resume 3d/3dbound.bnd

Scripting option ‘-plot’

puts ">>> plot 3d"
plot {3d/3dgrid.grd 3d/3dgrid.dat} {1 3 1 1 5 9.36} plt

Scripting option ‘-cut’

puts ">>> cut 3d grid"
cut {3d/3dgrid.grd 3d/3dgrid.dat} {0 3.8 1 0 1 0} cut
puts ">>> cut 3d bound"
cut {3d/3dbound.bnd} {0 3.8 1 0 1 0} cut

Scripting option ‘-reflect’

puts ">>> reflect 3d grid x"
reflect 3d/3dgrid.grd x rflx
puts ">>> reflect 3d bound y"
reflect 3d/3dbound.bnd y rfly

42
UTILITIES CHAPTER 3 DFISETOOLS

Scripting option ‘-set_trans’

puts ">>> set_transform 3d grid"
set_trans 3d/3dgrid.grd {0 0 1 0 1 0 1 0 0 -1 0 2} tsf

Scripting option ‘-transform’

puts ">>> transform 3d bound"
transform 3d/3dbound.bnd tsf

Scripting option ‘-tessellate’

puts ">>> tessellate 3d bound"
tessellate 3d/3dbound.bnd tess

Compressing and uncompressing datasets

Use dfisetools -compress <filename>.grd <filename>.dat

Validity 2D, 3D DF–ISE data files

This operation compresses all datasets in the file filename.dat.

Use dfisetools -expand <filename>.grd <filename>.dat

Validity 2D, 3D DF–ISE data files

This operation uncompresses all datasets in the file filename.dat.

43
CHAPTER 3 DFISETOOLS UTILITIES

44
UTILITIES CHAPTER 4 CURPOT

Curpot
Utilities

CHAPTER 4

This chapter describes the postprocessing tool Curpot and provides instructions for its use.

Overview
Curpot is a small postprocessing tool for computing the current potential from the total current density
for two-dimensional simulations performed with Sentaurus Device. The computational method is
implemented after1:

Abstract
The conservation of the total current density in semiconductor devices implies that the
current derives from a vector potential. The calculation of this current potential is a dual
problem of the original device simulation problem. A simple and elegant discrete method is
proposed for the 2-D case, which yields the current potential for a given, numerically
calculated current density. The approach is based upon a least squares principle and is
consistent with the assumptions leading to the discrete formulation of the semiconductor
transport equations. Accurate values of the contact currents are obtained and a simple way to
generate representations of current lines becomes available. The method has the advantage
that it does not require any definition of paths for the integration of current files.

Using Curpot
Curpot is used as follows:
curpot <grid file> <data file> <output file>

where <grid file> is the name of the grid file belonging to the simulated problem, <data file> is the
name of the plot file saved by Sentaurus Device after successfully finishing a simulation, and <output
file> is the name of the file where the data for the current potential is stored (in DF–ISE format).

NOTE The <data file> should contain (at least) the plot data for the total current density, that is,
TotaCurrentDensityshould have been specified in the Plot statement of the input file of
Sentaurus Device.

1. E. Palm and F. Van de Wiele, “Current Lines and Accurate Contact Current Evaluation in 2-D Numerical
Simulation of Semiconductor Devices,” IEEE Transactions on Electron Devices, vol. ED-32, no. 10,
pp. 2052–2059, 1985.

45
CHAPTER 4 CURPOT UTILITIES

Example
The following figures display plots of the current density and current potential for a simple device. The
current potential was computed with Curpot.
CTotal
u rre Current
nt P o teDensity
nt ia l

10

5
Y

9.0e+03
1.6E+00
8.1e+03
1.4E+00
7.2e+03
1.3E+00
4
6.4e+03
1.1E+00
5.5e+03
9.5E-01
3 4.6e+03
7.9E-01
3.7e+03
6.4E-01
2.9e+03
4.8E-01
2 2.0e+03
3.3E-01
1.1e+03
1.7E-01
2.2e+03
1.6E-02
1

0 2 4 6 8 10

TCurrent
o ta l C Potential
ur re nt D e ns it y

10

5
Y

1.6e+00
9.0E+03
1.4e+00
8.1E+03
1.3e+00
7.2E+03
4
1.1e+00
6.4E+03
9.5e-01
5.5E+03
7.9e-01
4.6E+03
3
6.4e-01
3.7E+03
4.8e-01
2.9E+03
2 3.3e-01
2.0E+03
1.7e-01
1.1E+03
1.6e-02
2.2E+02
1

0 2 4 6 8 10

46
UTILITIES CHAPTER 5 CONVERTER FOR SUPREM-4: SUP2LIG

Converter for SUPREM-4: sup2lig

Utilities

CHAPTER 5

This chapter describes the SUPREM-4 converter sup2lig.

Overview
This utility allows the conversion of input files of SUPREM-4 or its derivatives into the simple process
representation (SPR) language of Ligament (see Ligament, Simple process representation package on
page 95). The fundamental concept behind this program is not the translation of fully calibrated process
flows, but the possibility of a smooth and user-friendly transition from one format to another.

Since sup2lig invokes Ligament after its conversion process, the user automatically obtains a command
file for the required process simulator:
SUPREM® IV => sup2lig => LIGAMENT => DIOS/SPROCESS/SDE

Main features

Input format
The program supports most input format features of SUPREM-4, for example, macro definitions are
recognized and expanded, arithmetic expressions are calculated, lines can be concatenated using a plus
(+) sign, and parameter and statement abbreviations are allowed. However, discussion is restricted to
official documented input syntax.

Special characters are:

„ $
„ +
„ ;
„ ‘@{macro}’ and ‘@macro’
„ %
„ ^, !, #
„ Arithmetic operations (+, –, /, E, e)

47
CHAPTER 5 CONVERTER FOR SUPREM-4: SUP2LIG UTILITIES

Supported commands
In general, sup2lig only translates process simulation and several auxiliary commands (and their
synonyms):
„ Comment
„ Source
„ Return (interactive mode is not supported)
„ Foreach (loops cannot be generated, but it is possible to take the first element of the list and treat
this command as a ‘define’ statement)
„ Define
„ Undefine
„ Line (to calculate the lateral and vertical extent of the simulation domain)
„ Initialize
„ Mask
„ Mesh (adaptive grid algorithms are implemented in Dios, therefore, this command is ignored)
„ Deposition
„ Expose
„ Develop
„ Etch
„ Implantation
„ Diffusion
„ Epitaxy
„ Method

Of course, not all parameters of these commands are supported.

48
UTILITIES CHAPTER 5 CONVERTER FOR SUPREM-4: SUP2LIG

Specialities

Layout and masks

sup2lig translates LORENZO-IC layout information into the CIF format, which can be processed by
Ligament and visualized by Ligament Layout Editor.

Furthermore, the process flow and layout information are clearly distinguished. Therefore, CIF masks
are also generated for commands such as:
etch nitride right p1.x=0.25

In SUPREM-4, a definition of a particular mask is given as:

deposition thick=1 positive Photores
expose mas=nwell
develop

The SPR language of Ligament contains one command for these three process steps:
pattern (layer: nwell, polarity: light_field,
thickness: 1 um, side: front, type: default)

Therefore, if a deposition statement with parameter Photores is detected, the polarity is stored and this
deposition command is omitted (see Known problems on page 51).

Etching
Since Dios cannot support pure geometric etch algorithms, a support of arbitrary trapezoidal etch steps
is not feasible. Nevertheless, simple etch statements are converted (see above) and an effort is made to
detect process steps for generating ‘spacers.’

For example, in the latter case, sup2lig and Ligament write a Dios command file that includes ??. This
command file forces an error during syntax check:
! SUPREM: etch NITRIDE THICKNESS=0.15 TRAPEZOI ANGLE=80
Etch (time=1, Rate (mat=??nitride??, a1=150.0))

The user is requested to confirm this translation explicitly by editing the Dios command file. This
precaution prevents long simulation runs with wrong or incomplete command files.

49
CHAPTER 5 CONVERTER FOR SUPREM-4: SUP2LIG UTILITIES

Starting sup2lig
To start sup2lig on the command line, use:
sup2lig

or:
sup2lig -h

When the program has started, the command-line options with short descriptions are printed.
****************************************************************************
*** sup2lig ***
*** Version Y-2006.06 ***
*** (1.2, ia32, linux_gnu) ***
*** ***
*** Copyright (C) 1994-2006 ***
*** Synopsys, Inc. ***
*** ***
*** This software and the associated documentation are confidential ***
*** and proprietary to Synopsys, Inc. Your use or disclosure of this ***
*** software is subject to the terms and conditions of a written ***
*** license agreement between you, or your company, and Synopsys, Inc. ***
****************************************************************************

sup2lig supremFile [options]

supremFile Name of SUPREM-IV process flow description

options:
-cif Name of the mask file (CIF format)
-spr Name of the process flow (SPR format)
-cmd Name of the command file for '-simulator'
-simulator Name of the simulator (dios, sprocess, sde)
-depth Specifies the depth of the simulation domain (microns)
-info Level of information (0-2)
-debug Level of debug information (0-2)
-help Prints this message
-? Prints this message

The simplest way to run sup2lig is to copy a SUPREM-4 input file (test.inp) with all additional files (for
example, layout) into the current working directory and to start the program by using:
sup2lig test.inp

50
UTILITIES CHAPTER 5 CONVERTER FOR SUPREM-4: SUP2LIG

Output
sup2lig generates two files, lig.cmd and prl.par, which are stored in the current working directory. The
default names for these files can be changed through the command-line options:
sup2lig test.inp -cif test.cif -cmd test.cmd

Both files are processed by Ligament, which finally writes a command file (for example, test_dio.cmd)
into the directory of test.inp.

By default, Dios is used as target, but the optional parameter -simulator enables a switch to other
simulators.

Known problems
„ Deposit photoresist: As stated in Specialities on page 49, Ligament and Dios manage pattern
operations by using a single command. This feature leads to the problem that ‘extra’ photoresist
deposition statements are ignored.

„ Incomplete or ‘unofficial’ SUPREM-4 input files: Sometimes, sup2lig cannot resolve all macro
definitions (missing files that are read by using the source command, unofficial syntax, and so on),
in which case, a message is displayed that indicates a problem.
In this special case, load the Ligament command file (lig.cmd) and investigate the questioned line
(361). Corresponding SUPREM-4 commands are also listed in this command file.

51
CHAPTER 5 CONVERTER FOR SUPREM-4: SUP2LIG UTILITIES

52
UTILITIES CHAPTER 6 DIOS TO SENTAURUS PROCESS CONVERTER

Dios to Sentaurus Process

Utilities

CHAPTER 6

converter

This chapter describes the Dios to Sentaurus Process converter.

Overview
The Dios to Sentaurus Process converter enables the conversion of Dios command files to SPR
command files with additional information for further conversion to Sentaurus Process command files.
Conversion is performed in two steps. First, the converter front-end converts the Dios command files to
SPR command files. Second, the Ligament–Sentaurus Process back-end is used to create Sentaurus
Process command files.

The purpose of this converter is to help users change from Dios to Sentaurus Process command files by
converting Dios command files to Sentaurus Process syntax. The conversion reduces manual inputting,
but for various reasons, a full automatic conversion is not possible.

Only process-related Dios commands are translated to SPR. Physical models and model parameters are
not translated. Users must check the result of the conversion carefully and adapt it to their needs. Users
must add mesh-related specifications.

Using converter
The Dios to Sentaurus Process converter is a Ligament module. It can be used in two different ways.

From Ligament
The command-line option -input with the argument dios can be used to load a Dios command file and
create a Sentaurus Process command file:
ligament -input dios dio.cmd sprocess.cmd

Ligament can also be used to convert a Dios command file to SPR for further processing by the user.
When used with the command-line option -print, the converted command file is written to standard
output in SPR format. A file can be created by redirecting the output:
ligament -input dios -print dio.cmd > spr.cmd

53
CHAPTER 6 DIOS TO SENTAURUS PROCESS CONVERTER UTILITIES

From Ligament Flow Editor

The command-line option -input with the argument dios can be used to load a Dios command file instead
of an SPR file. The result of the conversion can be modified by users and can be either saved in SPR
format or translated to the target simulator:
ligedit -input dios dio.cmd

Supported commands
The Dios to Sentaurus Process converter only supports process-specific commands. Commands that are
simulation specific or simulator specific are not supported.

By default, Dios commands that are not supported by the converter are inserted into the flow as remarks.
These remarks start with the prefix unsupported command: and contain the command with its arguments.
This behavior can be switched off (see Customization on page 57). The following Dios commands are
supported by the converter:

„ comment „ etching „ mask

„ deposit „ grid „ substrate

„ diffusion „ implantation „ title

The names of the commands can be abbreviated as in Dios.

The following sections list the supported parameters for each supported command. The shortest possible
abbreviation for each parameter is given in parentheses.

Parameters that are not listed here are not supported. By default, unsupported parameters are converted
to a remark with the prefix unsupported parameter: and this behavior can be switched off (see
Customization).

Supported parameters that cannot be represented by SPR parameters are inserted into the type field using
the appropriate syntax and values for Dios and Sentaurus Process.

Besides these commands, the converter translates comments (lines starting with ‘!’) to SPR remarks.
Conditionals (#if, #elif, #else, and #endif) are converted to the corresponding SPR commands. See
Limitations on page 57 for details about the limitations of converting conditionals.

comment
Dios comment commands are converted to SPR comment commands. Double quotation marks in the
comment string are converted to single quotation marks.

54
UTILITIES CHAPTER 6 DIOS TO SENTAURUS PROCESS CONVERTER

deposit
Dios deposit commands are converted to SPR deposit commands. The supported parameters are:

„ concentration (con) „ material (m)

„ element (e) „ thickness (th)

diffusion
Dios diffusion commands are converted to SPR anneal or epitaxy commands. If the parameter thickness
has a value greater than zero, an SPR epitaxy command is created. For an epitaxy command, only one
time value and one temperature value are allowed. The full range of time, temperature, and temperature
rate specifications that are possible in Dios are supported. The supported parameters are:

„ atmosphere (at) „ hcl (hc) „ pressure (press)

„ concentration (c) „ n2 (n) „ temperature (te)

„ element (el) „ o2 (o) „ temprate (tempr)

„ flow (f) „ ph2o (ph) „ thickness (th)

„ h2 (h2) „ po2 (po2) „ time (t)

„ h2o (h)

etching
Dios etching commands are converted to SPR etch commands. The SPR support for specifying etching
rates and etching types is very limited. As there are several different possibilities in Dios to specify
etching rates and as, currently, it is not clear how this can be best translated to Sentaurus Process,
conversion of etching rates is not supported. If no value for the parameter remove is specified, the etch
type strip is used. Otherwise, the etch type is isotropic. The supported parameters are:
„ material (m)

„ remove (re)

„ over (o)

55
CHAPTER 6 DIOS TO SENTAURUS PROCESS CONVERTER UTILITIES

grid
The values of the parameters x and y are used for the value of the region field of the SPR environment
command. The supported parameters are:
„ x (x)

„ y (y)

implantation
Dios implantation commands are converted to SPR implant commands. The supported parameters are:

„ afactor (af) „ energy (en) „ revolving (rev)

„ amorphization (amorphi) „ function (fu) „ rotation (ro)

„ damage (da) „ ifactor (if) „ tilt (t)

„ dose (do) „ numsplits (nu) „ vfactor (vf)

„ element (e)

mask
Dios mask commands are converted to SPR pattern2d commands. The supported parameters are:
„ thickness (th)

„ x ( x)

substrate
Dios substrate commands are converted to SPR substrate commands. The parameter rho is only used if
it is specified in the input file. The supported parameters are:

„ concentration (co) „ orientation (orie)

„ element (e) „ rho (rh)

title
Dios title commands are converted to SPR environment commands. The supported parameter is title
(t).

56
UTILITIES CHAPTER 6 DIOS TO SENTAURUS PROCESS CONVERTER

Limitations
Dios interpreter control commands (for example @FILENAME, break, and set, see Dios, Interpreter control
commands on page 62) are not supported.

Comments that are placed between arguments of a Dios command are ignored. They are not converted
to SPR remarks. Comment blocks (beginning with /* and ending with */) are not supported.

The conditional directives (#if, #elif, #else, and #endif) of the Sentaurus Workbench preprocessor must
be placed between Dios commands or comments. They cannot be placed in the list of arguments to
choose between different values. Therefore, the following Dios input cannot be converted properly:
diff:(
#if @< variant == 0 >@
moddif=Equilibrium
#else
moddif=PairDiffusion
#endif
)

The converter displays a warning message and uses the last specified value for each argument. The
previous example must be changed to:
#if @< variant == 0 >@
diff:(moddif=Equilibrium)
#else
diff:(moddif=PairDiffusion)
#endif

or parameterized using variables of Sentaurus Workbench.

Other preprocessor directives (#do and #enddo) are not supported. Such lines are converted to SPR
remarks.

Only simple expressions are evaluated correctly. More complicated expressions may give unexpected
results. This can be either a Tcl syntax error or a wrong result. Users must check the result of any
converted expression.

Customization
The converter looks for a file named user.tcl in the working directory, the directory given by the relative
path ../input/dios relative to the directory specified with the command-line option -libdir or in the
directory $STROOT/tcad/$STRELEASE/lib/ligamentlib/input/dios. When the file is found, it is sourced. The
file user.tcl can be used to customize and extend the converter.

By setting the variable ::InputDios::debug to zero, unsupported commands are not converted to SPR
remarks. The variable ::InputDios::unsupportedParameter can be used in the same way to switch off the
output of unsupported parameters in the form of SPR remarks.

57
CHAPTER 6 DIOS TO SENTAURUS PROCESS CONVERTER UTILITIES

58
UTILITIES CHAPTER 7 MEASURE

Measure
Utilities

CHAPTER 7

This chapter the Measure tool, which extracts values from protocols.

Introduction
Measure is a Tcl script that extracts values from protocols with the help of templates. The generator of
the protocols is not necessarily Dios or a TCAD tool. For simplicity, this chapter uses the term
‘simulator’ to refer to the generator of the protocol. All that is necessary to use Measure is the ability to
create templates and command files for it. The templates allow Measure to recognize a region in the
protocol of the simulator from which to take the values.

Measure is a fully integrated tool in Sentaurus Workbench.

In its simplest form, a template consists of a single line, for example, the template thres.tmpl:
threshold voltage= @<m1>@ V

Here, m1 is a label that acts as a dummy argument and connects the extracted parameter to a user-
specified name. The function as dummy argument is given by the special strings @< and >@. To extract a
value, the other strings in the template must match exactly the content of the protocol file. The
connection to a user-specified name of the extracted parameter is given by using the command file for
Measure, for example, thres_msr.cmd:
{thres.tmpl {m1 THRESHOLD}}

For example, assume the protocol file of the simulator is called n9.AUS. A few lines from n9.AUS follow:
ETCH PO;
UTH;
threshold voltage......ug = -1.282+/-0.002 V
! UTH METHOD=0;
UTH METHOD=1;
threshold voltage= -1.43 V
PLOT FILE=N9_ID ID;

The command:
% measure -in n9.AUS -c thres_msr.cmd -out n9_msr.out

writes the following line into the result file n9_msr.out:

DOE: THRESHOLD -1.43

Here, DOE: is a special label used by the extractor of Inspect to transfer the name THRESHOLD and the
extracted value -1.43 from n9_msr.out into the Family Table of Sentaurus Workbench.

59
CHAPTER 7 MEASURE UTILITIES

To summarize this example, a protocol file (n9.AUS), a command file for Measure (thres_msr.cmd), and a
template file (thres.tmpl) are required to run Measure.

Command-line options
measure without any argument, measure -h, or measure -help produces the output:
% measure -h
measure 11.0.0
usage: measure -options

Measure extracts the values located at the positions of the marks in the templates from the protocol
file(s) and writes them to the result file(s) as a multicolumn table: DOE: name_i value_i.

Table 3 Command-line options

Options Description

-b Batch mode. The option -log is ignored. No protocol of the activities of Measure is given. The
extracted values are always written at least to standard output.

-c cmdString String containing commands for Measure.

-c fileName Name of a command file for Measure.

-genes Sentaurus Workbench mask for extracted values; default is DOE: (see Sentaurus Workbench,
Extracted variables on page 64).

-h Prints this message.

-help Prints this message.

-in fileName Name of a protocol file to be scanned for values. The metacharacter * can specify more than
one protocol file.

-info Level of mirroring the actions of Measure. Should be an integer greater than –1. Defaults to 0.

-lib Directory containing the templates; defaults to {'pwd', $DIOS_LIB, $STROOT_LIB/dioslib}.

-lmb Left marker boundary for the template marks. Defaults to "@<".

-log fileName Name of a file to protocol the activities of Measure itself. If not specified, protocol only to
standard output.

-nounits Removes the units from the extracted values. The default is an extraction with units if the
value and its unit build a word.

-off string String(s) used to stop the action of Measure in all protocols for all templates. Such strings
should not appear in the templates.

-on string String(s) used to start the action of Measure in all protocols for all templates. Such strings
should not appear in the templates.

60
UTILITIES CHAPTER 7 MEASURE

Table 3 Command-line options

Options Description

-out fileName Name of a file containing the extracted values. No specification causes the extracted values to
be written only to standard output.

-r Reverse mode. The protocol file(s) is read in reversed line order (from the end to beginning).
The templates are also reversed except for sections contained in
MEASURE_REPEAT ... MEASURE_END_REPEAT clauses.

-rmb Right marker boundary for the template marks. Defaults to ">@".

-unique string String to be appended with a counter to repeated instances of base names. Defaults to "_Q_".

-v Prints version number.

The interactively given command should have the form:

-c "{{templ1 {mark1 name1} ... {markN name1N}} \
... {templN {{mark1 nameN1} ... {markN nameNN}}}"

NOTE Use quotation marks. Otherwise, the Tcl shell cannot parse the input. In a command file,
quotation marks and backslashes must not be included. The base names of the extracted
values name11, ..., name1N, ..., nameNN should be unequivocal. Otherwise, different numbers
appear with the same base name and introduce confusion to the Family Tree.

If the file name following the -in option contains the metacharacter *, Measure processes all files that
match that name.

The option -c should be followed by a Measure command or by the name of a file containing a Measure
command. The templates can contain regular expressions to widen the range of matching regions in
different protocols or, with other words, to decrease the number of necessary templates to perform a
meaningful parameter extraction.

The output file name can be specified with the -out option. If this is the case, all output is written to this
file. If no -out option is given, the extracted values are written only to standard output. They are always
written to standard output, even if Measure works in batch mode.

Measure protocols its own activities to standard output and to the file specified using the -log option if
the latter is given. In batch mode, Measure does not report its activities to standard output.

Measure does not overwrite protocol files from other tools with its own output. For example, if the user
specifies:
% measure -in x_dio.log -out x_dio.log -log x_dio.log -c y_msr.cmd

Measure reports the extracted values to x_dio.log_1 and protocol to x_dio.log_2. Then, if the user
specifies:
% measure -in x_dio.log -out x_dio.log_1 -log x_dio.log_2 -c y_msr.cmd

61
CHAPTER 7 MEASURE UTILITIES

Measure changes the name of the old x_dio.log_1 to x_dio.log_3 and the old x_dio.log_2 to x_dio.log_4 in
order to write the information as far as possible to the expected files. No files should be lost with this
procedure.

By using the options -on and -off, strings can be specified to search in between only in the protocol file.

NOTE A string cannot appear as an ‘on string’ and an ‘off string.’

The strings are periodically applied. For example, if two ‘on strings’ and three ‘off strings’ are given,
the protocol file is scanned between on_string1 and off_string1, on_string2 and off_string2, on_string1
and off_string3, on_string2 and off_string1, and so on until the end.

Do not exclude the interested region of the protocol file. For example, if the Measure command is:
% measure.tcl -info 2 -log simplimpl.log\
-c "{impl.tmpl {m3 DOSE} {m7 ROTAT}}" \
-on {"---------------------------------"}\
-off {"----------------------------- IMPLantation -----"}

then, the region between the ‘off string’ and ‘on string’ is excluded, and Measure cannot, for example,
extract the implantation dose because the implantation dose always appears in Dios after the string given
in the above example as ‘off string.’

In addition, the ‘on strings’ and ‘off strings’ must not appear in the templates. Otherwise, Measure exits
with an error.

The option -nounits removes the units from the extracted values. If a value does not match as a number,
a warning is given and the value appears as NaN in the table of the extracted values.

Matching mechanism and templates

Templates must be created manually, with no support from Measure. It is the responsibility of users to
ensure that the simulator prints the information that is of interest to users. If the protocol does not contain
at least one region that matches at least one of the specified templates, Measure cannot extract any value
and it returns an error.

The four levels of matching between template lines and protocol lines are:
„ Exact or literal match
„ Regular expression match
„ Skip a dummy argument
„ No match

White space is irrelevant in matching.

62
UTILITIES CHAPTER 7 MEASURE

An exact match is important to determine whether a region in a protocol is represented by a template. A

regular expression match gives some freedom to reduce the number of templates or to increase their
applicability for extractions.

In the simplest case, a template consists of a single line, for example:

dopant = [a-zA-Z]+ energy = @<m7>@

This template could be used to extract the implantation energy from Dios protocols. The string [a-zA-Z]+
is a regular expression matching most possible dopant names, but it does not match BF2.

If the template is:

dopant = As energy = @<m7>@

only the energies of arsenic implants can be extracted.

For example, assume that the template:

dopant = [a-zA-Z]+ energy = @<m7>@

is stored in a file ii.tmpl.

An invocation of Measure can be:

% measure -in protocol_file_name -out output_file_name -c "{ii.tmpl {m7 eNeRgY}}"

It is important to have the same dummy argument (m7) in the command for measure
("{ii.tmpl {m7 eNeRgY}}") and the template. Otherwise, the connection between the value in the protocol
and the user-specified name (eNeRgY, in this case) cannot be established.

Therefore, the output file will contain lines such as:

DOE: eNeRgY 160keV
DOE: eNeRgY_Q_1 120keV
DOE: eNeRgY_Q_2 180.3keV

if, for example, the template was matched three times in the given protocol file. The appendix _Q_
followed by a natural number is used to make the values unequivocal in the case of more than one match
of a template in a protocol.

There is one common mistake in creating a template: Assume the protocol contains the line:
tilt2D = 45degree (ion beam, projected to plane.)

and the user wants to create a template line to match it. This cannot be performed by using:
tilt2D = @<m8>@ (ion beam, projected to plane.)

because if (ion encounters a Tcl string comparison engine, an error is raised because of unbalanced
parentheses. This also occurs with other paired strings or ordering operators such as ', ", (), {}, [].

63
CHAPTER 7 MEASURE UTILITIES

The solution is to match (ion and plane.) with regular expressions:

tilt2D = @<m8>@ {^\([a-zA-Z]+} beam, projected to {^[a-zA-Z.]+\)$}

To cope with changing layer stacks or a different number of periodic entries in the protocol, Measure
understands the following metaclause:

…some template lines

MEASURE_REPEAT specifier

…some other template lines

MEASURE_END_REPEAT

…some more template lines

The specifier must appear and can be one of the following: ZERO_OR_ONE, ZERO_OR_MORE, or ONE_OR_MORE.

The meaning is clear: Measure expects zero or one, zero or more, or one or more appearances of the
template lines in the metaclause to have a match. This even allows some lines of a protocol to be omitted
with the help of the ZERO_OR_ONE specifier, for example. The metaclauses cannot be mixed up; this means
that Measure returns an error if a template contains, for example:
MEASURE_REPEAT spec1
line1
line2
MEASURE_REPEAT spec2
line3
MEASURE_END_REPEAT
line4
line5
line6
MEASURE_END_REPEAT

The metaclauses should appear in the templates in uppercase and with exactly one period between
MEASURE_REPEAT and the specifier. This has been performed in the expectation that no protocol contains
such strings.

The -r option is another way to create a useful template. With this option, the protocol(s) is read from
the end to the beginning (a new file, with reversed line order, is generated) and the template(s) is
reversed blockwise. For example, this means that a template:

line1 is reversed into MEASURE_REPEAT spec2

line2 line9
line10
MEASURE_REPEAT spec1 MEASURE_END_REPEAT
line3
line4 line8
line5 line7
MEASURE_END_REPEAT line6

line6 MEASURE_REPEAT spec1

64
UTILITIES CHAPTER 7 MEASURE

line7 line3
line8 line4
line5
MEASURE_REPEAT spec2 MEASURE_END_REPEAT
line9
line10 line2
MEASURE_END_REPEAT line1

This can be used to find a template for the thickness of the first oxide (if looking from the top) and the
thickness of the last oxide.

Consider the following section of the protocol file lsop_1.log:

###### begin of the region #
warning: lsop_1.dio line:73 ambiguous definition of original area
warning: lsop_1.dio line:73 region fixed:
warning: lsop_1.dio line:73 boundary sort fixed
--------------------------------------------------------print(layers, x=-2.5)
-------------------------------------------- Print ----
lateral position x[um]: -2.5000
y[um] thickness[nm] material
2.828 1.8 OX
2.826 348.9 NI
2.477 798.9 AL
1.678 890.0 OX
0.788 400.0 PO
0.388 289.0 NI
0.099 419.7 OX
-0.321 679.4 SI
--------------------------------------------------------
print(layers, x=-0.4)
--------------------------------------------- Print ----
lateral position x[um]: -0.40000
y[um] thickness[nm] material
2.828 1.8 OX
2.826 349.0 NI
2.477 799.0 AL
1.678 890.2 OX
0.788 500.1 AL
0.288 289.0 NI
-0.001 998.7 SI
--------------------------------------------------------
--------------------------------------------------------
There have been 117 warnings and errors in your job.
All error messages are contained in the protocol file.

Let the template be (firstOx.tmpl):

lateral position x.um.: {^(-)?[0-9]*(\.|,)[0-9]+}
y.um. thickness.nm. material
MEASURE_REPEAT ZERO_OR_MORE
@<m3>@ @<m4>@ {SI|PO|NI|AL|LA|MS|ME}

65
CHAPTER 7 MEASURE UTILITIES

MEASURE_END_REPEAT
@<m2>@ @<m1>@ OX
MEASURE_REPEAT ZERO_OR_MORE
@<m5>@ @<m6>@ {OX|PO|NI|AL|LA|MS|ME}
MEASURE_END_REPEAT

The Measure command:

% measure -in lsop_1.log \
-c "{firstOx.tmpl {m1 first_oxide}}" \
-on {"----------------------------- Print ----"} \
-off {"-----------------------------------------"}

gives standard output:

Results from lsop_1.log
with template /usr/k2/users7/krause/work/firstOx.tmpl:
DOE: first_oxide 1.8

Results from lsop_1.log

with template /usr/k2/users7/krause/work/firstOx.tmpl:
DOE: first_oxide_Q_1 1.8
measure finished

but the Measure command:

% measure -in lsop_1.log \
-c "{firstOx.tmpl {m1 last_oxide}}" \
-on {"----------------------------- Print ----"} \
-off {"-----------------------------------------"} -r

gives:
Results from /tmp/lsop_1_reverse.log
with template /usr/k2/users7/krause/work/firstOx.tmpl:
DOE: last_oxide 890.2

Results from /tmp/lsop_1_reverse.log

with template /usr/k2/users7/krause/work/firstOx.tmpl:
DOE: last_oxide_Q_1 419.7
measure finished

NOTE The same template was used with the -r option and the ‘on strings’ are internally interchanged
with the ‘off strings.’ Users should always review the entire protocol. /tmp/lsop_1_reverse.log
is the protocol file lsop_1.log with reversed line order created by Measure.

66
UTILITIES CHAPTER 7 MEASURE

Using Measure in Sentaurus Workbench

Measure is available as a tool in Sentaurus Workbench. Users should specify (Tool > Edit Input >
Commands) a command for Measure after selecting Measure as a tool in the tool flow. By default, the
tool specification for Measure contains a run of the Inspect extractor to copy the values from the output
of Measure using the DOE: label into the Family Table of Sentaurus Workbench.

Users can overwrite the tool specification. To do this, create a tooldb_$USER file.

Using Measure in Dios

In Dios, users can launch a system call to Measure. Dios has a built-in Measure command. A simple
input file is:
title()
subs()
mask(x=0)
print(lay)
measure(template=thick,label("THICKNESS","Thickness"))
etch()
impl()
1d(rs)
measure(template=thres,label("RS","Rs","SURFACE","Surface"))
end

The Measure command in Dios mimics a Measure command. The last Measure call in the Dios
command file translates into the following Measure command:
{thres.tmpl {RS Rs} {SURFACE Surface}}

Where the template thres.tmpl can be given as:

@<q1>@ @<OXIDE>@ @<bla>@
@<q3>@ @<q4>@ @<bla1>@ @<RS>@ Masetti @<SURFACE>@

If Measure is launched by a system call in Dios, Measure writes its output into the actual Dios protocol
file. If control is given back from Measure to Dios, Dios continues to write into the same protocol file.
The tool specification for Dios contains a run of the Inspect extractor to copy the values from the Dios
protocol file using the DOE: label into the Family Table.

A full reference of the command in Dios is given in the Dios User Guide.

67
CHAPTER 7 MEASURE UTILITIES

Limitations
Equations between the dummy arguments are not implemented. Therefore, for example, Measure can be
used to extract numbers from a two-column table, but cannot find the values in the first column at which
the second column has a relative extremum and so on.

Measure performs no computations, only search operations.

There is no template creator or template checker.

68
UTILITIES CHAPTER 8 SENTAURUS SPICE2SDEVICE

Sentaurus spice2sdevice
Utilities

CHAPTER 8

The tool Sentaurus spice2sdevice converts SPICE circuit files into equivalent circuit files of Sentaurus
Device. A description of SPICE circuit files (extension .cir) can be found in the literature1. The circuit
files of Sentaurus Device (extension .scf) are discussed in the Sentaurus Device User Guide.

SPICE circuit files

A standard SPICE circuit file starts with a title line, for example:
POWER AMPLIFIER CIRCUIT

and can end with an optional line:

.END

The command-line option -m must be used if no title line is present (SPICE model files).

A line starting with a + character is interpreted as a continuation line. Comment lines start with one of
the following characters in the first column: #, $, ;, *.

The Sentaurus spice2sdevice converter recognizes element and model lines, subcircuit definitions and
calls, and .INCLUDE directives. Option and control lines are ignored.

SPICE models
A SPICE model line adheres to the following syntax:
.MODEL MNAME TYPE (PNAME1=PVAL1 PNAME2=PVAL2 ...)

1. T. Quarles et al., SPICE 3 Version 3F5 User’s Manual, Department of Electrical Engineering and Computer
Sciences, University of California, Berkeley, CA, USA, 1994.

69
CHAPTER 8 SENTAURUS SPICE2SDEVICE UTILITIES

Table 4 lists the recognized values for the TYPE field.

Table 4 SPICE models

Model type Device Description

c Capacitor Semiconductor capacitor model

r Resistor Semiconductor resistor model

csw CSwitch Current-controlled switch

sw Switch Voltage-controlled switch

d Diode Diode model

ltra LTRA Lossy transmission line model

njf JFET N-channel JFET model

pjf JFET P-channel JFET model

nmf MES N-channel MESFET model

pmf MES P-channel MESFET model

npn BJT NPN BJT model

pnp BJT PNP BJT model

nmos see below N-channel MOSFET model

pmos see below P-channel MOSFET model

urc URC Uniform distributed RC model

NOTE The device of a MOSFET model is determined according to the value of the parameter level.

Table 5 lists the values for the parameter level in MOSFET models that are recognized.

Table 5 SPICE MOSFET models

Level Device Description

1 Mos1 Shichman–Hodges

2 Mos2 MOS2

3 Mos3 MOS3, a semiempirical model

4 BSIM1 BSIM

5 BSIM2 BSIM2

6 Mos6 MOS6

8 BSIM3 BSIM3

70
UTILITIES CHAPTER 8 SENTAURUS SPICE2SDEVICE

Table 5 SPICE MOSFET models

Level Device Description

9 B3SOI Partially depleted SOI MOSFET model

14 BSIM4 BSIM4

The first letter of an instance name specifies the element type. Table 6 lists the types recognized by
Sentaurus spice2sdevice.

Table 6 SPICE instances

Instance name Device Description

b... ASRC Nonlinear source

c... Capacitor Capacitor

d... Diode Junction diode

e... VCVS Voltage-controlled voltage source

f... CCCS Current-controlled current source

g... VCCS Voltage-controlled current source

h... CCVS Current-controlled voltage source

i... ISource Current source

j... JFET Junction field effect transistor

k... mutual Coupled inductor

l... Inductor Inductor

m... See Table 5 MOSFET model

o... LTRA Lossy transmission line

q... BJT Bipolar junction transistor

r... Resistor Resistor

s... Switch Voltage-controlled switch

t... Tranline Lossless transmission line

u... URC Uniform distributed RC line

v... VSource Voltage source

w... CSwitch Current-controlled switch

x... Subcircuit call

z... MES GaAs MESFET

71
CHAPTER 8 SENTAURUS SPICE2SDEVICE UTILITIES

NOTE Nonlinear sources and transmission lines are not supported in Sentaurus Device.

Command-line options
Table 7 lists the command-line options recognized by Sentaurus spice2sdevice.

Table 7 Command-line options

Option Description

-c Translates a SPICE circuit file (default).

-d Prints additional debug information.

-h Displays a help message.

-m Translates a SPICE model file.

-o filename Stores the Sentaurus Device circuit file in filename.

-v Shows version information.

A SPICE model file is assumed to have no title line. Otherwise, it is identical to a SPICE circuit file.

Example
A simple resistor transistor logic (RTL) inverter as shown in Figure 10 is considered.

1 3 4

0
Figure 10 Simple RTL converter

This circuit can be described by the following SPICE circuit file (rtl.cir):
SIMPLE RTL INVERTER
VCC 4 0 5
VIN 1 0 PULSE 0 5 2NS 2NS 2NS 30NS 100NS
RB 1 2 10K
Q1 3 2 0 Q1
RC 3 4 1K
.PLOT DC V(3)
.PLOT TRAN V(3) (0,5)

72
UTILITIES CHAPTER 8 SENTAURUS SPICE2SDEVICE

.PRINT TRAN V(3)

.MODEL Q1 NPN BF 20 RB 100 TF .1NS CJC 2PF
.DC VIN 0 5 0.1
.TRAN 1NS 100NS
.END

The command:
spice2sdevice -o rtl.scf rtl.cir

produces the following output file (rtl.scf):

PSET q1
DEVICE BJT
PARAMETERS
bf = 20
cjc = 2e-12
npn = 1
pnp = 0
rb = 100
tf = 1e-10
END PSET

INSTANCE q1
PSET q1
ELECTRODES
3 2 0 0
PARAMETERS
END INSTANCE

INSTANCE rb
PSET Resistor_pset
ELECTRODES
1 2
PARAMETERS
resistance = 10000
END INSTANCE

INSTANCE rc
PSET Resistor_pset
ELECTRODES
3 4
PARAMETERS
resistance = 1000
END INSTANCE

INSTANCE vcc
PSET Vsource_pset
ELECTRODES
4 0
PARAMETERS
dc = 5
END INSTANCE

INSTANCE vin
PSET Vsource_pset

73
CHAPTER 8 SENTAURUS SPICE2SDEVICE UTILITIES

ELECTRODES
1 0
PARAMETERS
pulse = [0 5 2e-09 2e-09 2e-09 3e-08 1e-07]
END INSTANCE

The following command file of Sentaurus Device can then be used to perform a transient simulation:
File {
SpicePath = "."
}

System {
Plot "rtl.plt" (time() v(1) v(3))
}

Solve {
Set (vcc."dc" = 0)

Quasistationary (Goal {Parameter=vcc."dc" Value=5})

{ Coupled { Circuit } }

NewCurrentPrefix = "new_"

Transient (InitialTime=0 FinalTime=100e-9

InitialStep=1e-9 MaxStep=1e-9)
{ Coupled { Circuit } }
}

Figure 11 shows the voltages v 1 and v 3 as a function of time.

v(1) v(3)

4 4
Voltage

2 2

0 0
0 2e-08 4e-08 6e-08 8e-08 1e-07
Time

Figure 11 Transient simulation of simple RTL inverter

74