Brad Pierce wrote: > Gord, > > What's an example of the upwards reference problem you're thinking of > regarding interface-type ports? Do you mean when the reference to the > interface-type port is itself an XMR, because then the value on the > interface-type port (that is, some fully-qualified name of a structural > instance) could not just be substituted in for the port name? No, I didn't mean an xmr to the port, I meant an xmr through the port. module m (some_intf i); initial i.a.b = 7; endmdoule Normally, the resolution of "i" is either upwards itself, or if this is a "topological" name (entering phase 2 in my description) then i is a local scope or instance. If "a" then does not resolve, the resolution of "a" comes back through this instance on an upwards path. This implies that the following; module m; generate if (1) begin : i end if (1) begin : a reg b; initial i.a.b = 7; end endgenerate endmodule resolves. The "i" resolves to "m.i"; the "a" is then an upwards resolution to m.a and "b" resolves to m.a.b. Not intuitively obvious, but that is Verilog. Now, given the interface example, what is the upwards path for "a" is "a" does not exist inside interface "i"? Normally, one would expect the upwards reference to come back through "m" so that the following: module m (some_intf i); initial i.a.b = 7; generate if (1) begin : a reg b; end endgenerate endmdoule would resolve to m.a.b in the same manner as the generate version without the interface. But is that "correct"? Should "a" instead be resolved in an upwards manner from the *instantiation point* of whatever the real interface is (breaking the normal rule that you come back through "m")? Or should it be illegal (becoming inconsistent with the non-interface example)? Or should it come back through "m" (which is weird since "i" is NOT an instantiation here and we normally only go "up" through instantiations)? Just "composing" that path yields an answer but it isn't at all clear to me that such an answer is either correct, expected, or reasonable. Gord > > -- Brad > > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Monday, June 05, 2006 6:46 AM > To: Brad Pierce > Cc: sv-bc@verilog.org; sv-ec@verilog.org > Subject: 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.comReceived on Mon Jun 5 08:48:52 2006
This archive was generated by hypermail 2.1.8 : Mon Jun 05 2006 - 08:48:57 PDT