Subject: RE: [sv-bc] Separate Compilation Meeting Monday 6/9/03
From: Kevin Cameron (sv-xx@grfx.com)
Date: Thu Jun 19 2003 - 10:42:16 PDT
> 
> Adam,
> 
> The import statement is outside the module so it can be used in the
> Ansi-style ports. Imagine a module
> 
> 	module types:
> 
> 		typedef T ....
> 	endmodule
> 
> 	import types;
> 	module foo (input T t);
> 	endmodule
> 
> Jay
Any reason you couldn't do:
  module foo
    import types;
    (input T t);
    ...
  endmodule
?
The fact that a reg or wire is a port doesn't have to be declared
first, you could add syntax to allow port declarations anywhere in
a module, or you could just imply it from the use of input, output
and inout. E.g.:
  module foo;
    import types;
    
    input T t; // input => port
    ...
  endmodule
That would work with (complex) types declared local to the module
too.
Kev.
> > -----Original Message-----
> > From: Adam Krolnik [mailto:krolnik@lsil.com] 
> > Sent: Thursday, June 19, 2003 11:01 AM
> > To: Randy Misustin
> > Cc: sv-bc@eda.org
> > Subject: Re: [sv-bc] Separate Compilation Meeting Monday 6/9/03
> > 
> 
> > 
> > You write that you expected import statements to only affect 
> > the next module. If
> > this is so, then why not place the import statements inside 
> > the modules like software
> > languages do. Clearly this simplifies the import requirements 
> > because the statement
> > is already in the proper scope. Having the statement outside 
> > a module would only
> > have value when it would apply to all modules of a given file.
> > 
> > For example, without namespaces, etc. we use an include file 
> > to contain standard
> > functions that designers use. For each module they want, they 
> > include the file
> > 
> > module foo (...);
> > 
> > `include "stdfunc.vh";
> > 
> > ...
> > 
> > endmodule
> > 
> > I guess the real power of this proposal is:
> > 
> > 1. The 'import' statement giving the user control over what 
> > names are brought
> >     into their module.
> > 
> > 2. The ability to import a signal from another module and 
> > give it a local name.
> >     (like an alias as you mentioned.)
> > 
> > Anything other new abilities?
> > 
> > If we are proposing to allow people to specify which names 
> > come into their module,
> > should we allow a user to rename the element soas to not 
> > conflict with something else
> > they may have? I.e. consider what would happen if one needed 
> > to import functionality
> > from 2 sources and there is a name conflict. To use a Perl form:
> > 
> > use MyPkg1 {send_trans    => pkg1_send_trans,
> >              receive_trans => pkg1_receive_trans};
> > 
> > use MyPkg2 {send_trans    => pkg2_send_trans,
> >              receive_trans => pkg2_receive_trans};
> > 
> > 
> > 
> >       Adam Krolnik
> >       Verification Mgr.
> >       LSI Logic Corp.
> >       Plano TX. 75074
> > 
> > 
> > 
> > 
> 
This archive was generated by hypermail 2b28 : Thu Jun 19 2003 - 10:44:01 PDT