RE: [sv-ac] call for email vote on motion regarding Mantis 1728

Hi Manisha,

I deposited an updated version of the proposal based on your comments
and I am attaching it here for convenience.

See also my answers below.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Kulshrestha, Manisha
Sent: Wednesday, April 04, 2007 1:43 AM
To: sv-ac@server.eda-stds.org
Subject: RE: [sv-ac] call for email vote on motion regarding Mantis 1728

Hi,

I vote 'no' on this proposal. 

Here is the list of issues to be addressed (based on the feedback
Within Mentor):

1) points 9, 14, and 15 are outside the domain of the LRM and
    are not valid for inclusion.  If 9 (debug variables) is
    desirable, this needs to be expressed as named declaration
    with some value, not as a "debug" construct.  Debug
    handling is completely outside the scope of the LRM.

[Korchemny, Dmitry] I agree. Removed these items from the proposal.

2) the "macro" expansion and "hierarchical reference"
    expansion are contradictory.  A hierarchical reference
    "expansion" may bind differently if there is an
    upwards intervening reference.  This entire part of
    the language should be dropped.  The definition of the
    "let" should just say that non-formal idents bind to
    the names in the context of the definition; it is
    not useful (and could be incorrect) to attempt to define
    this in terms of a hierarchical reference.

[Korchemny, Dmitry] Fixed in the proposal.

3) If 'let' is allowed in any procedural context, why is there 
   restriction on the formal types as described in (3)? 

[Korchemny, Dmitry] Yes, it looks like there is no particular reason to
impose this limitation.

4) If a "let" is imported directly by name, eg:
      package p;
         int x;
         let y = x;
      endpackage
      module foo;
         import p::y;
      endmodule
    Does the import of p::y imply that p::x is also imported
    due to the macro expansion?

[Korchemny, Dmitry] p::x does not become imported

  If not, does this mean that
    such a "let" must be treated as a function call?
[Korchemny, Dmitry] Yes, I am citing the proposal: "Import from a
package should follow the same rules as when importing functions from
packages."

If not, how does one resolve the types given that "x" is not
    visible in the referring module?

5) In "Note 2" it says "a let can appear anywhere that an
    expression is allowed".  What is the impact of allowing
    a let in a default of a parameterized class parameter?
    It seems that there are going to be issues getting the
    context and the form correct.

[Korchemny, Dmitry] I don't think there should be an issue here. Let
will be instantiated at this point.

E.g.,

let s = 3 + 2;

class vector #(int size = s);
    bit [size-1:0] a;
endclass

Is evaluated to

class vector #(int size = (3 + 2));
    bit [size-1:0] a;
endclass

Could you provide an example where let instantiation would be
problematic?

6) Under what conditions is a "let" a constant expression?  As
    some as things are "hierarchical", there are issues with
    use in, for example, the RHS of a parameter default.

[Korchemny, Dmitry] When let is instantiated, it is known whether the
resulting expression is constant or not. This question cannot be
answered for the let statement itself. E.g.,

let a(x, y) = x + y;
bit b[3:0];

bit m[a(3, 5)]); // Legal - this is equivalent to m[(3 + 5)], (3 + 5) is
a constant expression

bit m[a(3, b)]); // Illegal - 3 + b is not a constant expression

7) Is a "let" permitted in a class?  If so, is it visible via
    inheritance?

[Korchemny, Dmitry] I don't think it should. Neither sequences nor
properties can be class members. Therefore neither should the let
statement be.

8) Since a "let" can be hierarchically referenced, how does
    one align seperate compilation with a reference to a "let"
    that has not yet been compiled?  If all "let" declarations
    are required to exist, they should be restricted to be in
    either the local design unit or a package since no other
    context can be guaranteed.

[Korchemny, Dmitry] The situation with let is no different than with
sequences and properties.

9) There doesn't appear to be any restriction regarding referencing
    a "let" in a deeper level of generate.  This can be used to
    create contradictory designs:
        module top;
          paramater p = genb.x;
          if (p) begin:genb
             let x = 0;
          end else begin
             let x = 1;
          end
        endmodule

[Korchemny, Dmitry] I agree, this construct should not be valid. I think
that hierarchical referencing of let statements in a deeper level of
generate should be forbidden.

