RE: [sv-bc] Resolving name resolution

Verilog 1995 was a much simpler language than System Verilog. There is
no question that features have been added to System Verilog that mean
more of the reasoning about and error checking of a modules can only be
done after elaboration. This really started with generate in Verilog
2001, and System Verilog has just made it worse with type parameters and
many other features.

For example, in Verilog 1995:

module m;
reg r;
assign r = 1;
endmodule

Tools can immediately flag the continuous assignment as illegal, because
'r' is a register type. In Verilog 2005:

module m;
parameter P = 1;

if (P == 1) begin: A
   reg r;
end else begin: A
   wire r;
end

assign A.r = 1;
endmodule

We can no longer immediately flag the continuous assignment as illegal.
It is illegal when the module is instantiated with the default parameter
values, but legal with other values of 'P'.

Now you can claim that 'A.r' is a hierarchical name, but it is a local
hierarchical name. Because it contains a dot we call it a hierarchical
name, and then think it is fine to not resolve it until after
elaboration and possibly give an error message about the illegal
continuous assignment after elaboration.

Now what about:

module #(type T = int) m;
T x;
assign x.r = 1;
endmodule 

This System Verilog module is illegal with default parameter values
also. Should it be an error even when all instantiations in the design
have parameter values that make it legal?

Some of the added power and flexibility of System Verilog comes from the
ability to use features like type parameters, which require error
checking be delayed until after elaboration.

The philosophical question that Gordon raises is a serious question. One
can argue that we have gone overboard and made System Verilog too
flexible and this will make it more difficult to use. My problem with
this argument is that P1800 is already an approved standard. It seems to
me the time to have had the discussion of this philosophical question
was before we approved the P1800 standard. In order to seriously do much
about this issue now, we have to start making backwards incompatible
changes in the language. I think that would be a bad idea at this time.
 

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Gordon Vreugdenhil
>
> 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.
> 
> 

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