Subject: [sv-cc] Re: assertion/coverage API questions
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Tue Mar 04 2003 - 08:31:06 PST
Adam,
the answers are as follows:
1. we could not agree on a canonical definition for expression coverage. There
are too many variants and too many alternative definitions between the
various vendors and even between user requests/intents.
Rather than deadlock here, we decided to just shelve this coverage type for now.
Note also that it was a specific requirement that coverage types be well
defined so that coverage numbers be consistent across tools.
2. the main reason is that attributes have to be attached to declarations and
there is no declaration present for a number of the possible FSM types
(concatenation style, part-select style).
In addition, as attributes are attached to each declaration individually, the
use of attributes is quite inconvinient for specifiying the legitimate states
for the FSM. These issues were also raised at Friday's all-committees LRM
review and no satisfactory alternative was found, so for now pragmas stay.
3. Good point. Something like this should be considered for SV3.2+
4. No. Currently the assertion coverage "covers" only whether a particular
assertion occurred or not, but no other details.
Again, this is something that should be considered for SV3.2+
Joao
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
344 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
From: Adam Krolnik <krolnik@lsil.com>
To: sv-cc@server.eda.org
CC: sv-ac@server.eda.org
Subject: Re: [sv-ac] Assertion API from SV-CC
Good morning all;
Reading this and the latest Assertion/Coverage api docs, I would like
to ask a few things.
1. You define 4 types of coverage (statement, fsm, toggle, assertion) -
why not
include abilities for expression coverage. It is not generally useful
to
talk about statement coverage of assign statements... The definition
could
be somewhat left open to allow tools to make their own definition.
But having
a definition allows inclusion into a database and user control.
2. FSM recognition.
Why is the 'comment as pragma' style being specified for FSM
extraction? Why not
instead make use of attributes? Is the pragma really intented to
start with
'tool state_vector' and 'tool enum' ?
3. Why not define some other attributes to limit coverage (or delete) on
specific
elements? It would be good if a user had ability to define no
coverage for
events that will not occur (specific combination of signals, values,
etc.)
You could have (* cover_state_vector = "{a,b,c}" *) ...
4. If a coverage assertion checks for a set of elements, via:
cover $insetz(command, v1, v2, v3, v4, ...);
Would coverage be noted for values chosen? So that one could see
which particular
values are not seen?
Thanks.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Tue Mar 04 2003 - 08:32:20 PST