Subject: Corrected SV-CC Meeting Minutes for 10-22-02
From: Amouroux, John (john_amouroux@mentorg.com)
Date: Tue Oct 29 2002 - 15:47:44 PST
Meeting minutes for the SV-CC Committee
October 22, 2002, 9:00-10:00am PST
Attendees:
Attendees:
[--xxxxxxx] Yatin Trivedi (ASIC Group, Chair)
[-----xxx-] Tarak Parikh (@HDL)
[--xx-xxx-] Francoise Martinole (Cadence)
[xxx--xxxx] Stuart Swan (Cadence)
[------xxx] John Amouroux (Mentor)
[------x--] Emerald Holzwarth (Mentor)
[-----xxxx] John Stickley (Mentor)
[------xxx] Doug Warmke (Mentor)
[--xx-xxxx] Michael Rohleder (Motorola)
[xxx-xxxxx] Kevin Cameron (National Semi)
[x--------] Tayung Liu (Novas)
[-xxxx-xxx] Bassam Tabbara (Novas)
[-----xxxx] Swapnajit Mittra (SGI)
[--x----xx] Darryl Parham (Sun)
[xxx-x----] Simon Davidmann (Synopsys)
[xx-xx----] Peter Flake (Synopsys)
[xxxxxxxxx] Joao Geada (Synopsys)
[xxx-xxxxx] Ghassan Khoory (Synopsys, Co-Chair)
[xxxxx-xxx] Andrzej Litwiniuk (Synopsys)
[---x-xxxx] Alain Reynaud (Tensilica)
[x-----xxx] Mike McNamara (Verisity)
Minutes:
General Issues:
o Last week's minutes were reviewed and approved unanimously.
o Yatin noted that he was happy to see more technical email discussions
occurring and encouraged more of the same.
o Swapnajit agreed to do an Excel spreadsheet of issues, and everyone
should be reviewing these when it is ready. [more on this later in
the minutes]
o Yatin explained why he delayed the coverage API vote, noting that the
email threads highlighted the uncertainties in the spec as well as
confusion with some of the definitions.
Coverage API:
o Joao explained that "line coverage" really means basic block coverage,
and that line coverage is really a term that makes the feature easier
to market.
o Michael noted that he is more interested in determining which blocks
got covered, which the proposed API does not currently address. Joao
said that the primary motivation for the current API was to provide
feedback to reactive test benches to direct further input. Joao said
that the API is easily extensible for other purposes, and that Synopsys
hadn't done this yet simply because these extensions have not yet been
requested by their customers.
o Michael thought that the FSM definition was limited, but Joao noted that
the state could be an expression and was not limited to a single value.
The state, in the complex case, would be produced by concatenation.
Concern was also expressed over whether or not the state could contain
more than just one's and zero's. Joao replied that X's are also
supported.
o <ring> <ring> <ring> ... [The meeting was interrupted due to an annoying
ringing on one of the lines.]
o Joao mentioned that in their product, the compiler sets up which areas
of the design can be monitored with the coverage API. At run time the
only control is over whether or not these pre-selected areas are enabled
or disabled for coverage monitoring. This is implementation-specific and
likely the most efficient implementation, but this should not be defined
in the spec. Joao said that he would clarify this. Michael also pointed
out that "user expressions" should be clarified as well.
o Joao asked if the committee would also like Synopsys to donate their
specifications for the pragmas and configuration file format for the
coverage API. The pragmas help define how/which FSM's will be covered via
source code adornment, and the configuration file, which is output from
the compile phase, gives the information on which constructs have been
enabled for coverage by the compiler for use during run time. Doug and
Michael both thought that this would be good.
o Again the discussion of how the Coverage API should be extended came up.
Doug noted that besides handling FSM's, it should also handle assertion,
statement, and path coverage. Joao noted that these others are
interesting,
but their customers had not asked for them yet. But he reiterated that
the
coverage API spec was written to allow for just such extensions.
o Yatin then asked the big question, should the Coverage API be extended,
and
should Synopsys do this before it is accepted by the committee? While
there was much discussion here and reservations expressed about accepting
a donation that still needed some clarifications, Yatin finally proposed
that the committee vote on the specification as is, and this was
acceptable
to the committee. So Yatin will conduct an email vote on this spec's
acceptance. He will send out an email and the voting will conclude by
this Friday, 10/25.
Issue List Handling:
o Swapnajit has generously volunteered his time to maintain the Issue List.
He will be doing this manually because he does not have the time to put
efforts into automating this. But if anyone had ideas about this he would
love to hear them.
o Swapnajit will handle these as Web pages instead of an Excel spreadsheet
as he originally proposed, and these pages will be made available on the
sv-cc web site by Yatin. Swapnajit will send out/post rules for the
site, and gave some guidelines.
- he should be explicitly cc'd on any issue email
- the subject of the email should contain the keyword "ISSUE:",
and the category of issue, namely "DIRECTC", "ASSERTION", or
"COVERAGE".
- the subject should also have a good, concise summary phrase for the
issue
- only one issue should be raised in a single email
- Swapnajit will assign issue numbers for tracking ease
Final notes:
o A final roll call was taken.
o Yatin confirmed that we will be having a face-to-face meeting on
November 7th in the San Jose area . Mike will be arranging the venue.
[These minutes were taken by John Amouroux. Please email me any necessary
corrections. (mailto:johnny@model.com)]
This archive was generated by hypermail 2b28 : Tue Oct 29 2002 - 15:48:10 PST