RE: [sv-cc] Meeting Minutes 12/15/2004

Yes, we agreed on that in proposal for 56 made by Charles, 1 and 2 do not
have a fullname but we would like to provide fullnames for packages and
package declared items.
 
One idea is that the fullname of a package would be "packname::" and an
object immediately declared in a package scope would have a fullname of
"packname::object_name"
 
The only issue would be IF in the future systemVerilog allows a design to
use packages of the same name but coming
from different libraries. In the current SV spec this is not allowed. In
that case I suppose we could enhance the fullname
to optionnaly include the library name to disambuguate which package.
The fullname therefore would be:
"libname.packname::" for a package fullname
 
and
"libname.packname::object_name" for an object declared immediately in a
package.
 
A simulator would have to do some look ahead in the VPI name string to
determine if the name contains a :: in order
to determine that this is a package based name.
 
The other alternative is to start the fullname of a package with a different
character such as the @ or any other character
which does not usually appear in a verilog identifier. This would avoid the
look ahead. For example we could have a fullname as:
[::libname]::packname::[name]{.name}
 
For ex for a variable var declared in task task declared in package pack
compiled in library lib:
::lib::pack::task.var (library name would be the future enhancement if the
SV spec is enhanced)
 
::pack would be the fullname of a package
::pack::task.var the fullname of variable var.
 
Starting with a :: makes it easier for a parser.
 
 
What do people think? Please respond so that I can formulate a proposal in
time.
 
Francoise
       '
 
 

  _____

From: Bassam Tabbara [mailto:bassam@novas.com]
Sent: Wednesday, December 15, 2004 5:35 PM
To: 'Francoise Martinolle'; 'SV-CC'
Subject: RE: [sv-cc] Meeting Minutes 12/15/2004

Hi Francoise,
 
Just a quick note about 56. I have 2 general impressions that may be Charles
can use as starting point for closing on this fast:
1) out of the 4 restrictions on vpi_handle_by_name, it seems the fourth
(objects in packages) raised the most eyebrows, followed by packages
themselves.
2) there seemed to be a general understanding (if not concensus) that using
"::" is a reasonable way (consistent with LRM) for accessing objects within
a package. This is listed on the bug ID originally among Charles'
suggestions...
 
Thx.
-Bassam.
 

--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893
 
  _____  
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Francoise Martinolle
Sent: Wednesday, December 15, 2004 1:40 PM
To: 'SV-CC'
Subject: [sv-cc] Meeting Minutes 12/15/2004
Minutes of 12/15/2004 SV-CC Meeting.
ATTENDEES
-xxxxxxxxxxxxxx Charles Dawson
xx-xxxxxxxxxxxx Francoise Martinolle
xxxxxxxxxxxxxxx Doug Warmke
xxxxxxxxxxx-xxx Bassam Tabbara
xxx-xxxxxxxxxxx Andrzej Litwiniuk
xx--xxxxxxxxxxx Joao Geada
xxxxxxxxxxx-xxx Jim Vellenga
xxxxxxxxxxxxxx- Ralph Duncan
x-x-xxxxxx--x-- Rob Slater
x-xxxxxxxxx-x-- Sachchidananda Patel
xxxxxxxxxxxxx-- Michael Rohleder
xx--xxxxx-xxx-- John Stickley
xxxxxxxxxxxx-x- Jim Garnett
xxxxxxxxxxx--x- Steven Dovich
-x-xxxx-x-xxxx Ghassan Khoory
-------------x Swapnajit Mitra
-------------x Karen Pieper
-----------x-- Angshuman Saha
-------x------ Kevin Cameron
-----x-------- Amit Kohli
----x--------- Surrendra Dudani
xxx----------- Stu Sutherland
1. Reviewed Patent information.
- Francoise asked if anyone was unfamiliar with the IEEE patent rules, 
and if it was needed to be read. Everyone is familiar with the patent 
information. The patent information was considered read.
2. Reviewed minutes of the 12/08/04 Meeting.
- Doug/Joao. Accepted.
3. Liaisons
Joao mentioned that there is another standard for transactions which may be 
using DPI in the future.
 
