Section 18.1

LRM-224

Change (changes in red and blue):

— Removal of the $root global declaration space from SystemVerilog 3.1

Section 18.2

LRM-207 LRM-249

Change Syntax 18-1 (changes in red and blue):

package_declaration ::=                                      // from Annex A.1.3

{ attribute_instance } package package_identifier ;

[ timeunits_declaration ] { { attribute_instance } package_item }

endpackage [ : package_identifier ]

LRM-240 LRM-249 LRM-250

Change Syntax 18-1 (changes in red and blue):

package_item ::=

  package_or_generate_item_declaration

| specparam_declaration

| concurrent_assertion_item_declaration

| anonymous_program

| timeunits_declaration19

 

package_or_generate_item_declaration ::=

  net_declaration

| data_declaration

| task_declaration

| function_declaration

| dpi_import_export

| extern_constraint_declaration

| extern_method_declaration

| class_declaration

| class_constructor_declaration

| parameter_declaration ;

| local_parameter_declaration

| covergroup_declaration

| overload_declaration

| concurrent_assertion_item_declaration

LRM-250

Change Syntax 18-1 (changes in red and blue):

anonymous_program_item ::=

  task_declaration

| function_declaration

| class_declaration

| class_constructor_declaration

| covergroup_declaration

LRM-224

Re-indent the ComplexPkg package (Complex is not indented correctly) (changes in red and blue):

 

Section 18.2.1

LRM-205

Change (changes in red and blue):

The import statement provides direct visibility of identifiers within packages. It allows identifiers declared within packages to be visible within the current scope without a package name qualifier. Hierarchical references to imported identifiers are allowed as if they were defined in the importing scope. Two forms of the import statement are provided: explicit import, and wildcard import. Explicit import allows control over precisely which symbols are imported:

 

import ComplexPkg::Complex;

import ComplexPkg::add;

 

An explicit import is treated like a local declaration. An explicit import shall be illegal if the imported identifier is declared in the same scope or explicitly imported from another package. Importing an identifier from the same package multiple times is allowed.

Section 18.3

LRM-233

Change (changes in red and blue):

When an identifier is referenced within a scope, SystemVerilog follows the Verilog name search rules:

 

— First, the nested scope is searched (1364-2001 12.6) (including nested module declarations), including any identifiers made available through package import declarations

 

— Next, the compilation-unit scope is searched, (including any symbols identifiers made available through package import declarations)

 

— Finally, the instance hierarchy is searched (1364-2001 12.5))

Section 18.7

LRM-242

Change (changes in red and blue):

extern module m (a,b,c,d);

extern module a #(parameter size= 8, parameter type type TP = logic [7:0])

(input [size:0] a, output TP b);

 

module top ();

wire [8:0] a;

logic [7:0] b;

 

m m (.*);

a a (.*);

endmodule

LRM-242

Change (changes in red and blue):

module a #(parameter size = 8, parameter type TP = logic [7:0])

(input [size:0] a, output TP b);

…

endmodule

 

Section 18.8

LRM-218 LRM-243

Change Syntax 18-4 (changes in red and blue):

inout_declaration ::=

  inout [ port_type ] list_of_port_identifiers

| inout data_type list_of_variable_identifiers

LRM-243

Change Syntax 18-4 (changes in red and blue):

input_declaration ::=

  input [ port_type ] list_of_port_identifiers

| input data_type list_of_variable_identifiers

 

output_declaration ::=

  output [ port_type ] list_of_port_identifiers

| output data_type list_of_variable_port_identifiers

LRM-243

Change Syntax 18-4 (changes in red and blue):

generic_interface_port_declaration ::=

  interface list_of_interface_identifiers

| interface . modport_identifier list_of_interface_identifiers

 

port_type ::=                                                         // from Annex A.2.2.1

  data_type

| net_type [ signing ] { packed_dimension }

| trireg [ signing ] { packed_dimension }

| [ signing ] { packed_dimension } range

 

port_type ::=                                                         // from Annex A.2.2.1

 

[ net_type_or_trireg ] [ signing ] { packed_dimension }

Section 18.9

LRM-243

Change (changes in red and blue):

The self-determined type of the port expression becomes the type for the port. If the port expression is to be an aggregate expression, then a cast must be used since self-determined aggregate expressions are not allowed. The port_expression port expression must resolve to a legal expression for type of module port (See section 18.12—Port connection rules). The port expression is optional because ports can be defined that do not connect to anything internal to the port.

 

Section 18.13

LRM-224

Change (changes in red and blue):

 

5) The module name space is introduced by $root and the module, macromodule, interface, package, program, and primitive constructs. It unifies the definition of modules, macromodules, interfaces, programs, functions, tasks, named blocks, instance names, parameters, named events, net declarations, variable declarations and user defined types within the enclosing construct.

LRM-224

Change (changes in red and blue):

7) The port name space is introduced by the module, macromodule, interface, primitive, and program constructs. It provides a means of structurally defining connections between two objects that are in two different name spaces. The connection can be unidirectional (either input or output) or bidirectional (inout or ref). The port name space overlaps the module and the block name spaces. Essentially, the port name space specifies the type of connection between names in different name spaces. The port type of declarations includes input, output, and inout, and ref. A port name introduced in the port name space can be reintroduced in the module name space by declaring a variable or a net with the same name as the port name.

 

Section 18.14

LRM-224

Change (changes in red and blue):

Nested identifiers can be read (in expressions), written (in assignments or task/function calls) or triggered off (in event expressions). They can also be used as type, task or function names.