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.	No Change	Section 2.5
			Editor’s Note: What is meant by "actual parameter" in the preceding paragraph? Is it referring to the Verilog parameter data type?
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):	No Change	Section 2.8
			Editor’s Note: Is the cross reference above correct?
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()	No Change	Section 3.8.9
			function integer atohex()
			function integer atooct()
			function integer atobin()
			Editor’s Note: "integer" or "int"?
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.	Change	Section 3.10
			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.
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)	No Change	Section 10.1
			Editor’s Note: Previous bullet added by the editor. It was not actually specified in EC-C120.
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.	Change	Section 10.6
			Editor’s Note: What is meant by "Signature"?
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.	Change	Section 10.6
			Editor’s Note: Need to update cross reference in preceding paragraph.
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.	No Change	Section 11.22
			Response: It appears that the LRM only supports static int and not int static. This may be enhanced in a future version.
LRM-16	SV-EC	12.4.3	inside	No Change	Section 12.4.3
			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.).
LRM-17	SV-EC	12.4.4	dist	No Change	Section 12.4.4
			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.).
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.	Change	Section 7.9
			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.).		Section 12.4.4
LRM-19	SV-EC	12.4.5	=>	No Change	Section 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.).
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 ) ] ;	Change	Section 12.10.1
			Editor’s Note: Verilog syntax is "function int unsigned" instead of "function unsigned int". Co-design’s SystemSim allows both Verilog and C styles.
LRM-22	SV-EC	12.10.2	function unsigned int $urandom_range( unsigned int maxval, unsigned int minval = 0 );	Change	Section 12.10.2
			Editor’s Note: Verilog syntax is “function int unsigned” instead of “function unsigned int” ?
LRM-23	SV-EC	12.10.3	task $srandom( int seed, [object obj] );	Change	Section 12.10.3
			Editor’s Note: Is “object” a data type? There is no keyword “object” anywhere else in the LRM.
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.	Change	Section 14.4
			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.
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.	Change	Section 18.8.3
			Editor’s Note: What is the cross reference for above?
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.	No Change	No Change
LRM-28	SV-CC	26.4.4	Each imported function shall be declared. Such declaration are referred to as import declarations. The syntax	No Change	Section 26.4.4
			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?
LRM-29	SV-CC	26.4.4	import "DPI" newQueue=function handle newAnonQueue(input string s=NULL);	Change	Section 26.4.4
			Editor’s Note: Is the uppercase “NULL” correct? The SystemVerilog keyword is in lowercase.
LRM-30	SV-CC	26.4.6.1	Here are examples of types of formal arguments (empty square brackets [] denote open array):	Change	Section 26.4.6.1
			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?
LRM-31	SV-CC	27.1.2	Assertion Temporal expression—A declarative expression (one or more clock cycles) describing the behavior	Change	Section 27.1.2
			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?
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.	Change	Section 27.2
			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"
LRM-33	SV-CC	27.2.3	27.2.2 Object properties	No Change	Section 27.2.3
			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.
LRM-34	SV-CC	27.3.2	— Any assertion updates from the SV-AC.	Change	Section 27.3.2
			— 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?
LRM-35	SV-CC	27.4.1	Section 27.4.1 Placing assertion “system” callbacks	Change	Section 27.4.1
			Editor’s Note: Why is “system” in quotes?.
LRM-36	SV-CC	27.4.2	cbAssertionStepSucess	Change	Section 27.4.2
			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?.
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.	Change	Section 27.5.2
			Editor’s Note: Why is “step control” in quotes?.
LRM-38	SV-CC	28.2	This section ...	Change	Section 28.2
			Editor’s Note: Something appears to be missing in this section.
LRM-39	SV-CC	28.2.2	This section ...	Change	Section 28.2.2
			Editor’s Note: Something appears to be missing in this section.
LRM-40	SV-CC	28.3.1	/* tool state_vector signal_name */	No Change	Section 28.3.1
			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
LRM-41	SV-CC	28.3.6	parameter [1:0] /* tool enum enumeration_name */	No Change	Section 28.3.6
			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.
