RE: [sv-ec] Re: [sv-bc] Slides for name resolution face to face

>-----Original Message-----
>From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
>Sent: Thursday, September 27, 2007 4:46 PM
>To: Maidment, Matthew R
>Cc: Jonathan Bromley; Steven Sharp; Mark.Hartoog@synopsys.com; 
>sv-bc@eda.org; sv-ec@eda.org
>Subject: Re: [sv-ec] Re: [sv-bc] Slides for name resolution 
>face to face
>
>Matt, I would contend that an implementation that did not
>resolve this design is incorrect independent of the
>"try again for structs" that we were discussing at the
>meeting.  The "try again" issue here has nothing to
>do with structs -- all of the non-leaf terms are scopes
>and this should resolve via pure 1364 rules.
>
>
>The question that I have is whether you would want the
>same behavior if you had the following for "foo":
>
>module foo();
>   bar no_longer_top();
>   gord_module top();
>endmodule
>
>module gord_module();
>   struct { int abce; } middle;
>endmodule

I would like the same behavior as with scopes.

>In this case you find "middle.abce"
>where "middle" is a struct.  With my rules
>this case would not resolve.  With yours
>it still would.

Right and in your case the struct is "closer" to the hierarchical
reference, but what if the roles are reversed and mistyped the
hierarchical reference and matched the struct?

>The argument that I'm making is that it
>is more likely to be an error when you have
>an incorrect struct field name.  In such cases,
>continuing the 1364 upwards rules seems like
>an unfortunate choice.

And my argument is-- how do you know my intent if
names really do overlap?

module top();
   struct { integer abcd; } middle;
endmodule

module middle();
logic abcd;
endmodule

module foo();
   bar top();
endmodule

module bar();
leaf middle();
endmodule


module leaf();
bit abce;
initial
  $display("top.middle.abcd=%b",top.middle.abcd);
endmodule

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.