RE: [sv-ac] coverage

Hi John,

Apparently there is a problem with the hit definition for the coverage.
I don't quite understand why first_match(a or b) should report two hits
instead of one.

I see two options:
1) Significantly extend the language for coverage constructs introducing
sets, skews (cross coverage items), etc which will define EXACTLY what
is going to be checked (e.g., all possible combinations, one hit, etc).
This implies merging two different coverage concepts (chapter 17 and
chapter 18) into one. It might be a right thing to do, because at
present there is absolutely no relation between the two coverage
concepts, and SV coverage treatment is very eclectic; but it requires a
deep revision of the entire language.

2) Define minimal requirements for the tools - e.g., each tool should
report all witness points (= all points defining the finite property
witness plus one partial witness at the simulation end). It does not
define exactly - how the tool actually does it: reports one hit point
for each time moment, multiple hit points when several transactions
terminated simultaneously etc.

Consider the following examples (using proposed followed_by construct):

cover property (@(posedge clk) a ##1 (b or c));

The tool should report all points when either consecutive a, b or a, c
combinations happen. It should be up to the tool whether to distinguish
between a, b and a, c or not. It also should be up to the tool to match
between a transaction beginning (=when a happened) and its end (= when b
or c happened)

cover property (@(posedge clk) en followed_by !b[*1:$] |-> a);

The tool should report all sequences triggered by en, started with a
series of a terminating with b. It also should report the sequence when
a was always asserted until the end of the simulation.

The second version seems much more feasible, since the first version
will take years to define.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John
Havlicek
Sent: Thursday, March 23, 2006 11:20 PM
To: krolnik@lsil.com
Cc: dbustan@freescale.com; sv-ac@eda.org
Subject: Re: [sv-ac] coverage

Hi Adam:

> 
> Is there consideration of a first match operator for choosing single
instead of 
> multiple matches?
> 

I think that trying to use first_match is a reasonable thing,
but there are some difficulties in getting this solution to
work.

The two coverage semantics described currently in the LRM are
really "all matches per attempt" and "at most one match per attempt".
The main problem with the LRM is the way it defines when one or
the other of these applies.  

My opinion is that the criteria described in 17.13.3 are ambiguous and
too "tricky".  Some accidents of the way the sequence expression is
written are used to determine which semantics applies.  This is why
I prefer some clear syntax for the distinction, like a different 
directive.

The use of first_match seems like a clear syntactic distinction,
but I don't think it exactly solves the problem without creating
some others.  

While first_match usually results in "at most one match per
attempt", this is not always the case.  For example, if both 
boolean conditions "a" and "b" occur at the clock event, then 
"first_match(a or b)" has a double hit at that event.  So if the 
"all matches per attempt" semantics is used, you will get 2 hits,
while if the "at most one match per attempt" semantics is used,
you will get only 1 hit.  

Also, with the current wording of 17.13.3, the appliction of
"first_match" does not itself clarify which semantics to use.
Therefore, some modifications to 17.13.3 need to be made to
explain how the use of "first_match" determines which semantics
apply.  To me, this seems tricky and likely to result in more
backward incompatibilities than the solution that adds a
"cover sequence" directive that has "all matches per attempt"
semantics and redefines "cover property" always to have 
"at most one match per attempt" semantics.

Best regards,

John H.