[sv-cc] Minutes of the SV-CC conf call 5-Nov-2003


Subject: [sv-cc] Minutes of the SV-CC conf call 5-Nov-2003
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Nov 05 2003 - 10:19:44 PST


Attendees:

Doug Warmke
Clint Olson
Avinash
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]
 * note 5 on page 3: How is this changed in light of $root and $unit ? Is this note still valid ?
 * pass an argument to a function or task, pass the object or a reference to the object ?
    How to represent pass by reference ?
 * page 4: why do we create motport ports ?
 * Generalize Verilog ports to also reflect SystemVerilog functionality
 * Traversal out of a reference object, why do we need three pathes
    (parent, scope, connection)
 * Do we need the huge number of type 'packed array', ..., 'multi array' to represent variables
 * there is no representation of a typedef
 * properties assoicated with vars, should be associated with subtypes of variables,
    make this more specific
 * 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.
 * Are interface arrays instances ?
 * Scope 26.6.3 end should be a fork
 * Missing link from named event, .... back to scope
 * Assertion do define a scope ? Covergroups are a variant of assertions
 * Could we map the modport port I/F to io_decls.
 * How to identify the type of the object retrieved by io_decl

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:22:52 PST