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