Bassam and Manisha, On page 469, it states "cbAssertionDisable. The assertion is disabled (e.g. as a result of a control action)". What is meant by "control action" - is this the "disable iff" clause of an assertion or is this a system control task like assertkill or vpi_control? Is there and/or should there be a connection between an assertion being disabled via "disable iff" versus the assertoff/assertkill constructs and vpi_control(vpiAssertionDisable, assertion_handle) (28.4.1). It seems clear to me that the 805 proposal currently focuses only on the "disable iff" clause. In section 29.4.3 and Annex I, can we change vpiAssertDisableCovered to vpiAssertDisableIffCovered. The use of "disable" is too vague. The same applies to other such references of "Disable". This might solve my problem with getting confused with other uses of disabled. Lisa ________________________________ From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] Sent: Wednesday, June 14, 2006 2:26 PM To: Bassam Tabbara; Lisa Piper; Bassam Tabbara; Kulshrestha, Manisha; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 So the callback on disable is asynchronous, when it stops the attempt (from starting or in flight). ed ________________________________ From: Bassam Tabbara Sent: Wednesday, June 14, 2006 2:22 PM To: Eduard Cerny; Lisa Piper; Bassam Tabbara; Kulshrestha, Manisha; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 The VPI uses the typical CB for some "event" that happened on a registered assertion with a returned reason, the set of these assertion-related reasons includes start/success/fail/disabled .... Lisa, please review p. 469-470 of LRM for clarification on how this works -- I didn't really get the premise/question/terminology in your original email. so can't comment directly only recap. Of course yes this is very similar to the cbValueChange in VPI. Yes this works per attempt, no it does not miss anything -- Actually you get a cb for start of attempt then a callback for "result":success/fail/disabled/.... As I stated earlier, if you want to disable all assertions you would use the "system" variants corresponding to assertion/off/.... that is not per assertion (attempt). Thx. -Bassam. ________________________________ From: Eduard Cerny Sent: Wednesday, June 14, 2006 6:19 AM To: Lisa Piper; Bassam Tabbara; Kulshrestha, Manisha; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 Isn't it that the disbale iff, although asynchronous is interpreted in the synchronous context of the assertions as - not starting a new attempt, and - killing attempts in flight. The first one could be tied to the clock of the disabled assertion. The 2nd one seems more problematic. In that case, the value change of the condition could trigger the call back as Lisa suggests. So, either a clock tick and disable condition being true or a change of disable if condition to true (for all attempts in flight). Does that make sense? ed ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Monday, June 12, 2006 9:26 AM To: Bassam Tabbara; Kulshrestha, Manisha; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 I have a question - "disable iff" is asynchronous. Below it is stated that there is always a callback per attempt. If it is per attempt, you could miss it. So will "disable iff" callbacks happen every simulation cycle, or every attempt? I don't like the idea of having one every simulation cycle. Perhaps it could be defined as a callback when it changes value. lisa ________________________________ From: owner-sv-ac@verilog.org [mailto:owner-sv-ac@verilog.org] On Behalf Of Bassam Tabbara Sent: Friday, June 09, 2006 2:57 PM To: Kulshrestha, Manisha; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 Hi Manisha, I think this is ok as is. About your concern, we are always issuing a callback per attempt result so this is no different. There is another set of callbacks (cbAssertionSys...) for a wide scale (all assertions) on/off/disable (aka kill), obviously that's only one CB until the next start/enable, under user control here not a matter of sampling a signal as in former. ** Ed, like the other ticket (I forget #), we should add SV-CC for reviewing VPI part as well once we are done with ticket in AC. Thx. -Bassam. ________________________________ From: owner-sv-ac@verilog.org [mailto:owner-sv-ac@verilog.org] On Behalf Of Kulshrestha, Manisha Sent: Friday, June 09, 2006 11:35 AM To: Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 Hi All, I have uploaded a new version of the proposal on mantis. This includes suggestions by Lisa (done differently than suggested) and corrections from Ed ( I have made succeeded to succeeded nonvacuously). Ed, I have made the corrections but I am not sure about usefulness of those callbacks. I feel callback on each disable evaluation when disable is already true, is going to be unnecessary and expensive. Probably Bassam can suggest something. Anyone else ? Thanks. Manisha ________________________________ From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] Sent: Thursday, June 08, 2006 7:39 AM To: Kulshrestha, Manisha; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 Manisha, the last statement in the document you sent says: - cbAssertionSuccess, cbAssertionVacuousSuccess, cbAssertionDisabledEvaluation and cbAssertionFailure: cb_time is the time when the assertion succeeded or failed. Should it say that in the case of disabled evaluation it is the time when it was disabled? Rather than just succeeded or failed? Is it useful to report disabled time likely to be the start time in many cases?) Also, under succeeded, does it cover vacuous success? Best regards, ed ________________________________ From: owner-sv-ac@verilog.org [mailto:owner-sv-ac@verilog.org] On Behalf Of Kulshrestha, Manisha Sent: Tuesday, June 06, 2006 11:50 AM To: sv-ac@verilog.org Subject: [sv-ac] FW: #805 -----Original Message----- From: Kulshrestha, Manisha Sent: Thu 6/1/2006 12:17 PM To: 'sv-ac@eda.org' Subject: #805 Hi All, I have incorporated most of the feedback in my updated proposal (attached here). Please send your feedback. The original proposals are still on mantis in case you want to compare. The main change in this document is that disabled is not a success and thus very few changes are needed in the LRM. Thanks. Manisha 805: disable iff condition should produce vacuous match Lisa: I agree with this too - failure counters do not make sense for coverage. failure counters do not make sense for coverage. Joseph: yes Doron: I think that disabled should not count as a success in coverage. we need to change is the report of the number of failures in coverage Bassam: yes Dmitry: I don't think the failure should be reported for coverage at all. Surrendra: yes Ed: No success with disable to be reported. Dmitry: I agree with the definition of the vacuous success. According to our discussion about the property coverage definition, there is no meaning in disabled coverage success, since it should not count as a coverage event at all. Therefore the suggestions concerning Clause 17.13.3, page 288, Clause 29.4.3, page 482, Clause 29.4.2, page 481, and Annex I are not relevant. I agree with the proposal concerning Clause 28.4.2. Volkan: yesReceived on Fri Jun 16 08:29:38 2006
This archive was generated by hypermail 2.1.8 : Fri Jun 16 2006 - 08:29:43 PDT