Coverpoint array

SystemVerilog
,
1

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 ?

2

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.

3

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;

4

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?

5

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?

6

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?

7

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.

8

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?

9

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.

10

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.