Subject: RE: [sv-bc] proposal for nested modules and interfaces
From: Jonathan Bromley (jonathan.bromley@doulos.com)
Date: Tue Jan 06 2004 - 03:37:45 PST
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: 05 January 2004 19:19
> To: sv-xx@grfx.com; sv-bc@eda.org; Jonathan Bromley
> Subject: RE: [sv-bc] proposal for nested modules and interfaces
> >If you are writing the nested module to encapsulate some
> >piece of local functionality, and you need that functionality
> >only once, it seems pretty silly to have to instantiate it
> >immediately after defining it.
>
> And having a module instance appear when you didn't intentionally
> instantiate one is pretty surprising. Surprising is much worse
> than silly.
I'm not sure; it's just a choice of definition. Nested modules
are clearly visible in the scope within which they are nested;
I don't see the "surprise". People have long been in the habit
of creating uninstantiated top-level modules as containers
for project-wide functions, parameters and so forth; such modules
are implicitly instantiated at the top level, and we don't think
of it as a "surprise".
> The most likely reason to create a nested module is to re-use it
> in multiple instantiations, not to encapsulate a single instance.
I'm not entirely convinced about this. Portless nested modules
provide a convenient way to explore choices about the partitioning
of functionality in a big module.
> If somebody wants to encapsulate one instance of some local
> functionality, they can already encapsulate the code inside a
> named generate block, with no need for a nested module.
This is true. I confess I hadn't thought of it in this way,
and I find it a convincing reason for NOT implicitly instantiating
nested modules. Thanks.
> And speaking of generates, your idea of when these implicit
> instantiations occurs needs some work. Consider a nested
> module that gets instantiated inside a generate-loop. For
> some parameter values it might get instantiated multiple times,
> for others just once. And in some end cases for some parameter
> values, it might get instantiated zero times because none are
> needed. Are you suggesting that it should then get implicitly
> instantiated once? And that there is no way to make it get
> instantiated zero times, even though that is what you really want
> in that case?
I find it hard to envisage a reason to generate multiple
instances of a PORTLESS local module. However, your point is
important and it raises an issue about the proposed
definition...
A nested module that is not explicitly instantiated
If the "failed" instantiation, in the generate that doesn't
happen, counts as "explicitly instantiated" for the purpose
of this rule, then your problem is fixed, no?
> Uninstantiated modules WITH ports are also top-level, so what
> you are proposing does NOT match existing behavior. And with
> Verilog-2001 configs, there is now a way to explicitly specify
> what modules get instantiated as top-level modules, instead of
> relying on this older implicit mechanism.
Whoops, mea culpa. You're right, of course.
-- Jonathan Bromley, ConsultantDoulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
This archive was generated by hypermail 2b28 : Tue Jan 06 2004 - 03:39:21 PST