RE: [sv-ac] proposal for Mantis 1728

Hi John,

We should distinguish between let statement and let expression: the let
statement corresponds to the notion of a sequence, while let expression
corresponds to a statement expression. Shalom suggested using term
"construct", but it seems to me that the term "statement" better
reflects the essence: we say "if" statement, declaration statement, but
not "if" construct, etc.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of John Havlicek
Sent: Tuesday, August 07, 2007 5:39 PM
To: sv-ac@server.eda-stds.org
Subject: [sv-ac] proposal for Mantis 1728

Hi Folks:

I had an action item to look at the proposal for 1728
and, if appropriate, call for a vote.

I have spent some time with the proposal, and my opinion
is that it's not ready for vote.  I've copied comments
below.

I also think there are some basic questions about 
elaboration raised by Gord that we should discuss.

If others disagree with my opinion about the state
of the proposal, then we can discuss that and consider
proceeding, on motion, with a vote.

J.H.

Notes 2007-08-06
----------------

p. 1.  I don't think it is appropriate to call such a thing a "let
statement".
   We already have a notion of "statement" in the language, and this
construct
   does not fit it.  An instance of a let declaration seems to me to
stand as
   an expression, not as a statement.  I recommend that the phrase "let
statement"
   be replaced throughout by something like "let expression".  Also, I
recommend
   that the phrase "let definition" be replaced by "let declaration"
throughout.

p. 1, LRM-ese:   
   . that can be used in other let statements  --> 
     that may be used in other let statements 
   . may be used for customization and may replace the compiler
directives -->
     can be used for customization and can replace the compiler
directives

p. 2, LRM-ese:
   . the let statement may serve this purpose  -->
     the let statement can serve this purpose 

p. 2.  I recommend
   . the let statement cannot be substituted by a function -->
     the let expression cannot be replaced by a function call

p. 2. I don't think it is a good idea to put a statement like

      The only alternative to let is a compiler directive with the
disadvantages
      as described earlier: ...

   in the LRM.  I recommend omitting this as a proposed addition to the
LRM
   or rewriting the point so that it compares using let to using a
compiler
   directive without claiming that there is no other alternative.

p. 2. 

      A synthesis tool may treat the auxiliary signals such as c as
      real ones and synthesize them into silicon. This may not be
      desirable.

   I am hesitant about referencing synthesis in the LRM in this way.
The
   following comment also applies to this text.

p. 2.  In general, I think that the rationalization or defense of the
existence
   of "let" in this discussion is not appropropriate for the LRM.  If
the proposal
   is passed and approved, then it will be a part of the standard.
Instead, I think
   this section should focus primarily on describing capabilities,
secondarily on 
   comparisons with alternative capabilities, and avoid the editorial
commentary.
   Examples can show advantages of using let without saying that other
mechanisms
   are "awkward", "workarounds", etc.

p. 2.  "are two-bit wide" is an awkward phrase in English;  "are of bit
width two"
   or "are of two-bit width" are preferable.

p. 2.  I recommend changing 

      The let statements can define parameterized expressions that can
      be instantiated in sequences, properties, verification
      statements and other let definitions.  Let cannot be
      instantiated in action blocks of verification statements.

  to 

      A let declaration defines a template expression, parameterized
      by its ports.  A let declaration may be instantiated in
      sequences, properties, verification statements, and other let
      declarations.  A let declaration shall not be instantiated in
      the action block of a verification statement.
   
p. 2.  

      The operand types are restricted the same way as in Boolean
      expressions used in assertions (16.5.1).n

   "operand" of a let is not defined.  Operators have operands, but let
is
   not an operator.  Something else is intended, and the language should
be made
   clearer.

p. 2, LRM-ese:
   . formal arguments can optionally be typed -->
     formal arguments may optionally be typed

p. 2.  

       following the same syntactic form as for arguments to sequences
       and properties (16.7.1)

   The BNF productions are not the same, so I am concerned about the
statement
   that the syntactic form is the same as for arguments to sequences and

   properties.  Does this comparison need to be made?

p. 2.  Check the green on the note to the editor:  I think the
parentheses 
   should be green.

p. 2, LRM-ese:
   . formal argument can have optional default values -->
     formal argument may have optional default values

p. 2.

      Scoping rules are such that referenced identifiers / names in
      the let expression which are not formal arguments bind in the
      declarative scope of the let statement

   I recommend avoiding "identifiers/names" and similar slash
constructs.
   I recommend looking at other places in the LRM where this scoping
