		Search-engine friendly clone of the ACL2 documentation.

Parse-ports

Parse-port-types

Handling of SystemVerilog-2012 port types.

Background

Here are a few key grammar rules within SystemVerilog ports:

net_port_type ::= [ net_type ] data_type_or_implicit
                | identifier
                | 'interconnect' implicit_data_type

variable_port_type ::= var_data_type

var_data_type ::= data_type
                | 'var' data_type_or_implicit

data_type_or_implicit ::= data_type | implicit_data_type

implicit_data_type ::= [ signing ] { packed_dimension }

These are used in two places. The first is in non-ANSI style SystemVerilog port declarations, where we have:

inout_declaration  ::= 'inout' net_port_type      list_of_port_identifiers

input_declaration  ::= 'input' net_port_type      list_of_port_identifiers
                     | 'input' variable_port_type list_of_variable_identifiers

output_declaration ::= 'output' net_port_type      list_of_port_identifiers
                     | 'output' variable_port_type list_of_variable_port_identifiers

ref_declaration    ::= 'ref'    variable_port_type list_of_variable_identifiers

The other is in ANSI-style SystemVerilog port declarations, where we have some trivial wrappers:

net_port_header       ::= [port_direction] net_port_type

variable_port_header  ::= [port_direction] variable_port_type

interface_port_header ::= identifier [ '.' identifier ]
                        | 'interface' [ '.' identifier ]

And then the main port declaration syntax:

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

Parsing Port Types

Determining the type of a port is tricky. Consider the above rules and suppose we're past any port direction stuff. Then,

In the non-ANSI case, we need to be able to recognize whether we have a net_port_type or variable_port_type.
In the ANSI case, we need to recognize whether we have a net_port_type, variable_port_type, or interface_port_header.

In either case, the port type is followed by an identifier (the port name), which may have then be followed by unpacked/variable dimensions. So to handle the trickier ANSI case, we basically want to parse:

my_port_type ::= net_port_type
               | variable_port_type
               | interface_port_type

net_port_type ::= [net_type] data_type
                | [net_type] [signing] {packed_dimension}
                | identifier
                | 'interconnect' [signing] {packed_dimension}

variable_port_type ::= data_type
                     | 'var' data_type
                     | 'var' [signing] {packed_dimension}

interface_port_header ::= identifier [ '.' identifier ]
                        | 'interface' [ '.' identifier ]

Where my_port_type is followed by an identifier and perhaps dimensions. Much of this is easy to handle: it's easy to identify the net_type keywords, the signing keywords, the var and interface keywords.

The tricky case is what to do if we find an identifier. A leading identifier might be:

Port name. This can happen in the net_port_type case, where there is no net_type, signing, or dimensions. In this case, the identifier might be followed by its unpacked dimensions.
Data type name. In the variable_port_type or net_port_type cases, we can have just a plain data type, which could be the name of a user-defined type like foo_t. In this case, the type name could be followed by packed dimensions that are part of the data type, but which come before the port name.
Interface name. In the interface_port_header case, we can have just a plain identifier that names an interface. Such an identifier must be followed by the port name or a period for modports.

Both NCVerilog and VCS appear to require uses of data type names to come earlier in the parse order. However, they allow interface names to be used even before the interface is defined.

Ruling out Interfaces

I believe it is the case that, whenever we see identifier . identifier, we can assume we are in the interface case. This is difficult to be sure of, but I've at least run some experiments on NCV/VCS to try to do things like:

module tricky;
  typedef logic [2:0] foo_t;
endmodule

module m (tricky.foo_t a);
  ...
endmodule

See in particular the ifport* files in the vl/failtest directory. Fortunately, both VCS and NCV appear to reject these sorts of attempts. At any rate, if this is correct, then when we are parsing a port and see identifier . identifier, we can be sure it is an interface.

The other tricky possibility is that we have a port such as foo_t foo. In this case, foo_t might be an interface or a data type. We do basic parsing in vl-parse-port-declaration-head-2012 and then resolve whether we got a datatype or interface after parsing, in port-resolve.

Subtopics

Vl-parsed-portdecl-head: Temporary structure to represent a parsed net_port_type or a var_port_type.
Vl-parse-port-declaration-head-2012: Matches net_port_type or variable_port_type. Assumes that an identifier (i.e., a port name) must follow.
Vl-parse-datatype-only-if-followed-by-id