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