Subject: Re: SV-CC Meeting Minutes - 10-29-02
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Oct 30 2002 - 10:03:56 PST
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 119
> From: "Stickley, John" <john_stickley@mentorg.com>
...
>
> 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.
Can we table a discussion on using C++ style linking and using virtual
functions for that meeting?
I think using the object-oriented techniques that are already available
in C++ will save the committee a lot of effort.
Maybe discuss LWPs/SystemC too?
Regards,
Kev.
PS: Sorry I missed the call - was at the Verify2002 event in San Jose.
> * 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 allowingfor
> 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 \ /
> ---------
----------
X-Sun-Data-Type: html
X-Sun-Content-Length: 7592
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 157
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Attendees:
<p>Ghassan Khoory (Synopsys)
<br>Swapanjit Mitra (SGI)
<br>Andrzej Litwiniuk (Synopsys)
<br>Johnny Amouroux (MTI)
<br>Emerald Holswarth(MTI)
<br>Stuart Swan (Cadence)
<br>Michael Rohleder (Motorola)
<br>Tarak Parikh (@HDL)
<br>Bassam Tabbara (Novas)
<br>Joao Gaeda (Synopsys)
<br>Francoise Martinole (Cadence)
<br>John Stickley (Mentor)
<p>1. Review and approval of last week's meeting minutes.
<p>2. Vote on coverage API completed - was accepted 4 votes for, 2 abstain.
<p>3. Face-to-face meeting confirmed for Nov. 7th. Tentatively planned
to
<br> be held at Synopsys's Mtn. View offices.
<ul>
<li>
<b>ACTION</b>: Swapnajit to confirm.</li>
</ul>
4. Discussions surrounding issue of whether function calls should support
<br> 0-time only or allow time consumption.
<ul>
<li>
This issue was discussed at length by e-mail earlier in the week.</li>
<br>Some favor coming up with a way of modeling time consuming tasks
<br>on the C side and allowing time consuming HDL tasks to be called
<br>from the C side. Others prefer to restrict calls and tasks to 0-time
<br>semantics.
<li>
Joao suggested that at least for functions, since Verilog and SV require</li>
<br>0-time, let's nail down the interface for 0-time function calls in
both
<br>directions and defer the issue of time consuming task support until
later.
<li>
Stuart felt that support for time consumption in calls needs to be worked</li>
<br>out up front before we continue to far down the road with the specification
<br>process for functions only.
<li>
John S. favors requiring 0-time semantics for HDL-to-C or C-to-HDL</li>
<br>function calls and for C-to-HDL task calls either restricting to 0-time
semantics
<br>or allowing HDL tasks to consume time but not have the API itself
<br>worry about preventing or allowing time consumption. As far as allowing
for
<br>time consumption on the C side, the API itself should not try to define
a "task"
<br>structure per se, but rather let the C environment such as SystemC
handle it and
<br>only consider function calls as 0-time synchronization points among
time
<br>consuming tasks or processes of the native language environment (C
or SV).
<li>
Joao stated that he would like to make it a goal of next week's phone conf.</li>
<br>and face-to-face meetings to get closure on this issue.
<li>
Andrzej Litwiniuk also made some proposals regarding time consumption</li>
<br>in is proposal sent out shortly before the meeting.</ul>
5. Discussions about context sensitivity function call handling proposal
from John S.
<ul>
<li>
John S. reiterated that this proposal did not change the syntax or HDL-to-C</li>
<br>call syntax and argument handling proposed in the DirectC donation
other
<br>than to provide additional support for a context pointer that can bind
calls
<br>to specific C models.
<li>
Joao commented that this might also be an elegant way of solving the "C
task"</li>
<br>dilemma by allowing model context pointers to refer to specific model
objects
<br>or time consuming threads on the C side.
<li>
This proposal also tried to suggest a "mirror syntax" for the C-to-HDL</li>
<br>direction that was modeled after the HDL-to-C direction already in
the
<br>DirectC donation document. Context handling for the C-to-HDL direction
<br>was also proposed.
<li>
<b>ACTION</b>: Ghassan asked John S. to coordinate with Joao and Stuart
to<br>
formalize the proposal for next week's face-to-face meeting.</li>
</ul>
6. Discussion about function name resolution and function override.
<ul>
<li>
I missed some of the gist of this topic but I gathered that it was being</li>
<br>suggested that we have some sort of function configuration capability
<br>whereby a function caller can bind through a configuration mechanism
<br>to a function callee.
<li>
Swapnajit also suggested that functions in local scope on the HDL side</li>
<br>always override HDL functions of the same name in outer HDL scopes
<br>or C functions of the same name being called on the C side.
<li>
More discussions need to occur to formalize these requirements.</li>
</ul>
7. Touched on Andrzej Litwiniuk's proposal sent shortly before the meeting.
<ul>
<li>
<b>ACTION</b>: Committee members should review this proposal and send feedback</li>
<br>by next week's meeting.</ul>
Please forward any corrections or omissions to the e-mail address below.
<p>-- johnS
<br> <tt>
__</tt>
<br><tt>
______
| \</tt>
<br><tt>______________________/ \__
/ \</tt>
<br><tt>
\ H Dome
___/ |</tt>
<br><tt>John Stickley
E | a __ ___/
/ \____</tt>
<br><tt>Principal Engineer
l | l | \ /</tt>
<br><tt>Verification Solutions Group |
f | \/ ____</tt>
<br><tt>Mentor Graphics Corp. - MED C \
-- / /</tt>
<br><tt>17 E. Cedar Place
a \ __/ /
/</tt>
<br><tt>Ramsey, NJ 07446
p | /
___/</tt>
<br><tt>
| / /</tt>
<br><tt><a href="mailto:John_Stickley@mentor.com">mailto:John_Stickley@mentor.com</a>
\ /</tt>
<br><tt>Phone: (201)818-2585
\ /</tt>
<br><tt>
---------</tt></html>
This archive was generated by hypermail 2b28 : Wed Oct 30 2002 - 10:04:34 PST