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.