Subject: Re: [sv-cc] Meeting minutes for Feb 5, 2003
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Thu Feb 06 2003 - 04:38:08 PST
Hi John,
very much thanks for taking the minutes. Some additions/corrections.
-Michael
"Amouroux, John" wrote:
> SV-CC Meeting Minutes, for Feb. 5, 2003:
>
> 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 already fine by Michael (w.r.t. registration of functions)
VPI is providing some builtin (defined by IEEE1364) registration function. So it is fine by the standard, not by me. I am not
important enough to make these kind of decisions :-). I further said that we still need to have a bootstrap function for VPI that
can call these registration functions, to avoid the problems Joao mentioned later.
> PLI has two methods -
> a) textual form (tab) - vcs
> b) function registration - modelsim & nc
+ xl (similar to nc)
> Michael proposes that we register via a bootstrap files and ??? [I missed
> this - JA].
also 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. The 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.
> There is no 100% reliable way to turn .a files into .so files. So we still
> need both registration methods.
This is a little bit out of context, since the discussions were around pli.tab vs. registration functions and how this relates to
the shared libraries.
> Francoise notes that when providing a library of models, a bootstrap
> capability must be provided to reference this library.
Francoise comment was that this bootstrap function must be part of the library. The discussion around this was rather good, my
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 is concerned about extending all this into the VPI/PLI side. He thinks
> this conceivably could impact optimizations.
We both were concerned. But my understanding is that we are not concerned about the goal (I originally was also concerned whether we
_can_ do sthg. like this -- there are sometimes rather interesting differences), but more about the timeline. Also there is the
chance that any definition here could result in disruptive changes, so we better evaluate this upfront. That was the reason why I
brought it up this way.
> Michael understands, and is just wondering if this is a worthy goal. In other words, should we even consider solving this 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.
I further have asked to receive feedback about the rest of the document (intro, part1+2) soon, so we can close it.
> 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
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 04:38:42 PST