RE: [sv-bc] Separate Compilation Meeting Monday 6/9/03


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