Subject: Reasons for extern modules
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Dec 05 2002 - 10:31:30 PST
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.
This archive was generated by hypermail 2b28 : Thu Dec 05 2002 - 10:33:46 PST