Subject: [sv-cc] Minutes of the SV-CC Conference Call 5-Mar-2003
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Mar 10 2003 - 02:08:15 PST
Attendees:
Francoise Martinole
Joao Geada
Andrzej Litwiniuk
Kevin Cameron
Doug Warmke
Swapanjit Mittra
Michael Rohleder
John Stickley
--Procedural part:
. Approval of minutes: Proposed by Joao, seconded by Michael
. Ghassan announced that we have a new LRM editor on board: Philip.McGee@synopsys.com
. Swapanjit asked Joao for taking over the coordination of documentation. Thanks Joao!
. John S. asked how to cross-check whether the refinements are going into the documents
. Swapnajit said in one week we need to enter the document freeze state and start to review the documents
. Joao will sent the current status of all documents to the team after the conference call
. Michael requested that there is a clear revision number on the documents and each reviewer will clearly state which version has
been reviewed and which comments are related to which version number. Accepted by the team.
--Discussion about extern/import/export:
. topic: using 'alias' instead of extern/import/export:
- Joao thinks that alias has a slightly different meaning in SV.
- Francoise was concerned about using the word alias
- Agreement was not to use the alias declaration for this purpose. This is a C linker symbol issue that has no relationship to
the alias statement of SV 3.1.
. Some people seem to prefer import/export extern.
- Doug likes the usage of the word 'extern', since this is the usage of the word in other areas as well. He is concerned that
import extern is a misnomer, but export extern is a good match. DPI seems to be a better solution here.
- Joao stated that DPI is not an issue, because it is an identifier, not a keyword.
- Some discussion between Joao and Andrzej whether this is a problem or not.
- Joao want to have a simplified way to have further extensions, not only for DPI, also for PLI/VPI. This might be a possible way
to do this.
- Michael asked why not just putting the DPI into double quotes ("DPI") to make it a string literal, to not pollute the keyword
space.
- Andrzej requested a short opinion poll on this topic.
- Kevin questions that we need to clearly distinguish between DPI and other functions. Why not just rely on the SV application to
find this out.
- Doug has concerns about this.
- Joao stated several concerns about this (namespace rules, how to map to the C world, ...).
- Joao answered to Kevin's concern that this stuff is then no longer transparent is that the _use_ of a function call is still
the same for SV and for C. Only the declaration is different.
- Michael wants this difference; Kevin disagrees.
Swapanjit requested a poll from the team about the function declaration syntax:
- Joao, Doug
. extern "DPI"
. export "DPI"
- Kevin abstain
. import extern
. export extern
- Andrzej, John S.
. extern import
. extern export
- Francoise
. extern
. export
- Michael wants to have "DPI" because it is extensible, not religious about usage of extern/export
Swapnajit proposed to settle on
. extern "DPI"
. export "DPI"
for now and asks for continuing the discussion
Joao continues with discussing the need for making the prototypes mandatory.
- clearly required for extern declarations
- ... (I missed this part, sorry)
Doug: it should be legal named function proto.
John: Andrzej gaves some good examples about the possible problems in his last response shortly sent before the conf call. Some
discussion about this email.
Joao sees not problem with it.
Andrzej sees a strong need to clearly and strictly define how to define the equivalence rules for functions. Neither the name, nor
the default value is part of the function signature. Only the result value, and the argument types.
Doug: is it allowed to declare a function multiple times?
Andrzej, Doug: no you open a can of worms.
Kevin, this is a real pain. Michael agrees.
John, Doug, Andrzej, Joao are strongly against this.
Joao states that C/C++ is different and therefore the syntax is different. Kevin does not want this difference.
Swapnajit asks to put this discussion to the reflector.
Doug wants to have more restrictions at the beginning. Relaxation can be done later.
Francoise. It is possible to have hierarchical references.
Joao, true, this is exactly the same as with native functions.
John, Doug says this is one of the overriding criteria here.
Question by Doug about the need for declaration of export functions; is it really mandatory.
Andrzej: we might also need to provide the c name mapped to. What about just putting the export to the extern declaration ?
Joao, Andrzej: this might make the syntax a little bit 'interesting'.
Francoise: the result might be inconsistent with the rest of SV.
Result export does not have the params. Doug withdraw his proposal. It is possible to provide a shortcut.
Swapnajit asked the team about its opinion w.r.t. the response to Karen Pieper about the ambigous line.
Francoise: Andrzej corrected this to replace this line with a specific paragraph.
Swapnajit wants to hold a poll about
a) the extern/export proposal and
b) the correction of the SystemVerilog Data Types representation
Will sent out the request for poll until Thursday
--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 : Mon Mar 10 2003 - 02:09:44 PST