FLOODS/FLOOPS Introduction

This manual is broken into several sections describing the commands that make up the FLorida Object Oriented Device and Process Simulator. These sections are:

TCL Help
Discussion of the tcl user interface / scripting language.
Alagator Control Language
Descriptions of the equation and scripting interface for physical models.
Grid Commands
Commands for use in initializing and storing structures.
Post Processing
Commands for use in post processing and data analysis.
Miscellaneous shared commands.
Process Simulation
Process simulation specific commands.
Device Simulation
Device simulation specific commands.
New Developments
A brief list of the new enhancements since the last release (June98).
Installation Directions
Installation help and notes - created as I did a clean install on a linux system. Your mileage may vary.

There are a large number of examples that come with the program and are not described. Please check the Test directory from the installation tape.

FLOODS and FLOOPS are written as command extensions to the tcl language. Consequently, an knowledge of tcl is extremely helpful in running the examples.


This section describes the use of the manual and the conventions used to denote the parameters and choices associated with each statement. The program accepts input in a fashion similar to SUPREM III and PISCES II. The input is made up of a series of statements. It is important to bear in mind that the parser is case sensitive, i.e. FOO is not the same as foo. Parameter values may be abbreviated, along as the abbreviation uniquely identifies the parameter.

Each statement can have parameters which are of the form:

parameter_name = value

Value is either a real number expression or a character string. There are some parameters that are booleans, which recognize true and false as special strings. If the value is left off a boolean parameter, it is set to true.

The manual describes these parameters in the following form:

param=<numeric list>
an array valued parameter
param = <n>
a real valued parameter
param = <c>
a string valued parameter
a boolean parameter set false
a boolean parameter set true

Choices are denoted by putting the parameters in parenthesis and separating them by vertical bars. For example, ( par1 | par2 ) states that either par1 or par2 may be specified but not both. Anything enclosed in brackets [ ] are optional parameters and aren't necessary. Almost everything in the program has some sort of default value, so almost all parameters are optional. In case of doubt, though, never rely on the defaults.

Command Options

Most commands now accept -help as a parameter. This will output a list of command parameters, defualts, parameter type, and a short help string for each.

Many commands now support -gui as an option. This will create a command dialog box with the most commonly used parameters appearing. This will only work if floops/floods was run with the -gui option on the command line.

Common Parameters

Material Specification

Materials are specified the same way for all commands that require a material parameter. Materials can be constructed at the command line and their name will get added to the list of available materials. The initial default list of materials includes these:

All materials can be specified in either lower or upper case. However, we are attempting to move the code toward upper case specification of materials for compatability with the parameter data base. Interface materials are specified by listing one material with a preceeding / in the name.

For example:

Specifies that this command should apply to the oxide material
Silicon /Oxide
Specifies that this command applies to the silicon - silicon dioxide interface material.

Note that materials specification interacts strongly with the parameter data base - names must match or short hands must have been defined.

Bugs and Missing Features

Dopants can be created with incomplete parameters. When a subsequent simulation is run, a core dump may occur resulting from invalid parameters.

Materials can be created with incomplete parameters. When a subsequent simulation is run, a core dump may occur resulting from invalid parameters.

Equal signs in the parameter specification sometimes has problems with tcl. When in doubt, add spaces around the equal sign.

See Also

Just about everything.

Copyright and Redistribution

This software and manual is copyrighted by the Mark Law, University of Florida Electrical and Computer Engineering department. It is intended for internal educational and research and development purposes only. Any use of any part of this software in any commercial package needs to be negotiated separately. Several of the implant models are copyrighted by Al Tasch from The University of Texas at Austin.

The UMFPACK package is copyrighted by Tim Davis, University of Florida, Computer and Information Sciences Department. (davis@cis.ufl.edu). Please contact Tim directly about redistribution of the UMFPACK software.

The tcl/tk package is in the public domain, and was developed by John Ousterhout at the University of California Berkeley.



Mark Law, University of Florida

Students and Post-Docs

Intel Development Team

Martin Giles, Stephen Cea, Hal Kennel, Aaron Lilak, and Patrick Keys. Intel is feeding back bug fixes and enhancements. Steve Morris - we miss you!


Rex Lowther, Harris
Grid and diffusion discretizations, Cylindrical Coordinates
Mike Morris, Steve Morris, Al Tasch, University of Texas, Austin
Dual pearson implant models for boron, bf2, and arsenic
Goodwin Chin, IBM
Original ideas for hierarchical mesh
Tim Davis, University of Florida
the UMF factorization code


Mark Law