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.
|
