System Verilog
LRM Changes
On
Status Legend: Open, Remove Note, Change, No Change
ID	Committee	Section	Description	Status	Changes
LRM-1	SV-EC	1 4.6.1 4.8 10.5.2 10.5.4 12.6 13.3.5 13.4 13.8 15.2 15.3	Editor’s Note: "parameter" is a Verilog keyword, and "parameterized" models refer to the usage of Verilog "parameters" (see Sections 11.21, 19.6 and 20). Use of the word "parameterized" in this context is not consistent with the Verilog LRM. Suggest using "arguments" (as in Verilog LRM), "formal arguments" or "formals".	13.3.5, 13.4, 15.3 are left unchanged	Section  1
					Section 4.6.1 4.8
					Section 10.5.2 10.5.4
					Section 12.6
					Section 13.1, 13.8
					Section 15.2
					Section 8.9
LRM-2	SV-BC	18.7	Editor’s Note: "parameter" is a Verilog keyword, and "parameterized" models refer to the usage of Verilog "parameters" (see Sections 11.21, 19.6 and 20). Use of the word "parameterized" in this context is not consistent with the Verilog LRM. Suggest using "arguments" (as in Verilog LRM), "formal arguments" or "formals".	No Change	Section 18.7
LRM-3	SV-BC	2.5	The time literal is interpreted as a realtime value scaled to the current time unit and rounded to the current time precision. Note that if a time literal is used as an actual parameter to a module or interface instance, the current time unit and precision are those of the module or interface instance. Editor’s Note: What is meant by "actual parameter" in the preceding paragraph? Is it referring to the Verilog parameter data type?	No Change	Section 2.5
LRM-4	SV-BC	2.8	Editor’s Note: Both BC62a and BC65 added the following description of structural literals. I used BC62a.	No Change	Section 2.8
LRM-5	SV-BC	2.8	Structure literals can also use member name and value, or data type and default value (see Section 7.13): Editor’s Note: Is the cross reference above correct?	No Change	Section 2.8
LRM-6	SV-BC	3.4	Editor’s Note: BC08-05 says to "Remove section 3.4.1". There is no such section, and the change order does not have the requisite details of which version it referred to, or what text is to be deleted.	Change	Section 3.4
LRM-7	SV-EC	3.8.9	function integer atoi() function integer atohex() function integer atooct() function integer atobin() Editor’s Note: "integer" or "int"?	No Change	Section 3.8.9
LRM-8	SV-EC	3.10	A typedef inside a generate may not define the actual type of a forward definition that exists outside the scope of the forward definition. Editor’s Note: Does "may not" in the preceding paragraph indicate a mandatory rule or an optional rule? If mandatory, then change to "shall". If optional, the sentence needs to be rephrased to not be ambiguous.	Change	Section 3.10
LRM-9	SV-BC	7.12 7.13 7.14 7.15	Editor’s Note: Both BC62a and BC65 added this new section. I used BC62a.	Change	Section 7.12 7.13 7.14 7.15
LRM-10	SV-EC	8.10	Editor’s Note: This new operator needs to be added to the operator precedence table and other sections describing operator rules (signed/unsigned/2-state/4-state/real operands, etc.).	No Change	Section 8.10
LRM-11	SV-EC	10.1	— Importing and exporting functions through the Direct Programming Interface (DPI) Editor’s Note: Previous bullet added by the editor. It was not actually specified in EC-C120.	No Change	Section 10.1
LRM-12	SV-CC	10.6	For any given cname, all declarations, regardless of scope, must have exactly the same type signature. The type signature includes the return type, the number, order, direction and types of each and every argument. Type includes dimensions and bounds of any arrays/array dimensions. For import declarations, arguments can be open arrays. Open arrays are defined in Section 1.4.5 of the DPI LRM. Signature also includes the pure/context qualifiers that may can be associated with an import definition. Editor’s Note: What is meant by "Signature"?	Change	Section 10.6
LRM-13	SV-CC	10.6	For any given cname, all declarations, regardless of scope, must have exactly the same type signature. The type signature includes the return type, the number, order, direction and types of each and every argument. Type includes dimensions and bounds of any arrays/array dimensions. For import declarations, arguments can be open arrays. Open arrays are defined in Section 1.4.5 of the DPI LRM. Signature also includes the pure/context qualifiers that may can be associated with an import definition. Editor’s Note: Need to update cross reference in preceding paragraph.	Change	Section 10.6
LRM-14	SV-EC	11.20	Editor’s Note: This new operator needs to be added to the operator precedence table and other sections describing operator rules (signed/unsigned/2-state/4-state/real operands, etc.).	Change	Section 7.9
					Section  11.20
LRM-15	SV-EC/SV-BC	11.22	Editor’s Note: Verilog syntax is "int static". Is the "static int" above correct? NOTE: The Co-design SystemSim simulator allows both forms. I submitted a request to the BC committee to clarify if SystemVerilog was intended to also allow both forms. I do not know the result of that request. Response: It appears that the LRM only supports static int and not int static. This may be enhanced in a future version.	No Change	Section 11.22
LRM-16	SV-EC	12.4.3	inside Editor’s Note: This new operator needs to be added to the operator precedence table and other sections describing operator rules (signed/unsigned/2-state/4-state/real operands, etc.).	No Change	Section 12.4.3
LRM-17	SV-EC	12.4.4	dist Editor’s Note: This new operator needs to be added to the operator precedence table and other sections describing operator rules (signed/unsigned/2-state/4-state/real operands, etc.).	No Change	Section 12.4.4
LRM-18	SV-EC	12.4.4	The := operator assigns the specified weight to the item, or if the item is a range, to every value in the range. The :/ operator assigns the specified weight to the item, or if the item is a range, to the range as a whole. Ifthere are n values in the range, the weight of each value is range_weight / n. Editor’s Note: These new operators need to be added to the operator precedence table and other sections describing operator rules (signed/unsigned/2-state/4-state/real operands, etc.).	Change	Section 7.9
					Section 12.4.4
