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

Mark Hartoog wrote:
> 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.


Absolutely this is bad.  In fact, I would consider such behavior
a bug.  Since Questa/ModelSim used to do exactly that in systf
cases, I know that we considered it a bug because we've fixed that
and no longer resolve to non-scopes in the upwards hierarchical
resolution algorithm.

I also know that Questa/ModelSim uses a slightly different algorithm
for name resolution than XL/NC.  There are a few very odd edge cases
in which one could distinguish the difference but we've never run
into a user case that exhibited the difference.  If and when all
of the resolution issues settle down, we are committed to moving
into compliance.  I also know that Questa/ModelSim is not exactly
compliant with the rules I have been suggesting -- there are pure
"ease of implementation" artifacts that I am hoping will eventually
be resolved at the committee level so that we can make one round
of changes to become compliant.  If no consensus is reached, I
don't know if we'll bother changing since we can easily argue
that we're compliant to the current rules now (since there is so
much question about the interpretation, probably everyone is
compliant).

These are exactly the kinds of issue that has caused me to push for
a set of *rules* rather than examples.  If we don't have pretty
clear rules, implementations will diverge.  Once they diverge,
one side might implement something for "compatibility" only to
discover later that the other vendor considered the behavior
in question to be a bug and has fixed the bug.  So incompatible
behavior takes still longer to iron out, users are confused and
angered by the shifting interpretations, and everyone spends way
too much energy dealing with changes.


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

Absolutely.

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

No, that is not at all what I want.

What I want and have been pushing for in a variety of ways is to
say that the first identifier must be sufficient to determine whether
a name is in fact hierarchical or whether it denotes a select.  You
commit to selects as early as possible and resolve hierarchically
as late as possible.  Users can always force resolution in the
hierarchical direction (effectively creating "forward" references)
by using the design unit name prefix form.


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

That is exactly what I have been trying to say.

I haven't heard anyone else propose any rules for this key problem.

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.