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

Gordon, part of the issue is that there are differences
between tools in how Verilog-1995 hierarchical name resolution is 
implemented. I know this because I get the bug reports from 
customers claiming that some other tool accepts a design that
we do not or vice versa. It is clear to me that some tools do
hierarchical 
name resolution of non-dotted identifiers that are not task/function
calls under some circumstances. I don't see any support for this
kind of resolution in the LRM, and I think it is a very bad idea,
but I can see how it might happen.

The 1364 LRM is not very clear about how hierarchical names are suppose
to be resolved in the corner cases. Much of our current implementation 
is because of compatibility with other implementations, and I know 
that there are still difference between tools.

I think resolving this issue requires clearing up the question of which
identifiers hierarchical name resolution is applied to and how it is
done.

You seem to want a rule that says at parse time you search for simple 
identifiers in all enclosed scopes, including $unit, but when you do 
hierarchical name resolution to local names you exclude $unit. To get 
consistency between tools you need to specify exactly what identifiers 
get resolved at parse time and which ones get resolved at elaboration 
time in every corner case.


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