[sv-bc] Gord's name resolution quiz

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Sun Jun 03 2007 - 17:01:05 PDT
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.
Received on Sun Jun 3 17:01:30 2007

This archive was generated by hypermail 2.1.8 : Sun Jun 03 2007 - 17:01:39 PDT