Re: [sv-bc] $unit::m or $root.m in module instance?

Brad Pierce wrote:

> Gord,
> 
> I'm just saying that $unit:: wouldn't be a way to disambiguate "nest",
> because a module is not defined in some particular $unit scope, even
> though the module, roughly speaking, wildcard imports some particular
> $unit scope.  For example, the global "nest" could be defined on a
> different compilation command line.  Maybe $definitions::nest?


I'd hate to start needing a special name for a name space.

I agree that $unit isn't appropriate and using $root would be
somewhat overloading $root.  Perhaps just "::name".  But the issue
of how to name modules within a deeper nesting structure would
still be there, so if we want to allow the general case, we'll
have to decide on the general form as well.

I guess I'd like some user feedback in terms of how useful the
general cases really are.  Do people really want to be able to
do deep nestings, apply configurations, and/or instantiate
modules declared in different (upwards) scopes?

The current restrictions make non-trivial cases infeasible; if
no one really cares about it, I'd rather leave this as a simpler
model rather than making all the interactions more complex.

Gord.



> 
>>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
> 
> 
> -- Brad
> 
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Wednesday, October 11, 2006 9:45 PM
> To: Brad Pierce
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] $unit::m or $root.m in module instance?
> 
> 
> 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
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com