RE: [sv-bc] Gord's name resolution quiz

From: Mark Hartoog <Mark.Hartoog_at_.....>
Date: Sun Jun 03 2007 - 19:58:40 PDT
When I get time in the next few days I will send what I think
are the best answers for this quiz, but I think these question
do not really address the corner cases.

Consider the case below. How do these 8 resolve or not resolve 
in both the instances u0 and u1:

typedef struct {
  int x;
  int y;
} ST;

class A;
  function void f1();
  endfunction
  function void f2();
  endfunction
endclass

ST a1;
A a2;

module child;
parameter P = 1;

initial
begin 
  a1.x = 0;  // (1)
  a2.f1();   // (2)
  a3.x = 0;  // (3)
  a4.f1();   // (4)
end

generate
if (P == 0) begin : a1
   int x;
   int y;
end : a1 
if (P == 0) begin : a2
   function void f1();
   endfunction
   function void f2();
   endfunction
end : a2
if (P == 0) begin : a3
   int x;
   int y;
end : a3 
if (P == 0) begin : a4
   function void f1();
   endfunction
   function void f2();
   endfunction
end : a4
endgenerate

initial 
begin
  a1.y = 0;  // (5)
  a2.f2();   // (6)
  a3.y = 0;  // (7)
  a4.f2();   // (8)
end
endmodule

ST a3;
A a4;

module top();
  child #(.P(0)) u0();
  child #(.P(1)) u1();
endmodule


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Gordon Vreugdenhil
> Sent: Sunday, June 03, 2007 5:01 PM
> To: SV_BC List
> Subject: [sv-bc] Gord's name resolution quiz
> 
> 
> Gord's Name Resolution Quiz
> 
> 
> There are 3 sections -- each section has an example with one 
> part of the example having numbered lines.  For each line, 
> say "resolves" if there is only one candidate, "resolves to 
> ...." if there is more than one,  or "doesn't resolve".  
> Provide a very short rule guiding your answer.
> 
> I've given my answers at the bottom; feel free to only 
> respond to those with which you disagree either on answer or 
> rationale.  Please *DO* actually respond since I would really 
> like to use this to see how close we are to being able to 
> actually formulate some real rules.
> 
> BTW, I do NOT think that resolving the issues that these 
> examples raise will give us closure on all the issues, but it 
> might help to focus on some key requirements about lexical 
> versus hierarchical resolution and when each applies.
> 
> 
> 
> ---------------------
> Part 1 - Module/$unit
> ---------------------
> 
> task a1;
>    int x;
> endtask
> 
> struct { int x; } a2;
> 
> class A3;
>    int x;
> endclass
> A3 a3;
> 
> int b1, b3;
> 
> module top;
>     int y;
>     initial begin
>        y = a1.x;     // (1)
>        y = a2.x;     // (2)
>        y = a3.x;     // (3)
>        y = a4.x;     // (4)
>        y = a5.x;     // (5)
>        y = a6.x;     // (6)
>        y = b1;       // (7)
>        y = b2;       // (8)
>        y = b3;       // (9)
>        t;            // (10)
>     end
>     int b3;
> endmodule
> 
> task a4;
>    int x;
> endtask
> 
> struct { int x; } a5;
> 
> A3 a6;
> 
> int b2;
> 
> task t;
> endtask
> 
> 
> ------------------------
> Part 2 - Module/generate
> ------------------------
> 
> module top;
> 
> task a1;
>    int x;
> endtask
> 
> struct { int x; } a2;
> 
> int b1,b3;
> 
> for (genvar g = 0; g < 5; g++) begin : b
>     int y;
>     initial begin
>        y = a1.x;     // (1)
>        y = a2.x;     // (2)    // be careful here!
>        y = a4.x;     // (3)
>        y = a5.x;     // (4)
>        y = b1;       // (5)
>        y = b2;       // (6)
>        y = b3;       // (7)
>     end
>     int b3;
>     struct { int x; } a2;
> end
> 
> task a4;
>    int x;
> endtask
> 
> struct { int x; } a5;
> 
> int b2;
> 
> endmodule
> 
> -----------------------------
> Part 3 - Module/nested module
> -----------------------------
> 
> module top;
> 
> task a1;
>    int x;
> endtask
> 
> struct { int x; } a2;
> 
> int b1, b3;
> 
> module nest;
>     int y;
>     initial begin
>        y = a1.x;     // (1)
>        y = a2.x;     // (2)   // be careful here!
>        y = a4.x;     // (3)
>        y = a5.x;     // (4)
>        y = b1;       // (5)
>        y = b2;       // (6)
>        y = b3;       // (7)
>     end
>     int b3;
>     task a2;
>       int x;
>     endtask
> endmodule
> 
> task a4;
>    int x;
> endtask
> 
> struct { int x; } a5;
> 
> int b2;
> 
> endmodule
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------
> Gord's answers (use at your own risk)
> -------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Part 1
> 
> (1)  resolves (upwards hierarchical to scope a1)
> (2)  resolves (struct select into visible non-scope decl)
> (3)  resolves (property select into visible non-scope decl)
> (4)  resolves (upwards hierarchical to scope a4 which exists
>       at elab time)
> (5)  does not resolve ("a5" is not a scope so it is
>       not subject to hierarchical resolution rules
>       and since a5 is not a visible decl at this
>       point, it is not found)
> (6)  does not resolve (same rationale as (5))
> (7)  resolves (visible non-scope decl)
> (8)  does not resolve (b2 is not a visible decl)
> (9)  resolves to $unit::b3 ($unit::b3 is visible at the
>       point of reference which top.b3 is not)
> (10) resolves (t must be a void function or a task so the
>       name is resolved hierarchically.  Since t denotes a
>       task name in $unit (at elab time), it resolves).
> 
> 
> 
> Part 2
> 
> (1) resolves (see part 1 (1))
> (2) resolves to top.a2.x (top.a2.x is visible *as a select* before
>      hierarchical resolution at elaboration time and since it is
>      a viable candidate, it wins)
> (3) resolves (a4 is an upwards scope at elab time)
> (4) does not resolve (see part 1 (5))
> (5) resolves (see part 1 (7))
> (6) does not resolve (see part 1 (8))
> (7) resolves to top.b3 ((top.b3 is visible at the
>       point of reference which top.b.b3 is not)
> 
> 
> 
> Part 3
> 
> (same answers as Part 2)
> 
> 
> --
> --------------------------------------------------------------------
> 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.
Received on Sun Jun 3 19:59:10 2007

This archive was generated by hypermail 2.1.8 : Sun Jun 03 2007 - 20:01:33 PDT