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

On example 1 and 2:

I only intended class methods to be delayed resolution scopes, not
the whole class declaration. I indicated this near the beginning 
where I defined DRS. I never intended the DRS rules to apply to 
examples 1 or 2.

On example 3, it is true that if you instantiate the module child
with the two parameters having the same value, you will get an
error message. This is the nature of generate. Certain kind of
errors in generate blocks are only recognized when you instantiate
the module with specific parameter values. There are many other 
circumstances where this is true. 
 

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Monday, August 20, 2007 8:46 AM
> To: Mark Hartoog
> Cc: sv-ec@eda.org; sv-bc@eda.org
> Subject: 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.