Subject: FW: SV-CC: Minutes
From: Vassilios.Gerousis@Infineon.Com
Date: Tue Jul 16 2002 - 20:32:45 PDT
-----Original Message-----
From: Joao Geada [mailto:Joao.Geada@synopsys.com]
Sent: Tuesday, July 16, 2002 5:18 PM
To: Vassilios.Gerousis@infineon.com; Kevin.Cameron@nsc.com;
stuart@cadence.com; simond@co-design.com; mac@verisity.com;
tarak@athdl.com; bassam@novas.com; Andrzej.Litwiniuk@synopsys.com;
Ghassan Khoory
Cc: Joao.Geada@synopsys.com
Subject: SV-CC: Minutes
NOTE: I'm sending the minutes directly to the email addresses I have for
the members of sv-cc, as currently there is an issue with the reflector that
is preventing me from using it to send any email.
Vassilios: would it be possible for you to forward this to the sv-cc list? Thanks.
SV-CC (07/12/2002)
Attendees:
[x] Ghassan Khoory (Synopsys, Co-Chair)
[x] Kevin Cameron (NSC)
[x] Simon Davidmann (Co-Design)
[x] Peter Flake (Co-Design)
[x] Joao Geada (Synopsys)
[x] Tayung Liu (Novas)
[x] Andrzej Litwiniuk (Synopsys)
[x] Mike McNamara (Verisity)
[x] Stuart Swan (Cadence)
Minutes:
(notes: meeting started 10 minutes late)
introductions all round
Ghassan read through the agenda and the goals assigned to this committee:
* to recommend a set of the following interfaces to System Verilog:
C/C++ API
Coverage API
Assertions API
Standard PLI additions as required by language extensions
Next meeting to occur on Tuesday 23, at 12pm EST (9am PST)
If there participants from Europe the meeting will be held one hour earlier.
Discussion then ensued, led by Stuart, over the prioritization of goals of
the committee: whether to focus the PLI/VPI improvements (aka tool's API)
vs to focus on the "direct C" API (aka user's API). Stuart expressed that
the VPI is already a part of Verilog, and thus is not an extension and
therefore
extending the VPI to System Verilog should be the primary objective.
[Joao editorial note: I think that, because VPI is part of Verilog, the
tasks of
creating the appropriate extensions to the VPI object model should belong
the the SV basic committee]
Concerns were also voiced over the feasability of reaching conclusions
on all the interfaces in the given time frame, particularly when the
necessary extensions to VPI to support the new features of SV are part
of the deliverables. All present agreed that this would not be
possible and we should focus on refining our goals and requirements
and communicate this up to the appropriate people/committees.
Stuart led a discussion as to whether a "direct C" interface qualifies
as an API or if instead it is a language extension that should be more
properly tackled by the SV-EC committee. Conclusion was reached that there
at best only minor language effects and that thus the "direct C" is an API
and is substantial to the commitee.
Question was asked whether we could continue to use the name "DirectC" as
this
may be owned by Synopsys.
After some discussion we all (unstated) appeared to agree to the following
requirements: goal of this committee is to define an interface from
System Verilog to foreign programming languages that, articulated by Mike:
* we will not attempt to solve all problems for all users/scenarios. Instead
the interface will satisfy the most common requirements issues.
(ie solve 85% of the problem, leave the remaining part for later revs)
* use of foreign functions in SV is transparent to the SV user
* foreign function writer need not know details of usage of the function in
SV
* object code created to run against one simulator should continue
to function correctly when linked against another simulator
(different rev of same vendor's simulator or different vendor's simulator)
as long as only the documented API/semantics are being followed.
[Mike also noted that this is true of the existing PLI/VPI interfaces]
Discussion about what types are to cross the foreign function API. The
question was that simple types are straightforward, but how would complex
types (structs, enums, unions) and pointers cross the boundary.
[Simon mentioned that, though not part of the current SV 3.0 proposal,
pointers
are very likely to be added soon to the SV 3.1 proposal]. There was no
specific agreement other than that this would be highly desirable, but that
for this to be possible there is a requirement that the SV 3.0
datastructures
definition be considerably tightned.
There was some discussion of what foreign languages to explicitly support.
The details were deferred but it was agreed that the objective was for the
specification to be neutral in that regard, leaving specific language
support to
the implemention. At least "C" must be supported. C++/Fortran also
mentioned.
[Editor: ie something like C++'s extern "lang" syntax]
Joao
==============================================================================
Joao Geada, PhD Sr. Staff R&D Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Tue Jul 16 2002 - 20:34:12 PDT