Subject: Meeting minutes for the SV-CC Committee, Nov 20th, DRAFT
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Nov 20 2002 - 11:18:04 PST
Hi all,
here are the draft meeting minutes. Please send any corrections/additions to me to revise. My apologies, when I did not properly identify everybody. I sometimes had real problems to find out who was speaking...
-Michael
Meeting minutes for the SV-CC Committee
November 20, 2002, 9:00-10:00am PST
Attendees:
John Amouroux (Mentor)
Kevin Cameron (National Semi)
Joe Daniels (self-employed)
Joao Geada (Synopsys)
Ghassan Khoory (Synopsys)
Andrzej Litwiniuk (Synopsys)
Francoise Martinole (Cadence)
Swapanjit Mittra (SGI)
Michael Rohleder (Motorola)
John Stickley (Mentor)
Stuart Swan (Cadence)
Bassam Tabbara (Novas)
Doug Warmke (Mentor)
Rolling attendance list will be generated by Swapanjit, since attendance from the previous meetings was not yet updated before the last meeting minutes. I hope this is the best way to avoid confusion.
A) Swapanjit informed the DWG that Joe Daniels has been appointed as LRM editor for this DWG. He is working with him and Ghassan to hand over this work.
B) Swapanjit reminded the DWG that Nov, 26 is last date for accepting issue filings
[Clarification request from Michael:
Is this deadline only related to issues about DirectC or also for issue w.r.t. the other interfaces (assertion, coverage)?]
C) Swapanjit asked for acceptance of the previous meeting minutes:
- Andrzej proposed to accept the minutes of the face-to-face meeting at Nov, 7; Joao seconded
- Michael proposed to accept the minutes from Nov, 12, John S seconded
- ??? proposed to accept the minutes from Nov, 19, Andrzej seconded
D) Swapanjit clarified his correction to the Meeting Minutes from yesterday (Item 9 not yet forwarded to the bc-cc), also the rolling attendance from previous meeting needs to be adjusted in the minutes. The rolling attendance from the Nov, 19 did not yet
show the attendance from Nov 7 and Nov 12.
E) The only technical topic of this call was - due to the limited time - to revisit the remaining 5 of Andrzej's 17 items that were not resolved during 11/07 face-to-face meeting. Item 0 to 12 can be found in the meeting minutes from the previous call.
This one starts with item 13:
13a) Agreed by all attending persons
13b)
Francoise: You say that the implementation of vectors is implementation dependent, and irrellevant for SV side.
Joao,Andrzej: Yes, as soon as you describe the C side, this of course matters and needs to be defined
John: When you say the layout is the same, do you say the memory ordering is the same?
Joao: Yes
Kevin: An example would be very useful ...
Michael requested to clarify that this is proposal is not covering the C side
Joao: This is in the third sentence of the Observation header.
Swapanjit: Andrzej, could we add this to the document?
Agreed by all attending persons,
under the condition that it is clearly stated in the observation that this proposal is not covering the C side.
14)
Francoise: Could you clarify, what is not permitted?
Andrzej: There is no intention to exclude something, just enumerate everything for clarity
Michael: Need to crosscheck whether there is something missing, difference between packed and unpacked vector?
Andrzej: Unpacked vectors are arrays ...
Kevin: Can a struct contain a reference or an array?
Andrzej: Yes
Comment from Doug:
Would you agree to modify this when we find out a problem when looking from the C side?
Michael proposed: accepted, revisit after looking from the C side
Proposal was agreed by all attending persons
15)
Andrzej: This item did not reach concensus, item is removed
Michael: Is this not a pure C problem?
Joao: Another good reason to remove it
Doug: Let's throw it out
Agreed by all attending persons to remove this item
16)
Andrzej.: Stated that this concept is similar/(equal?) to the DirectC solution
Francoise: Does this mean I have to write a different function for every vector size ?
Joao: No, it exactly tries to avoid this
Francoise: ...
Kevin: This means since on the C side there is only one bound free, I have to pass by reference
Joao: No, this types are not simply compared to C
Michael: What about multiple dimensions? Is there no need to at least match the number of dimensions?
Joao: Yes
Kevin: why dont' we just say everthing from SV can be passed and handle this stuff on the C side?
No agreement was reached on this topic.
Kevin did not want to accept this. It s not clear whether this can be implemented (Joao, it is in VCS...) or will be properly/efficiently done.
Swapanjit asked for voting on this issue and continue with the meeting.
Michael asked for adding a statement that the amount of dimensions must match.
Agreed by all attending persons.
17)
Kevin: Why do we have this restrictions?
Andrzej: We can not pass vectors of different sizes, there are good technical reasons ...
Kevin: I dont see why we cannot return structs
Francoise: ... <sorry, I missed this>
Michael: Although I would like to have the full SV data types also be able to returned, I understand that there are good reasons for doing this. This would require to define how to return data on the C side, which influences SV?
Kevin: We already agreed on the layout, so I do not see any problem here. You can always pass the vector to a struct.
Joe Daniels: Keep the proposal as it stands
Kevin: This is just inconsistent with C
Michael proposed to agree on the proposal as it stands, but revisit this after looking at it from the C side.
Agreed by all attending persons
F) Swapanjit will send out the rolling attendance list and extract the members eglible for voting.
G) Swapanjit proposed to vote also on Kevin's and Johns proposal (Is this correct, I thought it is from Joao and John S. ??? Or do I think about a different proposal here?) Francoise, Andrzej and Joao requested some more time to read it, think about it and
discuss it in the next call. Agreed.
Action Item for Swapanjit to create the rolling attendance list and send voting information
Action Item for Doug to clarify whether MGC can host the next face-to-face meeting.
This archive was generated by hypermail 2b28 : Wed Nov 20 2002 - 11:18:55 PST