Subject: Re: Reasons for extern modules
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Dec 06 2002 - 17:13:12 PST
> From stuart@sutherland-hdl.com Fri Dec 6 14:16:07 2002
>
> Kevin,
>
> I'm in favor of extern module definitions, but have a couple of
> questions. Let's say I put several extern definitions in a single file,
> for convenience, and then wanted to compile a design that included that
> file, but also included the full definition of one or more modules that
> also had extern definitions. Is it reasonable to specify that if a
> compiler/elaborator encounters the same module definition as the extern
> definition, ignore the extern? Would this be a quiet ignore, or cause a
> warning?
Good point. I'd say the extern should be ignored, but I'm not sure how
much we want to check that two definitions match (as C/C++ would) - I'd
guess it's probably not worth doing the checks considering how dependent
SV is on elaboration behavior, maybe leave it up to the vendors to
generate useful warnings.
> Also, can this concept of extern declarations be extended to interfaces
> and primitives? What about tasks, functions or variables that are defined
> somewhere else (e.g. globally, or in an interface, or in some other
> module)? The same concern about analyzing a module in isolation is
> affected by these types of external declarations, as well.
>
> Stu
extern tasks/functions are part of the foreign language interface proposal
the CC is currently working on.
I suppose we could do the same for interface too (it behaves much like
a module).
External primitives are not really distinguishable from modules, I don't
think you'ld need a seperate syntax - i.e. a UDP would override an extern
module.
I think the current plan is that the only difference between an extern
declaration and a regular declaration is the "extern" keyword - which
indicates you can't/shouldn't elaborate the module. If you have various
implementations of a module, you could throw all the common stuff
into one extern declaration - which could include variables, tasks and
functions - and use that for (say) a generic library definition.
Regards,
Kev.
> At 10:31 AM 12/5/2002, Kevin Cameron x3251 wrote:
>
> >The original reasons for (my) requesting external module definitions
> >were:
> >
> > a) AMS - If you split a design into analog and digital parts
> > which go to seperate simulators it's useful to define the
> > external interfaces to either part so that the simulators
> > can prepare the boundaries for PLI/VPI access.
> >
> > Some tools currently address this problem by insisting users
> > supply dummy stubs for analog modules and using external
> > configuration, but that creates the potential for major
> > blunders since the stubs are valid Verilog.
> >
> >
> > b) Black-box IP / representation stops. An external declaration
> > allows you to indicate a mid-level part of you design is
> > complete and syntactically correct when leaf modules are not
> > available. Representation stops are an issue with Verilog-AMS
> > because different vendors provide different sets of analog
> > primitive models built into their simulators.
> >
> >New Reasons are:
> >
> > c) (a) & (b) would apply for C/C++ external module/interface
> > implementations too.
> >
> > d) The introduction of ".*" port binding makes it impossible to
> > analyze a module in isolation if it instantiates other modules
> > using that syntax - since there is no concept of private/exported
> > for local signals all signals can be exported.
> >
> >
> >Of these reasons I consider (d) the most important from the language
> >design point-of-view.
> >
> >Note: from an implementation perspective the only difference between
> >an external module and a regular module (definition) is that you don't
> >elaborate external modules.
> >
> >Regards,
> >Kev.
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland Sutherland HDL Inc.
> stuart@sutherland-hdl.com 22805 SW 92nd Place
> phone: 503-692-0898 Tualatin, OR 97062
> www.sutherland-hdl.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 17:13:44 PST