Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.

    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages

    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage

    • Techniques & Tools

      • Verification IQ
      • Verification IP
      • Static-Based Techniques
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.

    • Universal Verification Methodology (UVM)

      • Introduction to UVM
      • UVM Basics
      • Advanced UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time

    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification

    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters

    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking

    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.

    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum

    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum

    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum

    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).

    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns

    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns

    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.

    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook

    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines

    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.

    • Featured & On-Demand

      • Continuous Integration - March 28th
      • Questa Verification IQ - April 11th
      • SystemVerilog Assertions
      • SoC Design & Functional Safety Flow
      • 2022 Functional Verification Study
      • Design Solutions as a Sleep Aid
      • CDC and RDC Assist
      • Formal and the Next Normal
      • Protocol and Memory Interface Verification
      • Webinar Calendar

    • On-Demand Library

      • Practical Flows for Continuous Integration
      • Lint vs Formal AutoCheck
      • The Three Pillars of Intent-Focused Insight
      • Formal Verification Made Easy
      • Fix FPGA Failures Faster
      • HPC Protocols & Memories
      • FPGA Design Challenges
      • High Defect Coverage
      • The Dog ate my RTL
      • Questa Lint & CDC
      • Complex Safety Architectures
      • Data Independence and Non-Determinism
      • Hierarchical CDC+RDC
      • All On-Demand Recordings

    • Recording Archive

      • Aerospace & Defense Tech Day
      • Exhaustive Scoreboarding
      • Improving Initial RTL Quality
      • CDC Philosophy
      • Hardware Emulation Productivity
      • Visualizer Debug Environment
      • Preparing for PCIe 6.0: Parts I & II
      • Automotive Functional Safety Forum
      • Siemens EDA Functional Verification
      • Improving Your SystemVerilog & UVM Skills
      • All Webinar Topics

    • Conferences & WRG

      • Industry Data & Surveys
      • DVCon 2023
      • DVCon 2022
      • DVCon 2021
      • Osmosis 2022
      • All Conferences

    • Siemens EDA Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • EDA Xcelerator Academy(Learning Services) Verification Training, Badging and Certification
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.

    • Blog & News

      • Verification IQ
      • Verification Horizons Blog
      • Technical Resources

    • Verification Horizons Publication

      • Verification Horizons - March 2023
      • Verification Horizons - December 2022
      • Verification Horizons - July 2022
      • Issue Archive

    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Academy News
      • Contact Us

    • Training

      • Learning @OneGlance (PDF)
      • SystemVerilog & UVM Classes
      • Siemens EDA Classes
Ask a Question
SystemVerilog
  • Home
  • Forums
  • SystemVerilog
  • coverpoint array

coverpoint array

SystemVerilog 6308
#SystemVerilog ... 19
birdluo
birdluo
Full Access
16 posts
November 28, 2017 at 6:36 pm

I want to collect the function coverage by the covergroup. The sequence is as below:

|<-------------sequence0----------->  |<-------------sequence1----------->
------------------------------------  ------------------------------------
|  frame0  |   frame1 | .. |framen |  |  frame0  |   frame1 | .. |framen | 
------------------------------------  ------------------------------------
                                    |                                    |
                                  sample                               sample

For different sequence, the number of frame is different.

I write below code for it. But I don't know how covergroup handle the array.

ethe_item  frame[];
covergroup
FRAMECOUNT:coverpoint framecount{
  bits framecount[] = { }??
}
 
FRAME:coverpoint frame[]{
  bits = ??
} 
 
CVR: cross FRAME,FRAMECOUNT;
 
endgroup

can you give me some examples for it ?

Replies

Log In to Reply
dave_59
dave_59
Forum Moderator
10658 posts
November 28, 2017 at 6:59 pm

In reply to birdluo:

Can you show the declarations for everything you want to cover? Then give an example with a particular set of values and explain what you want covered (i.e. what would you like to see reported). I do not understand what you are trying to sample with FRAME.

— Dave Rich, Verification Architect, Siemens EDA

birdluo
birdluo
Full Access
16 posts
November 28, 2017 at 8:12 pm

In reply to dave_59:

the ethe_item is as below?
class ethe_item extends uvm_object

bit[15:0] length;
bit[7:0] cetype;
...

endclass

what the FRAME report is as below.

for sequence0
FARME[0]:
length 32
cetype 3;
FARME[1]:
length 32
cetype 2;

for sequence1
FARME[0]:
length 32
cetype 6;
FARME[1]:
length 32
cetype 7;

dave_59
dave_59
Forum Moderator
10658 posts
November 28, 2017 at 10:44 pm

In reply to birdluo:

What is framecount?
You still didn't explain what kind of report you are looking for. What would it take to get 100% coverage?

— Dave Rich, Verification Architect, Siemens EDA

birdluo
birdluo
Full Access
16 posts
November 29, 2017 at 12:54 am

In reply to dave_59:

