Using The Power of The Interactive Tools:
Part 2 DeckBuild Continued

This is the second of a continuing series of articles that aim to
help users utilize more of the power hidden in the Silvaco Interactive Tools.
In this issue we will continue to look at DeckBuild.


DeckBuild History

The History function of DeckBuild is a powerful capability that allows corrections and changes to be made during an interactive simulation session. It provides backwards movement through the input deck, by selecting a previously simulated command line and initializing the simulator back to that point.

This feature is achieved by maintaining a set of history files, saved automatically after each significant process simulation step. Significant process steps are commands which would change the current status of the structure, such as implant, etch or diffuse. Comments, plot commands, blank lines, and model statements are ignored. These files are written to the local working directory and named `.historynn.str', where nn is a sequence number. As long as the length of the history file list is large enough and the lines in the deck have not been altered or moved since simulation, DeckBuild will remember the required line.

You can configure how, and if, DeckBuild maintains history files with the History menu (Figure 1). Press the 'History Props...' button from the Control Pad category on the Main Control popup.


Figure 1. Setting history options.

The History setting turns the entire mechanism on or off. This may be toggled as the simulation progresses, and DeckBuild will allow re-initialization from any part of the deck that was running with history enabled. If disabled, history files are not saved and the simulation runs a little faster.

The Length determines how many trailing process flow steps are remembered (how many history files to maintain). The default is 25, although up to 100 steps may be saved. When the limit is reached, DeckBuild starts re-using the old history files in a loop.

Skip determines how often history files are saved. The default value of 1 indicates that every significant process step will cause a history file to be saved. A value of 2 indicates, every other step, and so on.

The Clear button will reset the list removing all existing history files, while Save as defaults will save the current settings for use the next time you run DeckBuild.

Initializing from history is accomplished by selecting (highlighting) the line of interest, then pressing the Init button on the Execution control panel. DeckBuild will load the correct history file, reset the starting point to the selected line and allow you to continue the interactive execution from that point in the deck. When initializing from history, any GO statement flags specified for the 'go simulator' associated with the selected line will also be re-initialized. For example, if a particular version of the simulator had been specified using the 'simflags' argument, then the same version would be restarted

DeckBuild may not have any history attached to the selected line if you've selected a comment line or a skipped line. A notice will be displayed to suggest a previous point in the input deck by highlighting it.

If you selected a line that is so far back in the deck that DeckBuild no longer maintains relevant history, a notice prompt will appear informing you of the condition. Use a line closer to the current position, or increase the history length.


Set Statements and Variable Substitution

The set command is used to set the value of a user-defined variable. The value can later be substituted using $-substitution, which replaces the variable name with its value when the variable is preceded by a dollar sign '$'.

The syntax below shows how a variable (the name may not contain spaces), can be defined using the set statement:

set <variable> = <definition>

The definition can either be of value or expression type. A value can be either a numeric constant or a quoted string. An expression can consist of numeric constants, $-substituted variables, algebraic operators (+,-.*,/), and/or the built in functions shown below:

min (<expr>, <expr>)
max (<expr>, <expr>)
ave (<expr>, <expr>)
log (<expr>)
log10 (<expr>)
sqrt (<expr>)
abs (<expr>)

When a $-substitution is performed DeckBuild will look for the equivalent set variable value or extract command result. If no corresponding variable is found then DeckBuild will attempt to find and substitute the matching environment variable.

Example: to ensure an oxide overetch of 500Å

set time = 45
set temp = 995
set env = "nitro"
diffuse time=$time temp=$temp press=1 $env
extract name="tox x=0.1" thickness oxide x.val=0.1
extract name="tox x=0.5" thickness
oxide x.val=0.5
set etch_thickness = (max($"tox x=0.1", \
$"tox x=0.5")/10000) +0.05
etch oxide dry thickness = $etch_thickness

IC Layout Interface

Using the DeckBuild layout interface to MaskViews it is possible to create 'generic' simulation decks which can be used at any location on a wafer. Mask names from the device layout and mask layers defined in MaskViews can be used in the deck to replace deposit and etch statements with hard-coded geometry values.

To use the IC layout interface, a MaskViews layout must be created along with the corresponding generic simulation deck. When complete, a 1D or 2D cross-section in MaskViews should be selected and written to a file, (Figure 2) this is the cutline file. Before running the simulation, the cutline file must be loaded into DeckBuild. This can be done manually from the Cut Files popup under the Tools menu or by specifying the cutline to be loaded at runtime from the GO statement.


Figure 2. Defining a 2D cross section from
a layout in MaskViews for use in ATHENA.


Generic decks have no geometry information and no horizontal grid information for 2D mesh generation. All of this information is specific to the cross-section selected from the layout and is contained within the cutline file. The horizontal grid information is calculated by MaskViews such that a mesh line with a user specified grid spacing is placed at each mask edge. The grid information is substituted into the deck at runtime along with the mask, region and electrode information.

The DeckBuild Mask statement is used in the simulation deck to define where the photoresist or barrier will be deposited in the flow of process events. The simple syntax as shown below will be automatically substituted by DeckBuild.

mask name="<maskname>"

Other optional arguments such as 'delta_cd', 'bias' and 'misalign' can also be included in the statement. The delta_cd value can be used to vary the Critical Dimension (CD) of the specified layer, operating on an edge by edge basis. For example, for an IC layout with a 1.0 micron wide 'poly' the statement :

mask name="poly" delta_cd=-0.1

will create a poly length of 0.8 microns ( 0.1 microns removed from each edge). The bias value performs the same operation as the delta argument, thus if used in conjunction with delta the CD reduction will be the sum of bias and delta_cd values. This may be used globally where further experimentation is required for a fixed bias value.

The misalign option can be used to offset a layer with respect to other layers, for example:

mask name="poly" bias =-0.15 misalign =-0.1

will cause the poly to be reduced by 0.15 per edge and offset to the left by 0.1 microns.

MaskViews can also be used to defined regions for parameter extraction. Regions are boolean combinations of masks that uniquely define an area on the layout. The regions can be used to replace the cutline position value (x.val) in extract statements which define the position of the quantity to be measured. For example, a layout for a MOS inverter that contains N and P type devices might have WELL, AAD, and POLY masks. If you wanted to measure the gate oxide thickness in both types of devices, you might define a region GATE in MaskViews where WELL is "false", AAD is "true", and POLY is "true"(Figure 3). All other masks would be "don't care". Then, use this region in an extract statement:

extract oxide thickness region="GATE"

rather than

extract oxide thickness x.val=1.0



Figure 3. Defining a region using MaskViews.


Another definition requiring layout specific values is the electrode positioning. Usually the ATHENA electrode statement requires an X position and a name. DeckBuild provides the 'autoelectrode' statement to position electrodes automatically in generic simulation decks.

To use the 'autoelectrode' statement the masks containing one or more electrodes and their names must be defined in MaskViews. For example, the POLY mask for a MOS device is an electrode mask because it forms the gate contact. The 'autoelectrode' statement should then be placed in the deck directly after the photostrip step of the mask of interest.

It works by substituting one or more electrode statements at runtime, using information from the cutline file corresponding to the last electrode mask. DeckBuild will remember the electrodes specified for the current mask and can therefore define multiple electrodes for a single statement. This means an 'autoelectrode' statement should be used for each mask which contains one or more electrodes.