Re: [sv-bc] Resolving name resolution

Brad Pierce wrote:
> Gord and Mark,
> 
> What are the key differences between your two approaches to name
> resolution?

That isn't easy to answer but I'll take a shot.  Mark can
obviously correct me or provide his interpretation too.

Note that in the following when I use "interfaces" I mean
that in a generic manner unless I say "SV interfaces" in
which case I mean the SV design unit.


The biggest issue is, I think, a philosophical one, but one
that has fairly deep ramifications.

In Verilog, even in the presence of hierarchical names, it was
possible to determine by local inspection whether a name
bound locally or not.  If it didn't the special hierarchical
name rules kicked in.  So a designer always explicitly knew
when they had "topological" or non-local dependencies in
their design.  They could code locally with a high degree
of certainty as to the meaning of simple names and when
names depended on design-wide assumptions.

SystemVerilog muddied the waters along many fronts -- the
overloading of "dotted names" to mean BOTH hierarchical names
and structure/class selection, the introduction of classes
and inheritance, type parameters, package imports, bind,
SV interface ports, compilation units, and implicit dotted
name "methods" on arrays have all contributed to complicate
the name resolution and, in some cases, change traditional
Verilog semantics (array methods are really nasty here).

So, what to do?

Mark's suggestion is to make many more things dynamic.  "When in
doubt, defer to elaboration" would be a gross over-generalization
of Mark's position, but one that I don't think is entirely
unfair.

I don't think that position serves the design community, the
implementors, or the future of the language very well.

It is far easier to reason about modular design composition,
language feature interaction, etc. in the presence of much
more local semantic guarantees.  My approach is to hold
to the designer's original ability to reason locally about
names.  Clearly a designer needs to know about package
interfaces, etc. in order to reason locally, but I really
believe that it is critically important to the future
of SV to keep to as strong a line as possible on that
front.

This is why I am so strongly opposed to the highly dynamic
name resolution effects and late errors that Mark is
proposing.  I don't think we are very far off from being
able to have a much stronger and more compositional model
that preserves one's traditional ability to be able
to reason explicitly about when non-local interactions
are in play.  Sacrificing that carries a very, very high
price that everyone in the community is going to be
paying for a very long time.

So, that is my take (obviously biased!) on the positions.

Then there are a bunch of other differences, some of
which are related, some of which aren't.  A few are:
   1) what names are visible to a "bind"?
   2) are class members/methods visible in a forward
      manner?  Consistency of name interpretation is a big
      issue here and I've raised some of that already.
   3) $unit forward visibility


Most of those are likely resolvable once the philosophical
approach is settled.

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.