[sv-ec] Re: [sv-ac] Name resolution for bind -- AC feedback requested

Lisa Piper wrote:
 > I think you may be confusing the bind statement with the module to be
 > bound.

I don't think I'm confusing them, but I may not have been
sufficiently clear in my explanation of the issues.


Let me try again using a couple of examples.


Consider just a bind statement without any context:

    bind target mod #(T'(1)) new_inst(some_actual);

The "T" in this bind statement is a problem.  Just
to parse SV we must know that "T" denotes a type name; this
simple example could be handled but full parsing requires
type knowledge.

Here we can't possibly know whether "T" denotes a type in
the target module.

So that is the "type" problem that Mark and I are concerned
about.



In addition "some_actual" needs to also be resolved in the
target module.  If "some_actual" is only visible by way of
a wild card import in the target module or in the compilation
unit of the target module, must we deal with that resolution?

Here is the kind of "latent error" case we're worried about:

    bind nested_mod child c1(problem);

    package p;
       int problem;
    endpackage

    module top;
       import p::*;
       module nested_mod;
       endmodule

       int problem;
    endmodule

    module child(input int x);
    endmodule


Without the bind statement, p and top compile and simulate.


When we add the bind, if we must process the "child c1(problem)"
instantiation as though it was at the end of nested_mod, an
equivalent textual substitution model would yield:

    module top;
       import p::*;
       module nested_mod;
           child c1(problem);
       endmodule

       int problem;
    endmodule

But this is an illegal design since "problem" in nested_mod
would cause the import of "problem" into "top" and the later
declaration would be illegal.

So a pure "textual" equivalent rule is really not what we
want here.



So back to the LRM text:

      No semantic changes to the assertions are introduced due to
      this feature. It is equivalent to writing properties external
      to a module, using hierarchical path names.

My interpretation (and I think Arturo's interpretation) of this
is that the use of "problem" in the bind statement can only be
valid if a hierarchical name similar to "nested_mod.problem"
would be valid.  In particular, since hierarchical names do NOT
resolve to imported names or names in the compilation unit scope,
such an interpretation would remove any concerns about the problematic
cases and would be a relatively simple clarification of the LRM.

Given this interpretation, you don't really end up with a textual
substitution model.

For the example I gave, I believe that "problem" should resolve
to "top.problem" and there should be no error.  Describing this
is touchy since it is neither exactly the same as
"nested_mod.problem" nor exactly the same as just the textual
substitution of the instantiation defined in the bind.  It is
really something in between.  That is what needs to be clarified.

Gord.

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.