RE: [sv-ac] ballot result for 1682

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Tue Dec 18 2007 - 10:07:51 PST
Hi all,

I will upload the new version shortly. Please, wait until it is ready.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of John Havlicek
Sent: Tuesday, December 18, 2007 5:02 PM
To: sv-ac@server.eda.org
Subject: [sv-ac] ballot result for 1682

------------------------------------------------------------------------
----------
Ballot on Mantis 1682

- Called on 2007-12-13, final ballots due by 2007-12-17 T 23:59-08:00.

yv[xxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
yv[xx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny
(Synopsys)     
 n[-------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani
(Synopsys)
yv[xxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais
(Freescale)
 t[x--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek
(Freescale - Chair)
yv[xxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny
(Intel - Co-Chair)
nv[xx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha
(Mentor Graphics)
 n[---------------------------xxxxx-------x-xx-x-] Jiang Long (Mentor
Graphics)
 n[------x------------x--xxx.....................] Joseph Lu (Altera)
 v[xxxxxxxxxxxxxxxx..............................] Johan Martensson
(Jasper)
 n[------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller
(Freescale)
yv[xx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
yv[xxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
 n[----x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor
Graphics)
yv[xxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara
(Synopsys)
yv[xxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun
Microsystems)
   |--------------------------------------------- attendance on
2007-12-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 a valid voter
                t = chair eligible to vote only to make or break a tie


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

I have some questions about the changes related to the part where
$assertkill part is defined. The paragraphs say:

Even though global clocking future sampled value functions depend on
future values of their arguments, the
interval of simulation timesteps for an evaluation attempt of an
assertion containing global clocking future
sampled value functions is defined as though the future sampled values
were known in advance. The end of the
evaluation attempt is defined to be the last tick of the assertion clock
and is not delayed any additional
timesteps up to the next global clocking tick.
The behavior of disable iff and other asynchronous assertion related
controls such as $assertkill (see
19.10) is with respect to the interval of the evaluation attempt defined
above. If, for example, $assertkill is
executed in a timestep strictly after the last tick of the assertion
clock for the evaluation attempt, then it shall
not affect that attempt, even if $assertkill is executed no later than
the next global clocking tick.

Now here is an example:

@(posedge clk) $rising_gclk(a) |=3D> b;

Suppose clk happens at time 10, 30, 50 etc and the global clock happens
at 12. The $assertkill is issued at time 11. So, for the attempt which
starts at time 10, we can not do anything about $assertkill till we
reach time 12, at that point it will be decided if $rising_gclk(a) is
true or false. If it is false that means the assertion attempt ended at
time 10 itself and $assertkill will not have effect. But if
$rising_gclk(a) is true, the assertion will get evaluated further so
$assertkill will have an effect. So, we'll execute $assertkill at time
12 ??? What about the callbacks etc. associated with $assertkill ??


Based on our discussion in the meeting, I was under the impression that
since we decided to execute action block at the following global tick,
we'll keep the similar behavior for disable iff and other asynchronous
effects. May be I missed part of the discussion.

------------------------------------------------------------------------
----------
Friendly Amendments

[YF]

I vote yes with the friendly amendment that on the 2'nd page of  the
FormalFuture_071022_dk.pdf document 1b1 would be changed to 1'b1 in:
" Note. that $past_gclk(e) is equivalent to $past(e,1,1b1,1b1)."

[DB]

I vote yes with a friendly amendment

- F.4.1  replace

This subclause describes the semantics of several constructs that are
used=20
at a point in a word can depend both on the letter at that point and on
previous letters in the word.=20

With

This subclause describes the semantics of several constructs that are
used=20
at a point in a word may depend both on the letter at that point and on
other letters in the word.

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

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Dec 18 10:10:37 2007

This archive was generated by hypermail 2.1.8 : Tue Dec 18 2007 - 10:10:47 PST