Re: [sv-bc] E-mail Ballot: Respond by 8AM PST, Mon, Dec 10, 2007

>> In the second text change, the revised text would read
>> 
>> "If not found and the current scope is not the module scope, look for
>> the name in the enclosing scope, repeating as necessary until the name
>> is found, or the compilation unit scope is reached."
>> 
>> Notice the "and the current scope is not the module scope".  That would
>> imply that we don't look in the compilation unit scope if the current
>> scope is the module scope.  If it is assumed to apply to each repetition,
>> it would prevent us from ever looking in the compilation unit scope.
>
>
>Well, as is that is true.  With the 1809 rules it does not.  The
>compilation unit searching for task/func names in an upwards
>resolution is explicitly discussed there in terms of how such
>names interact with the basic algorithm.

I am not sure I follow your argument here.  The 1809 rules apply only
to task/function names.  Is your argument that the first component of
any name that could be resolved in the compilation unit scope must be
a task or function, and therefore the 1809 rules would apply?  Then
there is no need to mention the compilation unit scope in the normal
rules at all, since the special 1809 rules would be applied.  Besides,
I don't expect the 1809 rules to apply to a situation where a task/function
name is being used as a scope, only to a task/function call.

Or are you trying to account for the case of an upward search from inside
a task/function declared in the compilation unit, which will never reach
a module scope before reaching the compilation unit?  In any other case,
the mention of the compilation unit scope is a no-op, since the loop will
terminate on the if-condition upon reaching the module scope.  Then this
becomes a very obtuse way to handle that one case.

Or are you making a different argument here.


>> In the final text added to the end of item b), it should not say
>> "design unit scope is reached".  It should say "module scope is reached".
>> I think we have agreed that upward hierarchical searches do not look in
>> the compilation unit scope of parent instances, only in the compilation
>> unit scope of the reference.
>
>"design unit" here covers interfaces, etc. as well as modules.
>
>The "compilation unit" is not a design unit so it is specifically
>excluded by that term.

Oops, sorry.  I saw "unit" and my brain jumped to "compilation unit",
even while I was typing "design unit".  I withdraw this issue.

But doesn't this mean that the previous change also needs to use
"design unit scope" instead of "module scope"?

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.