In our journey of exploring the Blue Pearl Visual Verification Suite’s capabilities we will examine how it can help us create better finite state machines (FSMs) and counters.
FSMs are of course the central element of programmable logic designs. This is especially true when we are creating mission critical orhigh reliability solutions where the use of processors is discouraged or prohibited.
When we are creating state machines for high reliability applications, we want to ensure the state machine cannot inadvertently enter an illegal state. An illegal state is defined as one for which we have not set a behaviour or an entry path from the normal operation of the state machine.
If such an event were to occur in the operation of a mission critical or high reliability system, this could lead to failure of the system as behaviour is undefined. A traditional way to detect unmapped states is to perform a hand review of all FSMs within the design. This can take a considerable effort on large FSMs and can easily lead to errors as it is a manual review step.
I was pleased to see the latest release of the Visual Verification Suite includes new checks which enable us to verify that our state machines and counters are safely implemented.
The new messages are
- BPS-1067: State machine expanded to max states.
- BPS-1068: Counter cannot recover from unreachable states.
The first of these, checking that the state machine uses a power-of-two states, is contained within the FSM analysis and is enabled by setting the expand_fsm_to_state_var_size TCL variable to true. This variable can be set via the FSM Analysis Options page in the Design Settings dialog in the GUI, or via a TCL script in command line.
Setting this TCL variable results in the FSM analysis checking to ensure state machines include a power-of-two states.If not, a message is generated,and the FSM diagram is updated to show the missing state.
For example, in a simple FSM which only defines three of four states we get the following messages and diagram in the FSM viewer.
We can see the fourth state is clearly identified as not being correctly implemented in the state machine.
If we are implementing a high reliability system and such a warning is received, we are then able to identify the state machine and update the design to provide protection for the unmapped state.
Another area where the high reliability designs can run into issues is checking for counter terminal values. The second new message introduced ensures that instead of checking for “equal to” the desired terminal count, the design checks for “greater than or equal” or “less than or equal”depending upon the direction of the count.
If a single event upset flips the counter value to one that is beyond the specified terminal count, the check ensures that the counter will not be prevented from completing its action.
One way to enable this check on the counters in our design is to use the Load Checks page in the Design Settings dialog in the GUIand search for modulususing the text strip, as shown in the figure. Then, enable the check.
Next time we perform a load, all the counters in our design will be evaluated using the check and any counters which fail will be identified, allowing us to take corrective action.
In summary, these two new messages provide additional visibility of issues in our RTL designs which might impact performance in high reliability applications. They allow us to quickly focus in on counters and state machines which need corrective action to be suitable for the task at hand.