Section 10.1

LRM-11

Remove:

Editor’s Note: Previous bullet added by the editor. It was not actually specified in EC-C120.

Section 10.2

LRM-80

Changes:

input       // copy value in at beginning

output // copy value out at end

inout       // copy in at beginning and out at end

ref           // pass reference (see Section 10.5.2)

LRM-167

Changes:

Each formal argument also has a data type which can be explicitly declared or can inherit a default type. The task argument default type in SystemVerilog is logic reg.

Section 10.3

LRM-81

Changes:

SystemVerilog extends Verilog functions to allow the same formal arguments as tasks to be inputs or outputs. Function arguments are all passed by value, i.e. copied. directions are:

 

input // copy value in at beginning

output // copy value out at end

inout // copy in at beginning and out at end

ref           // pass reference (see Section 10.5.2)

Section 10.5.1

LRM-140

Changes:

function int crc( byte [1000:1] packet [1000:1] );

for( int j= 0 1; j <= 1000; j++ ) begin

crc ^= packet[j];

end

endfunction

Section 10.5.2

LRM-140

Changes:

function int crc( ref byte [1000:1] packet [1000:1] );

for( int j= 1; j <= 1000; j++ ) begin

crc ^= packet[j];

end

endfunction

LRM-191

Changes:

byte packet1[1000:1];

int k = crc( packet1 ); // pass by value or by reference: call is the same

LRM-1

Changes:

Passing an argument by reference is a unique parameter argument passing qualifier, different from input, output, or inout. Combining ref with any other qualifier is illegal. For example, the following declaration results in a compiler error:

Remove:

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”.

Section 10.5.3

LRM-148

Original:

read( , 5 ); // is equivalent to read( 0, 5, 1 );

 

read( 2, 5 ); // is equivalent to read( 2, 5, 1 );

 

read( , 5, ); // is equivalent to read( 0, 5, 1 );

 

read( , 5, 7 ); // is equivalent to read( 0, 5, 7 );

 

read( 1, 5, 2 ); // is equivalent to read( 1, 5, 2 );

 

read( ); // error; k has no default value

 

Changes (include remove blank lines):

read( , 5 );         // is equivalent to read( 0, 5, 1 );

read( 2, 5 );        // is equivalent to read( 2, 5, 1 );

read( , 5, );        // is equivalent to read( 0, 5, 1 );

read( , 5, 7 );      // is equivalent to read( 0, 5, 7 );

read( 1, 5, 2 );     // is equivalent to read( 1, 5, 2 );

read( );             // error; k has no default value

Section 10.5.4

LRM-1

Changes:

SystemVerilog allows arguments to tasks and functions to be passed by name as well as by position. This allows specifying non-consecutive default arguments and easily specifying the parameter argument to be passed at the call. For example:

 

Remove:

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”.

LRM-149

Original:

fun( .j(2), .s("yes") );     // fun( 2, “yes” );

 

fun( .s("yes") );           // fun( 1, “yes” );

 

fun( , "yes" );              // fun( 1, “yes” );

 

fun( .j(2) );               // fun( 2, “no” );

 

fun( 2 );                  // fun( 2, “no” );

 

fun( );                    // fun( 1, “no” );

Changes (remove blank lines):

fun( .j(2), .s("yes") );     // fun( 2, “yes” );

fun( .s("yes") );           // fun( 1, “yes” );

fun( , "yes" );              // fun( 1, “yes” );

fun( .j(2) );               // fun( 2, “no” );

fun( 2 );                  // fun( 2, “no” );

fun( );                    // fun( 1, “no” );

Section 10.6

LRM-12 LRM-13

Changes:

For any given cname, all declarations, regardless of scope, must have exactly the same type function signature. The type function signature includes the return type, the number, order, direction and types of each and every argument. Each type 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 24.4.6.1. The signature Signature also includes the pure/context qualifiers that can be associated with an import definition.

Remove editor’s note:

Editor’s Note: What is meant by “Signature”?

Editor’s Note: Need to update cross reference in preceding paragraph.