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 } ;
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 } ;
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
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
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
extern_method_declaration ::=
{ tf_property } function [ lifetime
automatic ] class_identifier :: function_body_declaration
| { tf_property } task [lifetime automatic] class_identifier :: task_body_declaration
class_item_property hiding_property ::=
static
| protected
| local
private
tf_property ::=
virtual
| class_item_property hiding_property
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”.
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?
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)?
Editor’s Note: String and event assignment restrictions not part of
bnf productions (semantic only)
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)?
| string
| chandle
| void
function_declaration ::=
function [ lifetime automatic ] function_body_declaration
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.
named_function_proto::= [ signing ] function_data_type function_identifier ( list_of_function_proto_formals
)
Editor’s Note: Since [
signing ] was removed from function_data_type,
we can’t have a signed prototype?
task_declaration ::= task
[lifetime automatic] task_body_declaration
tf_ref_declaration ::=
[const] ref tf_data_type
list_of_tf_variable_identifiers
tf_data_type ::=
data_type
| chandle
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
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
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 : $
net_alias ::= alias expression net_lvalue = expression net_lvalue;
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])
variable_assignment ::=
operator_assignment
| inc_or_dec_expression
final_construct ::= final
function_statement
action_block ::= [ statement ] [ else statement ] ; statement _or_null | [ statement ] else statement
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
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 ) ;
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
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.
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
time_literal7 ::=
unsigned_number time_unit
| fixed_point_number
time_unit
time_unit ::= s | ms |
us | ns | ps | fs
implicit_class_handle10 ::= [ this. ] | [ super. ]
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.
real_identifier ::= identifier
Editor’s Note: This isn’t referenced by
any other production. Remove? Add reference somewhere?
state_identifier ::= identifier
Editor’s Note: Looks like this is left
over from state machine syntax that didn’t make it into 3.0
Editor’s Note: This isn’t referenced by
any other production. Remove? Add reference somewhere?
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