Subject: [sv-bc] FW: [sv-ec] Issues with Draft 4 LRM
From: David W. Smith (david.smith@synopsys.com)
Date: Thu Apr 10 2003 - 15:14:04 PDT
I am also forwarding this to the SV-BC committee since some of the responses
are related to your committee.
Regards
David
-----Original Message-----
From: David W. Smith [mailto:david.smith@synopsys.com]
Sent: Thursday, April 10, 2003 3:13 PM
To: 'Neil Korpusik'; 'sv-ec@eda.org'
Cc: 'sv-ac@eda.org'
Subject: RE: [sv-ec] Issues with Draft 4 LRM
Hi Neil,
Thanks for the detailed review.
I have passed this on to the SV-AC committee as well since LRM-152 through
LRM-165 has been created for them based on your input.
I have responded to each of your items with either the explanation of why I
did nothing or an indication of the LRM number where the change has either
been made or recorded so it can be made.
The one area where I think we have some disagreement is in the area of bold
usage. I would like to get Stu's input on some of this and have asked him
for it.
The updated LRM Issues and Changes will be posted in the next 10 minutes.
Regards
David
-----Original Message-----
From: Neil Korpusik [mailto:Neil.Korpusik@eng.sun.com]
Sent: Wednesday, April 09, 2003 5:39 PM
To: sv-ec@eda.org; david.smith@Synopsys.COM
Subject: RE: [sv-ec] Issues with Draft 4 LRM
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.
DWS: You are correct. There is no easy fix. The section is termed Integer
Data Types referring to Integer-like Data Types. The keyword integer is used
different from the mathematical term integer (one is in bold and the other
is not). I recommend leaving it as is (I tried to change it but do not like
the result).
1. Page 11, section 3.8, 3rd paragraph
The first sentence is missing a period (between Verilog and However).
DWS: LRM-142
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, ...".
DWS: I cannot find this. Can you give the text?
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..."
DWS: Handled in LRM-143
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."
DWS: Not sure I agree. The use of string is a description is not a keyword.
When used as a keyword it is clearly bold when used as a description it is
not.
6. Page 14, section 3.8, last paragraph, first sentence
"...methods to work with strings..."
String should be bold.
DWS: Not sure I agree. See above.
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.
DWS: Not sure I agree. See above.
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
DWS: Fixed in LRM-144.
9. Page 21, section 3.11.4.2, last sentence.
"The last() function return the value..."
"The last() method returns the value..." <--- 2 corrections
DWS: Fixed in LRM_145
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).
DWS: Fixed in LRM_146
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
DWS: Fixed in LRM-147
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.
DWS: Not quite identical. I think I will leave there for now.
13. Page 42, section 5.4, next to last paragraph
The use of static (2) and class should all be bold.
DWS: I think the use is descriptive as it is in the following paragraph.
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.
DWS: But IEEE 1364-2001 Section 9.8.3 does and we have not tried to change
any semantics with order execution. If anything the statement in our 9.6
"One or more statements can be specified, each statement will execute as a
concurrent process" indicates that they cannot be ordered (else they would
be sequential). Do we need to say more?
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?
DWS: Since reg and logic are now equivalent it is not contradictory. reg is
kept for backward compatibility while logic is preferred but they are the
same. Change reg to logic in LRM-167.
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.
DWS: Fix in LRM-148
17. Page 82, example at top of the page
Get rid of the extra blank lines
DWS: Fix in LRM-149
18. Page 100, section 12.2, first example
addr[1:0] == `2b0;
addr[1:0] == 2'b0; <-- corrections
DWS: Fix in LRM-95
19. Page 109, last sentence
"The following rules determines which..."
"The following rules determine which..." <--- corrected
DWS: Fix in LRM-150
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
DWS: Fix in LRM-151
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
DWS: Fix in LRM-133
22. Page 156, section 16.1
There are several Verilog keywords used in this section that are not in
bold: module, always, initial, program.
DWS: True but they are not being used as keywords. We are somewhat
inconsistent in our bold usage.
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.
DWS: See previous
24. Page 159, sections 16.5
There are several Verilog keywords used in this section that are not in
bold: program, task, function.
DWS: See previous
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".
DWS: Opened LRM-152 for AC
26. Page 162, section 17.4, 3rd paragraph
"The timing model employed in concurrent..."
"The timing model employed in a concurrent..." <--- correction
DWS: Opened LRM-153 for AC
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
DWS: Opened LRM-154 for AC
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
DWS: Opened LRM-155 for AC
29. Page 167, 2nd paragraph
"After signal c, the signal length..."
"After signal c, the sequence length..." <-- correction
DWS: Opened LRM-156 for AC
29. Page 167, 2nd paragraph
"...when complex sequences constructed by..."
"...when complex sequences are constructed by..." <--- corrected
DWS: Opened LRM-157 for AC
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
DWS: Opened LRM-158 for AC
31. Page 167, section 17.6, 1st paragraph
sequence should be bold.
DWS: Opened LRM-159 for AC
32. Page 174, section 17.7.3
1st paragraph under figure 17-5
"...the expression succeeds..." <--- which expression? (te1 and te2?)
DWS: Opened LRM-160 for AC
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
DWS: Opened LRM-161 for AC
34. Page 177, 2nd paragraph
"...sequence is associated with time range..."
"...sequence is associated with a time range..." <---- corrected
DWS: Opened LRM-162 for AC
35. Page 183, section 17.7.10, 2nd example
data_end1 |-> ##[1:2]
data_end |-> ##[1:2] <--- corrected
DWS: Opened LRM-163 for AC
36. Page 188, section 17.10, last paragraph
"A property declaration is parameterized, like..."
"A property declaration can have arguments, like..." <--- correction
DWS: Opened LRM-164 for AC
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?
DWS: Opened LRM-165 for AC
38. Page 323, Annex B
It appears that the keywords endproperty and endsequence need to be
added to the list of keywords.
DWS: LRM-166
39. Page 325, Annex C, section C.2, first sentence.
The word class should be bold.
DWS: I am not sure I agree. The use of integer and string are a particular
type whereas class object is not a class.
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).
DWS: Pass on to Arturo for comment
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.
DWS: Pass on to Arturo for comment
Neil
This archive was generated by hypermail 2b28 : Thu Apr 10 2003 - 15:12:17 PDT