Subject: SV-CC Meeting Minutes 10/15/02
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Oct 15 2002 - 15:29:28 PDT
SV-CC meeting minutes
October 15, 2002
9:00am PST
Attendees:
Yatin Trivedi (ASIC group)
Joao Geada (Synopsys)
Ghassan Khoory (Synopsys)
Andrzej Litwiniuk (Synopsys)
John Stickley (Mentor)
Doug Warmke (MTI)
Johnny Amouroux (MTI)
Kevin Cameron (National Semi)
Swapnajit Mittra (Vineyard Research)
Bassam Tabbara (Novas)
Darryl Parham (Sun)
Michael Rohleder (Motorola)
Stuart Swan (Cadence)
Francoise Martinole (Cadence)
Mike McNamara (Verisity)
Alain Raynaud (Tensilica)
Tarak Parikh (@HDL)
Yatin encourages everyone to communicate more via email.
He feels there isn't enough work being done to further
our contributions to the LRM.
Discussion of face-to-face meeting in November.
Yatin proposes Thursday, Nov 7.
(Monday Nov 11 could be a backup date in case
too many people can't make it Nov 7.)
Yatin would like lots of technical progress before Nov 7
so that we can be very productive during the meeting.
Discussion of meeting durations:
Rather than biweekly 2 hour meetings, we will have a
1 hour meeting every Tuesday. The new weekly schedule
will start next Tuesday, 10/22.
Swapnajit suggests keeping a bug-tracking system
to keep track of the issues that people bring up.
Swapnajit can maintain the system. Yatin will forward
Swapnajit's email which proposes the system.
*** Minutes from Oct 1 meeting ***
Joao proposes that minutes of Oct 1 meeting be accepted.
Michael seconds, unanimous approval.
*** Presentation of Coverage API ***
Joao presents off the slide set.
Two components of the API:
1) First is for use by designers/engineers
2) Second is for use by tool developers
Some TB's, methodologies require runtime access to coverage data.
Interest is to know how coverage is improving with simulation time.
(Especially for reactive testbenches)
3rd party tools would like to be able to display coverage info
just as well as the built-in simulator features. Need a good
API to achieve that goal.
The coverage donation was described as follows:
There is a set of enums used in the API.
There are 3 tasks:
1) Control task (turn on, turn off, query availability of coverage)
2) Acquisition task (obtains metrics for certain design regions)
3) Limiting task (obtains available limits for certain design regions)
Tasks 2 and 3 can be used to derive a coverage percentage.
The API is neutral as per meaning of the numbers returned
by the tasks.
The tasks operate on all kinds of coverage metrics
(assertion, path, toggle, line, state, etc.)
All tasks have some kind of design region control.
Module-based, instance-based, all instances of module foo, etc.
There is also an API available to help gather/control coverage
for C-based testbenches. Joao terms this the "user coverage API".
There is a further part of the API intended for 3rd party tools.
It provides more detailed access to coverage. The spec only
deals with FSM coverage at the moment. The API is used to
gather the state vector for each FSM, along with other
FSM-specific data.
Discussion about usefulness of coverage if different tools
produce different numbers regarding coverage. Currently there
are no standards for measuring coverage. Joao makes the point
that the API presented here remains neutral on this topic.
Two ways of generating FSM vectors are 1) heuristics-based
and 2) manual user-entry based.
Discussion about "should SV-CC" be the one to standardize
the technical details of coverage?" No strong enthusiasm
shown about taking this on.
Joao states: The API does not control what coverage does.
It is just a mechanism for accessing what is done by
the coverage tool built into the SV simulator.
The point was made that the current FSM definition in
the Synopsys donation may be slightly limiting. Right now
it is a set of states and transitions. It could be extended
to be more general. [Editor's note: sorry, I couldn't
understand if any specific suggestions were made in this
regard - please email those if you have them.]
The suggestion was made to allow the API to give input into
the tool to help influence the coverage numbers. For example,
"consider these regions totally covered for path coverage".
Discussion about limits. i.e. what does 100% coverage mean?
Limits are defined by the coverage tool, but are static numbers
based on properties of the design. Once again, there are no
standards in this area - each tool will define its own limits
for each type of coverage data.
***
Currently Synopsys is not changing the coverage API and
has no plans to do so except for incorporating feedback
from SV-CC.
Synopsys is amending the assertions API to incorporate
more debug features (as explained previously).
***
Deadline for acceptance vote on coverage API is Friday 10/18.
Yatin will be corresponding with us on this topic.
***
Yatin sez:
Next week's meeting will address the issues that have
been brought up in regards to each donation. Start
with DirectC, then move to assertions, then coverage.
Hopefully most issues will be addressed via email.
The meeting can be used for voting and tie-up discussion.
***
These meeting minutes were taken and edited by
Doug Warmke of MTI, 10/15/02. Please email me if I
made any notable errors and I can resend the minutes.
This archive was generated by hypermail 2b28 : Tue Oct 15 2002 - 15:33:22 PDT