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

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?

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