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

Hi Ed,

As John mentioned in his email, we are voting for 'the concept of the
'let' statement as expressed in the Mantis item 1728 draft proposal'.
So, my understanding is that we need to consider what is written in the
proposal for describing this construct. Even if we do not consider the
general usage of this construct and the things which fall under sv-bc
domain, we need to discuss the issues which impact assertions 2, 3, 15,
16, 17 and 18. 

Thanks.
Manisha

-----Original Message-----
From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
Sent: Wednesday, April 04, 2007 5:31 AM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: [sv-ac] call for email vote on motion regarding Mantis 1728

Hi Manisha,

I believe that the vote was not on the proposal itself, but rather
whether something of that sort with whatever changes the committee(s)
may come up with should be sent to SV-BC for consideration. 

Best regards,
ed


> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of 
> Kulshrestha, Manisha
> Sent: Tuesday, April 03, 2007 6:43 PM
> To: sv-ac@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.
> 
> 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.
> 
> 3) If 'let' is allowed in any procedural context, why is there 
>    restriction on the formal types as described in (3)? 
> 
> 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?  If not, does this mean that
>     such a "let" must be treated as a function call?  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.
> 
> 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.
> 
> 7) Is a "let" permitted in a class?  If so, is it visible via
>     inheritance?
> 
> 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.
> 
> 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
> 
> 10) Is a let permitted in an automatic context?  If so, how does
>      one ensure that the automatic exists at the time of use?
> 
> 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?
> 
> 12) Is the let_identifier in the declaration a true name in the
>      scope?
> 
> 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());
> 
> 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?
> 
> 15) How do the "let" grammar rules tie into the rest of the
>      grammar?  In particular with expressions?
> 
> 
> 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).
> 
> 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??
> 
> 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.
> 
> 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.