LRM-19	SV-EC	12.4.5	=> Editor’s Note: This new operator needs to be added to the operator precedence table and other sections describing operator rules (signed/unsigned/2-state/4-state/real operands, etc.).	No Change	Section 12.4.5
LRM-20	SV-EC	12.4.9	Editor’s Note: Verilog syntax puts "static" after the data type, the opposite of C. Should the declaration for constraint be consistent with Verilog, or with C? Note that the Co-design SystemSim simulator allows the static declaration of SystemVerilog variables to be in either order. I submitted a request to the BC committee asking if the SystemVerilog LRM was intended to allow the same. I do not know the result of that request.	No Change	Section 12.4.9
LRM-21	SV-EC	12.10.1	function unsigned int $urandom [ (int seed ) ] ; Editor’s Note: Verilog syntax is "function int unsigned" instead of "function unsigned int". Co-design’s SystemSim allows both Verilog and C styles.	Change	Section 12.10.1
LRM-22	SV-EC	12.10.2	function unsigned int $urandom_range( unsigned int maxval, unsigned int minval = 0 ); Editor’s Note: Verilog syntax is “function int unsigned” instead of “function unsigned int” ?	Change	Section 12.10.2
LRM-23	SV-EC	12.10.3	task $srandom( int seed, [object obj] ); Editor’s Note: Is “object” a data type? There is no keyword “object” anywhere else in the LRM.	Change	Section 12.10.3
LRM-24	SV-SSWG	14.4	There are two kinds of PLI callbacks, those that are executed immediately when some object changes value in an update event, and those that are explicitly registered as a one-shot evaluation event. Editor’s Note: The preceding paragraph does not account for all types of callbacks. For example: cbStmt, cbEnterInteractive, cbStartOfReset, etc. These and some other callbacks are not logic value related, and they may occur more than one time after being registered. Peter Flake responds: Here is my proposal.  The term "specific activity" is taken from the Verilog 2001 LRM VPI section. There are two kinds of PLI callbacks, those that are executed immediately whenever some specific activity occurs, and those that are explicitly registered as a one-shot evaluation event.	Change	Section 14.4
LRM-25	SV-BC	18.7.3	Editor’s Note: BC42-24 said to make “.name” all bold. This was not done, because the bold text is used to designate a keyword, and “name” is not a keyword	Change	Section 18.7.3
LRM-26	SV-BC	18.8.3	See Section XX for more port connection rules with interfaces. Editor’s Note: What is the cross reference for above?	Change	Section 18.8.3
LRM-27	SV-AC	22.6 22.7	Editor’s Note: Are these system tasks to be removed? The new 3.1 assertion section does not mention them.	Open
LRM-28	SV-CC	26.4.4	Each imported function shall be declared. Such declaration are referred to as import declarations. The syntax of an import declaration is similar to the syntax of SystemVerilog function prototypes (see Section 10.6). Editor’s Note: Is the preceding cross reference correct?	No Change	Section 26.4.4
LRM-29	SV-CC	26.4.4	import "DPI" newQueue=function handle newAnonQueue(input string s=NULL); Editor’s Note: Is the uppercase “NULL” correct? The SystemVerilog keyword is in lowercase.	Change	Section 26.4.4
LRM-30	SV-CC	26.4.6.1	Here are examples of types of formal arguments (empty square brackets [] denote open array): logic bit [8:1] bit[] bit [7:0] b8x10 [1:10] // b8x10 is a formal arg name logic [31:0] l32x [] // l32x is a formal arg name logic [] lx3 [3:1] // lx3 is a formal arg name bit [] an_unsized_array [] // an_unsized_array is a formal arg name Editor’s Note: It is illegal in Verilog to start a name with a number (e.g. “132x”. Does that rule apply here?	Change	Section 26.4.6.1
LRM-31	SV-CC	27.1.2	Assertion Temporal expression—A declarative expression (one or more clock cycles) describing the behavior of a system over time. // This is the "body" of the assertion. Editor’s Note: Why the underlined comment, above? Should it be regular text, or deleted?	Change	Section 27.1.2
LRM-32	SV-CC	27.2	These extension shall be merged into the contents of the vpi_user.h file, described in IEEE Std 1364-2001, Annex G. The numbers in the range 700 - 799 are reserved for the assertion portion of the VPI. Editor’s Note: Is “shall”, which means mandatory, too strong here? It seems to infer that users or software vendors must modify the IEEE standard vpi_user.h header file, thereby making the file non IEEE compliant. Response: Shall is correct and yes vendors and users will have to modify vpi_user.h. Editor's Note: Grammer problem in "These extension"	Change	Section 27.2
LRM-33	SV-CC	27.2.3	27.2.2 Object properties This section lists the object property VPI calls. The VPI reserved range for these call is 700 - 729. /* Directives as properties */ #define vpiSequenceAssertion 701 #define vpiAssertAssertion 702 #define vpiAssumeAssertion 703 #define vpiRestrictAssertion 704 #define vpiCoverAssertion 705 #define vpiCheckAssertion 705 /* inlined behavior assertion */ #define vpiOtherDirectiveAssertion 706 /* placeholder for other assertion directive */ 27.2.3 Callbacks This section lists the system callbacks. The VPI reserved range for these call is 700 - 719. 1) Assertion #define cbAssertionStart 700 #define cbAssertionSuccess 701 #define cbAssertionFailure 702 #define cbAssertionStepSuccess 703 #define cbAssertionStepFailure 704 #define cbAssertionDisable 705 #define cbAssertionEnable 706 #define cbAssertionReset 707 #define cbAssertionKill 708 Editor’s Note: This section is using some of the same constant values as the previous section. Response:the enumeration constants are allowed to be different for different kind of object. One set of enumeration constants is for properties, while the other set is for callbacks reasons.	No Change	Section 27.2.3
LRM-34	SV-CC	27.3.2	— Any assertion updates from the SV-AC. — Assertion source information: the file, line, and column where the assertion is defined. — Assertion clocking domain/expression2 Editor’s Note: Item 6, above, does not seem appropriate in a standard. Should it be deleted? Editor’s Note: Are the two dashed-list lines above part of item 6? Editor’s Note: What is the “2” in “expression2”, above?	Change	Section 27.3.2
LRM-35	SV-CC	27.4.1	Section 27.4.1 Placing assertion “system” callbacks Editor’s Note: Why is “system” in quotes?.	Change	Section 27.4.1
LRM-36	SV-CC	27.4.2	cbAssertionStepSucess the progress of one “thread” along an attempt. By default, step callbacks are not enabled on any assertions; they are enabled on a per-assertion/per-attempt basis, rather than on a per-assertion basis. Editor’s Note: Why is “thread” in quotes?.	Change	Section 27.4.2
LRM-37	SV-CC	27.5.2	For the following operator, the second argument shall be a valid assertion handle, the third argument shall be an attempt start-time (as a pointer to a correctly initialized s_vpi_time structure) and the fourth argument shall be a “step control” constant. Editor’s Note: Why is “step control” in quotes?.	Change	Section 27.5.2
LRM-38	SV-CC	28.2	This section ... Editor’s Note: Something appears to be missing in this section.	Change	Section 28.2
LRM-39	SV-CC	28.2.2	This section ... Editor’s Note: Something appears to be missing in this section.	Change	Section 28.2.2
LRM-40	SV-CC	28.3.1	/* tool state_vector signal_name */ where tool and state_vector are required keywords. This pragma needs to be specified inside the module definition where the signal is declared. Editor’s Note: Throughout this coverage API section, Verilog-2001 attributes should be used, instead of using obsolete pragmas that are hidden in comments! Reply from SV-CC: no, pragmas have to be used as attributes are not sufficiently capable in the current revision of SV. Specifically, attributes can only be attached to a single declaration, whereas for FSM descriptions information needs to be attached to declarations of multiple variables/parameters, or to variable concatenations and part selects (for which no declarative item even exists to which an attribute could be attached). It is proposed that these limitations be raised as an issue to be resolved in SV 3.2	No Change	Section 28.3.1
LRM-41	SV-CC	28.3.6	parameter [1:0] /* tool enum enumeration_name */ S0 = 0, s1 = 1, s2 = 2, s3 = 3; Editor’s Note: Can SystemVerilog enumerated types be used instead of parameter constants? What about ‘define macros SV-CC reply: Yes, enumerated types could also be used, but this use of parameters for FSM modelling is common. In either case the pragma would be the same.	No Change	Section 28.3.6
LRM-42	SV-CC	28.4	This section ... Editor’s Note: Something appears to be missing in this section.	Change	Section 28.4
LRM-43	SV-CC	28.4.1	This section ... Editor’s Note: Something appears to be missing in this section.	Change	Section 28.4.1
LRM-44	SV-CC	28.4.3	All **what?? use vpi_get() along with the appropriate properties and object handles. Editor’s Note: The preceding sentence needs to be fixed.	Change	Section 28.4.3
LRM-45	SV-CC	28.4.4	28.4.4 Controlling coverage **Revise similar to Assertions** Editor’s Note: What is this comment referring to?	Change	Section 28.4.4
LRM-46	SV-BC	A.1.6	extern_tf_declaration ::= extern method_prototype | extern forkjoin task named_task_proto ; Editor’s Note: The added syntax added just for interface items may be better combined with the DPI import, but that is allowed anywhere a function may be declared... The BC should take a look at the DPI import/export to make sure these make sense... The dpi_import_export is in A.2.6	No Change	Section A.1.6
LRM-47	SV-EC	A.1.8	Editor’s Note: The examples seemed to allow arbitrary ordering for the extern, virtual, etc... So that is maintained here... either an order should be specified (and examples that use virtual protected or protected virtual at will should be changed). Or text should be added to sections to deal with question of “protected private”.	Change	Section 11.16
					Section A.1.8
