RE: [sv-bc] Named blocks conflicts with existing identifiers

$dumpvars is an interesting example, because the task arguments can be
both scope names and "variable" names.

(I use the term "variable" in quotes because it is not precise, not
intended to exclude nets, for example. But "variable" is the term used
in 1364-2005 Clause 18. I'll file a Mantis on that if there is not one
already.)

(And another extension to $dumpvars would be allow unpacked arrays.
Again, I'll file a Mantis if there is not one already.)

Shalom

>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>Behalf Of Gordon Vreugdenhil
>Sent: Monday, December 12, 2005 8:52 PM
>To: Brad Pierce
>Cc: sv-bc@eda.org
>Subject: Re: [sv-bc] Named blocks conflicts with existing
>identifiers
>
>Yes - I think that when one can name scopes, the scopes are
>treated as implicit hierarchical names in the sense that
>they follow the upward resolution rules defined for
>hierarchical
>names.  Similar issues exist for system routines such as
>$dumpvars
>that can name scopes.
>
>Narrowly speaking the grammar now in fact allows simple
>identifiers to be "hierarchical_..._identifiers".  This
>is likely confusing as it implies that all simple names follow
>hierarchical (upwards) resolution rules which is not the
>case.
>
>Gord.
>
>Brad Pierce wrote:
>
>> Named blocks and generate blocks are also searched for in the
>> instantiation hierarchy.  It's not just tasks and functions.
>>
>> "The description in 19.3 is also (mostly) incorrect in that
>> it claims that the instance hierarchy is searched.  This is
>> not true for simple identifiers; for historical reasons
>> task and function calls work in this manner, but other simple
>> identifier references do not;"
>>
>> -- Brad
>>
>>
>>
>>
>
>--
>---------------------------------------------------------------
>-----
>Gordon Vreugdenhil                                503-685-0808
>Model Technology (Mentor Graphics)
>gordonv@model.com