Hi all, I uploaded the new version of the proposal, it is ready for vote. The changes: * Added references to 16.8.3 from 19.10 and 19.11 (assertion system tasks). * Added a new subsection 38.4.2.1 "Placing callbacks for assertions with global clocking future sampled value functions" where I put the necessary explanations and Manisha's example, slightly modified. The idea is to delay the callback execution until the strictly subsequent tick of the global clock. The reason for doing this is that the callback event may depend on a future value and there is a need to wait until this value becomes known (the callback execution is delayed even if there is enough information at the time of the callback event - such definition is uniform and unambiguous). For some reason in the LRM the references to cb_time and to attemptStartTime are given in italic, and I am keeping using italic for them. Thanks, Dmitry -----Original Message----- From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Korchemny, Dmitry Sent: Tuesday, December 18, 2007 8:08 PM To: john.havlicek@freescale.com; sv-ac@server.eda.org Subject: RE: [sv-ac] ballot result for 1682 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. --------------------------------------------------------------------- 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.
This archive was generated by hypermail 2.1.8 : Tue Dec 18 2007 - 11:25:37 PST