Introducing New Device Models into SmartSpice and UTMOST Using the SmartSpice Interpreter

Introduction

In order to simulate a particular device, it is necessary to first create a model of the device. Even though SmartSpice contains an extensive list of internal device models, it is sometimes necessary for a user to add a new model to SmartSpice. This can occur for a number of reasons;

  • The user is interested in modeling an unusual/new device for which a model does not exist in SmartSpice.
  • The user wishes to use proprietary in-house models.
  • The user would like to support and enhance a model for which the source code is readily available.

 

As a result it is necessary to provide a well documented and intuitive interface to SmartSpice's internal data structures and algorithms, so that the user can easily integrate new models within SmartSpice.

The primary method by which this is achieved is via the SmartSpice Interpreter. The Interpreter [1] understands a super set of the C language syntax, its loops, assignment statements and conditional constructs. Extensions to the C language include constructs to declare state vectors, model parameters and instance parameters. Interface functions and variables which allow the interpreted model to access SmartSpice's internal algorithms are also provided.

This article will describe how a new model can be introduced and used in SmartSpice. The model to be introduced is an amorphous TFT model. The methodology by which such models can be accessed by the UTMOST parameter extraction package is also demonstrated with an example.

 

Model Structure

The organization of the source code required to implement a particular model closely follows that of a device model developed for Berkeley SPICE3. The model consists of a number of functions which will be called by SmartSpice during simulation. A simplified flowchart showing the order in which the functions contained within the model are executed is given in Figure 1.

 

Figure 1.Simplified flowchart of the execution
sequence of interpreted models functions.

 

The "setup" function is called at the very beginning of the simulation of a circuit. This function typically initializes the model and instance parameters to their default values and allocates any matrix locations required by a model's internal nodes. For interpreted models, this function does not have to be created by the user. SmartSpice automatically performs these actions.

The "temp" function is called at the start of each analysis and it calculates temperature dependent variables and intermediate variables which will be used later during the matrix assembly ("load") routines. For each analysis type supported by the model, a matrix assembly routine will have to be written. For interpreted models, SmartSpice supports DC, Transient, AC and Pole-Zero analyses. It is not necessary to provide functions for each of these analyses if they are not required by the user for simulation. For example, if only DC analysis is required for the interpreted model, then only the temperature and DC model code need be created.

Interpreted "Y" Device

Each interpreted device is treated as a "black box" by SmartSpice. In the input deck, an interpreted device is instantiated using the "Y" device prefix. An interpreted device can have any number of external terminals and internal nodes. The Y-device line contains standard device information, such as external node connections.

Model Parameter File

The first task when creating an interpreted model is to construct a file describing all of the parameters used within the model. There are two types of parameters, model and instance parameters. Model parameters can appear in the .MODEL statement, while instance parameters appear on the Y-device line which creates an instance of the device. State vector definitions are also stored within this file. State vectors can be thought of as variables which are local to each instance of the model and they are normally used to store previously calculated simulation values.

In order to identify the type of parameter being defined in this file, three non-standard declarations are used:

  • + Model parameters - keyword "state"
  • + Instance parameters - keyword "instance"
  • + State vectors - keyword "model"

For model and instance parameters, the keyword is followed by the parameter name used in the model equations, a default value and a list of aliases that are used to identify the parameter in the input deck. For example, in the

following declarations, two model parameters and two instance parameters are declared.

	model tox 		1.0e-7 	tox;
	model vtO 		3 			vt0, vtO, vto;
	instance		l 1e-6 	l;
	instance gm 	0 			NONE;

The first declaration defines a model parameter "tox". It's default value is 0.1mm and it can be specified in the .MODEL statement using the parameter name "tox". The second model parameter defined is "vtO", and it's default value is 3. It can be specified in the .MODEL statement using one of three possible names "vt0", "vtO" and "vto".

The third declaration defines an instance parameter "l", the length of the transistor. The default value is 1µm and it can be specified on the Y-device line using the name "l". The final declaration defines an instance parameter "gm". Since this parameter has the keyword NONE in its list of aliases, it cannot be specified in the input deck. It can then be used as a local variable within the instance to store intermediate values calculated, in the temperature routine.

 

