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

Hi, Stu & All -

I like your proposed solution. I just thought I was missing something in
the LRM but it looks like I have tripped over the same thing you tripped
over last January.

If we leave packages the way they are currently defined, we are going to
hear about it from the VHDL guys! :-)

Regards - Cliff

At 08:59 PM 8/15/2004, Stuart Sutherland wrote:
>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
>
>-----------------------
>
>

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training
Received on Sun Aug 15 21:20:02 2004