concept
   is discussed (22.8?) and emulating the turns of phrase used in them.

pp. 2-3.  Why do globally referenced names in a let declaration have to
   be declared before used?  Similarly, why does a let construct have
   to be declared before being instantiated?  Do these rules apply to
   other declared items, like tasks, functions, sequences, or
   properties?  It will be useful for discussion of this proposal to get

   pointers to other places in the LRM that discuss this kind of
requirement.
   There may be other places in Clause 16 that should be scrutinized. 
   See also Mantis 1852.

   In 6.5, I found

      Data must be declared before they are used, apart from implicit
      nets (see 6.9).

   From the context, I think "data" here refers only to nets and
variables.

   I have not found statements about the relationship of calls to tasks
   or functions and their declarations.

p. 3.

      The let expression is substituted in the place of instantiation
      without any partial evaluation of the expression, the same way
      as sequences do. The substituted expression is enclosed in
      parentheses (...) so as to preserve the priority of evaluation
      of the let expression. Recursive let instantiations are not
      permitted.

   I think this paragraph should say somehow that it is describing the
   meaning or semantics of a let instance.  I don't think the comparison
   to sequences is clear as a normative specification.  I think it will
   be better to write the description of the semantics as an independent
   statement, borrowing or emulating turns of phrase from other parts of
   the LRM.

p. 3, LRM-ese:
   . Let expressions can contain -->
     A let expressions may contain -->

p. 3.

      The let statement identifier must be unique in its namespace.

   Check whether let is covered by the rules in 22.6, which applies to
   an entire SystemVerilog description.  Also see 22.8.

p. 3.  I would remove the comparison to functions in talking about
importing from
   a package.  I recommend changing 

      Like functions, let statements can be imported from a
      package. 

   to

      A let declaration may be imported from a package.

   I don't understand the following:

      Binding of identifiers / names that are not formal arguments
      must be satisfied by the declarations in the package.

   Is this a reiteration of the scoping condition from item 5 above, or
is
   it something new and different?  Again, avoid the slash combinations.


p. 3.  I think the phrase "after substitution of let definitions" is
awkward.
   It will be good to find a better phrase for this, such as
"replacement of
   let instances" and try to make the meaning of this phrase clear in
item 7
   on let semantics.  This phrase should be used consistently throughout
the
   presentation of the examples.

p. 3.  There is a missing ")" in the a1 assertion in two places in
example 1.

p. 3.  I found surprising the appearance of the hierarchical paths, such
as "m.p", 
   in the second version of m in example 1.  Are they needed in this
example?  
   Is the point to avoid any issues with the order of declaration and
reference?

p. 4.  In example 3, the sequence declaration in the second module top
that 
   is commented out is confusing.  Why is this declaration any different
than
   the code in the first module top?  The declaration is misleading
because
   "x" changes to "top.a".

   Also, why is this example showing elaboration of both the let
instance 
   and the sequence instance?  Is this related to Gord's criticism that
this
   proposal, and the assertion Clause, assume an elaboration algorithm
that
   does not exist?

   Semantically, does elaboration of let instances commute with
elaboration
   of sequence and property instances?  Can the elaboration of let
instances
   that appear within sequences or properties be incorporated into the
rewriting 
   algorithm of 1549?

p. 5.  In example 5, second module m, can the outer begin block labels 
   use the constant expressions in square brackets, like "L0[0]"?  From 
   the syntax, I think these have to parse as block_identifier, which 
   must parse as identifier.

p. 5.

      Note that the let statements may not be referred to
      hierarchically using the paths m.L0[0].L1 and m.L0[2].L1.

   I assume that this means "let declarations", not "let statements",
and 
   I wonder why is this so?  I don't recall this being specified before,
so
   this seems like a normative note.  More generally, why should this be
so?

p. 6.

      However, if the function or the variable were referred to
      directly in the code, it would have to be imported explicitly.
   
   I don't understand this.  What code is being referred to?  My
intuition
   is that this example is trying to illustrate a general restriction of
   importation that probably is not necessary.

pp. 6-7.  Similar remarks to previous ones about elaborating.  My
reaction
   is that the example goes beyond the concepts of "let" and is
re-illustrating
   other concepts.  

   In general, my sense is that either the number of examples could be
reduced
   by combining some of the concepts or the complexity of the individual

   examples could be reduced by focussing each one.

p. 13.  Why is "operator_assignment" stricken from the
sequence_match_item 
   production?  What is the technical consequence of this?


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