RE: [sv-ac] call to vote on 1728

From: Kulshrestha, Manisha <Manisha_Kulshrestha_at_.....>
Date: Mon Sep 17 2007 - 10:50:49 PDT
Hi,

I have some more comments:

1. On page 3, it says "Another intended use of let is in modeling for
assertions to provide shortcuts for identifiers or subexpressions.", I
understand the usage for subexpressions but why would someone use a let
construct for identifier ?

2. On page 3, "A let declaration may be instantiated in expressions of
immediate assertions and match items of sequences, properties,
verification statements, and other let declarations." In this statement,
the ordering of words should be changed as match items apply to
sequences and properties only. 

3. On page 3, it says "The argument types are restricted the same way as
in boolean expressions used in assertions (see 16.5.1)." Why are we
putting same restrictions for let. Since let is going to get used in
immediate asserts also it should not have any restriction on its
declarations. Instead the checking should be done at the time of
instantiation if the usage is correct or not.

4. On page 4, " The let expression gets expanded with the actual
arguments by replacing the formal arguments with the actual arguments."
I think there should be some mention about typed formal arguments as
this is not going to be entirely true in case of typed arguments as type
casting will also be done along with replacement.

5. On page 4, "let expressions may contain sampled value function calls
(see 16.8.3). Their clock, if not explicitly specified, is inferred in
the instantiation context in the same way as if the functions were used
directly in sequences, properties or verification statements." I think
this statement is ignoring the fact that let can be used outside of
concurrent assertions also i.e. in immediate asserts. It should be
mentioned that in case the usage is in immediate asserts, a clock must
be specified (except for $sampled which does not require clock anymore
based on some other proposals).

6. I would like to see an example of a concurrent assertion which uses
typed arguments in the property declaration and also typed arguments to
the let construct used in the property. I think it will be nice to show
to the user that in this case actual will get type casted twice (once
due to property's argument type and once again due to let's argument
type). 

Thanks.
Manisha

-----Original Message-----
From: Kulshrestha, Manisha 
Sent: Monday, September 17, 2007 5:09 PM
To: sv-ac@server.eda-stds.org
Subject: RE: [sv-ac] call to vote on 1728

Hi,

I vote no on the proposal.

I noticed few corrections required in the proposal:

1. On page 3, In the footnote for let_instance (40) it says:
"let_instance may be used only in the expressions which are part of
sequence or property expressions, let declarations or immediate
assertions." Whereas on the same page later it says: "A let declaration
may be instantiated in other let declarations, sequences, properties,
concurrent and immediate assertions."

In the note (40), concurrent assertions are missing. 
On page (4) again it says "A let declaration may be instantiated in
expressions of immediate assertions and match items of sequences,
properties, verification statements, and other let declarations." This
statement is again inconsistent with other such statements. What is the
intended usage in match items ? Will it be used on the right hand side
of assignment or it can also be used in arguments of the subroutine
calls ?

2. The proposal does not say that let instance can be used in expect
statement (expect statement is not included in concurrent assertions).
Is that intended ? I think expect should be included in here.

I am still looking at the proposal and send more feedback if I find any
more issues.

Thanks.
Manisha

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of John Havlicek
Sent: Wednesday, September 12, 2007 11:05 PM
To: sv-ac@server.eda-stds.org
Subject: [sv-ac] call to vote on 1728

Hi Folks:

This is the call to vote on the proposal for Mantis 1728.

The document is 

  LetConstruct1728\ 070911_dk.pdf

on Mantis.

Please vote if you are eligible.  See the details below.

J.H.

------------------------------------------------------------------------
------

Ballot on Mantis 1728 

- Called on 2007-09-12, final ballots due at 2007-09-19 T 23:59-07:00
(PDT).

 v[xxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
 v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     
 n[-------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
 v[-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
 t[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
 v[xxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel -
Co-Chair)
 v[-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor
Graphics)
 n[---------------xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
 n[-------x--xxx.....................] Joseph Lu (Altera)
 v[xxxx..............................] Johan Martensson (Jasper)
 n[------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
 v[xxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
 v[xxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
 n[--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
 v[--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
 v[xxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems)
   |---------------------------------- attendance on 2007-09-11
 |------------------------------------ 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 or 3/4 overall)
		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.
Received on Mon Sep 17 23:21:19 2007

This archive was generated by hypermail 2.1.8 : Mon Sep 17 2007 - 23:21:52 PDT