NOTE: You will have to handle the red on bold items (keywords and punctuation since red is used here for changes. Sorry.

Section A.1.5

LRM-171

Changes:

module_or_generate_item ::=

  { attribute_instance } parameter_override

| { attribute_instance } continuous_assign

| { attribute_instance } gate_instantiation

| { attribute_instance } udp_instantiation

| { attribute_instance } module_instantiation

| { attribute_instance } initial_construct

| { attribute_instance } always_construct

| { attribute_instance } combinational_statement

| { attribute_instance } latch_statement

| { attribute_instance } ff_statement

| { attribute_instance } net_alias

| { attribute_instance } final_construct

| module_common_item

| { attribute_instance } ;

Section A.1.6

LRM-171

Changes:

interface_or_generate_item ::=

  { attribute_instance } continuous_assign

| { attribute_instance } initial_construct

| { attribute_instance } always_construct

| { attribute_instance } combinational_statement

| { attribute_instance } latch_statement

| { attribute_instance } ff_statement

| { attribute_instance } local_parameter_declaration

| { attribute_instance } parameter_declaration ;

| module_common_item

| { attribute_instance } modport_declaration

| { attribute_instance } extern_tf_declaration

| { attribute_instance } final_construct

| { attribute_instance } ;

LRM-46

Remove editor’s note:

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

Section A.1.7

LRM-199

Changes:

non_port_program_item ::=

| { attribute_instance } continuous_assign

| { attribute_instance } module_or_generate_item_declaration

| { attribute_instance } specparam_declaration

| { attribute_instance } local_parameter_declaration

| { attribute_instance } parameter_declaration ;

| { attribute_instance } initial_construct

| { attribute_instance } concurrent_assertion_item

| class_declaration

Section A.1.8

LRM-215

Changes:

class_item ::=

 { attribute_instance } [ rand_property ] [ class_item_property hiding_property ] data_declaration

| { attribute_instance } { tf_property } task_declaration

| { attribute_instance } { tf_property } function_declaration

| { attribute_instance } { tf_property } method_prototype

| { attribute_instance } constraint_prototype

| { attribute_instance } [ class_item_property hiding_property ] specparam_declaration

| { attribute_instance } [ class_item_property hiding_property ] local_parameter_declaration

| { attribute_instance } [ class_item_property hiding_property ] parameter_declaration ;

| { attribute_instance } [ class_item_property hiding_property ] constant_property

| { attribute_instance } constraint_declaration

LRM-216

Changes:

extern_method_declaration ::=

  { tf_property } function [ lifetime automatic ] class_identifier :: function_body_declaration

| { tf_property } task [lifetime automatic] class_identifier :: task_body_declaration

LRM-172 LRM-215

Changes:

class_item_property hiding_property ::=

 static

| protected

| local private

LRM-215

Changes:

tf_property ::=

  virtual

| class_item_property hiding_property

LRM-47

Remove editor’s note:

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

Section A.2.2.1

LRM-48

Changes:

non_integer_type ::= time | shortreal | real | realtime | $built-in

Remove editor’s note:

Editor’s Note: Why isn’t $built-in mentioned in the text? What is it? Remove? Should be bold?

LRM-50

Remove editor’s note:

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)?

LRM-50

Remove editor’s note:

Editor’s Note: String and event assignment restrictions not part of bnf productions (semantic only)

Section A.2.6

LRM-52

Remove editor’s note:

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)?

LRM-168

Changes:

| string

| chandle

| void

LRM-216

Changes:

function_declaration ::=

function [ lifetime automatic ] function_body_declaration

LRM-53

Remove editor’s note:

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.

LRM-54

Changes:

named_function_proto::= [ signing ] function_data_type function_identifier ( list_of_function_proto_formals )

Remove editor’s note:

Editor’s Note: Since [ signing ] was removed from function_data_type, we can’t have a signed prototype?

Section A.2.7

LRM-216

Changes:

task_declaration ::= task [lifetime automatic] task_body_declaration

LRM-84 LRM-169

Changes:

tf_ref_declaration ::=

[const] ref tf_data_type list_of_tf_variable_identifiers

LRM-168

Changes:

tf_data_type ::=

  data_type

| chandle

Section A.2.7

LRM-178

Changes:

sequence_expr ::=

  [ cycle_delay_range ] sequence_expr { cycle_delay_range sequence_expr }

| expression { , function_blocking_assignment } [ boolean_abbrev ]

| sequence_instance [ sequence_abbrev ]

| ( sequence_expr ) [ sequence_abbrev ]

| sequence_expr and sequence_expr

| sequence_expr intersect sequence_expr

| sequence_expr or sequence_expr

| first_match ( sequence_expr )

| expression throughout sequence_expr

| sequence_expr within sequence_expr

Section A.2.10

LRM-180

Changes:

sequence_expr ::=

  [ cycle_delay_range ] sequence_expr { cycle_delay_range sequence_expr }

