>the LRM says that a single implicit instance of a nested module is created >if no instance is explictly created Only if it has no ports -- http://www.eda.org/sv-bc/minutes/3.1a/sv-bc_04_01_05.html -- Brad A recent Mantis item about nested modules is http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001553 -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Wednesday, October 11, 2006 9:55 PM To: Gordon Vreugdenhil Cc: Brad Pierce; sv-bc@eda.org Subject: Re: [sv-bc] $unit::m or $root.m in module instance? Oh - one issue that just occurred to me that would be particularly nasty here -- the LRM says that a single implicit instance of a nested module is created if no instance is explictly created. So what happens if a configuration changes the an instance to no longer refer to the nested module? Does an instance of nested module have to be created? I suspect the real restriction needs to be based on the existence of an instantiation, not what the instantiation ends up creating after configurations are applied. Gotta love feature interaction.... Gord. Gordon Vreugdenhil wrote: > > Brad, nested modules are explicitly excluded from the global > definitions name space. The problem that I think Paul is concerned > about is if one has: > > module nest; > endmodule > > module top; > module nest; > endmodule > > // how do I create a global "nest" here instead > // of the top.nest version? Do I have to use a configuration? > > endmodule > > > I don't think the current syntax allows any mechanism to specify that. > Similarly, I don't think that just $root or similar is sufficient > since I could easily add another level of nesting and then want to > talk about the "nest" > in my parent scope. > > We likely need to allow general hierarchical names in the syntax and > have a semantic restriction that one can only create instances of > modules in scopes in scopes that are lexically outwards from the > instantiating scope. > > Similar issues in terms of rebinding instances to other modules will > occur in configurations. Imagine if you had some nesting and wanted > to configure a deeper instance to "top.nest"; I don't think the > current syntax would allow that. We could define that configurations > have to find the module declaration based on the nested location of > the instance, but then the reverse problem will still exist (how to > configure a nested instance to the one in the definitions space). > > If we don't deal with this, we'll have to live with much simpler > instantiation relationships. The current syntax effectively enforces > the restrictions and I am not convinced that I really want to extend > all of this, but we need to make an intentional decision. If we do > extend all of this, we need to be pretty careful about how naming and > other relationships are handled. > > Gord > > > > Brad Pierce wrote: > >> Module names are in a global definitions name space, not in some >> particular $unit. But to bind instances to different source >> descriptions, a configuration can be used. >> Should >> topmodule_identifier ::= identifier >> >> be >> >> topmodule_identifier ::= [ $root ] | identifier >> >> ? >> >> -- Brad >> >> >> -----Original Message----- >> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of >> Paul Graham >> Sent: Wednesday, October 11, 2006 6:04 PM >> To: sv-bc@eda.org >> Subject: [sv-bc] $unit::m or $root.m in module instance? >> >> It might be useful, in the presence of nested modules, to specify a >> module name in a module instantiation using $unit or $root: >> >> module top(); >> $unit::m1 u1(); >> $root.m2 u2(); >> endmodule >> >> The lrm says that the module name in a module_instantiation has to be >> an identifier. This rules out using $unit::<id> and $root.<id> as >> module names. I wonder if this restriction is intentional. >> >> Paul >> >> > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Wed Oct 11 22:53:01 2006
This archive was generated by hypermail 2.1.8 : Wed Oct 11 2006 - 22:53:48 PDT