Subject: [sv-cc] Meeting minutes for Feb 5, 2003 - amended
From: Amouroux, John (john_amouroux@mentorg.com)
Date: Thu Feb 06 2003 - 18:03:13 PST
SV-CC Meeting Minutes, for Feb. 5, 2003:
[Amended with Michael's comments on 2/6/02 - JA]
Agenda:
o Regular procedural work [Swapnajit, 5 min]
o Follow up on Issue 1.9 doc. [Michael, 20 min]
o Coverage API doc modifications [Joao, 10 minutes]
General:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Meeting minutes from 2/4 proposed and seconded by John A. and Bassam.
Follow-up on issue 1.9 - Michael::::::::::::::::::::::::::::::::::::
Michael has sent out his updates. He has removed the environment variables,
added the intention of the doc, and use cases. Switch names are now just
recommended, not mandatory. Added current working directory by default, and
only shared objects instead of archives (.a files).
Joao still wants to support archives. Francoise says that the specification
only lists the minimum support. Michael will check to ensure that this is
properly worded.
Michael also added a recommendation on how unresolved symbols are handled.
Also added a part 3 - and has some questions:
o Is the intro ok?
o Do we want to continue with part 2 - source code? And how
about automatic header generation and inclusion?
o Is part 3 something we really want?
Still open is the inclusion of .o files since .a files are not required.
Joao says we should just note that .o file support is not required, but can
be supported by vendors. This mirrors the decision we made above on .a
files.
Kevin proposes a "logical" naming scheme for referencing/mapping in the real
object files. Joao thinks that we are still too unsure about this to make
it a standard. He suggests that we see how things go and consider this in
3.2. (This concern was started by Andrzej via email.)
Back to part 3...
VPI is providing some builtin (defined by IEEE1364) registration function.
Michael further says that we still need to have a bootstrap function for VPI
that can call these registration functions, to avoid the problems Joao
mentions later.
PLI has two methods -
a) textual form (tab) - vcs
b) function registration - modelsim & nc (&xl)
Michael proposes that we register via a bootstrap files as well as a PLI
specific registration function. But this will return a structure containing
the registration information, similar to the content of the bootstrap file.
There are no registration functions defined for PLI like it is the case for
VPI (at least not for all simulators...). Basically the bootstrap file is
the VCS pli.tab file and the registration structure is the veriuser_tf
structure.
Joao says that the problem with the other registration method is that since
the global namespace is used, name clashes are possible. Michael proposes
his dual sv_register/tab file scheme to solve this, as it still gives
everyone choices.
The name clashes are avoided by being able to specify a bootstrap function
for VPI. This dual scheme is for PLI, not for VPI. It has
different reasons, as noted below.
There were some more concerns from Joao about the extensions to the pli.tab
Synopsys did (it contains some usage/performance hints).
These are not available for other simulators would also be hard to mirror in
some registration function scheme ... This is the
reason why I said both methods are good and useful.
Francoise notes that when providing a library of models, a bootstrap
capability must be provided to reference this library. Her comment was that
this bootstrap function must be part of the library. The discussion around
this was rather good. Michael's understanding was and is still that this is
solely due to performance reasons (don't need to search all libraries), but
also helps to avoid naming conflicts.
Joao and Michael are concerned about extending all this into the VPI/PLI
side. Joao thinks this conceivably could impact some optimizations. All
agree that the goal is worthy; it's more a matter of timing and disrupting
things currently supported or in progress. In other words, should we
consider solving this now, in the 3.2 timeframe or ever.
Kevin asks if Synopsys can donate their tab format for 3.2. The group
consensus is that this (part 3) should be proposed for 3.2, postponing it
for now. Swapnajit needs to move this to the 3.2 issues list. Michael
still wants feedback on part 1 and 2 soon so he can finish up his work.
Coverage API doc modifications - Joao::::::::::::::::::::::::::::::::
Joao sent this doc out yesterday; it has very few changes since the last
revision. He added Michael's overflow comment, and edited a relation
diagram. He requests that everyone read it and send out comments.
Swapnajit is sending out the poll announcement today for Friday's poll on
this.
Joe notes that he will start sending out some docs for review next week.
Misc:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Swapnajit proposes that we poll on Joao's string email by Friday as well.
The meeting concludes and roll call is taken.
Attendees::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Francoise Martinole
John Amouroux
Doug Warmke
Michael Rohleder
Kevin Cameron
Bassam Tabbara
Swapnajit Mittra
Joao Geada
Ghassan Khoory
Andrzej Litwiniuk
Joe Daniels
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 18:03:41 PST