Re: [sv-ec] Re: [sv-bc] Discussion overview of SV name resolution

Brad Pierce wrote:
> Gord,
> 
> Isn't an interface-type port just a clean way for elaboration to pass in
> the fully-qualified name of a structural instance?
> 
> What's so weird about that?

Interface ports are simpler than what Mark and I were getting at -- once
you deal with virtual interfaces, interfaces want to be types, not
topological constructs.  That is at least a bit weird.

Purely in terms of interface ports, things are still not obvious.
If you have a dotted name into an "instance" the upwards rules (my
Phase 2) normally apply.  However, what do you do with upwards
references in a dotted name once you go through an interface port?
Are they illegal?  Do they go upwards from the point of the
interface instantiation?  Do they go upwards from the point of the
design unit defining the interface  port?  Any answer there seems
to break at least one of the normal rules and is thus also "weird" in
my books.

Gord.


> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
> Behalf Of Gordon Vreugdenhil
> Sent: Friday, June 02, 2006 10:00 AM
> To: Mark Hartoog
> Cc: SV_EC List; SV_BC List
> Subject: [sv-ec] Re: [sv-bc] Discussion overview of SV name resolution
> 
> Mark, I completely agree that interfaces are very weird in the
> language.  There are likely going to be some need clarifications
> (particularly when you consider parameterized, generic, and virtual
> interfaces) that likely need to be preceeded by clarifications
> regarding the status of interfaces.
> 
> There are a few other situations similar to the issue that you
> raise -- for example if I have a method in a class with
> static lifetime formals, is it legal to drill down into the
> method formals by way of an object?  ie:
>     class C;
>        task static t (int x);
>        endtask
>     endclass
> 
>     C c = new;
> 
>     initial c.t.x = 1;   // legal?
> 
> This is another situation that crosses between what is normally
> "topological" (the scope) and what is clearly a select (class
> property/method selection).
> 
> My approach in what I wrote up was to distinguish based on when
> "upwards" resolution in the middle of a name was permitted.
> I don't think that "mid name" upwards references are particularly
> good from a language design perspective so while I took care
> to preserve the existing 1364 semantics, for things like
> interfaces, etc. I tend to think about those as "select like"
> in that I don't want to be able to get back to an "upwards"
> search through the topology.  If you disallow the upwards
> search aspects, then the "Phase 3" part really doesn't need
> to distinguish as much between topology and type.
> 
> Gord.
> 
> Mark Hartoog wrote:
> 
> 
>>This is a good start, but I think we need to extend this to include 
>>interfaces, interface ports and generate constructs within interfaces.
> 
> 
>>Consider:
>>
>>interface intf();
>>generate
>>begin : block
>>logic x;
>>end
>>endgenerate
>>endinterface
>>
>>module m(intf i);
>>initial $display(i.block.x);
>>endmodule
>>
>>Consider 'i.block.x'
>>
>>You say: "It is legal to have a dotted name composed of a hierarchical
> 
> 
>>prefix followed by a dot followed by a selected name.  It is not legal
> 
> 
>>to have a dotted name composed of a selected name followed by a
>>hierarchical 
>>name."
>>
>>What is the 'i.' part of the name? Is it a hierarchical name? You say
> 
> "A
> 
>>hierarchical name is a "topological reference" that is resolved in the
> 
> 
>>context of the structure of the instantiated design." By definition I
> 
> do
> 
>>not think 'i.' is really a hierarchical name.
>>
>>What then is the '.block.' part of the name. That looks like a
>>hierarchical
>>name to me. 
>>
>>I guess the question here is what is an interface? Is it part of the
>>structural 
>>hierarchy or is it a type? We seem to be trying to treat it as both
> 
> part
> 
>>of the 
>>hierarchy and also like a type. That is why we have the problem with
>>virtual 
>>interface declarations in packages and this confusion here.
> 
> 

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