10) Is a let permitted in an automatic context?  If so, how does
     one ensure that the automatic exists at the time of use?

[Korchemny, Dmitry] If I understand your question correctly the answer
is negative. Same situation as with sequences and properties.

11) Does a default of a "let" cause an identifier import even if
     the default is never used?
        package p;
          int x;
        endpackage
        module top;
          let y(z = x) = z;
          int x = y(1);
        endmodule
     This is illegal if "x" is imported since the "int x" declaration
     conflicts.  If "x" is not imported, how does one guarantee
     that a hierarchical reference to "top.y" doesn't require the
     import later?

[Korchemny, Dmitry] Again, there should be the same algorithm as in the
case of sequences or properties.

12) Is the let_identifier in the declaration a true name in the
     scope?

[Korchemny, Dmitry] If I understand your question correctly, the answer
is yes. The names should be unique in the scope. E.g., the following
should be illegal:

let x = a;
int x; // Illegal - name conflict

13) Given:
        module foo;
           let x = 1;
           initial $display(x);
        endmodule
     Does "x" bind to the "let" or is an upwards hierarchical
     reference?  What if you have:
           initial $display(x());

[Korchemny, Dmitry] "x" binds to the "let". In both cases we have
initial $display(1);

14) Why is the point of "let_actual_arg"?  I thought that a
     "let_instance" was always valid as an expression?  Isn't
     this redundant?

[Korchemny, Dmitry] I agree. Fixed in the proposal.

15) How do the "let" grammar rules tie into the rest of the
     grammar?  In particular with expressions?

[Korchemny, Dmitry] Fixed in the proposal.

16) I don't believe that point 8 can be done unless you assume
     that all "let" binding is a compile time activity (which it
     clearly cannot be).

[Korchemny, Dmitry] I deleted it. It is irrelevant to the proposal.

17) Point 11 talks about "let" as a statement.  I thought it was
     an expression.  Can a reference to a "let" ever be anything
     other than an expression??

[Korchemny, Dmitry] let is a statement. let instantiation is an
expression:

let x(y) = y + 1; // let statement
...x(a)...	// let instantiation

It is the same situation as with sequences and properties

18) This proposal does not clearly show the motivation behind the 
    proposal. All the examples are for the usage in concurrent 
    assertions (properties and sequences). Probably some examples 
    of usage in immediate assertions and other procedural contexts 
    will be useful.

[Korchemny, Dmitry] I copied the motivation section with minor changes
from our letter to SV-BC to the proposal.

Thanks.
Manisha


-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of John Havlicek
Sent: Tuesday, March 27, 2007 12:37 PM
To: sv-ac@server.eda-stds.org
Subject: [sv-ac] call for email vote on motion regarding Mantis 1728

All:

This is the call to vote on Ed's motion regarding Mantis 1728.

The text of the motion is below -- I made some very small editorial
changes to the English.

Please vote if you are eligible.  See details below.

J.H.


Ballot on the following motion:

"The P1800 SV-AC committee members consider that the concept of the
'let' statement as expressed in the Mantis item 1728 draft proposal is
very useful for defining effective assertions and assertion libraries.
Therefore, the committee recommends that the SV-BC committee consider
the proposal and work with SV-AC to formulate an effective enhancement
proposal for the IEEE 1800-2008 standard."

- Called on 2007-03-27, final ballots due by 23:59 PDT on 2007-04-03.

 v[xxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Freescale)
 v[xxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)	
 n[--------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
v[-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
t[xxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
v[xxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
v[xxxx----------xx-xxxx] Manisha Kulshrestha (Mentor Graphics)
n[--xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
n[--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
v[xx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)  v[x-x..................]
Erik Seligman (Intel)  n[----xxxx-xx----------] Tej Singh (Mentor
Graphics)  v[xxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
v[xxxxxx...............] Tom Thatcher (Sun Microsystems)
   |--------------------- attendance on 2007-03-27
 |----------------------- voting eligibility for this ballot
|------------------------ email ballots received


	Legend:
		x = attended
		- = missed
		r = represented
		. = not yet a member
		v = valid voter (2 out of last 3)
		n = not valid voter
                t = chair eligible to vote only to make or break a tie

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

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