[sv-cc] SV-CC minutes Jan 14 2004


Subject: [sv-cc] SV-CC minutes Jan 14 2004
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Jan 14 2004 - 10:09:08 PST


SV-CC minutes Jan 14, 2004

NOTE: Special meeting to be convened 8am Monday Jan 19.
Ghassan to send out announcement.

Attendees:
    Michael
    Avinash
    Francoise
    Ralph
    Bassam
    Doug
    Swapnajit
    Joao
    Ghassan

Proposal to accept Monday's minutes: Abhinash
Seconded by: Bassam

Swapnajit overview
==================
Joao needs to go through editorial comments and make
sure all are handled. Will do so once out of the woods
with VPI stuff.

VPI data reader
==============
Bassam goes through email sent in response to Michael's
most recent comments. (http://www.eda.org/sv-cc/hm/1732.html)
- order of routines (assertion and covg need to be accounted for,
  Bassam to do). Bassam will follow the order established by
  existing VPI.
- sizeof() issue will be fixed up as per Michael's suggestion
- vpi_close() can be called in limited interactive mode, but the
  actual reader implementation may choose to ignore this call.

Francoise's suggestion to consolidate vpi_get_time().
Doug agrees with suggestion, Michael disagrees.
Joao agrees, too. Bassam will implement this suggestion.

Francoise also wants the vpi_goto() function to be simplified.
Wants to combine existing 1st and 3rd arguments (time_p structure).
After some more discussion, it turns out there are a couple of use
modes here. Some debate about in the case of "next, next, next..."
should the implementation populate the time_p argument with the
current time. Michael, Doug, Joao want this. Decision made that
if the time_p is NULL, implementation won't populate it with
current time. If non-null, implementation will populate it.

Swapnajit confirms that Bassam can produce final version today.

Francoise's remaining issue is that vpi_load_init() is
still present. We have vpi_load(), and we can create collections.
So why can't the implementation automatically initialize at
first use? The reason to still have vpi_load_init() is to
give a "hint" to the implementation that will allow it
to be more efficient.

Joao explains that for implementations which store data in
signal order rather than time order, then this would be ignored.
But for implementations that store in time order, this can be
a valuable guide to enable a single-pass of scanning through
the database, pulling out only the signals of interest.

Francoise is satisfied that both can be present, and no further
action is necessary. The document describes the difference
adequately.

VPI information model
=====================
Francoise requests that Bassam put on his assertion expertise
hat and give the assertions area of the spec a thorough
scrubbing by tomorrow.

Bassam's comments:
1. We can now compose properties, it shows up in draft 3.
   Joao will look over changes in draft3 and include.
2. assume and cover. Go into page 27 and become different
   property types. assume behaves very much like an assert.
3. expect goes into statements.

Michael requests that cross references to sections in "the standard"
name precisely which standard they are referring to. Joao agrees.

Francoise requests that for diagrams intended to replace diagrams
in the IEEE 1364 standard, we annotate the tables with this info,
and the cross-ref to the IEEE table. For new tables, indicate that
they are new. Michael wants to have a table summarizing all such
information as well. Joao to digest and incorporate these comments.

Doug's comments:
2: $unit is treated exactly as a package.
         Joao will add a flag to the package VPI #defines such that a user
         can tell a package ISA implicit package brought into existence
         via $unit.
10: Will try to incorporate tagged unions.
         Should fold into existing unions OK.
default: OK

Functional coverage - missing, but Joao will take a look.
Joao's hope is that it is close enough to constraints that
it might be do-able in time.

Doug suggests that Joao and co. look over SV-EC's website and
fish up any other late-arriving technology additions to the language.

Francoise:
foreach (vpi_get_value(), vpi_put_value(), vpi_register_cb(), new cb's,
existing cb's that need to handle new object categories):
Behavior needs to be clarified when new types of objects show up.

Cadence and Synopsys will have one more meeting tomorrow (Thurs)
to wrap this all up as best as possible.

Swapnajit: Make sure all changes into doc by Friday.
Swapnajit declares vote on VPI donation as of today (1/14/04).
Deadline for vote will be next Wednesday, 1/21.



This archive was generated by hypermail 2b28 : Wed Jan 14 2004 - 10:10:20 PST