Subject: Coverage API requirements
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Fri Aug 16 2002 - 14:48:11 PDT
Coverage API Requirements:
"User side" API:
1- API should be similar for all coverages.
There are a wide number of coverage types available, with different sets offered by different vendors.
Therefore it is very desirable that the user-side coverage API use the same functions/mechanisms
to access any coverage.
2- support _at least_ the following coverages
2.1- line
2.2- toggle
2.3- fsm state
2.4- fsm transition
2.5- condition
3- set of coverages supported by the API must be able to be extended in a transparent
manner by vendors.
Intent is that if a user makes use of a vendor-specific coverage, the same code can
be linked and run against another vendor's tool (though, obviously no "interesting"
results will be obtained in this case)
4- Must have a means to provide "limiting coverage" number for
4.1- a specific instance
4.2- all instances of a specific module
4.3- a specific subhierarchy
4.4- all subtrees rooted on all instances of a module
NOTE: limiting coverage number == value of coverage representing 100% coverage.
See also point 5
5- Must have a means to provide current coverage number for
5.1- a specific instance
5.2- all instances of a specific module
5.3- a specific subhierarchy
5.4- all subtrees rooted on all instances of a module
Coverage number meaningful only with respect to the limiting coverage number
Justification for above approach: all coverage tools have different
technology and different understanding of basic coverage terms (at
least on a detailed level), so API has to be able to provide coverage
numbers to user in a consistent manner even though the actual numbers
themselves and even coverage types provided are likely to vary
significantly from vendor to vendor.
6- Must be able to control coverage
6.1- enable a specific coverage for
6.1.1- a specific instance
6.1.2- all instances of a module
6.1.3- a specific subtree
6.1.4- all subtrees rooted on all instances of a module
6.2- disable a specific coverage for
6.2.1 - 6.2.4 (same as 5.1.1 through 5.1.4)
Control results should include:
6.3- success
6.3- failure
6.4- this coverage not supported by this application
7- Must be able to query if a specific coverage is available for
7.1- a specific instance
7.2- all instances of a module
7.3- a specific subtree
7.4- all subtrees rooted on all instances of a module
Query results should include:
7.5- coverage is available on all instances
7.6- coverage is available on some instances
7.7- coverage is not available on any instance
7.8- coverage not supported by this application
"Application side" API:
extending the "user side" API with:
8- for a specific coverage & instance, means to obtain per "coverable item" information,
where number of coverable items == coverage limit for that coverage && instance
Note: all items "optional" ie a specific coverage may provide only some of these items
8.1 start & end line number (eg bounds of a block or statement)
8.2 descriptive string (eg fsm state name)
8.3 value (eg condition vector)
8.4 coverage state:
8.4.1 covered
8.4.2 not covered
8.4.3 ignored
8.4.4 illegal
8.5 attributes associated with this coverage
(free form "id = value" pairs?)
Again note that the intent is for the API to remain neutral wrt to the actual coverage
metric or technology being used.
9- mechanism to be able to force the coverage state for any specific item to be:
9.1 covered
9.2 not covered
9.3 ignored
9.4 illegal
==============================================================================
Joao Geada, PhD Sr. Staff R&D Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Fri Aug 16 2002 - 14:50:03 PDT