Subject: RE: External Modules/$root
From: Michael McNamara (mac@verisity.com)
Date: Mon Nov 26 2001 - 13:10:43 PST
Kevin Cameron writes:
>
> I would like to say I agree with Stefan on the potential for spagheti code
> if $root is introduced without some namespace management features.
>
> I think adding forward-declaration mechanisms like those that C & C++
> have will help by allowing [System]Verilog to support a modular compile
> model. Users would have an incentive to split their code as it would
> shorten compile times. To reinforce that I would propose that tasks,
> functions and modules etc. in $root are accessible only as $root.<object>
> unless they have been forward-declared, in which case the can be
> called directly.
>
> 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.
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.
> 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:09:09 PST