Subject: [sv-cc] Minutes of the SV-CC Conference Call 18-Feb-2003
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Feb 18 2003 - 10:37:40 PST
Attendees:
Francoise Martinole
Joao Geada
Andrzej Litwiniuk
Kevin Cameron
Doug Warmke
Swapanjit Mittra
Michael Rohleder
Joe Daniels
Bassam Tabbara
--Procedural part:
. Approval of minutes: Proposed by Joe, seconded by Andrzej
. Joe sent out first part of our deliverables.
Swapanjit will provide it to the team after the call. Had some problems with his mailer.
Current status is
- DirectC C layer side is relatively done
- Assertions doc mostly done; Joe expect only minor changes
- Waiting for DirectC SV layer side from Andzej and Joao (assumed end of this week)
- Waiting for Coverage doc, Joao will start to work on it on Thursday
--Inclusion document (ISSUE 1.9)
. Question: will the documentation for issue 1.9 (svInclusion) be included in the DirectC C layer side. Swapanjit asked about the
status of this document. Michael sent out the final version of his document. There were only minor changes due to removal of PLI/VPI
and removing the statements forbidding extensions.
. Francoise asked for a poll on this item. Swapanjit proposed to have one, deadline will be Friday. He will sent out the procedural
stuff for this.
. Joao asked for showing all vote results on the Web page. Swapanjit will do this. General sentiment was that we have two kinds of
votes: a) preliminary acceptance [this is an area we should spent time on] and b) readiness acceptance [this is good enough to be
included in the draft]. Swapnajit thinks svInclusion is now ready for a poll of the second type.
. Placing of Inclusion doc: Swapnajit proposed that Michael should work with Andrzej to include the svInclusion doc into the C layer
side. Proposal was that Michael send is to Andrzej for review against his stuff and then forwards it to Joe.
. Joe thinks it should become an Annex; Andrzej agrees, Michael agrees as long as it is a "normative" annex, not an "informative"
-- Draft3
Joao thinks there are some differences between draft3 and the current coverage API. Michael thinks that it is the intention of
having soon a draft containing all information so the various committee can review and crossreference any issues.
-- API Name
Michael was asking about the final name of the API we are defining here, has there been a decision about using DirectC or anything
else? Francoise has the concern that this might sound like it is the only C API. Doug agrees. Joao doesn't care how we call it.
Swap askes everybody in the team to send in some suggestions until tomorrow. Joe remarks that it will very likely anyway change
until DAC ...
-- Discussion about pass by reference, default values, passing argument by names
[Sorry, this discussion was so lively that I did only grabbed part of the most important pieces, it was also mostly impossible to
show the full flow of discussion - Michael]
Andrzej's proposal is to ignore passing by name. C side can not do this and this can not be changed, so we can not influence this.
SV side can do it, but would be rather complicated. Similar for default arguments. We can do this on system verilog side. Andrzej
thinks we should not support this features.
Andrzej has far more concerns about var arguments w.r.t. the DirectC interface.
The memory location will be immediately updated, the fanout will happen afterwards.
Doug questions whether the update semantics would permit problems here, since Verilog does not have preemptive coding, how can we
have differences here. Answer: two formal arguments, where both accessing the same variable. Joao pointed to the IEEE spec where the
scheduler can preempt any execution (p 66, section 5.4.1). Also mentioned in section 5.5. where a block is preempted in favor of
another block.
Swapanjit askes Andrzej whether this is currently being supported. Andrzej sees a conflict here between the work a user and the
stuff provided by the compiler. Michael asks how a user benefits from having var above inout. What benefit do we gain by supporting
var over having some possible problems. Kevin thinks it makes things significantly faster. (Some longer discussion with Joao here,
which I was not able to follow ...)
Michael asked for putting this up for poll, there are three problems we can work on separately.
Swapnajit will include also passing by reference in the poll for friday.
There are then two more issues: default values and passing by name. Andrzej questions its usefulness. Michael stated that one of our
goals was to have a DirectC function behave/look like any other SV task/function. This means we should have a minimum amount of
'special' restrictions for DirectC functions/tasks. Doug agrees to this.
General agreement was that we should have some more email discussion on this and then we might have another poll, also on this
questions (probably on Friday?). Swapnajit will send out an email as soon as there is an agreement on what would be the correct
questions for a poll.
Andrzej requests that we clarify upfront the restrictions. Doug thinks we should also ask the EC for completely clarifying the
semantics of this. Francoise want to ask the EC committee after the call.
Andrzej is also concerned about multiple relationshsips between extern function declarations. (did not get the rest here ...). Doug
would propose to have a look at prototype stuff in the draft. He also did not find any statement about 'default argument' within the
draft.
Francoise will ask Arturo for clarification about var, will also ask for reason for passing by reference (what is its utility of
support in the C interface), why are default values missing in the BNF. Dough thinks we should also ask for the updates semantics of
var. Kevin believes that prototypes are in the interface.
Kevin wants to know how to pass an argument of type class. Joao responds we can only pass the argument types defined in Andrzejs
proposal, class is not part of them. Kevin thinks this is a big hole in the defined interface.
Swapnajit reiterated earlier plans about reviewing the draft by ALL committees. We need to do this to be in sync with the other
committees.
--Final question was:
do we need a conference call tomorrow. There is an EC meeting tomorrow, so we will like collide with them. Are there any suggestions
for tomorrows meeting? Agreement was that there will be no meeting tomorrow.
Doug asks how we handle the patent stuff provided by Vassilios. Joao has concerns that he/we are not lawyers, so how does this apply
what we say. At the end only U.S. patent lawyers can properly handle this.
Swapnajit proposes that we give feedback directly to Vassilios separately.
--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 Feb 18 2003 - 10:38:20 PST