From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Sun Mar 01 1998 - 13:21:52 PST
BAD MSG:
Updated BNF98 in HTML format. Still not perfect but working on it!
ontent-Length: 38044
X-Lines: 979
X-Status: $$$$
X-UID: 0000000326
Status: RO
- Cliff
<p>Attachment Converted: "E:\INCOMING\BNF98.html"
//********************************************************************//
// Cliff Cummings E-mail: cliffc@sunburst-design.com //
// Sunburst Design Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training / On-Site Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//From ???@??? Mon Mar 02 12:30:59 1998
Return-Path: <yatin@multi2.netcomi.com>
Received: from multi2.netcomi.com (multi2.netcomi.com [204.58.155.202])
by gw.boyd.com (8.8.5/8.8.5) with ESMTP id MAA30355
for <stefen@boyd.com>; Mon, 2 Mar 1998 12:23:45 -0800
Received: (from yatin@localhost) by multi2.netcomi.com (8.8.5/8.7.3) id OAA20768; Mon, 2 Mar 1998 14:02:16 -0600
Received: from norway.it.earthlink.net (norway-c.it.earthlink.net [204.119.177.49]) by multi2.netcomi.com (8.8.5/8.7.3) with ESMTP id OAA20755 for <1364core@ovi.org>; Mon, 2 Mar 1998 14:02:07 -0600
Received: from newmicronpc (1Cust201.tnt1.beaverton.or.da.uu.net [153.35.201.201])
by norway.it.earthlink.net (8.8.7/8.8.5) with SMTP id MAA00921
for <1364core@ovi.org>; Mon, 2 Mar 1998 12:02:21 -0800 (PST)
Message-Id: <3.0.3.32.19980302120021.006b60c0@mail.earthlink.net>
X-Sender: verilogpro@mail.earthlink.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 02 Mar 1998 12:00:21 -0800
Old-To: 1364core@ovi.org
From: Stuart Sutherland <stuart@sutherland.com>
Subject: VOTING NOTICE: PLI task force items
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Loop: 1364core@ovi.org
To: Daryl.Stewart@cl.cam.ac.uk, S1364@eda.ics.es.osaka-u.ac.jp,
adamk@cyrix.com, alec@fintronic.com, andersn@nortel.ca,
anderson@acuson.com, bob@simucad.com, chas@cadence.com,
cliffc@europa.com, dinesh@synopsys.com, dixit@seva.com, dkf@apteq.com,
drew@silicon-sorcery.com, eli@interhdl.com, elkind@cadence.com,
elliot@wellspring.com, flake@elda.demon.co.uk,
furui@n022.saskg.semicon.sony.co.jp, gmoretti@veribest.com,
john@simucad.com, kurt@wsfdb.com, lynnh1@ix.netcom.com,
mac@surefirev.com, mannan@dsmtech.com, marek@cadence.com,
mno1@ricochet.net, naveen@lsil.com, pieper@synopsys.com,
prabhu@lsil.com, roberts@cadence.com, sjmeyer@crl.com, skp@cadence.com,
stefen@boyd.com, stuart@sutherland.com, tfitz@cadence.com,
trivedi@seva.com, vhberman@worldnet.att.net, vivek@veri-log.com,
wadswort@poci.amis.com
Status: RO
1364 Working Group;
The PLI task force has approved the following 15 items. Your vote on these
items will be requested at the 1364 VSG meeting on March 10, 1998. Please
review the task force resolutions and be prepared to vote at the meeting.
Note that these items are also available on our web page, along with the
lists of all pending, rejected and approved PLI task force actions. The
web site is www.sutherland.com/PLI_task_force.htm
If you have any questions prior to the VSG meeting, we would be glad to
answer them by e-mail. Please send your questions to both
stuart@sutherland.com and drew@silicon-sorcery.com.
Thanks!
Stu Sutherland
<p>************************************************************************
PLI Task Force ID: 50
Summary: Specify how vpi_get_value works with built-in
system functions.
Relevant LRM Sections: 22.5.12
Current Status: TF-Approved
Date Submitted: 08 Jan 1997
Date Analyzed: 28 Jul 1997
Date of Last Action: 02 Mar 1998
Author of Submission: Steve Meyer
Author's Net Address: sjmeyer@crl.com
Description of Problem:
In chapter 22, note 2 for system tasks and functions (LRM 22.5.12, p.
544) implies that vpi_get_value can be called for built in system
functions (such as $time). Does this mean a call by the PLI to $time
must be made, is it a typo, or does it mean return the value for the
last call of the system function?
Proposed Resolution:
28 Jul 1997:
Deferred. This needs further study. David Roberts to make a proposal
on what should be in the standard.
01 Oct 1997: Recommendation from David:
Arguments to PLI task or function are not evaluated until an
application requests their value. Effectively, the value of any
argument is not known until the application asks for it. When an
argument is an HDL or system function call, the function cannot be
evaluated until the application asks for it's value. If the
application never asks for the value of the function, it is never
evaluated.
If the application has a handle to an HDL or system function they
may ask for it's value at any time in the simulation. When this
happens the function is called and evaluated at this time.
Although this functionality is not a problem for interpreted
simulators, it is a more difficult problem for compiled code
simulators.
09 Feb 1998:
Unanimously approved David's recommendation (David, Drew, Stu present).
Submit this for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
Add the following to LRM 22.5.12, (p. 544) as note 5:
5-Arguments to PLI tasks or functions are not evaluated until an
application requests their value. Effectively, the value of any
argument is not known until the application asks for it. When an
argument is an HDL or system function call, the function cannot be
evaluated until the application asks for it's value. If the
application never asks for the value of the function, it is never
evaluated. If the application has a handle to an HDL or system
function it may ask for it's value at any time in the simulation.
When this happens the function is called and evaluated at this time.
************************************************************************
PLI Task Force ID: 74
Summary: Emphasize the word "instead" in tag description.
Relevant LRM Sections: 22.4.3
Current Status: TF-Approved
Date Submitted: 02 May 1997
Date Analyzed: 11 Aug 1997
Date of Last Action: 02 Mar 1998
Author of Submission: Charles Dawson
Author's Net Address: chas@cadence.com
Description of Problem:
The 2 uses of the word "instead" in the descriptions for tags
should be underlined to highlight their significance.
Proposed Resolution:
11 Aug 1997: Approved unanimous as modified.
1. Change vpiTag to Tag(italics, not bold) in all occurances in
the table.
2. Change vpiObj to Obj(italics, not bold) in all occurances in
the table.
3. Add a footnote on how Obj constant is derived (with a reference
to 22.2 for more details).
4. Add a more complete description on object and tag constants to
section 22.2.
Charles to provide the description.
01 Oct 1997: Recommendation from Charles:
Sometimes it is necessary to access a class of objects which does not
have a name, or whose name is ambiguous with another class of objects
which can be accessed from the reference handle.
<italics>Tags<un-italics> are used in this situation.
[show example of part select and the two expressions for ranges]
In this example, the tags vpiLeftRange and vpiRightRange are used to
access the expressions which make up the range of the part select.
These tags are used <bold>instead<un-bold> of vpiExpr to
get to the expressions. Without the tags, the VPI interface would not
know which expression should be accessed.
vpi_handle(vpiExpr,part_select_handle) would be illegal when the
reference handle (part_select_handle) is a handle to a part select.
This section should be added immediately after the paragraph that
begins:
The call to vpi_handle() in this example ...
<p> Here is the description for Item #3 above:
For relationships which do not have a tag, the type used for access is
determined by adding "vpi" to the beginning of the word within the
enclosure with each word's first letter being a capital. Using the
above example, if an application has a handle to a net, and wants to
go to the module instance where the net is defined, the call would be:
modH = vpi_handle(vpiModule,netH);
where netH is a handle to the net. As another example, to access a
"named event" object, use the type vpiNamedEvent.
This section should be placed immediately after the first example in
section 22.2.
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit for e-mail vote by PLI Task Force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
Make the following changes to the chart on 22.4.3 (p. 532):
1. Change vpiTag to Tag(italics, not bold) in all occurances in
the table.
2. Change vpiObj to Obj(italics, not bold) in all occurances in
the table.
3. Add the following footnote below the chart:
For relationships which do not have a tag, the type used for access
is determined by adding "vpi" to the beginning of the word within
the enclosure with each word's first letter being a capital. Refer
to 22.2 for more details on VPI access constant names.
4. In section 22.2 (p. 526), add the following paragraphs after the
example diagram in section:
For object relationships (unless a special tag is shown in the
diagram), the type used for access is determined by adding "vpi"
to the beginning of the word within the enclosure with each word's
first letter being a capital. Using the above example, if an
application has a handle to a net, and wants to go to the module
instance where the net is defined, the call would be:
modH = vpi_handle(vpiModule,netH);
where netH is a handle to the net. As another example, to access a
"named event" object, use the type vpiNamedEvent.
5. In section 22.2.1 (p. 527), add the following paragraphs after the
third paragraph, which begins "The call to vpi_handle() in the above
example ...":
Sometimes it is necessary to access a class of objects which do not
have a name, or whose name is ambiguous with another class of objects
which can be accessed from the reference handle.
<italics>Tags<un-italics>
are used in this situation.
[insert portion on diagram 22.5.15 showing part select and the two
expressions for ranges]
In this example, the tags vpiLeftRange and vpiRightRange are used to
access the expressions which make up the range of the part select.
These tags are used <bold>instead<un-bold> of vpiExpr to get to the
expressions. Without the tags, the VPI interface would not know which
expression should be accessed. vpi_handle(vpiExpr,part_select_handle)
would be illegal when the reference handle (part_select_handle) is a
handle to a part select.
<p>************************************************************************
PLI Task Force ID: 79
Summary: Add vpiResolvedNetType property to net type
description
Relevant LRM Sections: 22.5.4
Current Status: TF-Approved
Date Submitted: 02 May 1997
Date Analyzed: 03 Aug 1997
Date of Last Action: 02 Mar 1998
Author of Submission: Charles Dawson
Author's Net Address: chas@cadence.com
Description of Problem:
There should be the following property added to the net type
description for the net class:
int: vpiResolvedNetType
This property will describe the resolved net's type.
Proposed Resolution:
03 Aug 1997: This is an enhancement; deferred to a later time.
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit for e-mail vote by PLI Task Force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
In 22.5.4, change:
-> net type:
int: vpiNetType
To:
-> net type:
int: vpiNetType
int: vpiResolvedNetType
************************************************************************
PLI Task Force ID: 87
Summary: The property vpiSysFuncType should be removed.
Relevant LRM Sections: 22.5.12
Current Status: TF-Approved
Date Submitted: 02 May 1997
Date Analyzed: 03 Aug 1997
Date of Last Action: 02 Mar 1998
Author of Submission: Charles Dawson
Author's Net Address: chas@cadence.com
Description of Problem:
The property vpiSysFuncType should be removed. It is replaced by
vpiFuncType on page 544 (see 88, below).
Proposed Resolution:
03 Aug 1997: Charles and David to provide description of what needs
to be changed in LRM.
01 Oct 1997: Recommendation from Charles:
See item 88. for the description of the enhancement.
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
No action needed - item 88 describes the necessary changes.
************************************************************************
PLI Task Force ID: 88
Summary: Add property to indicate the return type for
systf call
Relevant LRM Sections: 22.5.12, Annex E
Current Status: TF-Approved
Date Submitted: 02 May 1997
Date Analyzed: 03 Aug 1997
Date of Last Action: 02 Mar 1998
Author of Submission: Charles Dawson
Author's Net Address: chas@cadence.com
Description of Problem:
There is a need for a property which will indicate the return
type for a function or system function call:
-> function type
int: vpiFuncType
This will require a new dotted enclosure around the func call and
sys func call enclosures.
The following return types should be defined in appendix E:
vpiRegFunc, vpiIntFunc, vpiRealFunc, vpiTimeFunc
Proposed Resolution:
03 Aug 1997: Charles and David to provide description of what needs
to be changed in LRM.
01 Oct 1997: Recommendation from Charles:
The return types for a func call and a sys func call can be the same.
This allows us to have one property that applies to both. To do this,
the following changes need to be made to the specification:
- Add the property:
-> type
int: vpiFuncType
below the definitions for func call and sys func call in section
22.5.12 on page 544.
- Add the following to Appendix E
#define vpiFuncType 47 /* HDL function and system function type */
#define vpiIntFunc 1 /* returns integer */
#define vpiRealFunc 2 /* returns real */
#define vpiTimeFunc 3 /* returns time */
#define vpiSizedFunc 3 /* returns an arbitrary size */
NOTE - Could be 47. See item #87
The property vpiSysFuncType can then be removed.
<p> 04 Nov 1997: Added the following to the recommendation:
The third paragraph of section 23.25.1 (page 589) will need to be
modified.
The definitions for vpiSysFuncType in appendix E are on page 628. They
will need to be removed.
08 Jan 1998: Received additional input from Charles:
The following sections/figures need to be updated as well:
Figure 23-16 (page 589). The comment after sysfunctype will need
modification.
The example in section 23.25.2 (page 591).
This example's routine register_my_systfs() should be modified to be this:
void register_my_systfs()
{
static s_vpi_systf_data systf_data_list[] = {
{vpiSysTask, 0, "$my_task", my_task_calltf,
my_task_compiletf},
{vpiSysFunc, vpiIntFunc, "$my_func", my_func_calltf,
my_func_compiletf},
{vpiSysFunc, vpiRealFunc, "$my_real_func", my_rfunc_calltf,
my_rfunc_compiletf},
{0}
};
p_vpi_systf_data systf_data_p = &(systf_data_list[0]);
while (systf_data_p->type)
vpi_register_systf(systf_data_p++);
}
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
1. On 22.5.12, add the following property below the definitions for func
call:
-> type
int: vpiFuncType
2. On 22.5.12, Change the property below the definitions for sys func
call FROM:
-> sys func type
int: vpiSysFuncType
TO:
-> type
int: vpiFuncType
3. Appendix E, change the following constants FROM:
/************** system taskfunc properties **************/
#define vpiSysFuncType 47 /* HDL function and system function
type */
#define vpiSysFuncInt 1 /* returns integer */
#define vpiSysFuncReal 2 /* returns real */
#define vpiSysFuncTime 3 /* returns time */
#define vpiSysFuncSized 3 /* returns an arbitrary size */
TO:
/************** task/function properties **************/
#define vpiFuncType 47 /* HDL function and system function
type */
#define vpiIntFunc 1 /* returns integer */
#define vpiRealFunc 2 /* returns real */
#define vpiTimeFunc 3 /* returns time */
#define vpiSizedFunc 3 /* returns an arbitrary size */
4. 23.25.1, change the constant names in the third paragraph FROM:
"vpiSysFuncInt, vpiSysFuncReal, vpiSysFuncTime, or vpiSysFuncSized"
TO:
"vpiIntFunc, vpiRealFunc, vpiTimeFunc, or vpiSizedFunc"
5. 23.25.1, Figure 23-16, change the sysfunctype declaration line FROM:
"int sysfunctype; /* vpiSysFunc[Int,Real,Time,Sized] */"
TO:
"int sysfunctype; /* vpi[IntFunc,RealFunc,TimeFunc,SizedFunc] */"
6. Appendix E, change the system taskfunc structure subtype line FROM:
"int subtype; /* vpiSysFunc[Int,Real,Time,Sized] */"
TO:
"int subtype; /* vpi[IntFunc,RealFunc,TimeFunc,SizedFunc] */"
7. 23.25.2, change the example's routine register_my_systfs() TO:
void register_my_systfs()
{
static s_vpi_systf_data systf_data_list[] = {
{vpiSysTask, 0, "$my_task", my_task_calltf,
my_task_compiletf},
{vpiSysFunc, vpiIntFunc, "$my_func", my_func_calltf,
my_func_compiletf},
{vpiSysFunc, vpiRealFunc, "$my_real_func", my_rfunc_calltf,
my_rfunc_compiletf},
{0}
};
p_vpi_systf_data systf_data_p = &(systf_data_list[0]);
while (systf_data_p->type)
vpi_register_systf(systf_data_p++);
}
<p>************************************************************************
PLI Task Force ID: 115
Summary: Use of "true", and "TRUE" is inconsistent
Relevant LRM Sections: 17 thru 23
Current Status: TF-Approved
Date Submitted: 16 Jun 1997
Date Analyzed: 03 Aug 1997
Date of Last Action: 02 Mar 1998
Author of Submission: Jacques Rouillard
Author's Net Address: rouillard@acm.org
Description of Problem:
Submitted comments on 1995 IEEE 1364 ballot:
The use of "true" and "false" is inconsistent throughout the examples
(upper and lower cases).
Proposed Resolution:
03 Aug 1997:
Could not find this problem in final 1364-1995 LRM. Steve Meyer to
contact submitter to see if he feels there is still a problem.
09 Feb 1998:
Resolved. Task force determined the problems do not exist in final
1995 LRM. Submitter never responded to e-mail.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
No changes are required.
************************************************************************
PLI Task Force ID: 183
Summary: Document acc_next_bit() with reg data types
Relevant LRM Sections: 18.5.9, 19.64
Current Status: TF-Approved
Date Submitted: 16 Dec 1997
Date Analyzed: 08 Jan 1998
Date of Last Action: 02 Mar 1998
Author of Submission: Stuart Sutherland
Author's Net Address: stuart@sutherland.com
Description of Problem:
LRM page 247, table 18-18 says acc_next_bit() can be used with a reg
data type, but the description of acc_next_bit() on page 384 limits
the routine to ports and nets (and path terms, per approved item #61).
Verilog-XL supports acc_next_bit() with a scalar reg, but not with
vector reg.
Proposed Resolution:
08 Jan 1998: Approved unanimous (Drew not present).
Remove acc_next_bit() from table 18-18.
09 Jan 1998: Drew asked to discuss this more at next task force meeting.
09 Feb 1998: Drew proposed:
- Change all occurances of expanded vector net to expanded vector in
section 19.64
- Change all occurances of net to expanded vector in 19.64
- Change example "net_handle" to "vector_handle"
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this item for an e-mail vote by the PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
1. In 19.64:
- Change all occurances of expanded vector net to expanded vector
- Change all occurances of net to expanded vector
2. In 19.64, Figure 19-67:
- Change all occurances of "net_handle" to "vector_handle"
<p>************************************************************************
PLI Task Force ID: 190
Summary: Define ACC/TF system task/function types
Relevant LRM Sections: 17
Current Status: TF-Approved
Date Submitted: 08 Jan 1998
Date Analyzed: 09 Feb 1998
Date of Last Action: 02 Mar 1998
Author of Submission: Stuart Sutherland
Author's Net Address: stuart@sutherland.com
Description of Problem:
The introduction of Section 17 hints that the PLI creates user-defined
system tasks or functions, but never defines what they are.
Propose:
Create a new section 17.3 (pushing old 17.3 to 17.4) which reads:
17.3 User-defined system task or function types
The type of a user-defined system task or functions determines how a
PLI application is called from the Verilog HDL source code. The types
are:
- A user <italics>task<end-italics> can be used in the same places a
Verilog HDL task can be used (refer to Section 10.2). A user-defined
system task can read and modify the arguments of the task, but does
not return any value.
- A user <italics>function<end-italics> can be used in the same places
a Verilog HDL function can be used (refer to Section 10.2). A
user-defined system function can read and modify the arguments of
the function, and will return a scalar or vector value. The bit
width of the return is determined by a user-supplied
<italics>sizetf<end-italics> application (see section 17.4.3).
- A user <italics>real-function<end-italics> can be used in the same
places a Verilog HDL function can be used (refer to Section 10.2).
A user-defined system real-function can read and modify the arguments
of the function, and will return a double-precision floating point
value.
The PLI ACC and TF interface mechanism provided with an implementation
shall provide some means of specifying the type of a PLI application.
Proposed Resolution:
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this for e-mail vote by the PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
Create a new section 17.3 (pushing old 17.3 to 17.4) which reads:
17.3 User-defined system task or function types
The type of a user-defined system task or functions determines how a
PLI application is called from the Verilog HDL source code. The types
are:
- A user <italics>task<end-italics> can be used in the same places a
Verilog HDL task can be used (refer to Section 10.2). A user-defined
system task can read and modify the arguments of the task, but does
not return any value.
- A user <italics>function<end-italics> can be used in the same places
a Verilog HDL function can be used (refer to Section 10.2). A
user-defined system function can read and modify the arguments of
the function, and will return a scalar or vector value. The bit
width of the return is determined by a user-supplied
<italics>sizetf<end-italics> application (see section 17.4.3).
- A user <italics>real-function<end-italics> can be used in the same
places a Verilog HDL function can be used (refer to Section 10.2).
A user-defined system real-function can read and modify the arguments
of the function, and will return a double-precision floating point
value.
<p>************************************************************************
PLI Task Force ID: 191
Summary: Define default return size of system functions
Relevant LRM Sections: 17.4.3
Current Status: TF-Approved
Date Submitted: 08 Jan 1998
Date Analyzed: 09 Feb 1998
Date of Last Action: 02 Mar 1998
Author of Submission: Stuart Sutherland
Author's Net Address: stuart@sutherland.com
Description of Problem:
Verilog-XL has a default return size if no sizetf application is
provided. Most (all) other simulators have cloned this undefined
behavior.
Propose:
1. Change the end of the last sentence of section 17.4.3 (page 230):
FROM:
The sizetf application shall not be called for PLI system tasks.
TO:
If no sizetf application is specified for a user-defined system
function, the function shall return 32-bits. The sizetf
application shall not be called for user-defined system tasks or
real-functions.
2. Add the following new paragraph to 23.25.1, just before the
first complete paragraph at the top of page 590.
The <italics>sizetf<end-italics> application shall only called if
the PLI application type is vpiSysFunction and the subtype is
vpiSysFuncSized. If no <italics>sizetf<end-italics> is provided,
a user-defined system function of vpiSysFuncSized shall return
32-bits.
Proposed Resolution:
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
1. Change the end of the last sentence of section 17.4.3 (page 230):
FROM:
The sizetf application shall not be called for PLI system tasks.
TO:
If no sizetf application is specified for a user-defined system
function, the function shall return 32-bits. The sizetf
application shall not be called for user-defined system tasks or
real-functions.
2. Add the following new paragraph to 23.25.1, just before the
first complete paragraph at the top of page 590.
The <italics>sizetf<end-italics> application shall only called if
the PLI application type is vpiSysFunction and the subtype is
vpiSysFuncSized. If no <italics>sizetf<end-italics> is provided,
a user-defined system function of vpiSysFuncSized shall return
32-bits.
************************************************************************
PLI Task Force ID: 193
Summary: var selects should have vpiFullName property
Relevant LRM Sections: 22.5.6 (page 538)
Current Status: TF-Approved
Date Submitted: 08 Jan 1998
Date Analyzed: 09 Feb 1998
Date of Last Action: 02 Mar 1998
Author of Submission: Charles Dawson
Author's Net Address: chas@cadence.com Description of Problem:
Objects whose type is vpiVarSelect should have the properties vpiName and
vpiFullName. This functionality is described in section 22.5.14 (page 546),
but I think it should also be shown in 22.5.6. All other simple expressions
have these properties defined where they are defined. If var selects are
done in this way, then vpiName and vpiFullName can be removed from section
22.5.14.
Proposed Resolution:
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
22.5.6, Add the following properties under the var select object:
-> name
str: vpiName
str: vpiFullName
22.5.14, Remove the properties:
-> name
str: vpiName
str: vpiFullName
<p>************************************************************************
PLI Task Force ID: 194
Summary: Define how vpiLoad and vpiDriver work with vectors
Relevant LRM Sections: 22.5.4
Current Status: TF-Approved
Date Submitted: 08 Jan 1998
Date Analyzed: 09 Feb 1998
Date of Last Action: 02 Mar 1998
Date of Last Action:
Author of Submission: Steve Meyer
Author's Net Address: sjmeyer@crl.com
Description of Problem:
Cross reference to item 171
Add Note 9 (?) in LRM section 22.5.4 page 536:
For VpiLoad and VpiDriver iterators, if passed object is vpiNet
(or vpiReg) for a vectored net (reg), all loads (drivers) are returned
exactly once as the load (driving) object, i.e if a part select load
(drives) only some bits, the load (driver) returned is the part select.
If a driver is repeated, it is only returned once. To trace exact bit
by bit connectivity pass vpiNetBit (or vpiRegBit) object to iterator.
Proposed Resolution:
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
1. 22.5.4, add the following note to the end of the notes:
For vpiLoad and vpiDriver iterators, if the object is vpiNet for a
vectored net, then all loads or drivers are returned exactly once as
the loading or driving object. i.e.: if a part select loads or drives
only some bits, the load or driver returned is the part select. If a
driver is repeated, it is only returned once. To trace exact bit
by bit connectivity pass a vpiNetBit object to the iterator.
2. 22.5.5, add the following note to the end of the notes:
For vpiLoad and vpiDriver iterators, if the object is vpiReg for a
vectored reg, then all loads or drivers are returned exactly once as
the loading or driving object. i.e.: if a part select loads or drives
only some bits, the load or driver returned is the part select. If a
driver is repeated, it is only returned once. To trace exact bit
by bit connectivity pass a vpiRegBit object to the iterator.
************************************************************************
PLI Task Force ID: 195
Summary: Add vpiLocalLoad and vpiLocalDriver
Relevant LRM Sections: 22.5.4
Current Status: Submitted
Current Status: TF-Approved
Date Submitted: 08 Jan 1998
Date Analyzed: 09 Feb 1998
Date of Last Action: 02 Mar 1998
Author's Net Address: sjmeyer@crl.com
Description of Problem:
New Proposal for local intra-module only vpiLocalLoad and vpiLocalDriver
Cross reference to 177
Add two new one-to-many access methods that correspond exactly to
vpiLoad and vpiDriver except only loads (drivers) that are local to
the object's containing instance are returned. Unlike flattened
vpiDriver and vpiLoad, output and inout ports for loads and input
and inout ports for drivers are returned for vpiLocalLoad and
vpiLocalDriver. Note 9 on loads and drivers for vpiNet where net
is vector also applies to local loads and drivers.
Proposed Resolution:
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
1. 22.5.4, add the following to the object diagram:
Two new one-to-many access methods vpiLocalLoad and
vpiLocalDriver, just under the corresponding vpiLoad and vpiDriver
access methods.
2. 22.5.4, add the following note:
vpiLocalLoad and vpiLocalDriver return only the drivers or loads
that are local to the object containing the net, including any
ports connected to the net (output and inout ports are loads,
input and inout ports are drivers).
************************************************************************
PLI Task Force ID: 197
Summary: path from module to process is wrong
Relevant LRM Sections: 22.5.16 (page 548)
Current Status: TF-Approved
Date Submitted: 30 Jan 1998
Date Analyzed: 09 Feb 1998
Date of Last Action: 02 Mar 1998
Author of Submission: Charles Dawson
Author's Net Address: chas@cadence.com
Description of Problem:
Something which I know I have brought up before...
The path from a module to the processes is a one to many tranition. It
is also possible to go from the process to the module (see section 22.5.1,
page 533). This is a one to one transition.
Proposed Resolution:
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
1. 22.5.16, change the single arrow from module to process to a
double arrow in the process data diagram.
2. 22.5.16, add a single arrow from process to module in the process
data diagram.
************************************************************************
PLI Task Force ID: 198
Summary: parameters and spec params should have a size
Relevant LRM Sections: 22.5.8 (page 540)
Current Status: TF-Approved
Date Submitted: 30 Jan 1998
Date Analyzed: 09 Feb 1998
Date of Last Action: 02 Mar 1998
Author of Submission: Charles Dawson
Author's Net Address: chas@cadence.com
Description of Problem:
Parameters and spec params should have the property size. These objects
can be part of an expression which has a size. Therefore these should
have a size as well.
Proposed Resolution:
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
Proposed Resolution:
TF Recommendation for current IEEE Std:
1. On 22.5.8, add the following property to the parameter diagram:
-> size
int: vpiSize
2. On 22.5.8, add the following property to the specparam diagram:
-> size
int: vpiSize
************************************************************************
PLI Task Force ID: 199
Summary: Delete accDevelopmentVersion from examples
Relevant LRM Sections: 18 & 19
Current Status: TF-Approved
Date Submitted: 09 Feb 1998
Date Analyzed: 09 Feb 1998
Date of Last Action: 02 Mar 1998
Author of Submission: Stuart Sutherland
Author's Net Address: stuart@sutherland.com
Description of Problem:
Item 30 (approved) changes acc_configure(accDevelopmentVersion,...)
to have no functionality other than to document what version an
application was written for. Many of the PLI examples in sections
18 and 19 use accDevelopmentVersion to reference the 1995 IEEE
standard. Since the configuration serves no functionality, it is
proposed that all references to accDevelopmentVersion in the PLI
examples be deleted.
Proposed Resolution:
09 Feb 1998:
Unanimously approved (David, Drew, Stu present).
Submit this for e-mail vote by PLI task force.
02 Mar 1998:
No negative votes received from PLI task force.
Submitted for vote by 1364 working group at 10 Mar 98 meeting.
TF Recommendation for current IEEE Std:
In sections 17 through 19, globally search for
"acc_configure(accDevelopmentVersion"
and delete that specific configuration from all examples.
************************************************************************
<p>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland.com
Specializing in Verilog HDL consulting and training. Publisher of the
popular Verilog HDL and Verilog PLI quick reference guides.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:46 PDT
and
sponsored by Boyd Technology, Inc.