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

At 07:57 AM 8/16/2004 -0400, VhdlCohen@aol.com wrote:
>All,
>Are we saying that if I compile a design with a package in file
>types_pkg.sv with modules m1.sv and m2.sv as follows then modules m1 and
>m2 would have visibililty into the package?
>tool_compile_commmand types_pkg.sv m1.sv m2.sv

Module m1 and m2 have visibility into the package because of the import
clause you placed before module m1. m1 and m2 can also refer to items
declared inside the package without
the import clause if using the :: scope resolution.

>In m1.sv I can do the following:
>
>import types_pkg :: *; // for module below
>module m1
>...
>endmodule : m1
>
>// Question: if module m3 is in same file as m1 (in m1.sv), does m3 see
>the types_pkg?

I believe so. The import clause is in the compilation unit scope and
applies to m3 as well.

>---
>
>while I am on the subject, is this legal?
> typedef struct {
> bit [7:0] opcode;
> bit [23:0] addr;
> } instruction_t;
>// using typedef from above -- no package!
> module (input instruction_t a,
> output instruction_t result
> );

I believe so, this is a global type which is defined in the compilation unit.

>Thanks,
>Ben Cohen
>---
>In a message dated 8/16/2004 12:18:48 AM Eastern Daylight Time, "Clifford
>E. Cummings" <cliffc@sunburst-design.com> writes:
>
> >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 Mon Aug 16 08:17:05 2004