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.com