[sv-ac] ballot on 1728

Hi Folks:

Our ballot on 1728 failed due to negative vote.

See the results below.  I also collected the comments
on the version of the proposal with which we started 
the vote.  There were one or more revisions.

J.H.

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

Ballot on Mantis 1728 

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

yv[xxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
yv[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)
nv[-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)
yv[xxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
yv[xxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
 n[--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
yv[--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
yv[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

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

ES:

   However, I think we have a
   slight mash-up in the preamble that should be fixed:
   
   
   
   package pex_gen9_common_expressions;
   let VALID_ARB(req, vld, arb_override) = (|(req&vld) || arb_override));
   ...
   endpackage
   module my_checker;
   import pex_gen9_common_expressions::*;
   logic a, b;
   wire [1:0] request;
   wire [1:0] valid;
   reg arb_out, ovr;
   ...
   prop: assert property(@(posedge clk)
   request |-> VALID_ARB(request,valid, ovr);
   ...
   endmodule
   
   
   is roughly equivalent to the following directive:
   
   
   `define at_least_two(sig, rst = 1'b0) rst || ($countones(sig) >= 2)
   
   
   
   Those things are not roughly equivalent in any sense!   I think the
   'roughly equivalent' part belongs to the *first* example.    So we
   should fix this to move the 'is rougly equivalent to...' and the
   following code snippet to just after these lines:
   
   // in a package
   
   let at_least_two(sig, rst = 1'b0) = rst || ($countones(sig) >= 2);


LP:

   Comment: normally in a package, don't you have to declare all variables
   that are used, such that in the pex_gen9_common_expressions package
   example shown, technically you should show declarations of req, vld, and
   arb_override (or perhaps just show ... before the let statement). 
   
   Comment: sequence and property types are added by 1549, not 1601. 1601
   is for "untyped" only. Also, 1549 adds the "event" type, which should
   also be excluded along with sequence and property.
   
   Comment: "see Clause 16.x.y" should be "see 16.x.y" (several instances)
   
   Comment: I think bold keywords and example code should be in courier new 9.
   
   Comment: cross-module - I think the terminology "hierarchical
   references" is used elsewhere.
   
   Comment: can a let expression contain the $sampled sampled value
   function(even though it is perhaps redundant). Perhaps it would be
   better to just reference the section so that as more are added we don't
   have to update this.
   
   Comment: in let_list_of_arguments, the ")" should be red


MK:

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


TT:

   Page 9:  The added text, I believe has incorrect coloring.  The square bracket
   in the expression should not be colored red.  Only the = should be red.
   
   let_port_item ::=
   { attribute_instance } let_formal_type identifier [= expression]
   						  ^^ Both colored red.
   
   
   What happens when you have both a
   	let a= ...
   and a
   	reg a = 1'b0;
   ?
   Is there a separate name space for let declarations?

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