From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Oct 05 2000 - 08:01:56 PDT
>Date: Thu, 5 Oct 2000 12:45:32 +0300 (IDT)
>From: Shalom Bresticker <shalom@msil.sps.mot.com>
>X-Sender: shalom@eagle
>To: "Clifford E. Cummings" <cliffc@sunburst-design.com>
>Subject: Re: BTF Review Schedule and Assignments - BTF Please Read & Respond
>
>Cliff,
>
>So where is the schedule and assignments ?
Aaargh!!
I somehow only cut-and-pasted a small section that I meant to send
yesterday. Here is the info (thanks, Shalom!)
- Cliff
<p>Dear BTF -
Some questions have been asked about the balloting process and where we
stand. We need to accomplish the following:
- The BTF needs to draft responses to address all comments.
- The BTF will draft and approve any change proposals that we believe
should be incorporated into the IEEE Verilog-2000 Standard
- The VSG will need to vote and approve all of the BTF proposed changes but
will not vote on the BTF responses to comments.
- All VSG approved changes will be re-circulated to all balloters for a
re-vote.
Schedule:
October: We hope to wrap up BTF proposals in the next conference call or two.
November 6th (Maq to confirm): VSG conference call to approve BTF changes.
After November 6th - wrap-up work and re-circulate changes to all balloters.
We hope to have all ballots returned in time to make the December Rev-Con
meeting.
In order to expedite the process, I am asking BTF members to review groups
of comments, write responses or proposals, and e-mail the proposed
responses to the entire BTF at btf@boyd.com. We will discuss the responses
at the next BTF conference call and hopefully wrap up our work at that time.
If you don't have time to address the comments, please e-mail me and let me
know so that I can distribute comments to other BTF members. If you have
time to address additional comments, please let me know in case we have
some that cannot help.
Please send all BNF related comments directly to me.
We also need to quickly identify and forward any comments that should be
addressed by the ATF and PTF.
Would the following BTF team members please review and compose responses or
proposals to address the following comments:
Cliff Cummings - I will prepare the BTF notes on the Cadence comments,
Cliff Cummings' comments and anything BNF that you can identify.
There are approximately 152 additional comments that need to be addressed
(attached below)
Anders Nordstrom - PeterF-Comment1-6 & Stu Sutherland's commentsn (Cliff
will help with Stu's comments)
Steven Sharp - AnneH-TC-1-14 & AnneH-EC 1-12
Adam Krolnik - AnneH-EC 13-32
James Markovitch AnneH-EC 33-52
Mike McNamara - JohnW-General 1-5 & JohnW-Comment 6-20
Shalom Bresticker - JohnW-Comment 21-40
Stefen Boyd - JohnW-Comment 41-60
Kurt Baty - JohnW Comment 61-80
********** COMMENTS **********
Comments from Peter Flake
PeterF-Comment 1. page 143
event e [0:3];
always @ e [i] $display ("event happened");
What happens when i changes? Does the always block trigger?
<p><p>PeterF-Comment 2: pages 15 and 16
Attributes have semicolons in the grammar but not in the examples. Which
is correct?
<p><p>PeterF-Comment 3: page 188
Port declarations can include input declarations, which have semicolons in
the grammar but not in the example on page 191. Which is correct?
<p><p>PeterF-Comment 4: page 78
I believe that variable initializations should occur before initial blocks,
rather than being unordered with respect to initial blocks.
<p><p>PeterF-Comment 5: page 124
Bit select of an integer or time variable is not explained, e.g. what the
bit numbers are. It seems strange that it is not treated like a scalared
reg, which cannot be accessed by bit.
<p><p>PeterF-Comment 6: page 41
Attributes are not mentioned in the discussion of name spaces
*************************
Comments From Stuart Sutherland
By Stuart Sutherland
stuart@sutherland-hdl.com
Phone: 1-503-692-0898
VOTED: Affirmative, Approve as an IEEE Standard with comments.
<p>Typo's:
---------------------------------
- Section 21 (page 373): The first paragraph should end with a semicolon.
- Section 21.3.2, Table 21-1 (pages 375-376): The table continuation variable
has a formatting problem. The text "<boldemphasis>" should be struck.
This problem occurs in several places:
Table 21-1 (page 376)
Table 22-1 (page 380)
Table 22-4 (page 383)
Table 22-11 (page 387)
Table 22-25 (page 394)
Table 22-30 (page 403)
Table 23-23 (page 463)
Table 23-49 (page 529)
- Section 22.5.16, Table 22-24 (pages 393-394): The table title is missing
the "(continued)" on the second page.
- Section 22.8.1, Table 22-27 (page 400): The third description line is
missing a space after the colon. It should read "One delay for: all..."
- Section 22.8.2 (page 400): In the third sentence, the cross reference to
"Table 22-27" should be to "Table 22-28".
- Section 23.2 (page 421): The second paragraph should use "shall" instead
of "will". The sentence should read: "If any of the limits do not meet
the above rules, they shall be truncated."
- Section 23.5 (page 425): The description of the two arguments should be
changed from "Handle to any objects" to "Handle to any object" (singular).
- Section 23.12 (page 444): The word "integer" should be struck from the
synopsis of acc_fetch_attribute_str().
- Section 23.13, Figure 23-14 (page 445): The function type in this
example should be changed from "PLI_INT32" to "void". This example
function is not a calltf routine, and does not return a value.
- Section 23.15, Figure 23-17 (page 451): The function type in this
example should be changed from "PLI_INT32" to "void". This example
function is not a calltf routine, and does not return a value.
- Section 23.18 (page 455): In the second paragraph, the cross reference to
"Table 23-23" should be to "Table 23-19".
- Section 23.18, Table 22-19 (pages 455-456): The table title is missing
the "(continued)" on the second page.
- Section 23.22 (page 464): In the third paragraph, the cross reference to
"Table 23-23" should be to "Table 23-24".
- Section 23.22, Table 22-24 (pages 464-465): The table title is missing
the "(continued)" on the second page.
- Section 23.27 (page 471): The second "double *" in the Argument types
is in the wrong font.
- Section 23.31 (page 478): In the fifth paragraph, first sentence,
change "an PLI_INT32" to "a PLI_INT32".
- Section 23.33 (page 480): In the second paragraph, the cross reference to
"Figure 23-25" should be to "Figure 23-36".
- Section 23.34 (page 482): In the second paragraph, the cross reference to
"Table 23-21" should be to "Table 23-34".
- Section 23.36 (page 487): In the second paragraph, the cross reference to
"Figure 23-39" should be to "Figure 23-40".
- Section 23.48 (page 504): In the third paragraph, the cross reference to
"Table 23-23" should be to "Table 23-42".
- Section 26 (page 671): Strike the first word of the first sentence of the
first paragraph, "Sections".
- Section 26.1 (page 671): In the third paragraph, last sentence, change
"... in TF interface ..." to "... in the TF interface ...".
- Section 26.3.2 (page 675): In the fourth paragraph, first sentence, change
"vpiResolvedType" to "vpiResolvedNetType".
- Section 26.3.3 (page 675): In the first sentence, change "... which is ..."
to "... which are ...".
- Section 26.3.4 (page 676): In the first sentence of the first paragraph,
change "Boolean" to "boolean" (not capitalized).
- Section 26.5 (page 679): In the first sentence of the first paragraph,
change "clause" to "subsection".
- Section 26.6.43 (page 712): Change the object "tchck" to "tchk".
- Section 27.9 (page 725): In the code example, change
"delay_s.da = &prim_da;" to "delay_s.da = prim_da;" (because prim_da is
an array).
- Section 27.33.3 (page 763): In the first sentence of the first paragraph,
change "The vpi_register_cb() can ..." to "The vpi_register_cb() routine
can ...".
Errata:
---------------------------------
- Section 22.1, (page 377): In the list "ACC routines that shall read
information...", change the item "Variables" to "Reg variables". The
other types of variables are listed later in the list.
- Section 22.1, (page 377): In the list "ACC routines that shall read
and write information...", change the item "Variables" to "Reg variables".
- Section 22.1, (page 377): In the list "ACC routines that shall read
information...", the item "Variables" should be "Reg variables". The
other types of variables are listed later in the list.
- Section 22.4.1, Table 22-1 (page 379): The text ", parameter" should be
struck from the descriptions of acc_fetch_attribute(),
acc_fetch_attribute_int() and acc_fetch_attribute_str().
- Section 22.5.13, Table 22-21 (page 392): The description for
acc_fetch_attribute(), acc_fetch_attribute_int() and
acc_fetch_attribute_str() should be to get the value of a "specparam",
not "parameter"
- Section 25.58 (page 663): Strike the sentence "Use tf_getnextlongtime()...
from the list of related routines.
- Section 5.3 (pages 67-68): There are several problems with the
description of how PLI read/write synchronization occurs in the event list.
The core issue is that PLI read/write synchronization DOES NOT take place
as one of the "inactive events". In most simulators, PLI read/write
synchronization occurs between the inactive events and non-blocking update
events, but some simulators process PLI read/write synchronization after
non-blocking updates and before monitor events. The following changes are
suggested, which involve several sections:
*** BEGINNING OF SUGGESTED CHANGES FOR PLI SYNCHRONIZATION DESCRIPTION ***
5.3 The stratified event queue (pages 67-68):
REPLACE ALL OF SECTION 5.3 WITH THE FOLLOWING REVISED TEXT:
The Verilog event queue is logically segmented into six different lists.
Events may be added to any of the six lists, but shall only be processed
from the active list.
1) ACTIVE EVENTS: These are events that occur at the current simulation time.
2) INACTIVE EVENTS: These are events that occur at the current simulation
time, but that shall be processed after all events in the current active
event list are processed.
3) SYNCHRONIZE EVENTS: These are events that are scheduled by the PLI as
read-write synchronization events.
4) NONBLOCKING ASSIGN UPDATE EVENTS: These are events that have been
evaluated during some previous simulation cycle, but shall be assigned
after all events in the current active and inactive event lists are processed.
5) MONITOR EVENTS: These are events that shall be processed after all the
active, inactive, synchronize and nonblocking assign update events are
processed.
6) FUTURE EVENTS: These are events that occur at some future simulation
time. Future events are divided into future inactive events and future
nonblocking assign update events.
The processing of all events in the active events list is called a
simulation cycle.
An explicit zero delay (#0) requires that the process be suspended and
added as an inactive event for the current time so that the process is
resumed in the next simulation cycle in the current time.
A nonblocking assignment (see 9.2.2) creates a nonblocking assign update
event, scheduled for current or a later simulation time.
Monitor events are unique in that they cannot create any other events in
the current simulation time. The $strobe and $fstrobe system tasks (see
Section 17) create monitor events for the current time step. The $monitor
and $fmonitor system tasks (see Section 17) create monitor events for their
arguments. These events are continuously re-enabled in every successive
time step.
PLI call backs scheduled with PLI routines tf_synchronize() (see Section
25.58) or vpi_register_cb() with reason cbReadWriteSynch (see Section
27.33) shall create synchronize events. A software implementation may
process synchronize events either before or after nonblocking assign update
events. The order of processing events within the synchronize events is
nondeterminate and is not under control of the user.
PLI call backs scheduled with PLI routines tf_rosynchronize() (see Section
25.43) or vpi_register_cb() with reason cbReadOnlySynch (see Section 27.33)
shall create monitor events.
==============
Section 5.4, Verilog simulation reference model (page 68)
ADD THE FOLLOWING PARAGRAPHS BEFORE THE FIRST PARAGRAPH:
When simulation advances to a new simulation time, it shall first activate
all inactive events in that time step. The simulator shall then process all
events in the active event list. When an event is processed, it is removed
from the active event list and disappears. As the active events are
processed, new events may be added to any of the six event lists, including
the end of the active event list. Once all active events have been
processed, the simulator will activate all events in the inactive event
list, and begin processing those events. The processing of these newly
activated events may result in new events being added in any of the event
lists, including new inactive events. After all the new active events are
processed, the simulator will active any new inactive events and process
those new events. When there are no more inactive events to be processed,
the simulator will then activate all events in the next list, which may be
either the synchronize event list or the nonblocking assign update event
list (depending on the implementation). As these new events are processed,
new events may be added to any of the six event lists. After executing the
new active events, the simulator will once again activate any inactive
events, then activate events in the next event list, and so forth.
Activating the events within the inactive, synchronize, nonblocking assign
update or monitor event lists begins a new simulation cycle within the
current simulation time step. This loop of activating events from one of
the event lists and beginning a new simulation cycle will repeat until all
event lists in the current simulation time are empty, at which time
simulation will advance to its next simulation time.
==============
Section 5.4, Verilog simulation reference model (page 68)
ADD THE FOLLOWING LINES AFTER THE LINE "activate all inactive events;":
} else if (there are synchronize events) {
activate all synchronize events;
==============
Section 5.4, Verilog simulation reference model (page 68)
ADD THE FOLLOWING NOTE AFTER THE CODE EXAMPLE:
- NOTE-events in the synchronize events list may be activated before or
after events in the nonblocking assign update events list.
==============
Section 24.6, Simulation Synchronization
CHANGE THE FIRST SENTENCE OF THE THIRD PARAGRAPH FROM:
The tf_synchronize() routine shall place a callback at the end of the
inactive event queue for the current time step.
CHANGE TO:
The tf_synchronize() routine shall place a callback in the synchronize
event list for the current time step (see section 5.3).
==============
Section 24.6, Simulation Synchronization
CHANGE THE FIRST SENTENCE OF THE FOURTH PARAGRAPH FROM:
The tf_rosynchronize() callback shall occur after all active, inactive, and
nonblocking assign update events for a time step have been processed.
CHANGE TO:
The tf_rosynchronize() routine shall place a callback in the monitor event
list for the current time step, after all active, inactive, synchronize and
nonblocking assign update events for a time step have been processed (see
section 5.3).
==============
Section 25.43, tf_rosynchronize
ADD THE FOLLOWING TO THE END OF THE 1ST PARAGRAPH:
Callbacks scheduled by tf_rosynchronize() and tf_irosynchronize() shall be
scheduled with other monitor events in the stratified event list (see
section 5.3).
==============
Section 25.58, tf_synchronize
ADD THE FOLLOWING TO THE END OF THE 1ST PARAGRAPH:
Callbacks scheduled by tf_synchronize() and tf_isynchronize() shall be
scheduled with other synchronize events in the stratified event list (see
section 5.3).
==============
Section 27.33.2, Simulation-time-related callbacks
CHANGE THE THIRD AND FOURTH PARAGRAPHS FROM:
cbReadWriteSynch Callback shall occur after execution of events for a
specified time.
cbReadOnlySynch Same as cbReadWriteSynch, except that writing values or
scheduling events before the next scheduled event is not
allowed.
CHANGE TO:
cbReadWriteSynch Callback shall be scheduled in the synchronize event list
for a specified time (see section 5.3).
cbReadOnlySynch Callback shall be scheduled in the monitor event list for
a specified time (see section 5.3); writing values or
scheduling events before the next scheduled event is
not allowed.
*** END OF SUGGESTED CHANGES FOR PLI SYNCHRONIZATION DESCRIPTION ***
<p>Comments From Anne Harris
IEEE P1364, Draft 5 Revision
Standard for Verilog(r) Hardware Description Language
Review Comments from Anne C. Harris
09 July 2000
<p>Technical Comments:
AnneH-TC-1) On page 46, in the fourth example, is -4'sd12 / 3 really 4? I
think that 4 is just an intermediate result for -4'sd12.
Anne is right this needs to be addressed
AnneH-TC-2) On page 48, in section 4.1.6, the text says that a reg is
treated as unsigned, but Table 4-8 shows a signed reg treated as a signed
2's complement (the same as an integer)
Needs to be addressed
AnneH-TC-3) On page 53, in example 2, neither start nor result is a signed
reg. According to the text before the examples, zero filling should be
used in this case, not sign filling.
<p><p>Yes - start should be declared signed so the example works
AnneH-TC-4) On page 113, it would be useful to show an example of the new
UDP header format.
<p><p>True - but no example will be added
AnneH-TC-5) On page 114, in Table 8-1, it says that "x" is not permitted in
the output field of a UDP. If this is true, then the example for notifier
regs in timing checks on page 265 is wrong, and there is no way to do
notify reg error handling in a UDP.
Table 8-1 needs to be fixed for "x"
AnneH-TC-6) On page 131, in section 9.3.2 paragraph 1, it says that the
left hand side of a force statement may be a bit or part select of a vector
net. However, on page 130, in the last paragraph of section 9.3, it says
that neither a bit select or a part select of a vector net is allowed for a
force. Which is correct?
Change 130 to not allow force on regs but is allowed it on nets
AnneH-TC-7) On page 250, in the middle of the page, in the description of
when $setuphold reports a timing violation, timecheck appears instead of
timestamp. The correct condition is:
>(beginning of time window) < (timestamp time) <= (end of time window)
Send to ATF!!
AnneH-TC-8) On page 254, in the middle of the page, in the description of
when $recrem reports a timing violation, timecheck appears instead of
timestamp. The correct condition is:
>(beginning of time window) < (timestamp time) <= (end of time window)
Send to ATF!!
AnneH-TC-9) On page 254, in the last sentence of section 15.2.6, change
$setuphold to $recrem.
<p><p>Send to ATF!!
AnneH-TC-10) On page 257, the text under case 2 should go with case 3
instead. In case 2, the remain active flag is not set, so only one
violation should be reported after a rising edge on CP. The text currently
in the document for case 3 saying that all CPN edges would cause a
violation is wrong because CPN edges after E would not cause violations,
since the rising CP edge at F with MODE low would disable the check.
Send to ATF!!
AnneH-TC-11) On page 284, in the second bullet item, "For each % character"
should be "For each % character, with the exception of %m".
Proposed: Steven
Second: Mac
Passed
AnneH-TC-12) On page 299, in section 17.2.4.4, there is an inconsistency.
In the second paragraph, it says that loading starts from the LSB if there
is no start argument. In the fifth paragraph, it says that loading starts
at the lowest numbered location. The lowest numbered location does not
have to be the LSB.
<p><p>AnneH-TC-13) On page 338, note 1 says that part of a vector cannot be
dumped to a VCD file. However, on page 342, item c), it says that an
individual bit of a vector can be dumped. If bit-selects of a vector are
allowed, but part-selects are not, this should be stated clearly in one
place and not split across two different sections of the document.
<p><p>AnneH-TC-14) On page 634, in Figure 25-6, node_ms_index, node_ls_index,
node_lhs_element, and node_rhs_element are declared. On page 636, at the
end of the page, node_ms_element, node_ls_element, node_lhs_index, and
node_rhs_index are referred to. According to Annex F, the names in Figure
25-6 are correct, and page 636 is wrong.
<p><p>Editorial Comments:
>
AnneH-EC-1) On page 16, "parallel" is spelled "paralee" the first three
times that it is used.
<p><p><p><p>AnneH-EC-2) On page 16, the two cases in example 3 appear to be identical.
What was supposed to be different?
<p><p>AnneH-EC-3) On page 24, "delay2" is declared but it isn't used.
<p><p><p><p>AnneH-EC-4) On page 70, in section 5.6.3, change "(or if it returns
immediately" to "(it returns immediately".
<p><p><p><p>AnneH-EC-5) On page 84, in example 3, the declaration of "in" in the module
busdriver should be "busin".
<p><p>AnneH-EC-6) On page 84, in example 4, setting the default value for the
parameter bits to "1" creates an uninteresting row of just one flip flop.
It might be better to choose a different default number.
<p><p>AnneH-EC-7) On page 113, in the second paragraph in section 8.1.1,
"parenthesis" should be "parentheses".
<p><p><p><p>AnneH-EC-8) On page 113, in section 8.1.2, it would be more clear if you
said "or as part of the output declaration, when using either the first or
second form". Also, the first occurrence of "output declaration" in this
sentence does not use an "_", but the second occurrence does - be consistent.
<p><p>AnneH-EC-9) On page 114, in section 8.1.4, it would be clearer if the last
sentence were worded "It is illegal to have the same combination of inputs,
including edges, produce different outputs", or "It is illegal to have the
same combination of inputs, including edges, result in different outputs".
Or yet another approach would be "It is illegal to specify exactly the same
combination of all table inputs, including edges, in more than one table
entry in a UDP".
<p><p>AnneH-EC-10) On page 125, change "reg_lvalue" in the first paragraph (two
occurrences) to "variable_lvalue" to be consistent with Syntax 9-1.
<p><p>AnneH-EC-11) On page 126, change 3 occurrences of "reg_lvalue" to
"variable_lvalue".
<p><p><p><p>AnneH-EC-12) On page 130, in section 9.3.1, change "reg" to "variable".
<p><p><p><p>AnneH-EC-13) On page 131, the last sentence in section 9.3.1 seems out of
place. "If either operand to an arithmetic operator is real, the resulting
expression is of type real" doesn't seem to have anything to do with the
discussion of the assign and deassign statements.
<p><p>AnneH-EC-14) On page 131, in section 9.3.2 paragraph 2, change "(as would a
net that is forced)" to "(as would a net that is assigned)".
<p><p>AnneH-EC-15) On page 158, in the example showing the second form of a task
declaration, remove the ";" after my_task. A semicolon should not separate
the task name from the port declarations inside the parentheses in the
second form.
<p><p>AnneH-EC-16) On page 161, in the fourth paragraph, the wrong bolding is
used. "endfunction keyword" should be "endfunction keyword".
<p><p><p>AnneH-EC-17) On page 165, the third paragraph starts off with "Either form
of disable statement". I only see one form described in Syntax 11-1.
<p><p><p><p>AnneH-EC-18) On page 183, in section 12.2 in the first paragraph, "This
first in the module_parameter_port_list" should be "The first is the
module_parameter_port_list".
<p><p>AnneH-EC-19) There are two pages 203 and two pages 204.
<p><p><p><p>AnneH-EC-20) On page 210, in section 13.4.1, "and map it into" should be
"and maps it into".
<p><p><p><p>AnneH-EC-21) On page 219, in the fourth paragraph of section 14.2.3, the
description of path destinations could be made clearer.
>"For parallel connections (=>), the destination shall be any scalar output
or inout port or one of its bit-selects" could change to "For parallel
connections (=>), the destination shall be any scalar output or inout port
or the bit-select of a vector output or inout port".
>"For full connections (*>), the destination shall be a list of one or more
of the vector or scalar output and inout ports, and bit-selects or
part-selects of those ports" could change to "For full connections (*>),
the destination shall be a list of one or more of the vector or scalar
output and inout ports, and bit-selects or part-selects of vector output
and inout ports".
<p><p>AnneH-EC-22) On page 237, in section 14.6.4.2 in paragraph 4, "It is an
error if a a module path" has an extra "a" in it.
<p><p>AnneH-EC-23) In the last paragraph on page 237, add "second" and "last" or
"third" designators. "The second waveform shows showcancelled behavior in
conjunction with on-event. The last waveform shows showcancelled behavior
in conjunction with on-detect".
<p><p>AnneH-EC-24) On page 259, in paragraph 2, change "$timeskew" to "$fullskew".
<p><p><p><p>AnneH-EC-25) On page 259, in case 2, "This transition at 'B'" should be
"This transition at 'C'".
<p><p>AnneH-EC-26) On page 296, in section 17.2.4, the wording is very awkward.
Try something like "Files opened using file descriptors may be read from,
only if they were opened with either the "r" or "r+" type values.
<p><p>AnneH-EC-27) On page 296, in section 17.2.4.1 in the sentence beginning
with "Care should be taken", the word "return" is used three times. This
sentence is very awkward. Try something like "Care should be take to define
the width of the reg which gets the return value of $fgetc to be wider than
8 bits. This allows EOF (-1) to be read from the reg as 0xff in the event
of an error."
<p><p>AnneH-EC-28) On page 297, in the paragraph starting with "Both functions
read" near the top of the page, there is a plural/singular agreement
problem. Should be "Both functions read characters, interpret them
according to a format, and store the results".
<p><p>AnneH-EC-29) On page 298, should the 'z' format get its own section? It is
currently described in the 'u' section.
<p><p>AnneH-EC-30) On page 325, the code for the poisson distribution is shown
twice. The code for the chi_square distribution appears on page 325, but a
partial duplicate also appears on page 326.
<p><p><p><p>AnneH-EC-31) On page 328, at the end of the second paragraph, change
"remainding" to "remaining".
<p><p>AnneH-EC-32) On page 342, item c), "The individual bits of vector nets can
be dumped individually" could be better worded as "A bit-select of a vector
net can be dumped".
<p><p><p><p>AnneH-EC-33) On page 342, in item d), it would be clearer if "identifier"
were replaced with "reference identifier".
<p><p>AnneH-EC-34) On page 361, in bullet 8, it should be stated that the `else
clause is only evaluated if none of the preceding `ifdef or `elsif
conditions are defined.
<p><p>AnneH-EC-35) On page 361, bullet 9 should not be a bulleted item, since
unlike the rest, it doesn't describe the decision flow of the `ifdef,
`else, `endif group of directives.
<p><p><p><p>AnneH-EC-36) On page 362, in bullet 4, it should be stated that the `else
clause is only evaluated if the preceding `ifndef condition is defined and
none of the preceding `elsif conditions are defined.
<p><p>AnneH-EC-37) On page 362, bullet 5 should not be a bulleted item, since
unlike the rest, it doesn't describe the decision flow of the `ifndef,
`else, `endif group of directives.
<p><p>AnneH-EC-38) On page 366, in line 2, there should be a space in
"timespecified" so that it is "time specified".
<p><p><p><p>AnneH-EC-39) On page 462, in Table 23-23, there is an entry for "regs or
variables" and another for "integer, time and real variables". The first
entry should just be "regs" instead of "regs or variables".
<p><p>AnneH-EC-40) On page 520, retitle Figure 23-60 as "Using
acc_handle_tchkarg1(), acc_handle_tchkarg2(), and acc_handle_notifier"
since this figure is referenced also in section 23.47 on acc_handle_notifier.
<p><p>AnneH-EC-41) On page 597, in the first paragraph, change "function However"
to include a period ("function. However").
<p><p><p><p>AnneH-EC-42) On page 662, "The text message generated by this example is
split off the io_printf() calls" would be clearer as "The text message
generated by this example is split between the two io_printf() calls".
<p><p>AnneH-EC-43) On page 675, in section 26.3.3 in the first line, "which is"
should be "which are".
<p><p>AnneH-EC-44) On page 676, in paragraph two of section 26.3.4, an extra
comma is needed before the word 'and':
>"The routines, C structures, and some examples".
<p><p><p><p>AnneH-EC-45) On page 721, at the end of the first paragraph, a possessive
is needed: "An application can get the path to the simulation's
save/restart location".
<p><p>AnneH-EC-46) On page 745, there is an extra comma. Change "file, opened,
using" to "file, opened using".
<p><p><p><p>AnneH-EC-47) On page 799, there is a missing square bracket. Change "[C.6"
to "[C.6]".
<p><p>AnneH-EC-48) On page 803, in item 1), change "in either initial and always
blocks" to "in either initial or always blocks".
<p><p><p><p>AnneH-EC-49) On page 803, in the next to last paragraph of section C.7, the
wording is very awkward: "The reset_value argument is an integer that
specifies whose value is returned..." ???
<p><p>AnneH-EC-50) On page 807, section D.1, change "The `default_decay_time
compiler directives" to the singular "The `default_decay_time compiler
directive".
<p><p>AnneH-EC-51) On page 807, place a white-space character between the
directive and the value:
>`default_decay_time integer_constant
>`default_decay_time 100
>`default_decay_time infinite
<p><p><p><p>AnneH-EC-52) On page 808, place a white-space character between the
directive and the value:
>`default_trireg_strength integer_constant
<p>IEEE P1364, Draft 5 comments Anne C. Harris 5 of 1
*******************
Comments From John Williams
Before enumerating by page, I have a few general comments.
JohnW-General #1: The PLI and maybe VF really are not part of the Verilog
Hardware
Description language; they don't describe hardware very much. So, perhaps they
should be moved to a different standard, one for access to a Verilog
simulator or
synthesizer database?
<p><p>JohnW-General #2: This document is too "flat" for a standard so big. I
suggest a
reorganization of the material into a smaller set of related categories. I am
supplying the following as an example:
I. Introduction and Overview, with minimal hierarchical Verilog design
example, including some timing checks.
II. Functional-modelling language elements (modules, nets, etc).
III. Library model language elements (UDPs, etc).
IV. Design hierarchy representation.
V. Timing checks & formats.
VI. Simulator and compiler elements (system tasks; compiler directives;
etc).
VII. Backannotation.
VIII. VPI.
IX. Backus-Naur, Annexes, etc.
<p><p>JohnW-General #3: Often, terms are used before being defined, and no
indication is given
as to where to find them. For example, "nonblocking" and "static".
Instances are
indicated specifically below.
The circumstances under which one would use the PLI often seem not obviously
defined. Does the "PLI" run on the Verilog source code? On the compiled but
not
yet simulated Verilog simulator db? On the simulation runtime code in memory?
What is the file format of the db that one must create to use the PLI? The
TF? The
VPI?
<p><p>JohnW-General #4: In the PLI areas, I often find the end-user of this
document being
called a "consumer". This creates a strange image of a design engineer. A Std
document might get dog-eared, but it never will be "used up" or "consumed",
so why
call the user a "consumer"? I suggest simply "user", or maybe "Verilog
designer",
"design engineer", or "code interface writer", depending on context.
<p><p>JohnW-General #5: For this ballot, I read most of the language
specification closely; I
merely skimmed the PLI; and, I just looked at the VPI and Annex material. So,
ones reassurance as to thoroughness of my criticism should be weighted
accordingly.
Nevertheless, I used up a whole pad of sticky notes . . ..
Pagewise Comments:
<p><p>JohnW-Comment #6: p. iii, Introduction, 2nd paragraph, last sentence:
Delete "It is
because of these rich features that". Reads like a tacky self-advertisement to
conceal a deficiency somewhere.
<p><p>JohnW-Comment #7: p. iii, Introduction, 3rd paragraph, after 3rd sentence:
After ". . .
nets and variables", add "The nets represent electrical or logical wires;
the variables
represent values of electrical or logical expressions."
<p><p>JohnW-Comment #8: p. xxxiii, after List of Tables, add a list of examples,
by design object
(adder, gate-level flip-flop, fifo, etc). These are scattered throughout
the text of this
big document, and designers will have to page around a lot to find one they
recalled
having seen.
<p><p>JohnW-Comment #9: p. 7, Section 2.3, Comments, add to the end, ", and
neither shall a
block comment token in a one-line comment." Thus, comments can't be
interleaved,
as well as can't be nested.
<p><p>JohnW-Comment #10: p. 7, Section 2.5, Numbers, add after the end,
"Real" here refers to floating-point format or other noninteger
numbers; it does not refer to the "real" vs imaginary part of a
complex number.
<p><p>JohnW-Comment #11: p. 7, Section 2.5, Numbers, Syntax 2-1. This really
should be a
general comment, I guess, but in this and almost every other Syntax box,
there seem
to be bitmapped font characters. I think the bitmapping is supposed to be
BOLD,
but the word processor or hard-copy printer used for this draft document
can't seem
to get them right. For example, the third lhs says, exp ::= e | E, but the
rhs is
bitmapped and grainey. Almost every line after lhs decimal_base is full of
grainey
characters. This is OK in a draft, but it should be fixed before final
typesetting.
<p><p>JohnW-Comment #12: p. 9, Section 2.5.1, Integer Constants, 4th paragraph
from top,
change the first sentence to read, "The second token, a base_format, shall
consist of
a case-insensitive letter . . .".
<p><p>JohnW-Comment #13: p. 11, Section 2.5.2, Real Constants, below the last
examples of
invalid formats, I suggest adding, "Decimal points are illegal for numbers
in binary,
hex, or octal format." Better: The standard should be changed to ALLOW real
numbers at least in decimal-like binary format (e. g., 'b0101.1110, where the
fractional part would mean 14/16 == 7/8).
<p><p>JohnW-Comment #14: p. 11, Section 2.6, Strings, first line of paragraph:
Here as well as
occasionally elsewhere, "smart quotes" are being used (this is what
Microsoft Word
calls them). These "smart quotes" are not ASCII standard characters and
generally
can not be found on a standard keyboard. They should not appear in this
document. So, change ". . . enclosed by double quotes ("") and . . ." to ".
. . enclosed
by double quotes ("") and . . .". Some programmers like the smart quotes for
sentimental historical reasons or because they are symmetrical, like open &
close
parens. But they are not standard. Maybe a Note should explain this here?
<p><p>JohnW-Comment #15: p. 12, Section 2.6.1 and 2.6.2: Smart quotes should be
changed (see
Comment #14).
<p><p>JohnW-Comment #16: p. 14, Section 2.7.4, System tasks and functions, after
the first
sentence, add, "System constructs are not design semantics but refer to
simulator
functionality."
<p><p>JohnW-Comment #17: p. 15, Section 2.8, Attributes, before the last sentence
on this page, I
suggest stating that attributes are boolean objects which, if present, only
may be
evaluated as true or false in a boolean expression. As elsewhere in Verilog
or C,
wherever meaningful, true means 1 and false means 0.
<p><p>JohnW-Comment #18: p. 16, Section 2.8.1, Examples, in all three parts of
Example 1,
parallel_case is mispelled "parallee_case".
<p><p>JohnW-Comment #19: p. 23, Section 3.2.1, Net declarations, the last
sentence in the first
paragraph ("It is illegal . . .") is not necessary here. This is a general
feature of any
modern programming language: The scope and conflict of names. If this has
to be
somewhere, it should be moved maybe to 2.7.
<p><p>JohnW-Comment #20: p. 26, Section 3.3.1, Specifying vectors, the two Notes
at the end
actually specify part of the standard; they should be plain text, not Notes.
<p><p>JohnW-Comment #21: p. 27, Section 3.4.1, Charge strength, I suggest adding
an example
declaration here.
<p><p>JohnW-Comment #22: p. 28, Section 3.6, Net types, really should not be just
a random list.
I suggest reorganizing Table 3-1 in five columns with labels: Connection
elements
= wire & tri; Logical connection elements = wor, wand, trior, & triand;
Logic storage
elements = trireg; Pull elements = tri0 & tri1; Supply elements = supply0 &
supply1.
<p><p>JohnW-Comment #23: p. 35, Section 3.9, Integers, reals, times, and
realtimes, ends with a
Note which specifies part of the standard. It should be text, not a Note.
<p><p>JohnW-Comment #24: p. 35, Section 3.9.2, Conversion, first paragraph ends
with the
statement, "The ties shall be rounded away from zero". I am not sure what this
means, so perhaps it should be deleted: What is tied here?
<p><p>JohnW-Comment #25: p. 36, Section 3.10, Arrays, I think the first two example
declarations should read,
reg x[11:0] scalar reg with 12, 1-bit elements
wire [0:7] y[5:0] eight-bit-wide vector wire indexed from 0 to 7
<p><p>JohnW-Comment #26: p. 37, Section 3.10.3.1.1, Array Declarations, I think
"reg rega;"
should be declared here to be used in the next section.
<p><p>JohnW-Comment #26a: p. 37, Section 3.10.3.1.1, Array Declarations, after
the declaration
examples, I suggest adding a Note: "Note: The reasoning here is the same as
for
numerical constants, in that the width comes first. For example, 16'h0531
has a
width of 16, just as reg [15:0] x does.
<p><p>JohnW-Comment #27: p. 37, Section 3.10.3.1.2, Assignment to array elements,
ends with a
Note which actually specifies part of the standard and should be moved as
text to
Section 3.10. Contrariwise, the immediately following Section 3.10.3.1.3
should be
deleted and its text moved as a Note to Section 3.10.3.1.1.
<p><p>JohnW-Comment #28: p. 38, Section 3.11, Parameters, should address the
question of
rounding when assignment is from a wider to a narrower range.
<p><p>JohnW-Comment #29: p. 38, Section 3.11.1, Module parameters, the caption
for Syntax 3-4
should read, "Syntax for module parameter declaration", even though
Backus-Naur
for local parameters is included. Or, it should be moved to Section 3.11.
<p><p>JohnW-Comment #30: p. 41, Section 3.12, Name spaces, the third paragraph
should end
with, ". . . shall not be defined again in that space, whether of the same
or a
different type."
<p><p>JohnW-Comment #31: p. 43, Section 4, Expressions, I suggest adding a Note:
"Expressions
differ from statements. An expression merely shows how a value is to be
computed;
a statement uses one or more values to change the state of something--for
example,
the state of the simulation. It is not hard to see that '==' or '===' may
be part of an
expression; however, '=' always is part of an assignment statement."
<p><p>JohnW-Comment #32: p. 47, Section 4.1.5, Arithmetic operators, in the
paragraph about
power operators, I suggest adding a specification that implied division by
zero shall
be handled by conversion to 'x' or an x vector.
<p><p>JohnW-Comment #33: p. 51, Section 4.1.9, Logical operators, the entire
"recommendation"
should be a Note: It doesn't make sense to make a recommendation part of the
specification of a standard. How could it be decided whether some Verilog
conformed with such a standard?
<p><p>JohnW-Comment #34: p. 60, Section 4.2.3.3, Null string handling, the
examples all are in
"smart quotes", which are illegal in ASCII.
<p><p>JohnW-Comment #35: p. 62, Section 4.3, Minimum, typical, and maximum delay
expressions, the Example 2 text at the top of the page should say, ". . .
shows a
typical expression . . .".
<p><p>JohnW-Comment #36: p. 64, Section 4.4.3, Example of self-determined
expressions should
end with the example, c=21 // example size is 16 bits (size of c).
<p><p>JohnW-Comment #37: p. 68, Section 5.3, The stratified event queue, around
the middle of
the page, should include a Note explaining blocking briefly & referring to its
explanation (5.6.3 & 9.22).
<p><p>JohnW-Comment #38: p. 77, Section 6.2.1, Variable declaration assignment,
says in the
first paragraph that "Variable declaration assignments to an array are not
allowed".
Why not? This exception seems merely to make things harder for the designer
and
should be deleted from the standard.
<p><p>JohnW-Comment #39: p. 82, Section 7.1.5, The range specification, says in
the third
paragraph that one instance identifier shall be associated with only one
range, and
the example, nand #2 t_nand[0:3] (. . .), t_nand[4:7] (. . .); is
shown illegal. Why? So long as there is no implied name conflict (t_nand[j]
declared more than once), array-name holes should be allowed.
<p><p>JohnW-Comment #40: p. 86, Section 7.3, buf and not gates, The paragraph
second from
the bottom of the page is not only pedantically repetitive, but it is
confusing because
it is repetitive. A designer would have to spend time comparing this and
the very
similar statement in Section 7.2, to be sure there was no difference in the
details.
This paragraph should be shortened to read in its entirety, "The delay
specification
shall be zero, one, or two delays, with meanings identical to those of 7.2."
<p><p>JohnW-Comment #41: p. 87, Section 7.4, bufif1, bufif0, notif0, and notif1
gates, I suggest
rewriting the first line as, "The instance declaration of these three-state
logic gates .
. .". The term, tristate, has been trademarked by National Semiconductor
and is not
necessary for this document.
<p><p>JohnW-Comment #42: p. 89, Section 7.5, MOS switches, the first three entire
paragraphs
on this page, as in Comment #40, simply repeat a previous description. They
should be deleted and replaced by something such as, "The delay
specification shall
be zero, one, two, or three delays, with meaning and terminal arrangement
as in
7.4."
<p><p>JohnW-Comment #43: p. 111, Section 8, User-defined primitives (UDPs), ends
with a
second-from the last sentence saying that the output shall be in one of
three states,
0, 1, or x. Why is not z allowed? This exception probably should be
eliminated.
Also, as in Comment #41, I suggest saying "three-state" instead of "tristate".
Finally, I also suggest a Note around here, explaining why UDPs might be
useful:
After all, a case variant in a module would allow one to define a lookup
table, too.
<p><p>JohnW-Comment #44: p. 113, Section 8.1.1, UDP header, the third sentence of
the first
paragraph probably should read, "This in turn is followed by a
comma-separated list
of port names enclosed . . .." Also, the second sentence in the second
paragraph
should say, ". . . comma-separated list of port declarations . . .".
<p><p>JohnW-Comment #45: p. 113, Section 8.1.1, UDP header, the third paragraph says
bidirectionals and vector port declarations are not allowed on a UDP. Why not?
Why this apparent irregularity in Verilog?
<p><p>JohnW-Comment #46: p. 155, Section 10.2, Tasks and task enabling, I suggest
that a new
paragraph be inserted before the first one here, or maybe at the start of
Section 10,
defining what "enable" means. A reader unfamiliar with Verilog will not
understand the similarity of an enabled task to an executing VHDL procedure
or a
called function in C. Is an "enabled" task somehow like a latch or gated
clock, or a
three-state? How does "enable" differ from "activate"?
<p><p>JohnW-Comment #47: p. 155, Section 10.2, Tasks and task enabling, final
sentence on this
page: Closely related to the previous Comment, it is unclear whether a task
enabled by another task necessarily has been declared or instantiated
within the
latter (in a nested or hierarchical sense). For example, suppose a task
changed the
value of a reg during simulation, and the change in turn propagated through
some
logic, maybe even to another module, and caused a second task to be
enabled. Does
this Section mean to say that the first task "enabled" the second?
In any event, I suggest the last sentence be replaced by, "Regardless of
how many
other tasks have been enabled by a certain task, control shall not be
returned by
that task until all tasks it enabled have returned control to it."
<p><p>JohnW-Comment #48: p. 159, Section 10.2.3, Task memory usage and concurrent
activation, should be preceded by a definition of what "static" means.
<p><p>JohnW-Comment #49: p. 162, Section 10.3.4, Function rules, Rule a possibly
should deal
with the case in which the '#' character introduces a parameter?
<p><p>JohnW-Comment #50: p. 162, Section 10.3.4, Function rules, Rule e should
allow for an
alternative usage, in which the function may be returned by executing a
return(value) statement, as in C.
<p><p>JohnW-Comment #51: p. 186, Section 12.2.2, Module instance parameter value
assignment, possibly includes a typo on the second line of the first
paragraph: I
think it should be, "They are: Assignment by ordered . . .".
<p><p>JohnW-Comment #52: p. 188, Section 12.2.3, Parameter dependence, seems
fairly obvious
and should be deleted or possibly rewritten as a Note or example.
<p><p>JohnW-Comment #53: p. 188, Section 12.3.4, may have a typo and probably
should be
called Port name declarations. Also, the second sentence of the first
paragraph is
ambiguous: Does it refer to all modules in a given design or compiler run?
Or (as I
think), just all port names in a given module? I suggest the second
sentence begin
with, "Each module . . .", or, maybe, "Any one module . . .".
<p><p>JohnW-Comment #54: p. 201, Section 12.6, Scope rules, end of second
paragraph from the
bottom might be improved a little by rewriting as, ". . . instance the same
name as
that of the net connected . . .".
<p><p>JohnW-Comment #55: p. 202, Section 12.6, Scope rules, I do not understand what
"precedence" means in the second paragraph. Does this mean there will not be a
name conflict if there is a module name and an instance name the same? If
there
will be a name conflict, then what difference would "search order" make?
Also, the
final sentence refers to a "downward path", which should be defined here.
<p><p>JohnW-Comment #56: p. 203, Section 12.6, Scope rules, I suggest the caption
be changed
to, "Figure 12-3 -- Scope of upward name referencing for nonhierarchical
names."
<p><p>JohnW-Comment #57: p. 209, Section 13.3.1.6, The use clause, I suggest the
last sentence
be changed to a Note.
<p><p>JohnW-Comment #58: p. 210, Section 13.4, Using libraries and configs, the
entire Section
13.4 should be removed from the binding text of the standard and changed to
a Note
or Annex, or maybe added to a nonbinding Introduction somewhere.
<p><p>JohnW-Comment #59: p. 213, Section 13.7, Reserved words, should be deleted
or changed
to a Note: These words already are in Annex B; respecifying that they are
reserved
here merely establishes dual points of control and creates unnecessary
opportunity
for error in the standard document.
<p><p>JohnW-Comment #60: p. 275, Section 16.2, Mapping of SDF constructs to
Verilog, possibly
should be reworded to say, ". . . replacing the timing values in the
Verilog file with
those from the SDF file." When synthesis of netlists is involved, there may be
several different design representations present, including RTL Verilog, and
Verilog, VHDL, or proprietary netlists.
Question: Should it be required that all SDF backannotation be reversible?
So that
it always shall be possible to recover the original timing values, before
backannotation, by a single backannotation run? This would be equivalent to
requiring that backannotation never could replace a timing format of n
values with
a different format of m values.
<p><p>JohnW-Comment #61: p. 285, Section 17.1.1.1 through Section 17.1.1.4, each
final
example should be made neater. Perhaps a little box with dotted lines and
rounded
corners should be used to represent the screen display during simulation?
<p><p>JohnW-Comment #62: p. 286, Section 17.1.1.2, Format specifications, third
paragraph
from the bottom. There is a problem in allowing the data to be written in the
native machine integer format, which varies with CPU hardware and compiler,
and
may be anywhere from 16 to 128 bits. I suggest standardizing and explicitly
requiring a definite width, say signed 32 bits, for data. Let the user
figure out
whatever native format specifier should be coded; if the user has unusual
hardware
or compiler, he or she will know it. This will improve portability and
reusability of
the data.
<p><p>JohnW-Comment #63: p. 304, Section 17.3.1, $printtimescale, the text just
before the
example probably should say, "The timescale information shall appear in the
following format:". Likewise, just after the example, it probably should
say, "The
information about c_det shall be displayed in . . .".
<p><p>JohnW-Comment #64: p. 318 - p. 327, Section 17.9.3, Algorithm for
probabilistic
distribution functions, I suggest that the code be moved to an Annex.
Perhaps it should be explicitly stated whether it is allowed to use an
improved
algorithm (maybe a numerical recipe in assembly language) which achieves the
same result? Also, technically, a "distribution function" of a random
variable is a
cumulative distribution function, an integral of the probability density
function from
the low end of the domain.
<p><p>JohnW-Comment #65: p. 334, Section 18.1.5, Limiting the size of the dump file
($dumplimit), really should include an option to allow the file to become a
FIFO on
limit: In a long simulation, often it is the latest data that are of
interest to the
designer.
<p><p>JohnW-Comment #66: p. 340, Section 18.2.3.2, $date, should default to the
yyyy MM dd
hh:mm:ss format, which makes sorting things by date much easier.
<p><p>JohnW-Comment #67: p. 342, Section 18.2.3.8, $var, seems to have a typo in
the final
example: Shouldn't the format be, "integer 32 addr[31:0]"? The unmatched
parenthesis here and elsewhere makes me uneasy.
<p><p>JohnW-Comment #68: p. 360, Section 19.3.1, ' define, I suggest some text or
a Note
explaining whether recursion is allowed in macroes, and whether macro
references
are allowed in macro definitions. For example, is this legal:
'define nand reg nand['high_bit:'low_bit]
<p><p>JohnW-Comment #69: p. 360, Section 19.3.2, ' undef, the final text should
be expanded to
read, "A 'undef'ed text macro has no value and no name; any subsequent
appearance of the 'name shall be replaced by the compiler by one
whitespace" (or,
maybe, be removed?)
<p><p>JohnW-Comment #70: p. 364, Section 19.6, ' resetall, the first line of text
should read, ". . .
all compiler directives except 'line are set to the default . . .". Also,
where are the
default values listed? They should be in a table or Annex referenced here.
<p><p>JohnW-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)
<p><p>JohnW-Comment #72: p. 373, Section 21.1, User-supplied PLI applications,
before the
final paragraph, it would be nice to explain what "TF" means (task-function?).
<p><p>JohnW-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."
<p><p>JohnW-Comment #74: p. 377, Section 22.1, ACC routine definition, after the
first sentence,
I suggest adding, "ACC stands for PLI access".
<p><p>JohnW-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 pointers to objects
in the
design hierarchy. All handles are of the same predefined data type."
<p><p>JohnW-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 . . .".
<p><p>JohnW-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, thus
conforming with this Standard.
<p><p>JohnW-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.
<p><p>JohnW-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++.
<p><p>JohnW-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.
[end of Comments]
<p>//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 14355 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
// Suite 200 Web: www.sunburst-design.com //
// Beaverton, OR 97005 //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:14 PDT
and
sponsored by Boyd Technology, Inc.