[sv-bc] Re: [sv-ec] Proposed rules for name binding

I still have philosophical objections to Mark's suggested
approach since I think that it further weakens one's
ability to reason locally about design consistency and
will make further language extensions increasingly
difficult due to the much more global name resolution
assumptions.  The discussion regarding extending configs
would pose problems in Mark's approach as would allowing
"bind" to target generate scopes rather than just module
instances.


Below are a few more specific issues to make sure that
the implications of Mark's suggested rules are clear.

I will continue to evaluate Mark's rules as time permits.
There are some additional aspects that I'm not sure
are correct yet but it will take me some time to be
sure.



---------
Example 1
---------

     typedef int T;
     class C;
         T x;
         int T;
     endclass

I believe that this is legal by the current LRM.

Mark, does your rule 6 makes this illegal?  It seems
that the delayed resolution of "T" would make it
find the local non-type member name.  But I don't see any
rule regarding consistency of resolved name use -- this
was the issue that I brought up initially in terms of
permitting forward class member references.  If you
want to make this illegal, that would certainly be an
incompatible change to the LRM.


---------
Example 2
---------

     class C#(int p = p2);
         localparam p2 = 1;
     endclass


Is this legal by your rules?  By your forward reference rules,
I believe that it is.  I don't think it should be.

Similarly, what about:

     class C#(type T = bit[p2:0]);
         localparam T p2 = 1;
     endclass


This is particularly an issue if "p2" is in fact defined in
an enclosing module scope.  One can make this even worse
by having:

     class C#(type T = bit[p2:0]) extends baseT;
     endclass

Now if "p2" happens to be defined in "baseT", do you bind
"p2" to that?


There are even more egregious examples that I assume you
would want to make illegal.  Here is one trivial case:

     class C;
         localparam p1 = p2;
         localparam p2 = p1;
     endclass


Obviously (to me) most of this should be illegal.  So the forward
reference rules in classes certainly need some significant
rework and restrictions.


---------
Example 3
---------

     package pkg;
         localparam width = 1;
     endpackage
...
     module child;
         parameter P = 1;
         parameter the_moon_is_blue = 0;
         import pkg::*;
         if (P == the_moon_is_blue) begin
             class some_special_monitor;
                 int x;
                 function new; x = width; endfunction
             endclass
         end

         localparam width = 5;
...
     endmodule



The implication in this case is that you will get a
symbol conflict in "child" only after elaboration and
only when a very unusual condition holds.  Such latent
problems can hide for a very long time in a design.

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