LRM-48	SV-BC	A.2.2.1	non_integer_type ::= time | shortreal | real | realtime | $built-in Editor’s Note: Why isn’t $built-in mentioned in the text? What is it? Remove? Should be bold?	Change	Section A.2.2.1
LRM-49	SV-EC	A.2.2.1	Editor’s Note: Singular is listed as anything but unpacked structs, unpacked arrays, and handle type. Either the text should simply let the singular_type bnf explain or should deal with other exceptions: union, void, dynamic arrays SV-BC Responds: SV-EC has added this. They split the packed and unpacked unions. Therefore, we are moving this issues back to EC. Stefen: Need the description in the LRM (3.9) to be cleaned up and make sure that BNF matches.	Open
LRM-50	SV-BC	A.2.2.1	Editor’s Note: Enum here suggests that we can have ports: input enum { a, b, c} myin; Is this a problem (considering the semi-strong typing introduced in 3.1 for enum)? SV-BC responds: Existing port connection sematics take care of this.	No Change	Section A.2.2.1
LRM-51	SV-EC	A.2.2.1	Editor’s Note: String and event assignment restrictions not part of bnf productions (semantic only) SV-BC responds: Should be moved back to EC, because string was added by EC	No Change	Section A.2.2.1
LRM-52	SV-BC	A.2.6	Editor’s Note: Enum here suggests that we can have return values: function enum { a, b, c} myfunc; Is this a problem (considering the semi-strong typing introduced in 3.1 for enum)? SV-BC responds: leave it. Existing sematic rules take care of it. DPI might need it also	No Change	Section A.2.6
LRM-53	SV-BC	A.2.6	Editor’s Note: Why eliminate [ signing ] from this production and then add note? The note will constantly need updating due to new types (e.g. string) and function prototypes won’t be allowed to be signed. Better to make “function_data_type ::= data_type | handle |void” and move the “[ signing ]” from function_declaration to the first line of range_or_type. SV-BC Response: The reason we voted for splitting this rule was the location of the signing which should go before the data type and after the function keyword. Recommendation: keep this BNF.	No Change	Section A.2.6
LRM-54	SV-BC	A.2.6	Editor’s Note: Since [ signing ] was removed from function_data_type, we can’t have a signed prototype?	Change	Section A.2.6
LRM-55	SV-EC	A.2.7	Editor’s Note: Looks like the new definition disallows “output signed [3:0] foo” (same for inout). I took the liberty of adding it. SV-BC Responds: It looks OK, but it should be moved back to EC because it was changed by them.	Open
LRM-56	SV-EC	A.6.1	Editor’s Note: I used expression since that is what is used in module instance ports. Dispite the style of showing semantics in the BNF, I’m following the style of ports of module instances. One restriction that is not clear in the text is that the bit and part selects of nets in an alias must be constant (i.e. can’t use [expression +: constant]) SV-BC Responds: Alias was pushed by SV-EC, therefore this issue should be moved back to them	Change	Section A.6.1
LRM-57	SV-BC	A.8.3	Editor’s Note: This change collided with BC19-44. I left variable_lvalue alone since it now does what variable_lvalue_item used to do.	No Change	Section A.8.3
LRM-58	SV-EC	A.8.4	Editor’s Note: The general syntax for making a function call to a method is given here. I do not list all the possible methods for each type. As is done with system tasks and functions, these will have BNF descriptions that are separate from Annex A. SV-BC Responds [ . method_identifier { attribute_instance } [ ( expression { , expression } ) ] ] This note refers to the changes which were specifically done by SV-EC. The issue should be moved back to SV-EC.	No Change	Section A.8.4
LRM-59	SV-BC	A.9.3	Editor’s Note: This isn’t referenced by any other production. Remove? Add reference somewhere?	Change	Section A.9.3
LRM-60	SV-BC	A.9.3	Editor’s Note: Looks like this is left over from state machine syntax that didn’t make it into 3.0	Change	Section A.9.3
LRM-61	SV-BC	A.9.3	Editor’s Note: This isn’t referenced by any other production. Remove? Add reference somewhere?	No Change	Section A.9.3
LRM-62	SV-CC	D.1	Formal arguments in SystemVerilog can be specified as open arrays solely in import declarations; exported SystemVerilog functions can not have formal arguments specified as open arrays. A formal argument is an open array when a range of one or more of its dimensions is unspecified (denoted in SystemVerilog by using empty square brackets ([])). This corresponds to a relaxation of the DPI argument-matching rules (section 1.5.1). An actual argument shall match the corresponding formal argument regardless of the range(s) for its corresponding dimension(s), which facilitates writing generalized C code that can handle SystemVerilog arrays of different sizes. Editor’s Note: What is the correct cross reference, above?	Change	Section D.1
LRM-63	SV-CC	D.5	Note that the constraints expressed here merely restate those expressed in section 1.4.1. Editor’s Note: What is the correct cross reference, above?	Change	Section D.5
LRM-64	SV-CC	D.5.5	Also refer to section 1.4.3. Editor’s Note: What is the correct cross reference, above?	Change	Section D.5.5
LRM-65	SV-CC	D.5.6	See also 1.4.2. Editor’s Note: What is the correct cross reference, above?	Change	Section D.5.6
LRM-66	SV-CC	D.5.7	See also section 1.4.1.4. Editor’s Note: What is the correct cross reference, above?	Change	Section D.5.7
LRM-67	SV-CC	D.6.6	1) If a packed part of an array has more than one dimension, it is linearized as specified by the equivalence of packed types (see section ??). Editor’s Note: What is the correct cross reference, above?	Change	Section D.6.6
LRM-68	SV-CC	D.7.2	It can be done while preserving the binary compatibility, see Annex D.7.5 and section A.11.11. Editor’s Note: What is the correct cross reference, above?	Change	Section D.7.2
LRM-69	SV-CC	D.7.5	compromising the portability (see section A.11.11). Such a technique does not work if a packed array is a part of another type. Editor’s Note: What is the correct cross reference, above?	Change	Section D.7.5
LRM-70	SV-CC	D.7.7	[There is a problem here: ‘int’ is the same as svBitVec32, long long is not the snae as svBitVect32[2], so how to return a value in the canonical representation as a function result, if this value is between 33 and 64 bits?] Editor’s Note: Has the preceding note been taken care of?	Change	Section D.7.7
LRM-71	SV-CC	D.8	A small set of DPI utility functions is available to assist programmers when working with context functions (see section A.8.3). If those utility functions are used with any non-context function, a system error will result. Editor’s Note: Has the preceding note been taken care of?	Change	Section D.8
LRM-72	SV-CC	D.10.2	Unpacked arrays, with the exception of formal arguments specified as open arrays, shall have the same layout as used by a C compiler; they are accessed using C indexing (see section A.6.6). Editor’s Note: What is the correct cross reference, above?	Change	Section D.10.2
LRM-73	SV-CC	D.11.1	In the former case, all indices are normalized on the C side (i.e., 0 and up) and the programmer needs to know the size of an array and be capable of determining how the ranges of the actual argument map onto C-style ranges (see section A.6.6). Editor’s Note: What is the correct cross reference, above?	Change	Section D.11.1
LRM-74	SV-EC	3.7	define/clarify why chandle cannot be used in structures or unions	Change	Section 3.7
LRM-75	SV-EC	4.2	remove Note: from shortcut description	Change	Section 4.2
LRM-76	SV-EC	4.10.1	change map.num to imem.num in example	Change	Section 4.10.1
LRM-77	SV-EC	7.5	Change !=== to !==	Change	Section 7.5
LRM-78	SV-EC	7.9	<= missing from precendence table	Change	Section 7.9
LRM-79	SV-EC	9.6	Change example of return in function to return in task	Change	Section 9.6
LRM-80	SV-EC	10.2	Add ref to list of directions for tasks	Change	Section 10.2
LRM-81	SV-EC	10.3	Add ref to list of directions for functions	Change	Section 10.3
LRM-82	SV-EC	4.3	Remove int from comment in example	Change	Section 4.3
LRM-83	SV-EC	9.6	Remove redundant description in Table 9-1 for fork…join	Change	Section 9.6
LRM-84	SV-EC	A.2.7	Add const to BNF for tf_ref_declaration	Change	Section A.2.7
LRM-85	SV-EC	G	Remove discussion of process keyword from Glossary	Change	Section G
LRM-86	SV-EC	13.4	Clarify run-time check support for parameterized mailboxes	Change	Section 13.4
LRM-87	SV-EC	8.10	Move description of Nonblocking event trigger to 13.5.2 (creating new section and renumbering existing 13.5.2)	Change	Section 8.10
LRM-88	SV-EC	C.4	Add note on iterator to clarify what happens on methods	Change	Section C.4
LRM-89	SV-BC	4.2	Missing text from SV-BC62	Change	Section 4.2
LRM-90	SV-EC	16.1	Rewording from Karen's review of chapter 16	Change	Section 16.1
LRM-91	SV-EC	16.2	module needs to be bold in example (from Karen's review of chapter 16)	Change	Section 16.2
LRM-92	SV-EC	16.2	Change UPD to UDP in text after example (from Karen's review of chapter 16)	Change	Section 16.2
LRM-93	SV-EC	16.6	Make $stop bold (from Karen's review of chapter 16)	Change	Section 16.6
LRM-94	SV-EC	12.1	hyphenate object oriented (from Brad's review of Chapter 12)	Change	Section 12.1
LRM-95	SV-EC	12.2	Correct binary literal (from Brad's review of Chapter 12)	Change	Section 12.2
LRM-96	SV-EC	12.2	Correct endfunction and endtask (from Brad's review of Chapter 12)	Change	Section 12.2
LRM_97	SV-EC	12.4.4	italicize expression (from Brad's review of Chapter 12)	Change	Section 12.4.4
LRM-98	SV-EC	12.4.8	Clarify legal value (from Brad's review of Chapter 12)	Change	Section 12.4.8
LRM_99	SV-EC	12.4.8	Reword sentence (from Brad's review of Chapter 12)	Change	Section 12.4.8
LRM-100	SV-EC	12.5.3	Add comma (from Brad's review of Chapter 12)	Change	Section 12.5.3
LRM-101	SV-EC	12.9	Change system task to built-in method (from Brad's review of Chapter 12)	Change	Section 12.9
LRM-102	SV-EC	12.10.1	Clarify random number sequence (from Brad's review of Chapter 12)	Change	Section 12.10.1
LRM-103	SV-EC	12.11.1	italicize hierarchical seeding (from Brad's review of Chapter 12)	Change	Section 12.11.1
LRM-104	SV-EC	12.11.2	Reword sentence (from Brad's review of Chapter 12)	Change	Section 12.11.2
LRM-105	SV-EC	12.12	italicize hierarchical object seeding (from Brad's review of Chapter 12)	Change	Section 12.12
LRM-106	SV-EC	12.2 12.4.6 15.2	Bi-directional to bidirectional (from Brad's review of Chapter 12)	Change	Section 12.2
					Section 12.4.6
					Section 15.2
LRM-107	SV-EC	12.4.7 12.11.1	sub-tree to subtree (from Brad's review of Chapter 12)	Change	Section 12.4.7
					Section 12.11.1
LRM-108	SV-BC	3.12	Correction of SV-BC8-7 from Dave Rich	Change	Section 3.12
LRM-109	SV-BC	8.11	Remove Section based on SV-BC85 from Dave Rich	Change	Section 8.11
LRM-110	SV-AC	Acknowledgements	Misspelled name from Connie O'Dell	Change	Section Ack
LRM-111	SV-AC	3.7	Grammar correction from Connie O'Dell	Change	Section 3.7
LRM-112	SV-AC	7.1 7.3	Spelling of incrementor and decrementor from Connie O'Dell	Change	Section 7.1 Section 7.3
LRM-113	SV-AC	17.6	Spelling of nedgedge from Connie O'Dell	Change	Section 17.6
LRM-114	SV-EC	3.11.3	3.11.3 says "SystemVerilog enumerated types are strongly typed, thus, a variable of type enum cannot be assigned a value that lies outside the enumeration set" but that isn't true -- a cast or union must be used but it's legal to do such an assignment.  I think the use of the phrase "strongly typed" is misleading.	Change	Section 3.11.3
LRM-115	SV-EC	3.11.4	Wrong placement of "Methods for iterating over enumerated types" section heading -- it's in the middle of section 3.11.4, instead of at the end, and doesn't introduce a new section -- it should introduce the next 3.11.x section.	Change	Section 3.11.4
LRM-116	SV-EC	3.11.3	3.11.3 says "Casting is discussed in Sections 3.14 and 3.15." but casting is also discussed in the section immediately following, 3.11.4.	Change	Section 3.11.3
LRM-117	SV-EC	3.11.4	3.11.4 discusses static casts but not dynamic casts.  It says casts to enums are not checked, but that is only true of static casts.	Change	Section 3.11.4
LRM-118	SV-BC	8.1	Font change found by Dennis's review of Chapter 8	Change	Section 8.1
LRM-119	SV-BC	8.3	Grammar correction from Dennis's review of Chapter 8	Change	Section 8.3
LRM-120	SV-BC	8.3	Change intro to example to a note from Dennis's revoew of Chapter 8	Change	Section 8.3
LRM-121	SV-BC	8.8	Reword sentence (from Dennis's review of Chapter 8)	Change	Section 8.8
LRM-122	SV-BC	8.11	Remove editor's note (from Dennis's review of Chapter 8)	Change	Section 8.11
LRM-123	SV-BC	8.2	Reword based on Dennis's review of Chapter 8	Change	Section 8.2
LRM-124	SV-AC	17.7.1	Remove redundant word from Connie O'Dell's review	Change	Section 17.7.1
LRM-125	SV-AC	17.7.3	Replace rxpressions with expressions per Connie O'Dell's review	Change	Section 17.7.3
LRM-126	SV-AC	17.10	Fix spelling per Connie O'Dell's review	Change	Section 7.10
LRM-127	SV-EC	11.14	Change the variable type and description based on Editorial review	Change	Section 11.14
LRM-128	SV-EC	Index	Add $exit, $urandom, $urandom_mode, and $srandom to index per Editorial review	Change	Index
LRM-129	SV-EC	11.20	Replace -> with . for class example per Editorial review	Change	Section 11.20
LRM-130	SV-EC	12.4.7	Correct cross reference to 12.7.1 per Editorial review	Change	Section 12.4.7
LRM-131	SV-EC	12.5.3	Add reference to $srandom definition where used per Editorial review	Change	Section 12.5.3
LRM-132	SV-EC	12.5.2	Clarification of use of super in if example per Editorial review	Change	Section 12.5.2
LRM-133	SV-EC	13.3.3 13.3.4	Clarify singular per Editorial review	Change	Section 13.3.3 Section 13.3.4
LRM-134	SV-EC	13.3.5 13.3.6 13.3.7 13.3.8	Change l-value to left-hand side expression per Editorial review	Change	Section 13.3.5 Section 13.3.6 Section 13.3.7 Section 13.3.8
LRM-135	SV-EC	15.7	Replace module with test for example per Editorial review	Change	Section 15.7
LRM-136	SV-EC	15.2	Replace read-only-synchronize with postponed region per Editorial review	Change	Section 15.2
LRM-137	SV-EC	15.14	Reword example to remove confusion with sampling per Editorial review	Change	Section 15.14
LRM-138	SV-EC	4.2	Clarify short hand notation based on comments from Stefen	Change	Section 4.2
LRM-139	SV-BC	19.4	Correct example for interface	Change	Section 19.4
LRM-140	SV-EC	10.5.1 10.5.2	Fixed illegal packed array specification found by Arturo	Change	Section 10.5.1 Section 10.5.2
LRM-141	SV-BC	A.8.1 A.8.4	Changed BNF of concatenation, constant_concatenation, primary, and constant_primary per Dave Rich	Change	Section A.8.1 Section A.8.4
LRM-142	SV-EC	3.8	Missing . between Verilog and However in third paragraph from Neil's review	Change	Section 3.8
LRM-143	SV-EC	3.8	Clarify use of operand and string in concatenation semantics of Table 3-2 from Neil's review	Change	Section 3.8
LRM-144	SV-EC	3.11	Grammer error found from Neil's review	Change	Section 3.11
LRM-145	SV-EC	3.11.4.2	Grammer error found from Neil's review	Change	Section 3.11.4.2
LRM-146	SV-EC	3.11.4.3 3.11.4.4 3.11.4.6	Replace function with member per Neil's review	Change	Section 3.11.4.3 Section 3.11.4.4 Section 3.11.4.6
LRM-147	SV-EC	4.2	Replace scalar (non-unpacked-array type) with singular per Neil's review	Change	Section 4.2
LRM-148	SV-EC	10.5.3	Formatting of examples inconsistent per Neil's review	Change	Section 10.5.3
LRM-149	SV-EC	10.5.4	Remove blank lines in example per Neil's review	Change	Section 10.5.4
LRM-150	SV-EC	12.4.7	Grammer error found from Neil's review	Change	Section 12.4.7
LRM-151	SV-EC	13.2	Extend EC-CH107 to try_get per Neil's review	Change	Section 13.2
LRM-152	SV-AC	17.3	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".	Open
LRM-153	SV-AC	17.4	Page 162, section 17.4, 3rd paragraph    "The timing model employed in concurrent..."    "The timing model employed in a concurrent..."  <--- correction	Open
LRM-154	SV-AC	17.4	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	Open
LRM-155	SV-AC	17.5	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	Open
LRM-156	SV-AC	17.5	Page 167, 2nd paragraph    "After signal c, the signal length..."    "After signal c, the sequence length..."  <-- correction	Open
LRM-157	SV-AC	17.5	Page 167, 2nd paragraph    "...when complex sequences constructed by..."    "...when complex sequences are constructed by..."  <--- corrected	Open
LRM-158	SV-AC	17.6	Sequences can be reused by declaring them as objects of type sequence with optional parameters:	Open
LRM-159	SV-AC	17.6	Page 167, section 17.6, 1st paragraph    sequence should be bold.	Open
LRM-160	SV-AC	17.7.3	Page 174, section 17.7.3    1st paragraph under figure 17-5    "...the expression succeeds..."    <--- which expression? (te1 and te2?)	Open
LRM-161	SV-AC	17.7.3	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	Open
LRM-162	SV-AC	17.7.5	Page 177, 2nd paragraph    "...sequence is associated with time range..."    "...sequence is associated with a time range..."  <---- corrected	Open
LRM-163	SV-AC	17.7.10	Page 183, section 17.7.10, 2nd example    data_end1 |-> ##[1:2]    data_end  |-> ##[1:2]    <--- corrected	Open
LRM-164	SV-AC	17.10	Page 188, section 17.10, last paragraph    "A property declaration is parameterized, like..."    "A property declaration can have arguments, like..."  <--- correction	Open
LRM-165	SV-AC	17.14	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?	Open
LRM-166	SV-AC	B	Add endsequence and endproperty to Annex B per Neil's review	Change	Section B
LRM-167	SV-BC	10.2	Change reg to logic per Neil's review and Dave Rich's input	Change	Section 10.2
LRM-168	SV-EC	A.2.6 A.2.7	Change handle to chandle per Stefen Boyd	Change	Section A.2.6 Section A.2.7
LRM-169	SV-EC	A.2.7	Add the "tf_" to the data_type in tf_ref_declaration per Stefen Boyd	Change	Section A.2.7
LRM-170	SV-EC	A.8.4 A.Notes	Super is not defined in the BNF	Change	Section A.8.4 Section A.Notes
LRM-171	SV-EC	A.1.5 A.1.6 A.6.2	Final is not defined in the BNF	Change	Section A.1.5 Section A.1.6 Section A.6.2
LRM-172	SV-EC	A.1.8	local is not defined in the BNF replace private	Change	Section A.1.8
LRM-173	SV-EC	A.8.4 A.Notes	this is not defined in the BNF	Change	Section A.8.4 Section A.Notes
LRM-174	SV-BC	12.4.6	Handle dangling else for if else constraints per Dan Jacobi's review	Change	Section 12.4.6
LRM-175	SV-BC	A.6.8	DJ-AA-13. BNF for more than one initial statement and more than one-step assignment with in a for loop is missing. Currently the BNF for the following for loop statement is  missing: for (a=1,b=2 ; a<10 & b<200 ; a=a+1,b=b*2) …	Change	Section A.6.8
LRM-176	SV-AC	A.6.3	DJ-AA-14. Under A.6.3 the following production is problematic  action_block ::= [ statement ] [ else statement ] ; The following assertion statement can be interpreted in more than one way: assert (cond) if (cond2) a = 1; else a = 2;; One-way to parse this statement - If the assertion succeeds (cond == true) evaluate the if-else conditional statement. The other way to parse this statement is – If the assertion succeeds (cond == true) and if cond2 is true than assign ‘a’ with the value 1. If the assertion fails then assign ‘a’ with the value 2. Some language needs to be added chapter 17 that deals with this case and with more complicated cases such as nested assertion and nested conditional if-else statements and the nesting of assertions in if-else statements and vise-versa for example how should the following RTL be parsed “ always  if (c1) assert (c2); else assert(c3); else if (c4) a =1; else a = 2;; else a=3;;;;;;;;	Change	Section A.6.3
LRM-177	SV-AC	A.2.10	DJ-AA-15. Under A.2.10 the following production has a loop: sequence_expr ::= [ cycle_delay_range ] sequence_expr { cycle_delay_range sequence_expr } … The token sequence_expr can parse itself I would recommend the following change to the begging of the sequence_expr production sequence_expr ::= [ cycle_delay_range ] sequence_expr { cycle_delay_range sequence_expr } cycle_delay_range  sequence_expr { cycle_delay_range sequence_expr } | sequence_expr cycle_delay_range sequence_expr  { cycle_delay_range   sequence_expr } Stefen responds: not clear what is being requested. The suggested change doesn't seem to make the production work any better.	Open
LRM-178	SV-AC	A.2.10	Change sequence_expr production (making parens bold) per Dan Jacobi	Change	Section A.2.10
LRM-179	SV-AC	A.2.10	DJ-AA-17. Precedence for the operators added by the sequence_expr production under A.2.10 should be added to section. The precedence for the and, intersect, or, first_match, throughout, and within operators is not defined. The following sequence expression :  d1 intersect d2 within d2 Can be parsed in two ways:  (d1 intersect d2) within d2  d1 intersect (d2 within d2) Stefen responds: This is not a bnf issue. AC needs to update LRM to indicate operator precedence	Open
LRM-180	SV-AC	A.2.10	DJ-AA-18. Under A.2.10 the production sequence_expr  causes a problem when adding a prentices around an expression that relates from the primary production. In the following example: d1 within (d2 & d3)   The prentices may be parsed using the primary production (primary :: = ( mintypmax_expression ) ) or using the sequence_expr production (sequence_expr ::= ( sequence_expr ) [ sequence_abbrev ] ) Stefen Responds: expression leads to primary which can be ( mintypmax_expression ) which is where confusion lies... I don't have any suggestions.	Open
LRM-181	SV-AC	A.2.10	DJ-AA-19. Under A.2.10 replace the name of the token const_range_expression to sequence_const_range_expression. The original name causes confusion with the constant_range_expression token.	Change	Section A.2.10
LRM-182	SV-BC	B	Remove longreal per Shalom Bresticker	Change	Section B
LRM-183	SV-BC	9.1	Reword per Matt Maidment	Change	Section 9.1
LRM-184	SV-BC	9.1	Remove comma per Matt Maidment	Change	Section 9.1
LRM-185	SV-BC	9.2 9.3 9.4	Titles are confusing change per Matt Maidment	Change	Section 9.2 Section 9.3 Section 9.4
LRM-186	SV-BC	9.6	Reword purpose of fork...join to be consistent with 1364-2001 per Matt Maidment	Change	Section 9.6
LRM-187	SV-BC	9.6	Reword SystemVerilog addition per Matt Maidment	Change	Section 9.6
LRM-188	SV-BC	9.6	Remove redundant word and grammer fix per Matt Maidment	Change	Section 9.6
LRM-189	SV-BC	9.7 9.8.2	Grammer fix per Matt Maidment	Change	Section 9.7 Section 9.8.2
LRM-190	SV-EC	3.8	Remove paragraph that contains redundant info per Neil Korpusik	Change	Section 3.8
LRM-191	SV-EC	10.5.2	Fix example per Arturo	Change	Section 10.5.2
LRM-192	SV-EC	11.13	Change property to member in description of Super per Arturo	Change	Section 11.13
LRM-193	SV-EC	11.19	Add comments to example per Arturo	Change	Section 11.19
LRM-194	SV-EC	15.11	Move clocking domain into module in example per Arturo	Change	Section 15.11
LRM-195	SV-EC	15.12 15.13	Swap 15.12 and 15.13 per Arturo	Change	Section 15.12 Section 15.13
LRM-196	SV-EC	19.5.2	Fix example per Arturo	Change	Section 19.5.2
LRM-197	SV-EC	3.11	Fix example per Arturo	Change	Section 3.11
LRM-198	SV-EC	5.7	Fix example per Arturo	Change	Section 5.7
LRM-199	SV-EC	A.1.7	Continuous assignment missing in list of program items	Change	Section A.1.7
LRM-200	SV-BC	18.5 19.2.1 19.2.2 19.4 19.4.1 19.4.2 19.4.3 19.5.2 19.5.3 19.5.4 19.6	SV-BC-18fg makes it illegal to use a variable on an inout port. Instead, they must use a ref port. I found a number of examples that need to be updated.	Change	Section 18.5
					Section 19.2.2 Section 19.4 Section 19.4.1 Section 19.4.2 Section 19.4.3 Section 19.5.2 Section 19.5.3 Section 19.5.3 Section 19.5.4 Section 19.6
LRM-201	SV-EC	11.1	The notion of framework is kind of foreign to Verilog. Why not replacing this with: SystemVerilog introduces an object-oriented class type system. since classes are just a new type.  Other grammer errors and clarification per Francoise's review.	Change	Section 11.1
LRM-202	SV-EC	11.3	Define the term subroutine in the Verilog context per Francoise's review	Change	Section 11.3
LRM-203	SV-EC	11.3	The data and methods portions should be delimited. Sometimes the comment is on the first line, sometimes it is below. Based on Francoise's review.	Change	Section 11.3
LRM-204	SV-EC	11.4	Reword the introduction to object handles per Francoise's review.	Change	Section 11.4
LRM-205	SV-EC	11.4	Move the last row to the front of the table in Table 11-2 per Francoise's review.	Change	Section 11.4
LRM-206	SV-EC	11.7	Misuse of the term task per Francoise's review.	Change	Section 11.7
LRM-207	SV-EC	11.7	Clarify use of subroutine calling conventions per Francoise's review.	Change	Section 11.7
LRM-208	SV-EC	11.8.1	Raise in level per Francoise's review.	Change	Section 11.8.1
LRM-209	SV-EC	11.9	Enhance definition of this per Francoise's review.	Change	Section 11.9
LRM-210	SV-EC	11.13	Clarify use of super to members per Francoise's review.	Change	Section 11.13
LRM-211	SV-EC	11.13	Define derived class and parent class per Francoise's review.	Change	Section 11.13
LRM-212	SV-EC	11.15	Clarify new handling per Francoise's review.	Change	Section 11.15
LRM-213	SV-EC	11.16	Reword default public status per Francoise's review.	Change	Section 11.16
LRM-214	SV-EC	11.17	Change case per Francoise's review.	Change	Section 11.17
LRM-215	SV-EC	A.1.8	Make sure that static int size=0; is supported in a class in the BNF per Francoise's review.	Change	Section A.1.8
LRM-216	SV-EC	A.1.8 A.2.6 A.2.7	Make sure that static task foo and task static foo are supported in a class in the BNF per Francoise's review	Open	Section A.1.8 Section A.2.6 Section A.2.7
LRM-217	SV-EC	11.18	Fix font problem per Francoise's review	Change	Section 11.18
LRM-218	SV-EC	11.19	Clarify polymorphic description per Francoise's review	Change	Section 11.19
LRM-219	SV-EC	11.21	Replace attributes with hiding encapsulation qualifiers per Francoise's review	Change	Section 11.21
LRM-220	SV-EC	11.24	Replace framework with type system per Francoise's review	Change	Section 11.24
LRM-221	SV-EC	12.1	Replace framework with type system per Francoise's review	Change	Section 12.1
LRM-222	SV-EC	12.2	Remove duplicate sentence per Francoise's review	Change	Section 12.2
LRM-223	SV-EC	12.3	Remove such as from description per Francoise's review	Change	Section 12.3
LRM-224	SV-EC	12.4.4	Clarify sentence per Francoise's review	Change	Section 12.4.4
LRM-225	SV-EC	12.7	The function form of $rand_mode() only accepts scalar singular variables, thus, if the specified variable is an array, a single element must be selected via its index. But singular variables include packed arrays. Per Francoise review	Change	Section 12.7
LRM-226	SV-EC	12.6	Replace parameter with arguments per Francoise's review	Change	Section 12.6
LRM-227	SV-EC	12.11	Change stream to sequence per Francoise's review	Change	Section 12.11
LRM-228	SV-EC	12.11.3 12.12	Remove void function from examples	Change	Section 12.11.3 Section 12.12
LRM-229	SV-EC	5.4	Add table for default values for types per Bradford's review.	Change	Section 5.4
LRM-230	SV-EC	11.10	Correct comment in example per Bradford's review.	Change	Section 11.10
LRM-231	SV-EC	12.4.3	Clarify range handling in inside per Bradford's review.	Change	Section 12.4.3
LRM-232	SV-EC	12.4.8	Fix typo in range per Bradford's review.	Change	Section 12.4.8
LRM-233	SV-EC	13.2	Add Semaphore example per Bradford's review.	Change	Section 13.2
LRM-234	SV-EC	13.3	Add Mailbox example per Bradford's review.	Change	Section 13.3
LRM-235	SV-EC	19.4.3	Fix bold on example per Bradford's review.	Change	Section 19.4.3
LRM-236	SV-EC	19.5.2	Fix bold on example per Bradford's review.	Change	Section 19.5.2
LRM-237	SV-EC	1 11.25 12.11 13.1 15.1 15.8 16.2	Replace test-bench with testbench per Cliff's review	Change	Section 1
					Section 11.25
					Section 12.11
					Section 13.1
					Section 15.1 Section 15.8
					Section 16.2
LRM-238	SV-EC	13.1	Fix grammar per Cliff's review	Change	Section 13.1
LRM-239	SV-EC	13.2.1	Change key_count to keyCount in description per Cliff's review	Change	Section 13.2.1
LRM-240	SV-EC	14.2	Clean up wording per Cliff's review	Change	Section 14.2
LRM-241	SV-EC	14.3	Add cross reference per Cliff's review	Change	Section 14.3
LRM-242	SV-EC	15.4	Add cross reference per Cliff's review	Change	Section 15.4
LRM-243	SV-EC	15.14.2	Fix hyphenation per Cliff's review	Change	Section 15.14.2
LRM-244	SV-EC	15.7	Fix plurality per Cliff's review	Change	Section 15.7
LRM-245	SV-EC	15.7	Correct examples per Cliff's review	Change	Section 15.7
LRM-246	SV-EC	15.8	Correct examples per Cliff's review	Change	Section 15.8
LRM-247	SV-EC	15.11	Remove other per Cliff's review	Change	Section 15.11
LRM-248	SV-EC	15.14.2	Spelling fix per Cliff's review	Change	Section 15.14.2
LRM-249	SV-EC	18.6	Remove incorrect word per Cliff's review	Change	Section 18.6
LRM-250	SV-EC	C.4.2	Grammar correction per Neil's review	Change	Section C.4.2
LRM-251	SV-EC	C.4.3 C.5.6 C.5.10 C.5.11	Fix bold on methods per Neil's review	Change	Section C.4.3 Section C.5.6 Section C.5.10 Section C.5.11
	SV-EC