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

Hi All, 

I did a bit of "research" to find the origins of the text in question
and here are my findings/comments:

- The first paragraph below "No semantic changes ..." pre-dates the 2nd
"When an instance is bound into a target scope ..." so I agree with
Arturo about the original intent of reference to declarations in the
target context. In fact bind is in 3.1 LRM and no packages.

- The 2nd paragraph was added in mantis item 627 as a clarification to
the binding. The type issue was raised then and the ensuing discussion
between Mark/Gord (item has reference to reflector thread) is largely
same as below.

Current interpretation/clarification below by Gord/Mark is in my opinion
on both counts consistent with the original vanilla (no packages, not
much depth to type parameterization) intent. 

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Wednesday, October 24, 2007 11:17 AM
To: Lisa Piper
Cc: SV_EC List; sv-ac@eda.org
Subject: [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.


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