LRM-42	SV-CC	28.4	This section ...	Change	Section 28.4
			Editor’s Note: Something appears to be missing in this section.
LRM-43	SV-CC	28.4.1	This section ...	Change	Section 28.4.1
			Editor’s Note: Something appears to be missing in this section.
LRM-44	SV-CC	28.4.3	All **what?? use vpi_get() along with the appropriate properties and object handles.	Change	Section 28.4.3
			Editor’s Note: The preceding sentence needs to be fixed.
LRM-45	SV-CC	28.4.4	28.4.4 Controlling coverage	Change	Section 28.4.4
			**Revise similar to Assertions**
			Editor’s Note: What is this comment referring to?
LRM-46	SV-BC	A.1.6	extern_tf_declaration ::=	No Change	Section A.1.6
			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
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	Change	Section 11.16
			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”.		Section A.1.8
LRM-48	SV-BC	A.2.2.1	non_integer_type ::= time | shortreal | real | realtime | $built-in	Change	Section A.2.2.1
			Editor’s Note: Why isn’t $built-in mentioned in the text? What is it? Remove? Should be bold?
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	No Change	No Change
			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. SUGGESTION: Singular should not become a BNF construct.  Singular is defined only to refer to non-aggregate types in the text of the LRM.  Some system tasks and built-in methods will need semantic checks to restrict their use to singular types, but that is best handled semantically and not via BNF.
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)?	No Change	Section A.2.2.1
			SV-BC responds:
			Existing port connection sematics take care of this.
LRM-51	SV-EC	A.2.2.1	Editor’s Note: String and event assignment restrictions not part of bnf productions (semantic only)	No Change	Section A.2.2.1
			SV-BC responds:
			Should be moved back to EC, because string was added by EC
LRM-52	SV-BC	A.2.6	Editor’s Note: Enum here suggests that we can have return values:	No Change	Section A.2.6
			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
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.	No Change	Section A.2.6
			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.
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.	Change	Section A.2.7 (Draft 5 change)
			SV-BC Responds:
			It looks OK, but it should be moved back to EC because it was changed by them. RESPONSE: The BNF needs to allow for the optional signed on all task/function arguments, regardless of their direction (input, output, or inout).  This is needed for backward compatibility with V2K. For the same reason, the implicit “reg” type must be supported.  Hence, “output signed [3:0] foo” is valid.
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])	Change	Section A.6.1
			SV-BC Responds:
			Alias was pushed by SV-EC, therefore this issue should be moved back to them
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.	No Change	Section A.8.4
			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.
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.	Change	Section D.1
			Editor’s Note: What is the correct cross reference, above?
LRM-63	SV-CC	D.5	Note that the constraints expressed here merely restate those expressed in section 1.4.1.	Change	Section D.5
			Editor’s Note: What is the correct cross reference, above?
LRM-64	SV-CC	D.5.5	Also refer to section 1.4.3.	Change	Section D.5.5
			Editor’s Note: What is the correct cross reference, above?
LRM-65	SV-CC	D.5.6	See also 1.4.2.	Change	Section D.5.6
			Editor’s Note: What is the correct cross reference, above?
LRM-66	SV-CC	D.5.7	See also section 1.4.1.4.	Change	Section D.5.7
			Editor’s Note: What is the correct cross reference, above?
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 ??).	Change	Section D.6.6
			Editor’s Note: What is the correct cross reference, above?
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.	Change	Section D.7.2
			Editor’s Note: What is the correct cross reference, above?
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.	Change	Section D.7.5
			Editor’s Note: What is the correct cross reference, above?
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?]	Change	Section D.7.7
			Editor’s Note: Has the preceding note been taken care of?
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.	Change	Section D.8
			Editor’s Note: Has the preceding note been taken care of?
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).	Change	Section D.10.2
			Editor’s Note: What is the correct cross reference, above?
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).	Change	Section D.11.1
			Editor’s Note: What is the correct cross reference, above?
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 litera