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

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?

>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