[sv-bc] FW: Proposal for SV 3.1a

Cliff,
 
Here's the proposal I made to make it easier to use packages with module
port declarations.
 
Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
503-692-0898
 

  _____

From: David W. Smith [mailto:David.Smith@Synopsys.COM]
Sent: Monday, January 26, 2004 8:43 AM
To: stuart@sutherland-hdl.com
Subject: RE: Proposal for SV 3.1a

HI Stu,

I did route this through some of the Synopsys experts and here are their
replies.

Peter:

The issue Stu raises was extensively discussed in SV-EC. The problem of
port declaration types already has the two solutions mentioned by Stu, and I
do not think that a last-minute change to reduce possible verbosity is
justified.

Dave Rich

The whole point of the separate compilation unit space was to prevent these
global collisions. Also, if you use a file per module compilation unit,
these global collisions will not be a problem.

Stu, I have to agree with both Peter and Dave. The recommended usage, and
the default as specified in Section 18.2 of Draft 3, is that each file is a
separate compilation unit and therefore these collisions do not occur. I
think the mechanisms are more than sufficient to handle the different usage
styles and avoid collision.

Regards

David

-----Original Message-----
From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
Sent: Saturday, January 24, 2004 1:57 AM
To: david.smith@Synopsys.COM
Subject: Proposal for SV 3.1a

David,

I know this is well past any deadlines, but the following problem came out
in an SV training class I was conducting this week. As I was pondering the
problem, a simple solution occurred to me. Can you please make sure the
following proposal gets to the right people for consideration and voting?

Thanks

Stu

-----------------------

Problem statement:

LRM 3.1a draft 2 adds packages to SystemVerilog. In order to use data types
or constants declared within a package in module port declarations, one must
either:

- Import the package into the $unit compilation unit space.

- Use the scope resolution operator for each module port or parameter that
references the package.

Importing packages into the compilation unit space could conflict with other
declarations in that space. In addition, some companies may impose modeling
guidelines prohibiting declarations in the compilation unit space.

Using the scope resolution operator is verbose. If multiple ports reference
types or parameters in a package, using the scope resolution operator can
also become repetitious. Even the following short example shows how using
the scope resolution operator in port lists becomes verbose and repetitive:

  package shared_decls;
    parameter WIDTH = 32;
   
    typedef struct {
      bit [7:0] opcode;
      bit [23:0] addr;
    } instruction_t;
  endpackage
 
  module (input [shared_decls::WIDTH-1:0] data,
          input shared_decls::instruction_t a,
          output [shared_decls::WIDTH-1:0] result
         );
    ...
  endmodule
       
The following proposal provides a simple way to reference package items in
module port declarations. It avoids the use of the compilation unit space,
and eliminates the verbosity and receptiveness of using the scope resolution
operator.

Add new subsection 18.2.2, as follows.

18.2.2 Using packages with module port declarations

Data types and constants declared in packages can be referenced in module
port declarations by importing the package as part of the module
declaration. The syntax is (new text shown in red):

   module_nonansi_header ::= // from Annex A.1.3
        { attribute_instance } module_keyword [ lifetime ] module_identifier
[ import_port_list ]
             [ parameter_port_list ] list_of_ports ;
   module_ansi_header ::=
        { attribute_instance } module_keyword [ lifetime ] module_identifier
[ import_port_list ]
             [ parameter_port_list ] [ list_of_port_declarations ] ;

   import_port_list ::= // from Annex A.1.4 (add as first production in
this section)
        # ( import package_import_item { , package_import_item } )

Declarations that are imported as part of a module declaration are visible
throughout the module. These imported declarations can be used as part of
the module port declarations. For example:

  package shared_decls;
    parameter WIDTH = 32;
   
    typedef struct {
      bit [7:0] opcode;
      bit [23:0] addr;
    } instruction_t;
  endpackage
 
  module #(import shared_decls::*)
          (input [WIDTH-1:0] data,
           input instruction_t a,
           output [WIDTH-1:0] result
          );
    ...
  endmodule

-----------------------

    
Received on Sun Aug 15 21:00:08 2004