Subject: Meeting minutes for the SV-CC Committee, 17-Dec-2002 (RESEND)
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Thu Dec 19 2002 - 16:43:20 PST
Resent with the attendance list included (as requested by Swapnajit)...
Swapnajit, did you have a look at the SV-EC rolling attendance list? I very much like this format ...
Also, I did (as Doug in his last two meeting minutes) only a 12 MEETINGS (not weeks) attendance list. I am not sure whether this is
correct, AFAIK the voting rules say ... FOR ALL MEETINGS ... But this is just a side note.
-Michael
Hi all,
here are the
Meeting minutes for the SV-CC Committee
December 17, 2002, 9:00-10:00am PST
Attendees:
Kevin Cameron (National)
Joao Geada (Synopsys)
Francoise Martinole (Cadence)
Swapnajit Mittra (SGI)
Michael Rohleder (Motorola)
John Stickley (Mentor)
Stuart Swan (Cadence )
Kurt Takara (0-in)
Doug Warmke Mentor
Rolling 12 Week Attendance List:
[xxx----------] Yatin Trivedi (ASIC Group)
[xx-x---------] Tarak Parikh (AT HDL)
[xxxx-xxxxxxxx] Francoise Martinole (Cadence)
[xxxx-x-xxxxxx] Stuart Swan (Cadence)
[xxxxxxxx-xxx-] John Amouroux (Mentor)
[x--xxx-------] Emerald Holzwarth (Mentor)
[xxxx-xxxxxxxx] John Stickley (Mentor)
[-----x-------] Duaine Pryor (Mentor)
[xxx-xxxxxxxxx] Doug Warmke (Mentor)
[xxxxxxxxx-xxx] Michael Rohleder (Motorola)
[xxx-xxxxxxxxx] Kevin Cameron (National Semi)
[-------------] Tayung Liu (Novas)
[xxxxxxxxxxx--] Bassam Tabbara (Novas)
[xxxxx-xxxxx-x] Swapnajit Mittra (SGI)
[-xx----------] Darryl Parham (Sun)
[-------------] Simon Davidmann (Synopsys)
[-------------] Peter Flake (Synopsys)
[xxxxxxxxxxxxx] Joao Geada (Synopsys)
[xxxxxxxxxxxx-] Ghassan Khoory (Synopsys)
[xxxxxxxxxxxx-] Andrzej Litwiniuk (Synopsys)
[xxx-x--------] Alain Reynaud (Tensilica)
[xxx--x-------] Mike McNamara (Verisity)
[----x-------x] Kurt Takara (0-in)
[-----x-------] Dave Rich (?)
[-----xxxxxx--] Joe Daniels (LRM Editor)
Logistics:
A) Joao proposed acceptance of minutes from last conference call, Kevin seconded.
B) Swapnajit indicated that he got email from the chairs of the other committees that their
face-to-face meeting is planned for 1-21
and 1-22 next year. As a result the best chance for our face-to-face would be 1-23; 1-24 would also
be possible, but 1-23 would be
preferable. Preferred location will be San Jose. Swapnajit will send out the invitation.
We spent most time of the technical with Kevin presenting his proposal:
a) Kevin explained the context structure in his proposal and the purpose of its fields.
b) He continued with the definition of a locator function, which will be in each library; benefit is
a reduced chance for clashes.
Joao: what will happen in case of clashes.
Kevin: This tries to avoid clashes
Francoise: module_spec is module name or instance?
Kevin: I think it will be module name, ...
Joao: where is the priority?
Swapnajit: I think this is in the middle of page 4
Joao: there are two possibilities for clashes:
- at locator function level: registering a register
- within a locator function
Michael: when is the locator function being called?
Kevin: This assumes C++; when the constructors are being called (before main).
Joao: How do you allow a compiler to select your locator method. Is this done with the static
attribute??? This will make static a
keyword. We have to be careful to properly distinguish attributes and keywords...
Kevin: You can still bind C functions here.
Doug: myBinder and the locator function are actually the same. Both are callbacks. Why don't we make
a call-forward function svBind?
Kevin: This will just permit a single invocation.
Joao: I am not convinced that here is a new capability in this proposal that can not be already done
by John's proposal.
Kevin: It can't, if there is just C. I am trying to solve National Semi problem we have when loading
C++ libraries.
Stuart: You can always get to C++ using C linking
Joao: I am afraid to make a special C++ thing that might just solve National's problems ...
Swapnajit requested to solve those discussions by email and to continue with the proposal
...
Doug: I think this is already possible with C linkage functions
Kevin: Scoping is a little bit different. Linker name specification is extended by library name. I
didn't go as far as Michael in
specifying what the library and the switches are for loading it. This can be left to the
implementor.
Joao: I think this is something to be put in the standard. The format for the string should be
exactly defined.
Kevin: Seamless uses something similar to clearly identify which function have to be loaded from
which library.
Michael: Don't see the need for the locator when having this capability. So is it really for
avoiding clashes or is it mostly needed
for other things like C++ loading.
Kevin: It also does name mangling; as such it overlaps with some of this functionality.
John: One thing we might want to do, is to change the terms attribute and keywords. This might be
confusing.
Kevin: It should be linker attributes, yes.
Joao: We should be consitent with other committees by defining "an attribute is something that an
implementation could validly
ignore without changing functionality for the user". So omitting an attribute would have some effect
but would not break code.
(some discussion of attribute vs. keyword continued. The agreement was that we have to be careful
with new keywords)
...
Kevin continued by describing his specification of queueable calls.
Joao: We have stayed away from exported tasks. There was not much consensus here ...
Kevin: You can safely delete this from this proposal, if this is a problem ...
Doug: We might want to clearly define that only void and non-void functions are supported.
Kevin: The queable call permits you to do things that are non-zero time.
John: You also can do this otherwise. This might be something we need to shelve this issue
altogether.
Kevin. We might want to remove this completely. I just think it is simple to implement.
Joao: You need to have a seperate thread.
Stuart: Reason is you have to have your own stack.
Kevin: SystemVerilog is definitely single-threaded in this proposal. When you call a queable task,
the C code will give you back a
handle to your task.
Swapnajit: let's take this to the email
Kevin: There are no special requirements for the simulator here
...
Last item covered by Kevin is the argument specification.
The corresponding attribute says it is a C type or a SV type. This has to be preceeded by the
exclamation mark.
Francoise: This needed to define the function name?
Kevin: yes needed for mangling
[Kevin made some statement about abstract vs. non-abstract paramters and the main differences to
Andrzejs proposal. I did not catch
all and most of it is stated in the proposal anyway...]
Kevin: for call-by reference you have to know what the structure layout is for C
input is passed by value only, the receiving funciton can scribble over it safely.
inout creates the canonical form of the data.
This is kind of similar to Andrzejs proposal. Return values use the standard C mechanisms.
...
Francoise: Let's assume an input argument which is a packed array. Do you pass it by value?
Kevin: Inputs are forced to be passed by value.
The type information should be sufficient to work out what the corresponding C type is.
The type information needs to include the sizes. This is needed to identify the corresponding
mangled name.
...
Swapnajit: Lets take further questions to the email.
--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 : Fri Dec 20 2002 - 01:37:10 PST