Some behaviors are too complex to capture using just an equation, truth table or FSM. Consider capturing the behavior of a custom processor for a soda machine dispenser that dispenses a soda when enough money has been deposited into the machine. A block diagram of the processor system is shown.

A coin detector provides the processor with a 1-bit input c that becomes 1 for one clock cycle when a coin is detected and an 8 bit input a indicates the value in cents of the inserted coin. Another 8-bit input s indicates the cost of a soda, which can be set by the machine owner. When the processor has detected that the total value of deposited coins equals or exceeds the cost of a soda, the processor should set an output bit d to 1 for one cycle, causing a soda to be dispensed. Assume that the value a persists until the next coin is deposited and that many clock cycles occur between successive coins being deposited.

An FSM is not sufficient for capturing the data aspects of this system's behavior. An FSM can only have Boolean inputs, not an 8-bit data input representing a binary number. An FSM has no convenient way of keeping track of the total data value of coins deposited so far. An FSM can only perform Boolean operation, not the data addition operation required to keep track of the total value of coins deposited.

A high level state machine (HLSM) extends FSMs with the data features neede to capture more complex behaviors, including:

1) multibit dataa inputs and outputs rather than just single bits

2) local storage

3) arithmetic operations like add and compare, rather than just Boolean operations.

HLSMs whose local storage is loaded on rising clock edges are used. Also, each local storage item and multibit input or output is assumed to be unsigned, unless specifically denoted as signed.

Figure shows an HLSM describing the behavior of the soda dispenser processor. The HLSM initially sets output d to 0 and sets a local storage item tot to 0. The HLSM then waits in state Wait to detect a coin being deposited. When detected, the HLSM goes to state Add, which adds the coin's value a which the HLSM returns to Wait. If tot's value is less than cost s of a soda (tot < s), the HLSM continues to wait for more coins. Otherwise, the HLSM goes to state Disp, which sets d to 1 to dispense a soda, after which the HLSM returns to state Init to clear tot back to 0 and start over again.

The start machine is not an FSM, because of reasons highlighted in the figure. One reason is because the state machine has inputs that are 8-bit types, whereas FSMs only allow inputs and outputs of Boolean types (a single bit each). Another reason is because the state machine declares local storage tot to store intermediate data, whereas FSMs dont allow local data storage - the only stored item in an FSM is the state itself. A third reason is because the state actions and transitions conditions involve data operations like tot = 0, tot < s, and tot + a whereas an FSM allows only Boolean operations like AND or OR.

The following are the conventions for HLSMs also used for FSMs:

1) Each transition is implicitly ANDed with a rising clock edge.

2) Any bit output not explicitly assigned a value in a state is implicitly assigned a 0.