Subject: External Modules/$root
From: Kevin Cameron (dkc@galaxy.nsc.com)
Date: Mon Nov 26 2001 - 12:04:12 PST
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). 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 - 12:24:56 PST