Re: [sv-bc] Re: [sv-ec] Updated proposal for 'let' syntax

Dmitry,

I have a couple of general comments and then I am going to bow
out of this discussion.

You (and others in AC) appear to have a particular *algorithm*
in mind for elaboration.  Things that fit the macro-like model
for "let" AND fit the particular algorithm are valid while
anythin else is not.  That appears to be driving your comments
on generate, on bind, etc.

Unfortunately, Verilog does *not* define elaboration algorithmically
and any feature that requires such a definition is, as far as
I am concerned, fundamentally flawed.  That is part of why I
claimed that other assertions constructs are flawed -- this isn't
a simple "mantis bug" issue, but rather a fundamental misconception
about how elaboration is defined and the relationships that must
exist.

As one specific example, there is nothing in Verilog that requires
that generate loops be evaluated in order of declaration nor any
requirement that the bodies be elaborated as part of index
evaluation.  One could evaluate just the loop header to determine
the index set and then elaborate the loop body instances in any
order whatsoever -- forwards, backwards, alphabetically, randomly,
whatever.  No approach would violate the fundamental relationships
that exist.

The reason that this works is that there are very carefully designed
restrictions on the *relationships* between parameters, genvars,
constant expressions, and hierarchical references that mean that
you do not *need* to have an algorithmic definition of elaboration.

It is apparent (to me) that the direction that is necessary to meet
your assumptions is to define an algorithm for elaboration.  I am,
and will continue to be, strongly opposed to such an approach.  The
fact that the assertions sublanguage already appears to contain
such assumptions is, in my mind, a fundamental flaw in the assertions
language and not an aspect that I want to allow to pollute the
rest of the LRM.  Had there been sufficient time for review and
redesign of the assertions sublanguage originally, I would have
pushed very hard to ensure that the assertions constructs fit the
rest of the language.  I doubt there would be any willingness to
re-examine those assumptions at this point so the best that I
can do now from my perspective is to limit the damage of those
assumptions.

Since it appears that AC is prepared to limit "let" to the assertions
context, I am willing to bow out since the incorrect assumptions
are then limited to the arena in which the incorrect assumptions
already exist.  If you intend to propose extending such constructs
outside that domain, I will be again raising these same issues.

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.