State Machine

The digital state machine provides for straightforward descriptions of clocked combinational logic blocks with a variable number of inputs and outputs and with an unlimited number of possible states. The model can be configured to behave as virtually any type of counter or clocked combinational logic block and can be used to replace very large digital circuit schematics with an identically functional but faster representation.

The d_state model is configured through the use of a state definition file (state.in) which resides in a directory of your choosing. The file defines all states to be understood by the model, plus input bit combinations which trigger changes in state. An example state.in file is shown below:

----------------- begin file --------------
* This is an example state.in file. This file
* defines a simple 2-bit counter with one input. The
* value of this input determines whether the counter counts
* up (in = 1) or down (in = 0).

0 0s 0s 0 -> 3
        1 -> 1

1 0s 1s 0 -> 0
        1 -> 2

2 1s 0s 0 -> 1
        1 -> 3

3 1s 1s 0 -> 2
3 1s 1s 1 -> 0
------------------ end file ---------------

Several attributes of the above file structure should be noted. First, ALL LINES IN THE FILE MUST BE ONE OF FOUR TYPES. These are:

1. A comment, beginning with a "*" in the first column.
2. A header line, which is a complete description of the current state, the outputs corresponding to that state, an input value, and the state that the model will assume should that input be encountered. The first line of a state definition must ALWAYS be a header line.
3. A continuation line, which is a partial description of a state, consisting of an input value and the state that the model will assume should that input be encountered. Note that continuation lines may only be used after the initial header line definition for a state.
4. A line containing nothing but whitespace (space, formfeed, newline, carriage return, tab, vertical tab).

A line which is not one of the above will cause a file-loading error.

Note that in the example shown, whitespace (any combination of blanks, tabs, commas) is used to separate values, and that the character "->" is used to underline the state transition implied by the input preceding it. This particular character is not critical in of itself, and can be replaced with any other character or non-broken combination of characters that you prefer (e.g. "==>", ">>, ":", "resolves _to", etc.)

The order of the output and input bits in the file is important; the first column is always interpreted to refer to the "zeroth" bit of input and output. Thus, in the file above, the output from state 1 sets out[0] to "0s", and out[1] to "1z".

The state numbers need not be in any particular order, but a state definition (which consists of the sum total of all lines which define the state, its outputs, and all methods by which a state can be exited) must be made on contiguous line numbers; a state definition cannot be broken into sub-blocks and distributed randomly throughout the file. On the other hand, the state definition can be broken up by as many comment lines as you desire.

Header files may be used throughout the state.in file, and continuation lines can be discarded completely if you so choose: continuation lines are primarily provided as a convenience.

Input Values

Output Values

Port Table

Parameter Table

If the filename contains spaces must be delimited by quotation marks. If you do not specify a full path, the file is searched in the following order:

1. As a file attachment within the current job.
2. In the folder that contains the current job.
3. In the folder USER/LIBRARY.
4. As a file attachment within the jobs in the folder USER/LIBRARY.
5. In the folder APP/LIBRARY.
6. As a file attachment within the jobs in the folder APP/LIBRARY.
7. In the folder APP/BIN.
8. As a file attachment within the jobs in the folder APP/BIN.
9. Within the current job. As a block of text defined by Directive #BEGINDATA.
10. Within the jobs in the folder of the current job. As a block of text defined by Directive #BEGINDATA.
11. Within the jobs in the folder USER/LIBRARY. As a block of text defined by Directive #BEGINDATA.
12. Within the jobs in the folder APP/LIBRARY. As a block of text defined by Directive #BEGINDATA.

Error Messages

D_STATE: source file 'state.txt' not found.

This message is displayed each time the specified file does not exist.

D_STATE: Source text was not read successfully. 
The most common cause of this problem 
is a trailing blank line in the source text

This error occurs when the source text has not been read successfully. This is due to one of the following:

• The counted number of tokens in one of the file's input lines does not equal that required to define either a state header or a continuation line (Note that all comment lines are ignored, so these will never cause the error to occur).
• An output state value was defined using a symbol which was invalid.
• An input value was defined using a symbol which was invalid (i.e., it was not one of the following: 0, 1, X, or x).

D_STATE: An error exists in the ordering of states values
in the states->state array. This is usually caused
by non-contiguous state definitions in the state.in file

This error is caused by the different state definitions in the input file being non-contiguous. In general, it will refer to the different states not being defined uniquely, or being "broken up" in some fashion within the state.in file.

Example

a4 [2 3 4 5] 1 12 [22 23 24 25 26 27 28 29] statel

.model statel d_state(clk_delay = 13.0e-9 reset.delay = 27.0e-9
+                     state_file = newstate.txt reset_state = 2)

See also

XSPICE Devices
XSPICE Code Models