Subject: Re: Corrected SV-CC Meeting Minutes for 10-22-02
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Oct 30 2002 - 07:54:16 PST
John,
I was present last week and this week meetings.
Please update the attendance sheet.
Francoise
'
At 03:47 PM 10/29/2002 -0800, Amouroux, John wrote:
>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>mailto:johnny@model.com)]
>
This archive was generated by hypermail 2b28 : Wed Oct 30 2002 - 07:55:09 PST