Steve Dovich reported that it is unclear in what status will be the
Encryption proposal after the 1800 WG meeting. Steve will post a proposal on
the VPI impact for the Encryption proposal for protected Verilog source
code. 
Joao mentioned that he read it and has personal opinions about it. Surrendra
will send feedback to the encryption committee.
4. New business
- 54, 55, 56 
    Jim V. moves that 54 and 55 are duplicates of 56 for which we have a
proposal
    Joao seconds
    no opposed, no abstain, Passes
 
  Charles needs to update the database for 54 and 55 as duplicates of 56.
 
- 333
     Jim V. described the changes he made: 
     moved arrayNet inside Nets superclass, remove vpiIsPacked as the
vpiVector   
     property can provide the same information. The proposal is ready to be 
     voted on today.
 
- 62
    no action today, recognized that it should be resolved as it notes a
backward 
    compatibility issue between 1364-2001 and 1800. An informal proposal is
in 
    the description of the erratum. If meeting next week, Francoise will
make a 
    proposal for next week. otherwise Jim V. agreed to resolve when he
returns 
    from vacation.
 
The people who can meet next week are:
  Joao, Doug, Steve, Michael, Sachchi Jim G. Rob, Francoise
 
- 77 
   Jim V. stated that this is not difficult to fix. 
   errata proposal from Jim V. next year. 
   Charles to assign to Jim.
5. Reviewed of items with proposals.
- 341
   This proposal add some macro definitions to svdpi.h similar to the ones 
   existing in vpi_user.h. Someone said that the proto_params macro is not 
   needed anymore because all compilers are supporting ANSI C compiler.
   Motion: Doug to combine proposals 341 with CC 50 without the proto params
          Joao seconds
          No opposed, no abstain, Passes
- 50
   New proposal distributed for review
   Andrzej wants to change the string value for DPI.
   Discussion:
        Ralph would like DPI-1800 or DPI-C instead of just C.
   
        Jim V. prefers DPI-C (standard) and DPI-sv31a (deprecated), 
               plain DPI will not work.
        Steve D.: leave DPI but it is implementation defined what it uses
        Others: Not in agreement with Steve
 
      Plain "C", Doug likes the string to explicitly indicates that it is
DPI.
      Motion: 
         Doug proposes DPI-C for standard canonical DPI and 
         DPI-3.1a for deprecated DPI
         John Stickley seconds, no opposed, no abstain, passes.
      Doug will modify the proposal 50 to include this.
      
     Doug notes that errata 5, 205, 278, 288, 318, 335 and 341 all 
     are all duplicate and subsumed by 50
 
     Motion: reconsider all of the above: Doug moves, Joao seconds. Passes
     
     Steve D. moves that we amend the reconsidered motions to be duplicate 
     of 50. Doug seconds, no opposed, no abstain, passes.
 
     Charles to mark all of these as duplicate of 50.
 
     Motion: Steve D. moves that we approve the amended motions in a block 
             as a single vote.
             Jim V. seconds, no opposed, no abstain, Passes
 
   
     Motion: Doug makes the motion to pass 50 as amended
             Joao seconds, no opposed
             Andrzej abstains for 50, because he is against changing DPI to 
             specify vendor internal format for logic types.
             Passes
   Steve D. makes the observation that the items reconsidered need to come 
            off the WG list for voting since they are now merged with 50.
 
  - 333 
        Jim V. stated that note 25 will depends on the outcome of 64 and
        that we should look at 64 before considering 333.
 
  - 64
        Jim V. asked what do the vpiScalar ad vpiVector properties return
for 
        int, longint, shortint, byte var. 
        Joao mentioned that integer/time are not identical types as 
        logic [31:0] / logic [63:0] 
        Francoise pointed out that erratum 51 answered the question posted 
        by Jim Vellenga on whether or not integer types are equivalent to 
        packed array types.
        51 states that "Although an integer type with a predefined width n
