Subject: RE: [sv-ec] Issues with Draft 4 LRM
From: Neil Korpusik (Neil.Korpusik@eng.sun.com)
Date: Wed Apr 09 2003 - 17:39:18 PDT
Hi David,
Here is my list of nits and typos for draft 4 of the LRM. I haven't read
the whole thing, but this is what I noticed in the sections that I have
had a chance to read.
0. Page 8, table 3-1
There are several 2-state data types that are defined as being an integer.
The problem is that an integer is a 4-state data type.
1. Page 11, section 3.8, 3rd paragraph
The first sentence is missing a period (between Verilog and However).
2. Page 11, section 3.8, 3rd paragraph
The last sentence is a duplicated in the first sentence of paragraph
9, which begins with "A string literal is ...".
3. Page 11, section 3.8, 9th paragraph
The second sentence of this paragraph is duplicated in the paragraph
(2 down) that begins with "A string, string literal, ...".
4. Page 12, Table 3-2, the row on concatenation
In the semantics section there are several places (3) where the word
string is used, when it should probably use the word operand. Reducing
the number of usages of the word string in this paragraph should simplify
it.
- "Each string may be ..."
- "If at least one string is of type..."
- "If all the strings are..."
5. Page 13, table 3-2, the row on multiplier and str.method()
There are several uses of the word string that should be in bold.
- "...the result is a string..."
- "...involving string types..."
- "...a specified method on strings."
6. Page 14, section 3.8, last paragraph, first sentence
"...methods to work with strings..."
String should be bold.
7. Same comment as 6. for sections 3.8.1, 3.8.4, 3.8.5, 3.8.8, uses of
string that should probably be bold.
8. Page 18, section 3.11, paragraph 6
"An unassigned enumerated name that follows and enum..."
"An unassigned enumerated name that follows an enum..." <-- corrected
9. Page 21, section 3.11.4.2, last sentence.
"The last() function return the value..."
"The last() method returns the value..." <--- 2 corrections
10. Page 21-22, sections 3.11.4.2, 3.11.4.3, 3.11.4.4, 3.11.4.6
These sections use the word function where they should use the
word method (to be consistent with the way we have worded descriptions
like these in other sections of the LRM).
11. Page 29, first paragraph
"Unpacked arrays can be made of any scalar (non-packed-array) type."
"Unpacked arrays can be made of any singular type." <--- proposed
12. Page 29, paragraph 5, which begins with "When assigning to an unpacked..."
This paragraph is duplicated on page 32, section 4.7, first paragraph.
13. Page 42, section 5.4, next to last paragraph
The use of static (2) and class should all be bold.
14. Page 70, section 9.6
We have agreed that there is no implied order of execution for the
statement blocks, yet the text makes no mention of this point.
15. Page 76, 2nd paragraph, last sentence.
"The task argument type in System Verilog is reg."
and on page 78, 3rd paragraph, 2nd sentence.
"The default type in System Verilog is logic".
Isn't this contradictory?
16. Page 81, section 10.5.3, examples at end
- The fonts got changed on several of the lines.
- The extra blank lines should be removed.
17. Page 82, example at top of the page
Get rid of the extra blank lines
18. Page 100, section 12.2, first example
addr[1:0] == `2b0;
addr[1:0] == 2'b0; <-- corrections
19. Page 109, last sentence
"The following rules determines which..."
"The following rules determine which..." <--- corrected
20. Page 122, section 13.2, last sentence
We made some corrections here, but one of them got left out.
"Try to obtain a key without blocking: try_get()"
"Try to obtain one or more keys without blocking: try_get()" <--- correction
21. Page 125, sections 13.3.3 and 13.3.4
"The message is any singular (non-packed array) expression..."
"The message is any singular expression..." <--- correction
22. Page 156, section 16.1
There are several Verilog keywords used in this section that are not in
bold: module, always, initial, program.
23. Page 158, sections 16.2 and 16.3
There are several Verilog keywords used in this section that are not in
bold: program, static.
24. Page 159, sections 16.5
There are several Verilog keywords used in this section that are not in
bold: program, task, function.
25. Page 162, paragraph 2-3 (including the example)
This section is discussing methodology and not language constructs.
I suggest that this be removed.
Starting with "If the severity..." and ending with ".. assert failed at
time 10".
26. Page 162, section 17.4, 3rd paragraph
"The timing model employed in concurrent..."
"The timing model employed in a concurrent..." <--- correction
27. Page 163, 3d paragraph
"The two words "clock tick" and "sampling event" are used..."
"The two phrases "clock tick" and "sampling event" are used..." <-- corrected
28. Page 166, paragraph after second example
"...first subsequent tick and req will be false on the next tick..."
"...first subsequent clock tick and req will be false on the next clock
tick..." <-- corrected
29. Page 167, 2nd paragraph
"After signal c, the signal length..."
"After signal c, the sequence length..." <-- correction
29. Page 167, 2nd paragraph
"...when complex sequences constructed by..."
"...when complex sequences are constructed by..." <--- corrected
30. Page 167, section 17.6, 1st paragraph
"...as objects of type sequence with optional parameters:"
"...as objects of type sequence with optional arguments:" <--- corrected
31. Page 167, section 17.6, 1st paragraph
sequence should be bold.
32. Page 174, section 17.7.3
1st paragraph under figure 17-5
"...the expression succeeds..." <--- which expression? (te1 and te2?)
33. Page 174, last paragraph
"The expression matches at clock tick 1,3 and 8..."
"The expression matches at clock tick 1,3,8 and 14..." <-- corrected
34. Page 177, 2nd paragraph
"...sequence is associated with time range..."
"...sequence is associated with a time range..." <---- corrected
35. Page 183, section 17.7.10, 2nd example
data_end1 |-> ##[1:2]
data_end |-> ##[1:2] <--- corrected
36. Page 188, section 17.10, last paragraph
"A property declaration is parameterized, like..."
"A property declaration can have arguments, like..." <--- correction
37. Page 199, section 17.14
This whole section on templates hasn't been carefully worked out.
The ASWG (assertion syntax working group) tried to clean it up but didn't
have time to do it justice. We came to the conclusion that we simply
didn't have time to deal with it and kicked it back to the SVAC.
Should this be taken out of 3.1 and put on the wish list for 3.2?
38. Page 323, Annex B
It appears that the keywords endproperty and endsequence need to be
added to the list of keywords.
39. Page 325, Annex C, section C.2, first sentence.
The word class should be bold.
40. Annex C
Some of these methods discuss a wrap-around condition. It would be
nice to have an example that shows this in detail (e.g. C.5.14).
41. Annex C, page 326, C.4.1
I assume that the next() method stops at the end of the list and
won't wrap-around. The text doesn't state the behavior in this case.
Neil
This archive was generated by hypermail 2b28 : Wed Apr 09 2003 - 17:45:39 PDT