Meeting minutes for the SV-CC Committee

October 22, 2002, 9:00-10: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) 
    Mike McNamara        (Verisity) 
    Alain Raynaud        (Tensilica) 
    

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 removed.

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 gaves 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)]