RE: [sv-bc] Root cause --- $unit is as broken as could be -- maybe too late to standardize it?

From: Mark Hartoog <Mark.Hartoog_at_.....>
Date: Sun Jun 03 2007 - 20:45:56 PDT
The issue is that for historical reasons hierarchical resolution 
of task and function names includes first looking again for a local 
resolution in the current module. A local resolution is not 
hierarchical, it is a forward reference, but that is the way 
hierarchical resolution was implemented. Backwards compatibility
requires us to not change this.

The question is whether the rules of 19.3 only apply to identifier 
resolution at parse time, or do they apply to the local resolution
of identifiers at elaboration time.

I originally did not like the forward reference to task/functions in
$unit (then $root), but the argument was made that this is what
verilog users expected. They expect to be able to forward reference
task/functions, so why should they be able to do this in every
context, except $unit?

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Sunday, June 03, 2007 3:33 PM
> To: Mark Hartoog
> Cc: stuart@sutherland-hdl.com; sv-bc@eda.org
> Subject: Re: [sv-bc] Root cause --- $unit is as broken as 
> could be -- maybe too late to standardize it?
> 
> Mark, this is extremely incomplete in scope.
> 
> For example, directly applying those "clear" rules requires
> that the following be legal:
>    module top;
>      int y;
>      initial y = x;
>      int x;
>    endmodule
> 
> Clearly "x" exists in "top" so why doesn't this resolve.
> You're not claiming it *should* are you??
> 
> The Section in 12.6 that 19.3 references is dealing
> with upwards names resolution in the context of hierarchical
> names.  The problem is (and always has been) that this
> rule is way too simplistic and doesn't deal with all of the
> real interactions.  It is the interactions between what
> is *permitted* as a hierarchical resolution and what is
> *required* to be a "lexical" resolution that is a key
> problem that has never been addressed and is at the crux
> of all the problems that we're having.
> 
> Hierarchical resolution ignores the "position" of a declaration
> (which is why "forward" refs to functions work - they aren't
> "forward" at all).  Hierarchical resolution in Verilog must
> be conceptualized as occurring at *elaboration* time when
> the "parent" context is already complete.
> 
> Now, if you want to claim that *all* name resolution occurs
> in such a context then you have a massive legacy issue.
> If you don't then appealing to 19.3 is essentially useless.
> 
> I'm going to post a small "quiz" later this afternoon about
> whether various (nearly symmetric) cases should/shouldn't
> resolve.  That might help clarify the issues if not the
> answers.
> 
> Gord.
> -- 
> --------------------------------------------------------------------
> 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 20:46:30 2007

This archive was generated by hypermail 2.1.8 : Sun Jun 03 2007 - 20:47:32 PDT