is 
        not a packed array, it matches (see Section 5.8.1), and can be
selected 
        from as if it were, a packed array type with a single [n-1:0]
dimension."
        Therefore the integer types (int, longint, byte, shortint, time) 
        are vectors.
        Jim V. also said that the vpiScalar, vpiVector properties should
also 
        apply to a var bit (which is the same as reg bit) since it used to
apply 
        to that object type regbit in 1364-2001.
        Jim G. made a new proposal for 64 including sentences to take care
of 
        these two issues.
 
                
      Motion: Jim G. moves to approve his new proposal
              Joao seconds, no opposed, no abstain, Passes
 
 
- 332
      Motion: Joao moves to approve current proposal for uwire
              Jim V. seconds, no opposed, no abstain, Passes.
 
 
- 333
    Jim V: Moves with friendly amendment to note 25 based on the wording of
64 
           A net bit is a scalar and the vpi property vpiScalar shall return
TRUE
           (vpiVector property shall return FALSE).
           Friendly amendment from Jim G. to bold vpiScalar and vpiVector
           Joao seconds, No opposed, no abstain, Passes
 
- 56
    We discussed the proposal made by Charles to 56, Joao expressed the
concern 
    that packages are becoming a important language construct and that VPI 
    should be able to access them by name along with objects declared in
    packages. Michael, Bassam, Joao and Francoise echoed. We did not have
time
    to discuss potential solutions. 
Charles needs to reconsider its proposal with this new guidance.
 
Joao moves we ajourn.
Meeting ended at 1:07pm (EST)
7. Action items
SV-CC action items:
- Charles to update database with items discussed during 12/15 meeting.
- Francoise to ask Peter Ashenden what was done to improve
printing from Rational Rose.
- Francoise to inquire about the feasibility of third parties
shipping the UML for the diagrams.
- Sachi to drive finding a better solution for 052.
- Chas to add Stu to SV-CC email alias.
- JimV to enter a new SV-CC item for adding tables for return values of
the properties.
- Joao to setup a meeting to discuss Item 050.
- ALL to review proposal for Item 333 for next meeting.
PTF action items:
- Steve to compare BNF with the access available
for attributes to see if they match
- Francoise to remove "+" from tags in UML diagrams and
add vpi prefix where appropriate.
- Francoise to send out HTML for 1364-2001 diagrams, using
something other than JPG for importing diagrams into frame.
- Stu to write proposal for PTF 368.
- Francoise to write proposals for PTF 373, 374, and 396.
- Steve to write proposals for PTF 311, and 495.
- Sachi to write proposals for PTF 307, 312, and 313.
- Stu to enter new PTF item for save/restart/reset issue.
- JimG to write proposals for PTF 517, 533, and 534.
- Chas to write proposal for PTF 296.
- Francoise to lookup wording for PTF 524 in VHPI.
- Francoise will open a new PTF issue to look for situations like 25.6.15,
where multiple methods are used access the same object enclosure
- Chas to reword proposal for PTF 525.
- Draft a straw man proposal using a clean slate with no concern for
existing PLI/VPI on the best way to represent all Verilog and
SystemVerilog kinds and types. This straw man will then be used as a
basis for discussing backward compatibility with the existing reg, net,
variables, functions, and parameter diagrams. It may be decided that
full backward compatibility is not possible, or is not the best approach
moving forward.
- Sachi will file a PTF item for the clarification of what can be done
at ROsync time and putting values in future times.
- Francoise to file a PTF item that asks to specify the order that iteration
occur in, when the order is important.
- Steve to add ETF item for Annex C to remove the Informative label, but
still allow the contents to be option
 
8. Items for consideration at the next meeting :
- 62 note for vpiArray change from 1364 to 1800 standard
- 56 (packages issue)
 
Francoise Martinolle
(978) 262 - 6283
fm <mailto:fm@cadence.com> @cadence.com