Does SystemVerilog grammar support non-ANSI style module header declaration?

[klcheungaj]

it seems that only Verilog grammar supports it

[msagca]

Hi @klcheungaj

I've merged ANSI and non-ANSI style header declarations into one rule because the original syntax was ambiguous. I might have made a mistake while doing so. Can you provide an example that has legal syntax but generates an error?

[klcheungaj]

Hi @msagca In fact, I didn't see an error. I just found it kind of unintuitive as non-ansi port list is matched by the rule ansi_port_declaration. But you are right that the original syntax was ambiguous.

[msagca]

@klcheungaj

The last alternative of ansi_port_declaration covers the explicit port, so I got rid of the second alternative of port.

port ::=
[ port_expression ]
| . port_identifier ( [ port_expression ] )

ansi_port_declaration ::=
[ net_port_header | interface_port_header ] port_identifier { unpacked_dimension } [ = constant_expression ]
| [ variable_port_header ] port_identifier { variable_dimension } [ = constant_expression ]
| [ port_direction ] . port_identifier ( [ expression ] )

[klcheungaj]

how about the first alternative of port. The rule port_expression is defined as follows

port
	: port_implicit?
	;
port_implicit
	: port_expression
	;
port_expression
	: port_identifier constant_bit_select? '[' constant_indexed_range ']'
	| port_identifier const_member_select+ ( '[' constant_part_select_range ']' )?
	| '{' port_reference ( ',' port_reference )* '}'
	;
const_member_select
	: '.' member_identifier constant_bit_select?
	;

let's say I have a Verilog module defined using non-ANSI style

module foo(a,b,c);

endmodule

The rule port_expression is not able to match ports a, b and c. Is this on purpose?

[msagca]

@klcheungaj

Yes, anything that can match any alternative of ansi_port_declaration is omitted in port_expression. I minimized the coverage of the rule port because ANSI style port declaration is more commonly used.

[klcheungaj]

get it, thank you!