Re: 2ND TRY --> BTF Review Schedule and Assignments - BTF Please Read & Respond

From: Shalom Bresticker (shalom@msil.sps.mot.com)
Date: Fri Oct 06 2000 - 06:10:42 PDT


Due to the Sabbath and Yom Kippur, I cannot get to this before Tuesday, but it
looks like enough time. Only 38 and 39 look like technical issues, and they are
only requests for further enhancements, not errors detected.

In a separate issue, what about the problems I reported which Patrick Doane
found ?

 --

**************************************************************************
Shalom Bresticker Shalom_Bresticker-R50386@email.mot.com
Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890
http://www.motorola-semi.co.il/
**************************************************************************

On Thu, 5 Oct 2000, Clifford E. Cummings wrote:

<p>> Shalom Bresticker - JohnW-Comment 21-40
>
>
> JohnW-Comment #21: p. 27, Section 3.4.1, Charge strength, I suggest adding
> an example
> declaration here.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> 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
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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."
>
>
>
> 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."
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> 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.
>
>
>
> 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 . . .".
>
>
>
> 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).
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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."



This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:54:14 PDT and
sponsored by Boyd Technology, Inc.