From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Thu Oct 05 2000 - 23:45:17 PDT
<x-flowed>
At 06:29 PM 10/4/2000, Clifford E. Cummings wrote:
>JohnW-General #1 ...
BTF,
FYI, the PLI task force has prepared the following responses to John's
comments regarding the PLI sections. This e-mail has not been sent out--we
are waiting until all ballot comments have been addressed by all task
forces. I assume there will be a working group meeting to review all
responses before they are sent.
Stu
=========================
John,
Thank you for your valuable review of the proposed IEEE 1364-2000 Verilog
standard. Your comments reflect a great deal of thought and are very much
appreciated.
The PLI task force within the 1364 Verilog Standards Group has reviewed
your comments regarding the PLI sections of the standard. As we reviewed
each item, two primary criteria were used to determine if a change should
be made to the proposed 1364-2000 reference manual. The first criteria was
whether or not there was an errata in the ballot draft of the
standard. The second criteria was if the suggested change made a
significant clarification to the standard. In some cases the PLI task
force agreed in principle with a suggestion, but felt that the current
wording in the standard was adequate. We will, however, keep these
suggestions on file, for consideration in the next revision of the Verilog
standard.
Following are the decisions we have reached. If you do not agree with any
of our conclusions, we would be happy to revisit those items.
Please send me an e-mail acknowledging your receipt of this message, and
whether you agree or disagree with our decisions.
Stu Sutherland,
co-chair, PLI Task Force, 1364 Verilog Standards Group
=====================================================================
Comment #71: p. 373, Section 21, probably should be named, PLI TF and
ACC interface, and, the fourth bullet after the first paragraph should
say, "...should be treated as functions (which return only a value) or
tasks (analogous to procedures or subroutines in other programming
languages)
REJECTED: The change to the title by removing "mechanism" is not required,
since the section uses the term "interface mechanism". To say that a
system function only returns a value is not correct, because a system
function is allowed to put values onto the writable arguments of the
system function.
Comment #72: p. 373, Section 21.1, User-supplied PLI applications,
before the final paragraph, it would be nice to explain what "TF"
means (<underline_on>t<underline_off>ask-<underline_on>f<underline_off>
unction?).
REJECTED: The PLI task force of the IEEE 1364 standard working group
agrees that the clarification would make the text more friendly, but the
change does not add any technical value and does not correct any errata.
This change will be considered for a future revision of the 1364 standard.
It should be noted that section 20.1 already explains the definition of
TF, ACC and VPI.
Comment #73: p. 373, Section 21.1.1, The sizetf class of PLI
applications, the second sentence probably should read not shall but,
"...how many bits wide that return-value will be."
REJECTED: The IEEE style of language requires the use of "shall" in this
paragraph. "Shall" denotes that all software tools must comply with
this requirement or behavior.
Comment #74: p. 377, Section 22.1, ACC routine definition, after the
first sentence, I suggest adding, "ACC stands for PLI
<underline_on>acc<underline_off>ess".
REJECTED: This is similar to comment #72, and is rejected for the same
reasons. The clarification will be considered for the next revision
of the Verilog language.
Comment #75: p. 378, Section 22.2, The handle data type, it is unclear
whether all handles are the same exact type, or whether there might be
several different predefined (sub)types of handle (there certainly are
in Windows programming). I suggest rewriting the first sentence as,
"Handles are pointer to objects in the design hierarchy. All handles
are of the same predefined data type."
REJECTED: Handles to different types of objects may be different,
and are different in some simulators. Handles are intended to be
an abstract data type, that allow access to the simulation data
structure while at the same time serving as a layer between the
PLI application and the internals of the data structure. The standard
does not state the exact nature of handles in order to allow software
tools latitude on how to implement handles.
Comment #76: p. 379, Section 22.4.1, Fetch routines, the table and
other tables use the word "Get". While this is OK for C++ methods,
which get stuff but generally keep within the class, it is not really
descriptive of what happens in the PLI: The routines return the gotten
data to the caller. Therefore, I suggest relabelling all tabulated
routines, using the word, "Returns the ..." instead of "Gets the...".
REJECTED: Not all routines "return" the value being obtained.
Some routines, such as acc_fetch_delays(), place the values retrieved
into variables instead of returning the values.
Comment #77: p. 405, Section 22.9, String handling, I don't see any
value to including this Section in the standard: It (Sections 22.9.1
through 22.9.4) should be removed entirely. Unless I am missing
something, this section merely describes a user-unfriendly peculiarity
of some specific Verilog implementation. That implementation should
be redone, with dynamic memory allocation for strings, this conforming
with this Standard.
REJECTED: The PLI task force agrees that this section is documenting the
behavior of the original Verilog simulator. However, the task force
feels it is important to keep this section in the standard so that
existing applications that expect this behavior will be portable to
all Verilog simulators.
Comment #78: p. 407, Section 22.10, Using VCL ACC routines, and
subsequent Sections. Suddenly, we find the Standard referring to the
designer, programmer, or other user as a "consumer". This word should
not be used (looks as though an EE student switched to an MBA, forgot
what he was doing, and ended up in SA by mistake). Please see my
General Comment #4.
REJECTED: The two ACC routines which refer to "consumer",
acc_vcl_add() and acc_vcl_delete(), are not referring the simulator
user or PLI the application developer. The "consumer" is the
user-specified routine which is called when a value change occurs.
The PLI task force feels the usage of this term is appropriate in
the context in which it is used.
Comment #79: p. 592, Section 24.3.7, Writing the correct C data types,
the second sentence ("There is no inherent data type checking in the C
language.") should be deleted as false: Ever since ANSI C, C has had
data typing as strong as garlic; however it has been optional. When
desiring strong type checking, one need merely declare tagged structs;
or, better, upgrade to C++.
APPROVED: The sentence "There is no inherent data type checking in the C
language." will be removed from the standard.
Comment #80: p. 671, Section 26.1, VPI system tasks and functions, I
suggest adding a Note mentioning how VPI differs
from PLI ACC and TF.
REJECTED: The PLI task force agrees that further explanation would make
the manual more friendly. However, adding additional explanation is not
correcting an errata in the proposed 1364-2000 standard. The general
differences between the TF, ACC and VPI routines is already covered in
section 20.1. The task force will consider adding additional explanation
in the next revision of the standard.
<p><p>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
</x-flowed>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:14 PDT
and
sponsored by Boyd Technology, Inc.