Hi Manisha, Well that kinda explains why I thought I saw this fix (to 29) before and surprised I now find it's missing -- may be we should keep earlier proposals as an RCS of sorts :). Ok, I think there is some mixup here -- The "outstanding" discussion I think revolves around *cover* construct (meaning whether cover(disabled) returns True or False), there were no issues with assert. For the coverage chapter, despite the naming and the "covered" all over the place :), the coverable entity is an *assertion*, clearly stated in chapter, this is merely a count of all the different results -- so it's hard to say we're not collecting this. In fact the formula (Lisa's original email) has this data .... As far as the proposal, I think not adding this would be inconsistent, not just because the callbacks exist but more simply as I say above because the result ("disabled") exists, that is a state so no escaping it. BTW, I recall we had a similar discussion about vacuous and counting it. Thx. -Bassam. ________________________________ From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] Sent: Friday, June 09, 2006 3:57 PM To: Bassam Tabbara; Lisa Piper; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 Hi Bassam, So far my understanding is that we do not want to consider disabling of a property as a coverage event. This is the reason we do not want to provide coverage counting for disabled evaluations. This is the reason I skipped vpi routines for them. I believe providing vpi routines for counting disabled evaluations will not be consistent with rest of the proposal. Thanks. Manisha ________________________________ From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] Sent: Friday, June 09, 2006 3:43 PM To: Kulshrestha, Manisha; Lisa Piper; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 Hi Lisa/Manisha, here's my opinion Lisa: - Yep seems missing, good catch -- adding it removes the need for the sentence "The coverage counters ..." - Let's keep separate, we don't want to go back to associating disabled with vacuous and/or success Manisha: - You point out something that surely needs to be added, I missed this and thought we had this coverage chapter fix already between 805 and 1361 but I am mistaken. ** I fail to see why tools are being discussed -- this is the LRM and we should add a basis set of access from VPI to any and all language (syntax/execution semantics) no picking and choosing ... this is indeed an omission. Actually another correction on p. 481 vpiAssertVacuousSuccessCovered is missing from the list but used later. Thx. -Bassam. ________________________________ From: owner-sv-ac@verilog.org [mailto:owner-sv-ac@verilog.org] On Behalf Of Kulshrestha, Manisha Sent: Friday, June 09, 2006 3:26 PM To: Lisa Piper; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 Hi Lisa, This is just a formula which I have modified as disabled is not considered a success or failure any more. This does not mean that tools need to keep a counter for disabled evaluations or report them in any form. If you look at that section in the LRM, there are specific vpi functions for getting different counts and I have not added any new function for disabled so there is no need to keep this information in the tool (atleast LRM does not require the tools to do so). I hope this clarifies. Thanks Manisha ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Friday, June 09, 2006 3:16 PM To: Kulshrestha, Manisha; Eduard Cerny; sv-ac@verilog.org Subject: RE: [sv-ac] FW: #805 Manisha, Is there an implication here that a "disabled" counter also exists? It was not added to the list of counters in 17.13.3 - it was stated that disabled evaluations do not affect the other counters. But in 29.4.3, the section that talks about accessing coverage counts via vpi calls, it states: in progress = attempts - (successes + vacuous success + disabled + failures). Isn't this implying that a disabled counter exists since it is not meaningful otherwise? I question the value of requiring a disabled counter. I think the disabled counts should be included with the vacuous counts. If a tool vendor wants to add separate counters for the two, they can choose to do so, but it should not be required. Lisa ps - sorry I did not pick up on that earlier! ________________________________ From: owner-sv-ac@verilog.org [mailto:owner-sv-ac@verilog.org] On Behalf Of Kulshrestha, Manisha Sent: Friday, June 09, 2006 2:35 PM 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 9 16:23:40 2006
This archive was generated by hypermail 2.1.8 : Fri Jun 09 2006 - 16:23:47 PDT