| expression { , function_blocking_assignment } [ boolean_abbrev ]

| sequence_instance [ sequence_abbrev ]

| ( ( sequence_expr ) ) [ sequence_abbrev ]

| sequence_expr and sequence_expr

| sequence_expr intersect sequence_expr

| sequence_expr or sequence_expr

| first_match ( sequence_expr )

| expression throughout sequence_expr

| sequence_expr within sequence_expr

LRM-180

Changes:

const_or_range_expression ::=

  constant_expression

| const_range_expression sequence_const_range_expression

 

sequence_const_range_expression const_range_expression ::=

  constant_expression : constant_expression

| constant_expression : $

Section A.6.1

LRM-56

Changes:

net_alias ::= alias expression net_lvalue = expression  net_lvalue;

Remove editor’s note:

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])

Section A.6.2

LRM-171

Changes:

variable_assignment ::=

  operator_assignment

| inc_or_dec_expression

 

final_construct ::= final function_statement

Section A.6.3

LRM-176

Changes:

action_block ::= [ statement ] [ else statement ] ;  statement _or_null | [ statement ] else statement

Section A.6.8

LRM-175

Changes:

function_loop_statement ::=

  forever function_statement_or_null

| repeat ( expression ) function_statement_or_null

| while ( expression ) function_statement_or_null

| for ( variable_decl_or_assignment { , variable_decl_or_assignment } ; expression ; variable_assignment { , variable_assignment } )

     function_statement_or_null

LRM-175

Changes:

loop_statement ::=

  forever statement_or_null

| repeat ( expression ) statement_or_null

| while ( expression ) statement_or_null

| for ( variable_decl_or_assignment { , variable_decl_or_assignment }; expression ; variable_assignment { , variable_assignment } )

    statement_or_null

| do statement_or_null while ( expression ) ;

Section A.8.1

LRM-141

Changes:

 

concatenation ::= { expression { , expression } }

   { expression { , expression } }

|  { struct_member_label : expression { , struct_member_label : expression } }

|  { array_member_label : expression { , array_member_label : expression } }

 

constant_concatenation ::= { constant_expression { , constant_expression } }

  { constant_expression { , constant_expression } }

| { struct_member_label : constant_expression { , struct_member_label : constant_expression } }

| { array_member_label : constant_expression { , array_member_label : constant_expression } }

 

struct_member_label ::=

  default

| type_identifier

| variable_identifier

 

array_member_label ::=

  default

| type_identifier

| constant_expression

Section A.8.3

LRM-57

Remove editor’s note:

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.

Section A.8.4

LRM-141 LRM-170 LRM-173

Changes:

constant_primary ::=

  constant_concatenation

| constant_function_call

| ( constant_mintypmax_expression )

| constant_multiple_concatenation

| genvar_identifier

| number

| parameter_identifier

| specparam_identifier

| casting_type ' ( constant_expression )

| casting_type ' constant_concatenation

| casting_type ' constant_multiple_concatenation

| time_literal

| ’0 | ’1 | ’z | ’Z | ’x | ’X

 

module_path_primary ::=

  number

| identifier

| module_path_concatenation

| module_path_multiple_concatenation

| function_call

| system_function_call

| constant_function_call

| ( module_path_mintypmax_expression )

 

primary ::=

  number

| implicit_class_handle hierarchical_identifier { [ expression ] } [ [ range_expression ] ]

[ . method_identifier { attribute_instance } [ ( expression { , expression } ) ] ]

| concatenation

| multiple_concatenation

| function_call

| system_function_call

| constant_function_call

| ( mintypmax_expression )

| casting_type ( expression )

| void ’ ( function_call )

| casting_type { expression { , expression } } concatenation

| casting_type { expression { expression } } multiple_concatenation

| time_literal

| ’0 | ’1 | ’z | ’Z | ’x | ’X

| null

LRM-170 LRM-173

Changes:

 

time_literal7 ::=

  unsigned_number time_unit

| fixed_point_number time_unit

time_unit ::= s | ms | us | ns | ps | fs

 

implicit_class_handle10 ::= [ this. ] | [ super. ]

LRM-58

Remove editor’s note:

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.

Section A.9.3

LRM-59

Changes:

real_identifier ::= identifier

Remove editor’s note:

Editor’s Note: This isn’t referenced by any other production. Remove? Add reference somewhere?

LRM-60

Changes:

state_identifier ::= identifier

Remove editor’s note:

Editor’s Note: Looks like this is left over from state machine syntax that didn’t make it into 3.0

LRM-61

Remove editor’s note:

Editor’s Note: This isn’t referenced by any other production. Remove? Add reference somewhere?

Section A.notes

LRM-170 LRM-173

Changes:

9) Open-array ( [ ] ) form shall only be used with dpi_proto_formal

 

10) implicit_class_handle shall only appear with the scope of a class_declaration or extern_method_declaration