Session 15: FSM
Verification and Code 1. FSM verification
coverage 2. Code Coverage
371
FSM VERIFICATION
Complete state verification: Ensure that all states ST_6 IDLE
are reachable and testable. Each state should be
entered and exited as intended.
Example: all the states in right hand side should
ST_5 ST_3 ST_0
be covered in the simulation
ST_4 ST_2 ST_1
372
FSM VERIFICATION
Ensure that all states can be entered and exited.
Problem: unreachable states ST_6 IDLE
States that cannot be reached from the initial
state under any conditions. D=0
Example: at ST_5, if D is always 1, ST_6 is an
ST_5 ST_3 ST_0
unreachable state. D=1
ST_4 ST_2 ST_1
373
FSM VERIFICATION
Ensure that all states can be entered and exited.
D=1
Problem: Dead states ST_6 IDLE
Once entered, can not transition to any other
state. D=0
Example: at ST_6, if D is always 0, the state
ST_5 ST_3 ST_0
machine is stucked. ST_6 is a dead state. D=1
ST_4 ST_2 ST_1
374
FSM VERIFICATION
Ensure that the conditions triggering state transitions
are correct and do not overlap unintentionally!!!
Problem: Transition failure ST_6 IDLE
Can not move do desire states as the specification
Example: as specification, ST_5 can be moved
back to ST_2. But at ST_5, D is always 0, then
ST_5 ST_3 ST_0
state can not move back to ST_2. So, transition D=0
from ST_5 to ST_2 is not guaranteed.
D=1
ST_4 ST_2 ST_1
375
FSM VERIFICATION
Ensure that all the conditions and combination of
state transition are tested!!!
Problem: Wrong transition ST_6 IDLE
The issue often occurs at states that has multiple
conditions for transition due to priority conflict.
Example: as ST_2, when A=1 & B=1, state moves
ST_5 ST_3 ST_0
to ST_3, not ST_4 as the specification.
A=1
ST_4 ST_2 ST_1
B=1
A=x
376
FSM VERIFICATION
State encoding must be uinique !!!
Problem: Wrong state encoding
State is uniquely encoded and that there is no ST_6 IDLE
ambiguity in state representation.
Example: state encoding
IDLE: 4’h00
ST_0: 4’h01 ST_5 ST_3 ST_0
ST_1: 4’h02
ST_2: 4’h03
ST_3: 4’h03 wrong state encoding
It can lead to moving to wrong state after
reaching ST_1. ST_4 ST_2 ST_1
377
FSM VERIFICATION
Problem: Wrong operation after reset Ensure that the FSM correctly initializes to a
After reset occurs, states are not transit to initial state. known state upon reset !!!
This issue occurs at modules that have multiple reset,
e.g. Power-ON (POR) reset and System reset.
ST_6 IDLE
Example: This FSM is inside module that has POR reset
and system reset. This FSM is reset by POR reset only.
When system reset occur at ST_4, D (initizlize by system
reset) is reset to 0 so state is stucked at ST_4 and can
not go back to IDLE state. ST_5 ST_3 ST_0
Power-ON reset: is a type of reset signal generated during the power-up
of a device. It ensures that the device starts in a known state every time
power is applied
D=1
System reset: is a broader reset mechanism that can be triggered by
various conditions or sources during the normal operation of a system.
It ensures the system can be brought back to a known state under ST_4 ST_2 ST_1
specific conditions.
378
COVERAGE RECAP
Identify Verification Scope Coverage: helps DV engineers identify areas they haven't yet tested. Here are
and Method
some examples:
Design Requirement ▪ Some lines of code that haven't been tested
Analysis ▪ An else-if condition that hasn't been tested
Create Verification
▪ A logical combination of values that hasn't been tested
Specification and Plan ▪ Some states of a state machine that haven't been tested
….
Build Test Environment and
Test Case (Scenario)
Coverage also helps RTL design engineers identify unreasonable lines of code and
conditions that never occur. As a result, RTL engineers can optimize their designs
Run Simulation and Debug to make them better.
Check and Improve Completing coverage is a MUST to demonstrate that the verification work is
Coverage completed.
Verification Review
Coverage will help to detect the above issues !!!
379
CODE COVERAGE
Code coverage is a metric used to measure how much the design source in RTL or gates
are tested. Code coverage measures how often a suite or tests exercises certain aspects
of the source.
Missing code coverage is usually an indication of 2 things:
▪ Un-used code, or
▪ Holes in the verification
We can improve the coverage by:
▪ Remove the un-used code
▪ Add testcases to cover the verification holes.
We need to achieve 100% code coverage in the final project!!!
380
COMMON CODE COVERAGE TYPES
Statements coverage
Some common code coverage types are: statement, branch, expression, condition,
toggle.
Statement coverage: sometimes called “line coverage” is the most basic form of code
coverage. The EDA tools will count of how many times a given statement is executed
during simulation.
381
COMMON CODE COVERAGE TYPES
Branch coverage
Branch coverage: relates to branching constructs such as “if” and “case” statements. It
measurestrue branch and false branch execution.
382
COMMON CODE COVERAGE TYPES
Expression coverage
Expression coverage: analyzes the activity of expressions on the right-hand side of
assignment statements, and counts when these expressions are executed.
FEC (Focused Expression Coverage): is a method that measures coverage for each input
of an expression. If all inputs are fully covered, the expression has reached 100%
coverage.
Example of expression:
assign y = a & (b | c); expression that will be analyzed by FEC
383
COMMON CODE COVERAGE TYPES
Expression coverage
In FEC, an input is said to be fully covered when the following conditions apply:
▪ All other inputs are in a state that allow the covered input to control the output of
the expression.
▪ The output can be seen in both 0 and 1 states while the target input is controlling it.
Example:
assign y = a & (b | c);
For terminal a to be covered, the value of expression (b | c) must be in a non-masking
state (that is, 1 for the & operator)
.
384
COMMON CODE COVERAGE TYPES
Expression coverage
The tool will break the big expression into smaller basic expressions and evaluate one by one.
Example the expression:
assign z = a & (b | c);
Test vector (a,b,c) = (1,1,0) Test vector (a,b,c) = (1,1,0), (0,1,0)
385
COMMON CODE COVERAGE TYPES
Condition coverage
Condition coverage: Similar to expression coverage but it analyzes the decision made in
“if” and ternary statements (condition ? true_value : false value).
//current state logic
assign cnt_pre = cnt_clr ? 8’h0:
en1 | en2 ? cnt + 1’b1:
cnt;
------------------------------------
always @* begin
Target of condition coverage
if( a & b)
y = 1;
else
y = 0;
end
386
COMMON CODE COVERAGE TYPES
Toggle coverage
Toggle coverage: to measure how many times each bit of a signal has changed (or toggled) during
simulation.
Data types which are target of toggle coverage calculation: wire, reg, bit, enum, real, shortreal and integer.
Note: the Questa Sim does not monitor toggle
coverage for ports of target instance. It only
monitor toggles on signals.
But we can monitor the related port toggle on the
top level.
The example on the left shows toggle report in
testbench, which is top of dut.
Test vector (a,b,c) = (1,1,0), (0,1,0)
387
PRACTICE
1. Create 15_ss15 in your home directory
2. Copy share/teacher/15_ss15/cov_practice into your directory. The design contains only 1 expression as
the previous examples: y = a & (b | c);
3. Start writing test case in home directory, write first vector (a,b,c) = (1,1,0).
4. % make help to see the new options
5. % make all_cov to build and run simulation in coverage mode. Simulation should be PASSED and
test.ucdb is generated.
6. % make gen_cov to generate coverage report. The report is in coverage folder.
7. Read and analyze the summary and detail report
8. Improve the coverage by adding testcase one by one and see the differences in the coverage report
(repeat step 3 until coverage of dut is 100%).
9. % make gen_html to generate coverage report in html format. Open the index.html in covhtmlreport
folder report to see the coverage.
10. Apply this method for one another design to see other coverage metrics.
388
Homework
Homework1: Apply code coverage method for counter below:
Homework2(advanced): APB protocol presentation at SS17
389
