Subject: [sv-cc] Minutes from SV-CC conference call 25-Mar-2003
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Mar 25 2003 - 09:59:41 PST
Hi all,
here are the minutes from todays conf. call. I am sorry, if I missed something; it is surely my fault.
Attendance:
Swapnajit Mittra
Doug Warmke
John Stickley
Francoise
Andrzej Litwiniuk
Ghassan Khoori
Bassam Tabbare
Joao Gaeda
Michael Rohleder
John Amouroux
Kevin Cameron
* Approval of minutes from last conference call:
Adjorned for latter approval
* Procedural items
- SV-EC indicated that they accept every proposal we will provide; there is currently no problem with our proposal
- Karen Pieper indicated that there will be most likely no feedback; Swapnajit requested that there will be feedback until tomorrow.
Currently we have not yet closed the loop on this.
- Handing over LRM to Stu on Friday; Friday will be the final deadline.
- Draft 4 will be available at 1st April, review period is 2 weeks
- There will also be some cross-committee checking, we have to check SV-AC and they will check ours
- Draft 5 will be out for final review only one week
- Final voting would be an Accellera approved vote
* SV-CC LRM work
- Joao will send out Draft 7 today
- Swapnajit requested some deadline after
* Technical problems
a) UserContext Handling
- John S. had some call will Francoise. There is some problem or better awkwardness that we have to pre-allocate ID's on a per
function basis, John
- Joao indicated that the original proposal had a single argument. You anyway need hashing; John S denies this. Andrzej and Joao
said you have to do some indexing. They believe that there will be very few instances that need that functionality. John wants to
have an integer instead of a string. He believes there would be the need for static storage. Francoise said that there should be an
unique ID provided by the application. Michael is still confused about the actual selection of the scope: declarative scope, module
scope or function call scope.
Swapnajit asked John S. to clean up the proposal and send it to the team. John S. wants to update Francoise' proposal.
Francoise asked what is the usage of the scope handle.
b) Scope visible by exported functions
Doug has an issue that we have overdid the visibility of exported functions. The export function must be declared in the scope
defined by this function, not in an enclosing scope. Joao agrees with Doug. The result will be pretty ugly, the application might
need to handle those scoping specially.
Agreement is to permit an exported function only to be called, if it is in the same context, not in the enclosing context. Joao will
check with the proposal provided to D. Smith, will contact him. No upward possibility.
c) Popping context
Proposal is to return the previous context when setting a new context. Joao indicated that we had this before. Michael believed that
this might be some overhead. John S. believes that there is very few overhead, it is more for convinience.
Francoise is concerned about handling of Save/Restore, John/Doug/Joao would like to leave this with the vendors. Doug said that DPI
needs to use PLI/VPI to get control for this; as such it is not self-contained. Francoise requested that we state this clearly, that
we are relying on PLI/VPI for this kind of implementation.
John asked Swapnajit that we carry this forward to 3.2, and just state that it is implementation dependent.
Accepted unanonymous.
Also accepted that we change the set scope functions to return the previous scope.
John also indicated that svScopeFullName should have a return type; should be const char*
Some confusion about where is the current list of functions. It is page 41 on the last document sent out (8.8.3)
d) Unnamed function arguments are supported
Doug indicated that originally we found out that unnamed function arguments are supported by SV in function prototypes, but he
believes we do not really support prototypes. Andrzej said they rather prototypes than declarations, the definition is elsewhere (in
the C side). Doug believes they are still used instead of declarations, and as such they should be treated as such. Andrzej believes
the current restrictions are sufficient and are compliant with other SV language; this will keep the BNF short. Joao and John S.
agree mostly.
Doug states, if there are no real concerns by other people he will have not a real problem with them.
Francoise thinks this is fine.
e) Misc
. svGetCallerInfo(): are there not some similar concerns with this function. Joao indicated that there are several preconditions
before this function is available and encountered them (I didn't grabbed this, sorry).
. Michael has been requested to carefully review 8.8.3.
. We need to make sure to consistently name svGetScopeFromName(), and svGetNameFromScope() and have the correct function signatures.
--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 : Tue Mar 25 2003 - 10:01:12 PST