XSPICE includes a library of predefined "Code Models" that can be placed within any circuit description in a manner similar to that used to place standard SPICE device models.

Code model instance cards always begin with letter "A", and always make use of a .MODEL card to describe the code model desired.

Two tables are included for each model:

• The Port table contains all the information about the input and output connections of the device.
• The Parameter table contains all of the information about the device’s model parameters.

The list of the ports is used in the device instance, while the list of parameters is used in the definition of a model.

The Port Table

It defines the set of valid ports available to the code model. The ports listed in the port table appear in the order required by
the device’s call line. The fields in the port table are as follows:

Description

Describes the purpose and function of the port.

Direction

The direction of a port specifies the dataflow direction through the port. A direction must be one of: IN, OUT or INOUT.

Default Type and Allowed types

The Default Type field specifies the default signal type that will be expected at the port. The Allowed Types specify the signal types that are allowed at the port. The following table summarizes the allowable types.

Vector

This entry is either a YES or NO. NO signifies a single connection. The value YES specify that the port is a vector. A port which is a vector can be thought of as a bus. In code model instance square brackets, such as [1 2 3 4], are used to enclose vector input nodes. If this value is YES, the vector bounds field will contain limits for the number of connections.

Vector Bounds

The Vector Bounds field specifies the upper and lower bounds on the size of a vector. The lower bound of a vector specifies the minimum number of elements in the vector; the upper bound specifies the maximum number of elements. If the range is unconstrained, or the associated port is not a vector, the vector bounds is specified by a hyphen ("-"). Using the hyphen, partial constraints on the vector bound may be defined (e.g. [2,-] indicates that the least number of port elements allowed is two, but there is no maximum number).

Null Allowed

This entry is either a YES or NO. The value YES specify that is legal to leave this port unconnected. NO specify that the port must be connected. The string “NULL” is used as a placeholder on the call line. It replaces the node number and indicates an unconnected port.

The Parameter Table

The parameter table defines the set of valid parameters available to the code model. The entries can appear in any order. The fields in the parameter table are as follows:

Name

The identifier which will be used on .MODEL cards to refer to this parameter.

Description

Is used to describe the purpose and function of the parameter.

Data Type

Valid data types include boolean, complex, int, real and string.

Default Value

This value is supplied for the parameter in the event that the .MODEL card does not supply a value for the parameter.

Limits

A range is specified by a value representing a lower bound separated by space from another value representing an upper bound (e.g. [0 10]). The lower and upper bounds are inclusive. Either the lower or the upper bound may be replaced by a hyphen ("-") to indicate that the bound is unconstrained (e.g. [10 - ]) .

Vector

The value YES specify that the parameter is a vector. NO Specify that is a scalar. A vector parameter may contain values separated by spaces, commas or parentheses, and must be enclosed in square braces. For example, den_array=[0 10 100] or cntrl_freq_array=[0,10k 1,20k 2,100k].

Vector Bounds

The Vector Bounds field specifies the upper and lower bounds on the size of a vector.

Null Allowed

The value YES specifies that the value of the parameter can be omitted. If the parameter is omitted, the default value is used. If Null Allowed is NO the simulator will flag an error if the .MODEL card omits a value for this parameter.

Analog Models

Analog code models operate using continuous voltages and currents like traditional SPICE models. Their inputs and outputs all use the analog node type. No special translational bridges are required to interconnect these elements unless a connection is being made to a  digital node type.

Hybrid Models

Elements are classified as analog, event-driven (digital), or hybrid (analog and event-driven) based on their node types. Each input or output is of a specific type. The models may have either analog or event-driven node types. An element that uses both analog and event-driven nodal connections is called a “hybrid”. Elements which use different node types must communicate through special elements called “Node Bridges”. The following hybrids and node bridges are supplied with simulator.

Digital Models

All digital code models are processed by the event-driven simulator. All digital nodes are initialized to ZERO at the start of a simulation. All of the basic digital gates, flipflops, and latches drive their outputs with a STRONG digital signal strength. In general, any unknown, or floating input will cause an output to be unknown. Most digital elements allow their rising and falling delays to be independently set.

In order to communicate with analog node types, node bridges must be used.

In order to view or print the digital waveforms, you must convert the digital signals into analog signals using the variables DGTPLOTxxx. See also Simulator options.

See also

XSPICE devices