Generating Templates Files

Once the parameters file has been created, it can be used to generate template files for each of the analyses supported. This is done from the SmartSpice command line using the buildtemplates command. For example, in order to generate the template model code using the tft_parameters file, the following command is used,

% build templates INTE tft_parameters tft tft

This generates four files, tfttemp.template, tftdc.template tftac.template and tftpz.template. Within each file the outline of the function called by SmartSpice for each analysis is provided. The name of the function is the same as the name of the file, without the .template extension. The tftdc function is used for both DC and Transient analyses.

 

Inserting Model Equations

For the TFT model, only the DC and Temperature analysis options were initially supported. This meant that two functions were modified, tfttemp and tftdc. All circuit variables that are needed by each of the functions are passed in via the function argument list. For example, in the definition of the tftdc function, given in Figure 2, the argument list contains the list of instance and model parameters of the current interpreted device being simulated, circuit variables such as integration method, scaling factors, tolerances, time steps (in the case of transient analysis) and the previously calculated unknowns. In addition, the argument list contains variables to update the matrix and the right-hand side vector.

 

int tftdc	(instance, model, instanceGiven, 
modelGiven, iteration_number,
		device_name, keyrhscallv_dc,state_vector_base,
		CKTag, CKTintegrateMethod, CKTorder,
		CKTgmin, CKTdcgmin, CKTmode, CKTscale,
		CKTreltol, CKTabstol, CKTscalm, 
CKTnoncon, CKTdelta, 
		CKTdeltaOld,CKTcurrentAnalysis,CKTpredictor,
		Node, CKTrhsOld,
		CKTstate0, CKTstate1, CKTstate2,
		CKTstate3, CKTstate4, CKTstate5, CKTstate6,
		currents,
		conductances)
double 	*instance; double *model; int 
			*instanceGiven; int *modelGiven;
int 		iteration_number;
char 		*device_name; int keyrhscallv_dc; 
int state_vector_base;
double 	*CKTag; int CKTintegrateMethod; int CKTorder;
double 	CKTgmin; double CKTdcgmin; 
int CKTmode; double CKTscale;
double 	CKTreltol; double CKTabstol; 
double CKTscalm; int *CKTnoncon;
double 	CKTdelta; double CKTdeltaOld; 
			int CKTcurrentAnalysis; int CKTpredictor;
int 		*Node; double *CKTrhsOld;
double 	*CKTstate0; double *CKTstate1;
 double *CKTstate2;
double 	*CKTstate3; double *CKTstate4; 
double *CKTstate5; double *CKTstate6;
double 	*currents; /* 
Currents to be returned by interpreter */
double 	conductances[20][20]; /* 
Conductances to be returned by interpreter */
{
	return (0);
}

Figure 2. Skeleton of the tftdc function.

 

 

The interpreted functions can contain local variables and the model equations are inserted after the initialization code section in the function. For the analysis functions, SmartSpice requires that all of the output current, conductance and capacitance variables are calculated.

 

Using The TFT Interpreted Device

In order to use the interpreted TFT device within a circuit the Y-device is used. The name of the parameters file, in this case tft_parameters, must be specified in each device using the USERPARAMS device parameter. This is followed by the list of device parameters as in any normal device. In the following example device, the name of the device instance is "Ytft". The first two values define the number of external and internal nodes which the device has, 3 and 2 respectively. The connections to the external nodes are then given. This list is then followed by the name of the device model, TFTMOD in this case. The first parameter of the instance is userparams which points to the file containing the list of device parameters. This is then followed by a list of instance parameters in the usual manner.

Ytft 3 2 1 2 0 TFTMOD
+ userparams = tft_parameters
+ l=20u w=300u
+ tempdebug = 1

In order to assist in developing model code, a debugger interface is provided. This debugger is similar to the "dbxtool" commonly found on UNIX systems, and it allows the user to set breakpoints, inspect variable values and step through the code. In the Ytft device, the debugger is turned on during the execution of the temperature routine. It is also possible to turn it on during the execution of the analysis routines. The debugger can also be activated from the run-time screen, the command line, and from within the interpreted code itself as in the following example.

