Re: [sv-bc] 22.2.2.2 port types

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Wed Apr 16 2008 - 11:08:52 PDT

Bresticker, Shalom wrote:

22.2.2.2 says,
"ANSI style port declarations can be explicitly named, allowing ...
assignment pattern expressions of elements declared in a module,
interface, or program to be specified on the port list."

I probably did not understand you?

  

The second sentence means that '{...} cannot be used to pick 
up the (undefined) type of the external port, or its 
correspondent in the instantiation.
    

Shalom

You're quite right that these statements contradict each other.   But that is what the second sentence means!
Common sense about the ideas behind ANSI-style declaration leads us to think that the whole paragraph you
originally quoted simply doesn't pertain to ANSI-style port declarations - it must be a hold over from
the description of  non-ANSI-style (original Verilog) port_expressions.

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

net_port_header ::= [ port_direction ] net_port_type
variable_port_header ::= [ port_direction ] variable_port_type

net_port_type³² ::=                                     // from A.2.2.1
        [ net_type ] data_type_or_implicit
variable_port_type ::= var_data_type
var_data_type ::= data_type | var data_type_or_implicit

32) When a net_port_type contains a data_type, it shall only be legal to omit the explicit net_type when declaring an
    inout port.

data_type_or_implicit ::=
        data_type
      | [ signing ] { packed_dimension }

Since providing the data type for an ansi_port_declartion is not optional, only "implicit",
the context for the optional expression should always be read as having a data type!
Therefore the "expression" which constructs the port should not be self-determined, and should be
an assignment-like context.  This negates the whole thrust of the second example and its
explanation, which was the  paragraph you originally quoted:

For example:
     module mymod (
        output .P1(r[3:0]),
        output .P2(r[7:4]),
        ref    .Y(x),
        input bit R );
        logic [7:0] r;
        int x;
        ...
     endmodule

The self-determined type of the port expression becomes the type for the port. The port expression shall not
be considered an assignment-like context. The port expression must resolve to a legal expression for type of
module port (see 22.3.3). The port expression is optional because ports can be defined that do not connect to
anything internal to the port.

The BNF  which makes this example legal suggests that P1 and P2 are conventional  "implicitly typed" nets
in which the declared name is a simple scalar net (logic).  But the text and the non-scalar expressions
are clearly meant to override this meaning.  They provide a richer set of source of type information taken from
the self-determined type of the expression.  In this later case, the meaning I translated is meant to contradict
the usual case where the ANSI-style declaration assigns a type to the external port. 

Perhaps this is supposed to resemble PARAMETER declarations, in that they can either have a declared type, or
they are typeless and become whatever you assign to them in an override or default setting.  I really
don't know, since I didn't have a hand in writing it.  The two paragraphs seem to talk about opposite
situations where you have vs lack a known data type for the external port_identifier.  The rhetorical structure
could have made this a lot clearer!

Greg

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Wed Apr 16 11:09:32 2008