Subject: [sv-cc] Minutes of the SV-CC conf call 5-Nov-2003 [revised upon input from Avinash]
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Nov 05 2003 - 10:55:16 PST
Thanks a lot to Avinash for providing me his list of issues. I have compiled a (hopefully complete list of issues from our both
entries) and replaced mine by this. Hope we both captured everything ...
Attendees:
Doug Warmke
Clint Olson
Avinash Mani
John Stickley
Francoise Martinole
Swapnajit Mittra
Joao Geada
Andrzej Litwiniuk
Ghassan Khoory
Ralph
Michael Rohleder
Bassam Tabbara
Last meeting minutes:
Doug proposes acceptance, Avinash proposes
Logistics
. Mentor offered to host the F2F meeting on Nov 11, Doug has already sent out instructions on how to reach the site.
Swapnajit
asked everybody to send proposals for important topics to compile the agenda.
. SV-BC has sent the separate compilation proposal to all committees. Everybody has been asked to review this
Technical discussion
. Bassam has already sent out a new version of the donation, but this didn't get through the reflector, he will resend
it now.
. Doug was not yet able to revise the disable task proposal. There are no major updates w.r.t. to the latest discussion
(the
write-up from Joao). He only wants to add some minor things:
- a very simple API to permit also disable higher up the call chain
- ... (did miss any further, if there were ...)
Joao presented Synopsys VPI extensions to Verilog 2001
. located at http://www.eda.org/sv-cc/hm/att-1479/01-VPI_Extenssions_to_SV.pdf
Questions: [issues are not contained here, but noted below]
- Francoise: when there is a class mentioned, does this mean a class instance or a class declaration?
Joao: it is always an instance with one exception to be denoted later
- Francoise: why is a modport different from a normal port.
Joao: modport is only restricting the visibility of the elements within an interface.
- Francoise: Could we not describe this like an iodecl.
Joao: don't know this now.
Swapnajit: let's list this and solve any upcoming issues later
- Swapnajit: since there is no longer $root, is note 5 on page 3 still valid?
Joao, Francoise: very likely not, need to look further. Need to look the proposed changes for $unit
- Francoise is TF decl an existing VL 2001 stuff. Joao: Yes
- Francoise: what is this I/F connection method? Take a look at the example ... went through the example.
[continue at page 7]
- Francoise: a packed array is like a vector. Joao: Can be accessed like a vector, but can also be accessed by
elements.
- Francoise: why do we need to have this 'packed array', ..., 'multi array'.
Joao: because we are restricted by a flat type system. This was the most straightforward way of representing SV
- Michael: Is the organisation of this document related to
- Francoise: there is no representation of a typedef.
Joao: typedef can not live by themself
It is very dangerous to do this in a language, where there are generate, ... and other constructions.
- Francoise: We don't have interface array
Joao: they are not instances. ... Make this an issue
- Francoise: How do you access classes that are defined in a scope.
- Joao: We can also have ref's for io_decls
- Francoise: Variable can be of any type now, what is the effect on io_decls.
Joao: if you get a ref you can always get to the real object and ask this
Michael: what about typedef's in this context. We have just a restricted type then
- Francoise: What is an input skew, is it just a time value
Joao: yes
Issue: [tentative, to be reviewed and finished by Swapnajit and Avinash]
1) why separate definition for modport, combine it with the iodecl? --- Francoise
2) note 5 on page 2 needs reconsideration in light of changes to $root in the separate
compilation proposal. Is this note still valid?
3) page 3 again try to merge this with the iodecl rather than having it separate ---- Francoise
4) Do not create a new class of objects for refobj on page 4, just align with the refport , how to represent pass by reference? ---
Francoise
5) Why do we have vpiModportPort and vpiInterfacePort? --- to differentiate the instance of the Modport from the definition
6) In general ----- the port or iodecl should be generalized rather than having ModportPort and InterfacePort be separate classes
--- Francoise
7) why do we need vpiInterfaceConn, if we need that why do we need refObj for connectivity ? --- Francoise
8) typo vipMultiArray rather than vpiMultiArray on page 7
9) Why do we need all the various sub-types under the arrays such as MultiPacArray, MultiArray, etc... should be mapped into scalar,
vector and array. ---- Francoise
10) No representation/definition of typedef in current proposal,
required for full decompiler capability --- Francoise and Michael
11) Certain properties of class variables may need to be associated with the particular type of variable rather than the entire
variables class eg vpiAssociateArray, vpiDynamicArray with class Var rather than with vpiVariables; properties assoicated with vars,
should be associated with subtypes of variables, make this more specific
12) How do you represent that someone is driving just a member of a variable rather than a complete variable ---- Francoise; In VPI
it is undefined whether there are loads and drivers, you can only ask this on the bit level. Asking for the driver of a compound
object is currently a problem.
13) Page 9 , interface arrays should be part of the diagram for Instance arrays???
Are interface arrays instances ?
14) In the scope diagram on page 10 the "end:" should be a fork.
15) How do you iterate on classes inside a scope? --- You iterate on variables and you get back a class var for classes declared
there
16) Arrow back to the scope from all the various iterators inside a scope (1 to many relationship)
17) No link to assertions/cover groups in the scope diagram on page 10
18) Why have we not mapped in the Interfaceport and Modportport into the iodecl object diagram on page 11? ---- Francoise
19) Add one-to-one relationship to access types in the iodecl diagram on page 11
20) Input skew is a time value, it is not negative but it is interpreted as a negative value wrt the clock edge (clocking domain
section on page 11)
21) How to identify the type of the object retrieved by io_decl
22) Traversal out of a reference object, why do we need three pathes (parent, scope, connectivity)
Thanks a lot to Avinash for providing me his excellent list of issues, which mostly supersedes my fast write-ups. I have only
extended it with stuff I thought adds some more detail.
Sorry, for having not noted everything. This was above my speed of hearing (what you said) , reading (the donation), thinking (about
what I heard, what the donation means) and typing at one time. 4 task at once without hyperthreading is a little bit too much for a
serial processor. Sorry.
-Michael
--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 Nov 05 2003 - 10:57:19 PST