AR - Issues 19-34, 19-65.

“Expand variable_assignment to include inc_or_dec assignment and operator_assignment. Then we can simplify the BNF for these assignments. Dan to send a proposal.”

Motivation:

Currently the BNF does not permit the parsing of for loops using the following in the loop’s step assignments:

Auto increment/decrement assignments e.g.:

for (int i = 0; i <= 255; i++) … // this example is taken from section 8.4 in

// the System Verilog LRM

Assignments using assignment operators e.g.:

for (int i = 0; i <= 255; i += 1) …

Although the SV-EC committee addressed the for loop statement I do not think they addressed this issue. The current BNF causes inconsistency between the BNF and the example in the System-Verilog 3.0 LRM.

The Suggested Change:

The general idea is to add the operator assignment and the auto increment/decrement assignment to the variable_assignment syntactic category. (This is similar to the genvar_assignment syntactic category.)

Under A.6.2

Replace: variable_assignment ::= variable_lvalue = expression <bold =>

With : variable_assignment ::= operator_assignment

| inc_or_dec_expression

This change will enable the parsing of such statements

for ( var++; var > 50; --var) …

for (var +=4; var < 50; var *= 5) …

assign var++; // procedural continuous assignment

force var += 5;

release --var;

This proposal, if accepted should replace the issues listed as SV-BC-19-34 and SV-C-19-65.

AR - Issues 19-48, 19-61, 19-62:

“Is white space allowed between #1 and ms for time_literals? Delayed to get Dave's feedback. Jay found that no space is allowed.

Dan moves that we add two footnotes to the time_literal production to indicate that no white space is allowed between the numbers and the time_unit. He will draft a proposal.”

Motivation :

According the BNF the following statement is ambiguous.

and #1 ps (out,in1,in2);

The word ‘ps’ can be considered to be a time unit. (Specifying the delay of the and gate to be one Pico-second.). The ‘ps’ word can also stand for the name of the gate instance.

Note that section 2.5 in the LRM resolves this ambiguity by specifying:

“Time is written in integer or fixed point format, followed without a space by a time unit (fs ps ns us ms s)”.

The Suggested Change:

Add a footnote in the BNF indicating that the number of time units may not be followed by a white space, before the time unit.

Under A.8.4

Replace : time_literal ::=

unsigned_number time_unit

| fixed_point_number time_unit

With : time_literal⁹ ::= <superscript 9>

unsigned_number time_unit

| fixed_point_number time_unit

Under the “NOTES” section (following A.9.5)

Add : 9) The unsigned_number or fixed_point_number in time_literal shall not

be followed by a white space.

This proposal, if accepted should replace the issues listed as SV-BC-19-48, SV-C-19-61, and SV-BC-19-62.

AR – Issues 19-49, 19-52, 19-55

“Dan will determine the proposal to vote on next time.”

Issues 19-49, 19-52, and 19-55 were filed to the ETF as ETF # 181. The ETF # 181 issue is still in the proposal state.

However Issues 19-52 and 19-55 were also filled as part as ETF # 53. The ETF # 53 issue’s status is ‘vsgpassed’.

ETF # 53 also disables the use of a non-constant index operation is a net_lvalue or a variable_lvalue using a concatenation operator. This illegal indexing is demonstrated :

mynet[index] = 1; // this is illegal

{ mynet[index] } = 1; // this is legal according to the BNF.

ETF # 53 suggested fix (http://www.boyd.com/1364_btf/report/full_pr/53.html)

net_lvalue ::=
hierarchical_net_identifier {'['constant_expression']'} ['['constant_range_expression']']
| '{' net_lvalue { ',' net_lvalue } '}'

variable_lvalue ::=
hierarchical_variable_identifier {'['expression']'} ['['range_expression']']
| '{' variable_lvalue { ',' variable_lvalue } '}'

* Eliminate productions:
net_concatenation
net_concatenation_value
variable_concatenation
variable_concatenation_value

My suggestion is to :

Accept issue 19-49 if the ETF accepts issue ETF # 181.
Accept issues 19-52 and 19-55 by adopting ETF # 53 after making some adjustments to the System-Verilog BNF. This will also reflect the other issues addressed by ETF #53.

The Suggested Change:

Under A.8.5

Replace :

net_lvalue ::=

hierarchical_net_identifier

| hierarchical_net_identifier [ constant_expression ] { [ constant_expression ] }

[ constant_range_expression ]

| hierarchical_net_identifier [ constant_range_expression ]

| hierarchical_net_identifier ( [ constant_expression { , constant_expression } ] )

| net_concatenation

With :

net_lvalue ::=

hierarchical_net_identifier {[constant_expression]} <bold []>

[ [constant_range_expression] ] <internal [] in bold>
| { net_lvalue { , net_lvalue } } <external {} in bold> <bold ,>

This change includes issue SV-BC-19-52 and is part of ETF #53.

Replace :

variable_lvalue_item ::=

hierarchical_variable_identifier

| hierarchical_variable_identifier [ expression ] { [ expression ] }

| hierarchical_variable_identifier [ expression ] { [ expression ] } [ range_expression ]

| hierarchical_variable_identifier [ range_expression ]

| variable_concatenation

With :

variable_lvalue_item ::=
hierarchical_variable_identifier {[expression]} <bold []>

[ [range_expression] ] <internal [] in bold>
| { variable_lvalue { , variable_lvalue } } <external {} in bold> <bold ,>

This change includes issue SV-BC-19-55 and is part of ETF #53 after some adjustments.

Dan Jacobi

Intel