100% found this document useful (1 vote)
992 views10 pages

Verification Plan in Mentor Graphics Questa

Test Plan for verification engineers is the guide or the metric which is used to measure results of coverage and other verification activities. Questa as a verification tool has its own procedure in order to enables verification engineers to check if their verification plan is met or not. In this document we will see steps that can be followed in order to use Questa to apply your verification plan.
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
100% found this document useful (1 vote)
992 views10 pages

Verification Plan in Mentor Graphics Questa

Test Plan for verification engineers is the guide or the metric which is used to measure results of coverage and other verification activities. Questa as a verification tool has its own procedure in order to enables verification engineers to check if their verification plan is met or not. In this document we will see steps that can be followed in order to use Questa to apply your verification plan.
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/ 10

Writing Veri ication Plan in Questa

ELECTGON
www.electgon.com
[email protected]

03.06.2019
Contents

1 What is a Veri ication Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1


1.1 Procedures to Add Veri ication Plan in Questa . . . . . . . . . . . . . . . 1
2 Step 1: Write Veri ication Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1 Fields in the Veri ication Plan . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1.1 Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1.2 Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.3 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.4 Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.5 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.6 Weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.7 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.8 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Summary of Veri ication Plan Fields . . . . . . . . . . . . . . . . . . . . . 3
2.3 Identifying Full Path of a Target . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Testplan Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Step 2: Export the Plan to XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Step 3: Import XML plan into Veri ication Environment . . . . . . . . . . . . . . 6
5 Step 4: Merge Imported Plan with Simulation Data . . . . . . . . . . . . . . . . 6
Abstract

Test Plan for veri ication engineers is the guide or the metric which is used to measure results
of coverage and other veri ication activities. Questa as a veri ication tool has its own procedure
in order to enables veri ication engineers from checking if their veri ication plan is met or
not. In this document we will show steps can be followed in order to use Questa to apply
your veri ication plan.
Veri ication Plan in Questa 1. What is a Veri ication Plan

1 What is a Veri ication Plan


Veri ication Plan is an organization of what should be touched in your simulation. It should
include all your assertions, coverpoints, bins, crosses,.. so that a inal report can be displayed
showing what was achieved in your simulation and what is not achieved.
Veri ication Plan should be developed side by side with your veri ication environment. At
the end we should map a relation between veri ication items (cover points, assertions …) and
test plan ields. This will be clear more in coming sections. What is important to know now
is that veri ication items as it is constructed in your veri ication environement, it should be
listed also in your veri ication plan so that veri ication tool (Questa in our documenet here)
can be able to display test report at the end of your simulation.
This means also that these veri ication items should be listed in the plan with a prede ined
layout so that Questa can be able to recognize each veri ication item and be able to ind it in
veri ication environment. So in the following sections we will show this prede ined layout of
veri ication plan for Questa.

1.1 Procedures to Add Veri ication Plan in Questa

Mainly 4 steps are followed in order to successfully integrate a veri ication plan (or Test Plan)
into your veri ication environment using Questa.

2 Step 1: Write Veri ication Plan


As mentioned before, there is special format for the Testplan in order to be sucessfully imported
and understood by Questa. The easiest way is to write this plan in a spreadsheet orgainzed
as discussed in the following subsection

2.1 Fields in the Veri ication Plan

The ields (or columns, in the case of a spreadsheet) of data in a testplan are determined
positionally. In other words, for an import to work correctly, the ields to be imported must
appear in their default (expected) positions in the plan.
The following Fields are mandatory ields that are required by Questa in order to be read
successfully.

2.1.1 Section

Format: <section#>[.<subsection#>]...

• The section number, which is used to determine plan hierarchy and to generate tags
(links to coverage items in the design).

• Duplicate Section numbers are not allowed and result in an error.

• You must de ine parent sections before child sections, for example: section 1 before 1.1,
before 1.1.1, and so on.

1
Veri ication Plan in Questa 2. Step 1: Write Veri ication Plan

2.1.2 Title

Format: <scope_name>

• The name of the test plan “section”, where <scope_name> appears in the VM Tracker
window and in the coverage reports.

• Use of special characters is discouraged (“*?/.”).

• Duplicate Title entries (at a sibling level) are not allowed and result in an error.

An example of a title/name: if section 1 has a section title of “Interfaces”, and section 1.1 has a
section title of “Wishbone”, then the hierarchical name of section 1.1 becomes /Interfaces/Wishbone.

2.1.3 Description

Format: <text>
Textual description of the Section. Usually, this would be a description of the testcase or
test procedure that the section details. This can be free‐form text.

2.1.4 Link

Format: <coverage_item> <coverage_item> ...

• Speci ies the coverage objects or test data records which are linked to the testplan
section.

• A testplan section can have one or multiple links to a coverage object or test data record.

• A speci ic format is required for the Link string itself.

2.1.5 Type

Format: type of <coverage_item> type of <coverage_item> ...

• Speci ies the type of coverage item referred to in the Link ield.

