Subject: [sv-cc] Minutes from SV-CC conference call at 21-Jan-2004
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Jan 21 2004 - 10:11:20 PST
Hi all,
here are the Minutes from the SV-cc call today.
Rgds,
-Michael
Ralph
Joao
Swapnajit
Francoise
Bassam
Ghassan
Doug
Michael
Avinash
IMPORTANT: Next call will be on Friday Jan, 23rd at 8:00 am Pacific Time, 11:00 am Eastern Time, 17:00 MUC time
Approval of meeting minutes from 20-Jan-2004
Joao proposed, Ralph seconded
Swapnajit asked Joao to summarize status of VPI extensions
. there are several changes pending from Bassam, Francoise, Michael
pg 28 30.27 Question from Michael, how do I get the class a method belongs to
Joao: over the expr retrieved by vpiPrefix, over the scope for virtual Methods
Michael: could we add some Note on this?
continued the review of the newest draft (dated Jan, 19th), starting with 30.26 Threads
. Joao: Threads are created by fork..., but not by fork_join
. Francoise, Michael: We should provide it for all fork...
. Joao: This is a concept that did not exist in 1364
Francoise: feedback from Charles about 30.25 Frames:
we should not care about backwards compatibility (as mentioned by Michael). This diagram
will be changed anyway by IEEE. When integrating SV 3.1a they will take care of this.
30.27 tf cal
. memory should be replaced by reg array
. Joao: there are only two methods that might have a vpiWith identifier, Michael: It would be worth to note this
30.28 Module path
. Michael: there are two ways to get to module, Joao: reason is backwards compatibility, new code should use always Instance
30.29 Concurrent Assertions
. Francoise: did you see my remark from yesterday about the disable condition
. We should directly go via a property disable condition to the expression, this simplifies the diagram
30.30 Disable Condition
. remove disable condition, retitle diagram
. Michael: we might think about combining: property spec, property decl, property inst
30.31 Property Spec
. relation to disable condition is to be replaced by a relation to expr, use disable condition to access this relation
. redraw double arrow to variables
. Box Sequence should also include property inst, box should be anonymous
. Francoise: why do we have to go over vpiOperand, an expression is itself a property instance; Joao it is recursive
. Joao: we should the diagram at the bottom to resemble the expr diagram, Bassam provided a lot of input here
30.32 Multiclock Sequence Expression
. Francoise: need to review this; there is sthg new called a Multiclock property expr
30.33 Sequence Declarations
. Michael: is there a relationship between formal list and formal list item
. Joao: yeah, this is incorrect, it should be an iterator to a formal list item
. Francoise: this would be the first time we call sthg 'item'; we should just call it 'formal'
. Francoise: move variables from sequence spec to sequence decl
. Bassam: that means we can merge sequence decl and sequence spec
. Joao agrees
. Bassam: the same might be true for property spec and property decl, this would relate to Michaels comment before
. Joao agrees, we can try this
. Joao: an iterator to actual args is missing
. Joao: an iterator on formals needs to be tidied up
30.34 Sequence Expression
. Francoise: issue has been stated yesterday. Broad agreement
. Joao: immediate assertion will look like an if-stmt
. vpiSeqOpType should become vpiOpType
[running out of time]
--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 : Wed Jan 21 2004 - 10:15:23 PST