0% found this document useful (0 votes)
14 views

Session 15 FSM Verification and Code Coverage

Code COverage
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views

Session 15 FSM Verification and Code Coverage

Code COverage
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

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

You might also like