Subject: Re: External Modules/$root
From: Kevin Cameron (dkc@galaxy.nsc.com)
Date: Mon Nov 26 2001 - 14:36:40 PST
Michael McNamara wrote:
> Kevin Cameron writes:
> >
> > ....
> > The external module mechanism proposed for Verilog-AMS was intended
> > to support vendor-specific simulation models. SystemVerilog is working
> > at a higher level and requires a more general solution which includes tasks
> > and functions. I propose that for tasks and functions a declaration without
> > any statement is viewed as a forward declaration, and similarly a module
> > declaration preceded by 'extern' is viewed as a forward declaration (and
> > may not include statements).
>
> 1) I propose that forward declarations of modules, tasks and fuctions
> 'look the same'. Further I propose that forward declarations of
> modules, functions and tasks all require the prefix of a 'extern'
> keyword.
>
> a) This will make it much easier for the users.
C has 'extern' on routine forward declarations optionally, and I don't see anyone
using it these days - I was just taking that as the precedent.
> b) This will make it much easier for compilers. Consider that a
> function or task has no limit as to the number of arguments that
> they might accept; and hence the compiler might have to read
> ahead hundreds of tokens before it could determine whether it is
> looking at a declaration, or a forward declaration.
The compiler has to read it regardless, I'm not sure it would be "much
easier".
The reason for only putting 'extern' on modules is that an empty module
is legitimate Verilog, while tasks and functions without statements are
not.
Kev.
> > An external module definition may include forward task and function
> > declarations if the user wishes to export them, as well as
> > declarations of internal nodes that are available for hierarchical
> > reference (e.g. transistor model temperature in
> > Verilog-A). Attributes (between the extern & module?) would be used
> > to indicate where the module is implemented if is not part of the
> > compiled source presented to the simulator.
> >
> > Apart from vendor-specific simulation models and supporting modular
> > compilation, external module definitions help facilitate the inclusion of
> > compiled IP and multiple language simulation.
> >
> > [previous mail - http://www.eda.org/vlog-pp/hm/0112.html]
> >
> > Kev.
> >
> >
> >
> >
> >
This archive was generated by hypermail 2b28 : Mon Nov 26 2001 - 14:37:25 PST