Re: [sv-ac] call to vote on 1756

Hi Ed,

With the current implementation, adding a $assertoff simply causes the
assertion not to fire if it is active on the first clock.

With the proposed change, a $assertoff could potentially change the time at
which the assertion fires, causing the simulation to fail.

Tom

Eduard Cerny wrote On 10/22/07 10:49 AM,:
> Hi Tom,
> 
> but this problem exists now too, no?
> ed 
> 
> 
>>-----Original Message-----
>>From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
>>Behalf Of Thomas Thatcher
>>Sent: Monday, October 22, 2007 1:36 PM
>>To: john.havlicek@freescale.com
>>Cc: sv-ac@eda.org
>>Subject: Re: [sv-ac] call to vote on 1756
>>
>>I vote no on 1756.
>>
>>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?
>>
>>Tom
>>
>>John Havlicek wrote On 10/16/07 04:53 PM,:
>>
>>>Hi Folks:
>>>
>>>This is the call to vote on the proposal for Mantis 1756.
>>>
>>>The document on Mantis is
>>>
>>>1756_AssertInInitialAssertoff_on.071015.pdf
>>>
>>>Please vote if you are eligible.  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)
>>> v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny 
>>
>>(Synopsys)     
>>
>>> n[-----------x-xxx---------x-x-xxx-x---x] Surrendra Dudani 
>>
>>(Synopsys)
>>
>>> v[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)
>>> v[xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
>>> v[xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
>>> n[---x--------xxxx-----xxxx-xx----------] Tej Singh 
>>
>>(Mentor Graphics)
>>
>>> v[xxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
>>> v[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
>>
>>-- 
>>------------------
>>Thomas J. Thatcher
>>Sun Microsystems
>>------------------
>>
>>-- 
>>This message has been scanned for viruses and
>>dangerous content by MailScanner, and is
>>believed to be clean.
>>
>>
> 
> 

-- 
------------------
Thomas J. Thatcher
Sun Microsystems
------------------

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