|<-------------sequence0-----------> |<-------------sequence1----------->
------------------------------------ ------------------------------------
| frame0 | frame1 | .. |framen | | frame0 | frame1 | .. |framen |
------------------------------------ ------------------------------------
framecount is number of frame in a sequence.

example:
for sequence0
framecount[0] :2
FARME[0]:
length 32
cetype 3;
FARME[1]:
length 32
cetype 2;

for sequence1
framecount[1] :3

FARME[0]:
length 32
cetype 2;
FARME[1]:
length 32
cetype 3;
FARME[2]:
length 32
cetype 3;

In verification, the sequence0 find the bug, because the difference order of cetype cause the different resulut.

cetype order:
sequence0:
cetype :3
cetype :2

sequence1:
cetype :2
cetype :3
...

The bug exists in the sequence0.

there are some ideas:
1.whether there are the other cetype order that hit bug.
2.when regress finish, coveragegoup tell me what the hole is. based on it , I will add cases or modify the test method.

for these problem, are there any proposal?

birdluo
birdluo
Full Access
16 posts
November 29, 2017 at 4:49 pm

In reply to birdluo:

Maybe I should change the way of thinking.
I write a component of uvm to collect the cover information that meet my requirement.
when a testcase simulation ends, the cover information will be saved in the enviroment.
when the regress finish, the cover information of every case in enviroment will merge.
there should be a format of cover infomation that ead tool can parse.
are there format standard for cover info?

dave_59
dave_59
Forum Moderator
10658 posts
November 29, 2017 at 10:37 pm

In reply to birdluo:

There is no standard format for writing coverage information, there is a standard API called UCIS that you can use to write into a database. But you have a long way to go before you get to that.

Functional coverage is a way of capturing requirements and scenarios that have been tested without failure. It is not for debugging tests that have failed. If you can't explain the requirements, you will not be able two write SystemVerilog covergroups or use UCIS.

If we just consider at cetype, it seems you want to look all the possible transitions between frames. With just 2 frames, there are 65536 possible transitions. With 4 frames, there are 2**32 possible transitions. Maybe there are a limited number of valid values for cetype, but I'm sure frame count is much larger. Maybe you only care about adjacent transitions.

Now let us consider length, which is a 16-bit number, as well. Do you really want to cross every possible value of length with every possible transition of cetype?

My point in all this is you need to figure out what it means to be exhaustive, and how to move your testing away from exhaustive and still meet your requirements.

— Dave Rich, Verification Architect, Siemens EDA

birdluo
birdluo
Full Access
16 posts
December 03, 2017 at 6:19 pm

thank you for the reply.

Maybe it is interesting question.

In the verification, We hope that the design can be proved to be correct.
yes,for adjacent 2 transitions, there are 65536 possible transitions.
Exhaustive test is not good method.

But I want to know if the 65536 possible transitions is correct.
Maybe there are better methods.
For your point, can you give me some methods?

dave_59
dave_59
Forum Moderator
10658 posts
December 04, 2017 at 8:30 am

In reply to birdluo:

This is the art of verification. One does not exhaustively test a multiplier with every possible input because we now have confidence in synthesis tools to implement it correctly. But we need to check its boundary conditions to make sure the multiplier has been specified correctly.

If you have a design where you feel it needs to be tested exhaustively, then you may want to look at formal or acceleration technologies.

— Dave Rich, Verification Architect, Siemens EDA

birdluo
birdluo
Full Access
16 posts
December 04, 2017 at 5:32 pm

In reply to dave_59:

how to find the boundary condition should be art.
|<-------------sequence0-----------> |<-------------sequence1----------->
------------------------------------ ------------------------------------
| frame0 | frame1 | .. |framen | | frame0 | frame1 | .. |framen |
------------------------------------ ------------------------------------
| |
sample sample
for above example if design reset at the start of every sequence, the sequences should be independent.
verifcaton work is as below:
1.reset circuit will be verified.
2.the senarion of a sequence will be verified.
3.Maybe the relationship of sequences will not be cared.

But no reset circuit, the relationship of sequences need to be cared.
the influence factor is two much.

So verification method is very affected by design idea.

for large-scale design, the formal have some limitation.are there the paper of acceleration technologies?
how to know whether the verification is enough?
I can not still describe this question clearly, I want to know your thought or flow.

Siemens Digital Industries Software

Siemens Digital Industries Software

#TodayMeetsTomorrow

Portfolio

  • Cloud
  • Mendix
  • Electronic Design Automation
  • MindSphere
  • Design, Manufacturing and PLM Software
  • View all Portfolio

Explore

  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Customer Stories
  • Partners
  • Trust Center

Contact

  • VA - Contact Us
  • PLM - Contact Us
  • EDA - Contact Us
  • Worldwide Offices
  • Support Center
  • Give us Feedback
© Siemens 2023
Terms of Use Privacy Statement Cookie Statement DMCA