Designs based on Finite State Machines - Digital Design of Signal Processing Systems: A Practical Approach - page 410

For a sequence of inputs, using the design specification, the designer needs to find the
corresponding sequence of outputs for writing test cases. A test case then checks whether the
FSM implementation conforms to the given set. The designer should find a minimum number of
shortest possible length sequences that check every possible transition. Various coverage measures
are used for evaluating the completeness of testing. Various coverage tools are also available that the
designer can easily adopt and integrate with the RTL flow. The tools help the designer to identify
unverified areas of the FSM implementation. The designer then needs to generate new test cases to
verify those areas. A brief discussion of these measures is given here.
9.6.2 Coverage Metrics for Design Validation
9.6.2.1 Code Coverage
The simplest of all the metrics is code coverage that validates that every line of code is executed at
least once. This is very easy to verify as most of the simulators come with inbuilt profilers. Though
100% line coverage is a good initial measure, this type of coverage is not a good enough indicator
of quality of testing and so must be augmented with other more meaningful measures.
9.6.2.2 Toggle Coverage
This measure checks whether every bit in all the registers has at least toggled once from 0 to 1 and 1 to 0.
This is difficult to cover, as the content of registers are the outcome of some complex functions. The tester
usually does not have deep enough understanding of the function to make its outcome generate the required
bit patterns. Therefore the designer relies on random testing to verify this test metric. The toggling of all bits
does not cover all sequences of state transitions so it does not completely test the design.
9.6.2.3 State Coverage
This measure keeps a record of the frequency of transitions into different states. Its objective is to
ensure that the testingmust make the FSM transit in all the states at least once. In many FSMdesigns
a state can be reached from different states, so state coverage still does not guarantee complete
testing of the FSM.
9.6.2.4 Transition or Arc Coverage
This measure requires the FSM to use all the transitions in the design at least once. Although it is a
good measure, it is still not enough to ensure the correctness of the implementation.
9.6.2.5 Path Coverage
Path coverage is the most intensive measure of the correctness of a design. Starting from the initial
state, traversing all paths in the design gives completeness to testing and verification. Inmany design
instances with moderately large number of states, exhaustive generation of test vectors to transverse
all paths may not be possible, so smart techniques to generate non-trivial paths for testing are critical.
Commercially available and freeware tools [17-19] provide code coverage measurements and give
a good indication of the thoroughness of testing.
One of these techniques is 'state space reduction'. This reduces the FSM to a smaller FSM by
merging different nodes into one. The reduced FSM is then tested for path coverage.
There are various techniques for generating test vectors. Specification-based testing works on
building a model from the specifications. The test cases are then derived from the model based on a