if (strcmp (device_name, "Ytft") == 0)
{
if (iteration_number == 10)
command ("dcdebug Ytft on");
else if (iteration_number == 20)
command ("dcdebug Ytft off");
}

This will activate the debugger from the 10th iteration to the 20th iteration.

The .MODEL statement is used to specify the functions being used by the interpreted device and the files in which the functions can be found. The .MODEL statement also contains model parameters. The following .MODEL statement describes the TFTMOD model used in the previous Ytft instance. The name of the model is followed by the type of the model, NTYPE in this case. As in the actual device, the name of the file containing the device parameters is the first model parameter. The names of the files and functions containing the temperature and DC code are followed by a list of model parameters, as shown here.

.MODEL TFTMOD NTYPE (
+ userparams = tft_parameters
+ dcsourcecode = tftdc.c
+ dcfunction = tftdc
+ tempsourcecode = tfttemp.c
+ tempfunction = tfttemp
+ r=10000 lambdax=0.002 )

 

How To Access The SmartSpice Interpreter Models From UTMOST

SmartSpice interpreter models can also be accessed by UTMOST through the Interpreted Models Interface in VYPER. For more information on SmartSpice Interpreted models please refer to the previous sections of this article and Chapter 6 of the SmartSpice User's Manual Volume 2.

A Thin Film Transistor (TFT) device interpreted model will be used as an example to explain the interface between UTMOST and SmartSpice interpreted models. In this example, after the generation of the TFT interpreted model there should be four files in the following locations.

<directory_where_vyper_is_ activated>
/vyper_data/interp/tftmodel
<directory_where_vyper_is_ activated>
/vyper_data/interp/tft/tft_parameters
<directory_where_vyper_is_ activated>
/vyper_data/interp/tft/tftdc.c
<directory_where_vyper_is_ 
activated>/vyper_data/interp/tft/tfttemp.c

The tftmodel file should contain the information listed below. In this example the directory where vyper is activated from is /travel/silvaco/

.LIB Interpreted Model s.model TFTMOD (
+path = /travel/silvaco/vyper_data/interp/tft
+userparams = tft_parameters
+dcsourcecode = tftdc.c
+dcfunction = tftdc
+tempsourcecode = tfttemp.c
+tempfunction = tfttemp
+)

After the verification of the model files follow the following steps to establish the interface to the interpreted models through VYPER:

1. Press the Files Button in the main VYPER Screen and select the "Net Setup" option.
This will open the VYPER Configuration Screen.
 
2. Select the "INTERPRETER" and press the "Connect" button. This will open the
"Interpreted Models Interface" Screen (Figure 3.).
 
3. Enter the path to the directory containing the tftmodel in the text field across from the
"File name txt" and press the "Load" button.
 
4. Press the Arrow key across from the "Model" text and select "TFTMODEL". This will
fill the top and the middle section of the screen with the proper file names as shown in Figure 3.

 

Figure 3. Interpreted Models Interface Screen using a TFT example.

 

 
5. At this point the interface to the SmartSpice interpreted TFT model is completed. Press the
"quit" button to close the screens and go back to the main UTMOST Screen.
 
6. Press the "System" button to open the "Common Control Screen" and toggle the
"Spice Models" button until it reads "Interpreter".
 

UTMOST's TFT module can be used to collect the data from TFT devices. After the data collection the "Simulate" option from the graphics screen is used to obtain the simulated results with the SmartSpice interpreted models for an amorphous TFT device.

In Figure 4 and Figure 5 the measured and simulated IDS-VGS and IDS-VDS data is displayed for an amorphous TFT device where parameters were optimized using a SmartSpice interpreter model.

 

Figure 4. IDS-V DS measured (ooooo) and simulated (_____) TFT data.

 

Figure 5. I DS-V GS measured (ooooo) and simulated (_____) TFT data.

 

References

[1] Simulation Standard, Vol. 6, No. 7, July 1995.