RE: [sv-bc] name resolution of struct members

>
>Subject: RE: [sv-bc] name resolution of struct members
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Sorry for not responding to the name resolution issues
>earlier; I'm somewhat behind on my reflector monitoring.
>
> > Note that the text has other problems as well. It only allows upwards
> > name references for two-part names like a.b, not longer names like
> > a.b.c.
> > It refers to module_instance.item_name, where item_name is a grammar
> > nonterminal that is defined in Syntax 12-8 and apparently allows only
> > simple identifiers. So I wouldn't take a literal reading of the text
> > too seriously.
> >
> > Steven Sharp
> > sharp@cadence.com
>
>
>The SystemVerilog situation is even more strange than what
>has been brought up so far. Consider:
> e.next.next.next.junk
>Now, if "e" is an variable of an enum type in the current
>context, I would want to treat the ".next" portions as
>referring to the "next" method on an enum. However, by
>the time I get to "junk" I know that can't be the case.
>Do I then have to retreat and do normal name resolution?
>
>Ick.
>
>My suggestion is to keep things simpler (and less surprising)
>to the users. Verilog hierarchical name resolution is bad
>enough to explain when considering instance arrays, conditional
>generates and generate loops; I don't think we should make
>things worse.
>
>What I would personally like to see is to have a rule that
>keeps things backwards compatible in the contexts of designs
>that people currently have but to prune searches in other
>contexts.
>
>In particular, I think something along the lines of the
>following would reduce the "surprise" factors, would be
>reasonable to implement, and is reasonably easy to
>explain (my wording not withstanding).
>
> After having resolved a portion of a hierarchical name
> (refered to as the "prefix"), if the next component of the
> hierarchical name (or a possible method call sequence)
> can be interpreted as a valid method name of the prefix
> or as a field name of the prefix, the remainder of the
> hierarchical name (or method call sequence) shall be
> resolved solely with respect to the item targetted by the
> prefix. In other words, matching a structure field
> or a method name commits the name resolution algorithm to
> completing the resolution with respect to the item which
> matched the field or method name. If the remainder of
> name does not resolve within this context, an error
> shall be reported.
>
>I would actually like to see something similar to this for
>1364-ETF in describing rules for index matches for array
>instances and generate loops -- once you get there, you
>stay there; if the index isn't in range, it is an error
>and you don't continue an upwards search. But that's for a
>separate email to 1364-ETF.
>
>Gord.
Received on Thu May 6 05:58:27 2004