Francoise,
I prefer the first alternative, i.e. "packname::object_name" and
"libname.packname::object_name".
Thanks for asking.
Regards,
Doug
________________________________
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf
Of Francoise Martinolle
Sent: Wednesday, December 15, 2004 2:57 PM
To: bassam@novas.com; 'Francoise Martinolle'; 'SV-CC'
Subject: 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
Received on Wed Dec 15 16:47:54 2004
This archive was generated by hypermail 2.1.8 : Wed Dec 15 2004 - 16:48:05 PST