RE: [sv-ec] RE: [sv-bc] Resolving name resolution

For SV-BCers that aren't also SV-ECers, I think Mark is referring to the
example at end of 17.7 in Draft 3a, which I reproduce here --

In the example below, the randomize()...with class is Foo.

   class Foo;
       rand integer x;
   endclass

   class Bar;
       integer x;
       integer y;

       task doit(Foo f, integer x, integer z);
         int result;
         result = f.randomize() with {x < y + z;};
       endtask
   endclass

In the f.randomize() with constraint block, x is a member of class Foo
and hides the x in class Bar. It also hides the x argument in the doit()
task. y is a member of Bar. z is a local argument.

-- Brad

p.s.  It would be nice to get rid of these "foo" and "bar" references
from the LRM, because together they are pronounced the same as a common
vulgar acronym.


-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Mark
Hartoog
Sent: Tuesday, September 04, 2007 3:22 PM
To: sv-bc; sv-ec@eda.org
Subject: [sv-ec] RE: [sv-bc] Resolving name resolution

Gord and I have had an offline email exchange about name resolution.

What it basically comes down to is Gord find situations like this:

  function void f (int x);
      some_object.randomize with (x < y);

fundamentally different from other situations in Verilog or System
Verilog where names cannot be resolved until elaboration. I find this
situation not really all that different from the system verilog code:

   parameter type T = ....
   T x;
   initial x.y = 1;

where 'y' cannot be resolved until elaboration, or the V2k code:

parameter p = 1;
generate
if (1) begin : A
  if (1) begin : B
     initial $display("%m A.x =", A.x);
     if (p == 1) begin : A
        int x = 1;
     end
  end
  int x = 2;
end
endgenerate

Here 'A.x' cannot be resolved until after elaboration.

I will let Gord defend his position. My position is that these
situations are really not that different. If we had the standard to do
over again, I would probably vote for a different randomize with syntax,
but this is now part of an approved standard and customers are writing
code this way. If this were unimplementable, I think we could justify
making a language change that was not backwards

compatible, but it is not unimplementable. I have not seen any other
proposal to 'fix' this issue which is backwards compatible with P1800. 

Mark Hartoog


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