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


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.

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.

Gord.




Maidment, Matthew R wrote:
>> -----Original Message-----
>> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
>> Sent: Thursday, September 27, 2007 7:09 AM
>> To: Jonathan Bromley
>> Cc: Steven Sharp; Mark.Hartoog@synopsys.com; sv-bc@eda.org; 
>> sv-ec@eda.org; Maidment, Matthew R
>> Subject: Re: [sv-ec] Re: [sv-bc] Slides for name resolution 
>> face to face
>>
>>
>>
>> Matt, I don't recall whether you ended up reluctantly
>> agreeing to the approach that I was suggesting or whether
>> you still want to champion the "try again" rules.  Can
>> you comment on where you are on this point?
> 
> I'm of the "try again" camp.  Here's an example that is handled
> differently by different implementations:
> 
> module top();
> middle 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
> 
> module other();
> logic abcd;
> endmodule
> 
> and I prefer that top.middle.abcd can be resolved.
> 
> Matt

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