[sv-ac] ballot result for 1756

Hi Folks:

Our ballot on 1756 failed due to a negative vote.

See the details below.

J.H.

-----------------------------------------------------------------------------------
Ballot on Mantis 1756

- Called on 2007-10-16, final ballots due at 2007-10-23 T 23:59-07:00.

 v[xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
yv[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     
 n[-----------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
yv[xxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
 t[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
 v[xxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
 v[xxxx-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[xxxxxxxx..............................] Johan Martensson (Jasper)
 n[----------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
yv[xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
yv[xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
 n[---x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
yv[xxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
nv[xxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems)
   |------------------------------------- attendance on 2007-10-16
 |--------------------------------------- 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


-----------------------------------------------------------------------------------
Rationale for Negative Vote:

[TT]

I have the same concern that Manisha expressed:  that a simulation could be
broken by a user adding a $assertoff or $assertkill at time 0.

The only reason I see that you might want to check an assertion only on the
first clock edge would be to check reset values in a design.
If the designer puts a concurrent assertion in an initial block to check reset
values, a different engineer could then add a $assertoff at time zero, and now
the assertion fires because it is evaluated long past reset.

Is there some important use model that I am missing?

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