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

Hi Dmitry,

Thanks for modifying the proposal. Some further comments,

1. The proposal strongly bonds 'let' with 'property' and 'sequence'. If
"let" is restricted to only those contexts in which sequence and
property references are permitted, that is fine. But that is'nt the
restriction and it is not easy for someone not familiar with property
and sequence semantics to extrapolate the rules easily.

2. Quoting your reponse to one of the objections

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

It is valid to refer to sequence and properties in a deeper level of
generate.
So why should it be a restriction for generate. A valid restriction
would be

A reference to a let in a context that requires a constant expression
shall only
be legal if an equivalent reference to a constant function would be
legal.

3) Example 9 says "Import from a package should follow the same rules as
when importing functions from
packages."
This is slightly confusing in the sense that it does not say it is
talking about function import rules and not about calling function from
the package i.e. let is still expanded like a macro and not called like
a function.

Regards
Tej

> -----Original Message-----
> From: owner-sv-ac@server.eda.org 
> [mailto:owner-sv-ac@server.eda.org] On Behalf Of Korchemny, Dmitry
> Sent: Monday, May 07, 2007 11:17 AM
> To: Kulshrestha, Manisha; sv-ac@server.eda-stds.org
> Subject: 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.
> 
> 

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