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

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
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?
---

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
          );
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
>
>
>
-- 
-- 
-------