Scribd
Upload
4 views

Functional Coverage

Uploaded by

sindhuu0702
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
4 views

Functional Coverage

Uploaded by

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

FUNCTIONAL

COVERAGE
MODULE 5
PRESENTED BY
DHANUSHREE M
R
COVERAGE

• In System Verilog, coverage is a mechanism used to measure how


thoroughly the design has been tested. It helps identify parts of the
design that have not been exercised by testbenches.
• Coverage types in System Verilog include:
• 1.Code coverage
• 2.Functional coverage
• 3.Assertion coverage
• 1. Code Coverage:
• Statement Coverage:
• Measures whether each line of code has been executed at least once.
• Branch Coverage:
• Ensures that every branch (e.g., if-else, case statements) in the design
has been exercised.
• Condition Coverage:
• Checks if all conditions (in boolean expressions) evaluate to both true
and false.
• Example 9-1

• Incomplete D-flip flop model missing a pathmodule dff(output logic q, q_l,

• input logic clk, d, reset_l);

• always @(posedge clk or negedge reset_l) begin

• q <= d;

• q_l <= !d;

• end

• endmodule

• The reset logic was accidently left out. A code coverage tool would report

• that every line had been exercised, yet the model was not implemented correctly.
Functional Coverage is a type of coverage in software verification that checks whether specific
functionality, features, or requirements of a design are tested. Unlike code coverage (focused on
lines/branches of code), functional coverage ensures all functionalities or scenarios of interest are
validated.
Example Suppose we are testing an ALU (Arithmetic Logic Unit) that performs 4
operations:
1. Addition
2. Subtraction
3. Multiplication
4. Division
We want to ensure that all operations are tested during verification.
Functional Coverage Example in System Verilog
`systemverilog
// Define a covergroup to measure functional coverage
covergroup alu_operations_cg;
// Coverpoint for ALU operation types coverpoint operation { bins addition =
{0}; // Operation 0 -> Addition bins subtraction = {1}; // Operation 1 ->
Subtraction bins multiplication = {2}; // Operation 2 -> Multiplication bins
division = {3}; // Operation 3 -> Division }
Endgroup
// Instantiate and sample the covergroupmodule alu_testbench; alu_operations_cg cg
= new(); initial begin int operation; // Simulate ALU operations operation
= 0; cg.sample(); // Addition operation = 1; cg.sample(); // Subtraction
operation = 2; cg.sample(); // Multiplication operation = 3; cg.sample(); // Division
endendmodule
Explanation of the Example1.
Feature Under Test:
ALU operations (addition, subtraction, multiplication, division).
2. Functional Coverage Goal:
Ensure all 4 operations are tested at least once.
Outcome
- If all 4 bins (operations) are exercised during testing, the functional coverage will be
100%. - If any operation (e.g., multiplication) is missed, the coverage report will show
less than 100%, indicating incomplete testing.
Code coverage and functional coverage with respect to MX Player :
Code Coverage Code coverage measures the extent to which the code is
executed during testing. In the context of MX Player, code coverage would
involve checking if all the lines of code, such as:
Video playback functionality
- Audio playback functionality
- Subtitle rendering functionality
- Error handling mechanisms (e.g., for unsupported file formats)
For example, let's say we have a module in MX
Player responsible for video playback:
public class Video Player
{
public void playVideo(String filePath)
{
// Code to play video
}
public void pauseVideo()
{
// Code to pause video
}
public void stopVideo()
{
// Code to stop video
}
}
Functional Coverage
Functional coverage measures the extent to which the
specified functionalities or requirements are tested. In
the context of MX Player, functional coverage would
involve checking if all the specified functionalities, such
as:- Playing different video file formats (e.g., MP4, AVI,
MKV)- Playing videos with different resolutions and
aspect ratios- Supporting different subtitle formats
(e.g., SRT, ASS, SSA)- Handling errors and exceptions
(e.g., unsupported file format, network error)-
For example, let's say we have a requirement for MX Player to
support playback of videos with different resolutions:-
480p
- 720p
- 1080p
- Functional coverage would involve checking if MX Player can
successfully play videos with each of these resolutions.
Assertion CoverageAssertion coverage is a type of coverage analysis that
checks whether specific assertions or checks in the code are executed
during testing
In the context of MX Player, assertion coverage
would involve checking if all the assertions or
checks in the code, such as:
- Checking if the video file is valid before playback
- Verifying if the audio and video streams are
synchronized
- Ensuring that the subtitle rendering is correct
- Handling errors and exceptions (e.g.,
unsupported file format, network error)
Bug rate
An indirect way to measure coverage is to look at the rate at
which fresh
bugs are found. You should keep track of how many bugs you
found each
week, over the life of a project. At the start, you may find many
bugs through
inspection as you create the testbench. As you read the design
spec, you may
find inconsistencies, which hopefully are fixed before the RTL is
written.
Once the testbench is up and running, a torrent of bugs is found
as you check
each module in the system. The bug rate drops, hopefully to zero,
as the
design nears tape-out. However, just because the bug rates
approaches zero,
you are not yet done. Every time the rate sags, it is time to find
different ways
to create corner cases

You might also like