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

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Monday, December 12, 2005 9:22 PM
To: Feldman, Yulik
Cc: sv-bc@eda.org; Goren, Orly; Bresticker, Shalom
Subject: Re: [sv-bc] Named blocks conflicts with existing identifiers

> [Yulik] I'm not sure how you can know whether you may resolve the
given
> identifier directly or you have to defer its resolution. Until you
> resolve it, you don't know whether it is a function/task or other
> "problematic" construct. 

Actually, you do.  Task/function calls are known to be so directly due
to parentheses.  This was in fact an issue in the initial P1800
work where unparenthesized calls were permitted even for functions
with simple names.  Due to the issues I am raising here, it was
recognized that this would intefere with implicit net creation and
the P1800 rules (see 12.4.5) were changed so that a compiler could
make correct assumptions.
[Yulik] OK, I was not aware of this recent amendment. 

 > Also, a non-hierarchical identifier
> ("undotted") may appear to be a cross-hierarchical reference, once you
> resolve it. 

Don't thnk so.  Not unless it is a scope reference (function, task, etc)
which
are all in known contexts.

Can you give a definite example for a simple identifier that doesn't
name a scope/task/function of where you believe that this can happen?

[Yulik] No, I was referring to scope references. Simple identifiers
representing references to variables obviously may not happen to be
cross-hierarchical references, due to variable scope rules limiting
their look-up to the local module. Still, it is not clear to me whether
references to nets also have similar limitation to variables, since
section 12.7 "Scope rules" doesn't refer to them explicitly. It would
make sense that they do have similar restrictions, in which case the
section language is not precise enough and should be fixed. If they
don't have such restrictions (i.e. their look-up doesn't stop at module
boundary), then the example you're asking for would be a reference to a
net in parent module.

To conclude, since functions can be now detected in the parse stage, and
given that you agree on my interpretation of references to nets, I see
that one can distinguish between references that can be bound at parse
stage and those that can't.

So, back to the original question, do you think it makes sense to have
different look-up rules for the two categories of identifiers? I.e. when
binding the simple identifiers at parse stage, to disregard the
declarations that follow them in the scope (since they are not parsed
yet), and while binding the hierarchical identifiers and scope
references after the hierarchy is established, to consider those
declarations (since they are now already parsed and are part of the
scope)? Or, the rules should be the same for the both categories? If
they should be the same, what the rules should be - should they consider
the declarations-after-use or disregard them?

Thanks,
	Yulik.