[sv-bc] DataTypes: BNF changes

Kathy suggested sending out the proposed LRM changes for datatypes on nets
in sections, to make it easier to discuss in separate email threads.

Here are the proposed changes for the BNF.

Steven Sharp
sharp@cadence.com

Changes to BNF to allow data types on nets:

In Annex A.2.1.3, CHANGE

 "net_declaration ::=
     net_type_or_trireg [drive_strength|charge_strength] [vectored|scalared]
       [signing] {packed_dimensions} [delay3] list_of_net_decl_assignments;"

TO

 "net_declaration ::=
     net_type_or_trireg [drive_strength|charge_strength] [vectored|scalared]
       data_type_or_implicit [delay3] list_of_net_decl_assignments;"

Add this excerpt to the appropriate syntax box in the appropriate section.

Note that this syntactically allows a lot of data types that we won't
necessarily allow for nets. They will be eliminated by a semantic rule
about what types are supported for nets. Such a semantic rule will be
needed anyway, since a typedef is syntactically legal but could represent
a type not supported for nets. Trying to define a separate net_data_type
production for a syntactic restriction would be a lot messier. Brad
Pierce has said he agrees with this general approach. We can't write the
semantic rule until we determine what types will be allowed on nets.

In Syntax 18-4 and Annex A.2.2.1, CHANGE

 "port_type ::= [net_type_or_trireg] [signing] {packed_dimension}"

TO

 "port_type ::= [net_type_or_trireg] [signing] {packed_dimension} |
                 net_type_or_trireg data_type"

Note that this requires explicitly specifying a net_type_or_trireg to get a
net port with a data type. We are also planning to propose the possibility
of inout port declarations defaulting to be nets even without a
net_type_or_trireg in the declaration. The same might apply to input ports
also. The BNF would need further change for this, given the apparent desire
to use different productions for variable and net ports to imply different
semantics.
Received on Wed Nov 3 14:10:23 2004