• There must be one entry in the “Type” column for each entry found in the “Link” column.
However, there can be a single entry in the “Type” column which is applied to all the
entries in the “Link” ield.

2.1.6 Weight

Format: <weight_as_int>
An integer value used in the calculation of the weighted averages of the parent sections,
calculated in loating point.

2
Veri ication Plan in Questa 2. Step 1: Write Veri ication Plan

2.1.7 Goal

Format: <goal> (1 ‐ 100)

• Speci ies the percentage value as a goal for a particular coverage object in the GUI.

• This sets the threshold at which the bar‐graph goes from uncovered (red) to covered
(green) within the Questa SIM GUI.

• It does not affect the overall coverage grading calculation.

2.1.8 Path

Format: <path/to/linked/item>

• An optional data ield, not included by default.

• Speci ies the actual instance path to an item in a corresponding Link.

• Alternatively, an absolute path can be speci ied in the Link column (e.g. /top/a/cov1).

2.2 Summary of Veri ication Plan Fields

It is noted that all of these ields are free to enter any text according to user design except for
the following ields that shall follow speci ied format:

• Section

• Link

• Type

Important:

• While adding ’Section’ ield you must write parent section before child section. And it
should be numbers.

• While adding ’Type’ ield, inputs for this ield are prede ined and case sensitive. So it is
allowed only to use one of the following values in this ield

“Type” Field Entries


Assertion Cross Instance
Bin Directive Rule
Branch DU Tag
Condition Expression Test
CoverGroup Formal_Proof Toggle
CoverPoint Formal_Assumption XML
CoverItem FSM

3
Veri ication Plan in Questa 2. Step 1: Write Veri ication Plan

• While adding ’Link’ ield, for each type de ined in previous table, the Link ield has
speci ic format. To make it simple, the Link ield can accept full path of instance name
(i.e. object that is needed to be tracked). In this case no need to write the path again in
the Path ield. Or it can accept only the instance name, i.e without the hierarichal path.
In this case we have to add path to this instance.

Instance name then depends on the type of this instance (CoverPoint, Cross, Directive,...).

“Type” of Instance Link Syntax


Assertion Name (use Path ield in this case)
Full Path
Bin Full Path
Branch Full Path
Condition Full Path
CoverGroup Name (use Path ield in this case)
Full Path
CoverPoint <CoverGroupType>::<CoverPointName>;
<Full path to
CoverGroupType>::<CoverPointName>;
CoverItem Name (use Path ield in this case)
Full Path
Cross <CoverGroupType>::<CrossName>;
<Full path to CoverGroupType>::<CrossName>;
Directive Name (use Path ield in this case)
Full Path
DU Full Path
Expression Full Path
Formal_Proof Full Path
Formal_Assumption
FSM Full Path
Instance Full Path

So it can be noticed that easiest way to remember this is to write full path to the object
that you want to track. In case of Coverpoints and Cross, “::“ is needed before coverpoint
name.

2.3 Identifying Full Path of a Target

It may be ambiguous while Test Plan writing, what is the exact path of the object so that
we can link it correctly in our Test Plan. The following steps may be helpful for identifying
required path.

1. Save UCDB result of your simulation. Use the following command in your do ile in
order to save it:

4
Veri ication Plan in Questa 2. Step 1: Write Veri ication Plan

 
coverage save -onexit <Target_Directory>/<filename.ucdb>
 

where <Target_Directory> is the directory you like to save the ucdb output in. < ilename.ucdb>
is your ucdb output.

2. Open your UCBD output by running the following command

 
vsim -viewcov <Target_Directory>/<filename.ucdb>
 

3. In Questa GUI you can ind hierarichal structure of all your simulation objects as shown
in igure 1.

Figure 1: Objects Paths in Questa

Or as alternative, in Questa GUI top toolbar click on View> >Coverage> >Covergroup. In


covergroup window you can check the path of your objects.

2.4 Testplan Sample

At the end, your Test plan should look like igure 2.

5
Veri ication Plan in Questa 3. Step 2: Export the Plan to XML

Figure 2: Testplan Sample

3 Step 2: Export the Plan to XML


This can be done by saving your spreadsheet as microsoft Excel 2003 XML.

4 Step 3: Import XML plan into Veri ication Environment


Use the following command to import the xml plan
 
xml2ucdb -format Excel xml_plan_name.xml <Target_Dir>/<imported_name.ucdb>
 

5 Step 4: Merge Imported Plan with Simulation Data


Use the following command to merge your plan with simulation results
 
vcover merge -totals <Target_Dir>/<Merged_plan.ucdb> <imported_name.ucdb> <
Test1_result.ucdb> <Test2_result.ucdb> <Test3_result.ucdb> ...
 
note that option ‐totals is used to include all coverage items (assertions, coverpoints,
cross,..) into your test tracing.

6
Bibliography

[1] Questa SIM Veri ication Management User’s Guide.

[2] Questa SIM Command Reference Manual.

[3] Lecture Notes/Script, Prof. Dr. Ing. Stefan Wolter – Hochschule Bremen – Spring 2015.

You might also like