SV-CC Meeting Minutes - 10-29-02


Subject: SV-CC Meeting Minutes - 10-29-02
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Oct 29 2002 - 15:18:14 PST


Attendees:

Ghassan Khoory (Synopsys)
Swapanjit Mitra (SGI)
Andrzej Litwiniuk (Synopsys)
Johnny Amouroux (MTI)
Emerald Holswarth(MTI)
Stuart Swan (Cadence)
Michael Rohleder (Motorola)
Tarak Parikh (@HDL)
Bassam Tabbara (Novas)
Joao Gaeda (Synopsys)
Francoise Martinole (Cadence)
John Stickley (Mentor)

1. Review and approval of last week's meeting minutes.

2. Vote on coverage API completed - was accepted 4 votes for, 2 abstain.

3. Face-to-face meeting confirmed for Nov. 7th. Tentatively planned to
    be held at Synopsys's Mtn. View offices.

* ACTION: Swapnajit to confirm.

4. Discussions surrounding issue of whether function calls should
support
    0-time only or allow time consumption.

* This issue was discussed at length by e-mail earlier in the
week.

        Some favor coming up with a way of modeling time consuming tasks

on the C side and allowing time consuming HDL tasks to be called
from the C side. Others prefer to restrict calls and tasks to 0-time
semantics.
* Joao suggested that at least for functions, since Verilog and SV
require

        0-time, let's nail down the interface for 0-time function calls
in both
directions and defer the issue of time consuming task support until
later.
* Stuart felt that support for time consumption in calls needs to
be worked

        out up front before we continue to far down the road with the
specification
process for functions only.
* John S. favors requiring 0-time semantics for HDL-to-C or
C-to-HDL

        function calls and for C-to-HDL task calls either restricting to
0-time semantics
or allowing HDL tasks to consume time but not have the API itself
worry about preventing or allowing time consumption. As far as allowing
for
time consumption on the C side, the API itself should not try to define
a "task"
structure per se, but rather let the C environment such as SystemC
handle it and
only consider function calls as 0-time synchronization points among time

consuming tasks or processes of the native language environment (C or
SV).
* Joao stated that he would like to make it a goal of next week's
phone conf.

        and face-to-face meetings to get closure on this issue.
* Andrzej Litwiniuk also made some proposals regarding time
consumption

        in is proposal sent out shortly before the meeting.

5. Discussions about context sensitivity function call handling proposal
from John S.

* John S. reiterated that this proposal did not change the syntax
or HDL-to-C

        call syntax and argument handling proposed in the DirectC
donation other
than to provide additional support for a context pointer that can bind
calls
to specific C models.
* Joao commented that this might also be an elegant way of solving
the "C task"

        dilemma by allowing model context pointers to refer to specific
model objects
or time consuming threads on the C side.
* This proposal also tried to suggest a "mirror syntax" for the
C-to-HDL

        direction that was modeled after the HDL-to-C direction already
in the
DirectC donation document. Context handling for the C-to-HDL direction
was also proposed.
* ACTION: Ghassan asked John S. to coordinate with Joao and Stuart
to
formalize the proposal for next week's face-to-face meeting.

6. Discussion about function name resolution and function override.

* I missed some of the gist of this topic but I gathered that it
was being

        suggested that we have some sort of function configuration
capability
whereby a function caller can bind through a configuration mechanism
to a function callee.
* Swapnajit also suggested that functions in local scope on the
HDL side

        always override HDL functions of the same name in outer HDL
scopes
or C functions of the same name being called on the C side.
* More discussions need to occur to formalize these requirements.

7. Touched on Andrzej Litwiniuk's proposal sent shortly before the
meeting.

* ACTION: Committee members should review this proposal and send
feedback

        by next week's meeting.

Please forward any corrections or omissions to the e-mail address below.

-- johnS
                                                           __
                       ______ | \
______________________/ \__ / \
                                \ H Dome ___/ |
John Stickley E | a __ ___/ / \____
Principal Engineer l | l | \ /
Verification Solutions Group | f | \/ ____
Mentor Graphics Corp. - MED C \ -- / /
17 E. Cedar Place a \ __/ / /
Ramsey, NJ 07446 p | / ___/
                                 | / /
mailto:John_Stickley@mentor.com <mailto:John_Stickley@mentor.com> \
/
Phone: (201)818-2585 \ /
                                   ---------



This archive was generated by hypermail 2b28 : Tue Oct 29 2002 - 15:22:53 PST