Hi Bassam, Unfortunately they are not that simple as they look. If you include an immediate assertion into an assertion library, you need to be able to define the reset sequence somehow. We got many requests from designers to introduce a reset signal. The only way to do this now is like assert (rst || prop) (I have a typo in my original mail, where I wrote !rst) But then the vacuous pass can be neither disabled nor reported. Thanks, Dmitry ________________________________ From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] Sent: Tuesday, June 12, 2007 5:45 PM To: Korchemny, Dmitry; Lisa Piper; Kulshrestha, Manisha; Bassam Tabbara; sv-ac@eda-stds.org Subject: RE: [sv-ac] uploaded updated proposals for 1361 Hi Dmitry, I suggest we keep the immediate's expr simple i.e. whatever "if" allows -- I suspect this is part of their appeal, simple syntax/semantics. Thx. -Bassam. ________________________________ From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] Sent: Tuesday, June 12, 2007 7:36 AM To: Lisa Piper; Kulshrestha, Manisha; Bassam Tabbara; sv-ac@eda-stds.org Subject: RE: [sv-ac] uploaded updated proposals for 1361 Hi Manisha, I would like to initiate a discussion on immediate assertions. Currently immediate assertions are Cinderella of SVA, but they are also heavily used in practice. But the notion of vacuous pass of immediate assertions is not defined. Usually immediate assertions also have a reset, but since it is not defined syntactically it cannot be recognized by simulation tools. One solution would be to introduce disable iff statement for immediate assertions as well: assert ((disable iff rst) prop) <--> assert (!rst || prop). What do you think? Thanks, Dmitry ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Lisa Piper Sent: Wednesday, June 06, 2007 4:31 PM To: Kulshrestha, Manisha; Bassam Tabbara; sv-ac@server.eda-stds.org Subject: RE: [sv-ac] uploaded updated proposals for 1361 ________________________________ From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] Sent: Wednesday, June 06, 2007 2:40 AM To: Bassam Tabbara; Lisa Piper; sv-ac@eda-stds.org Subject: RE: [sv-ac] uploaded updated proposals for 1361 Hi Lisa, Thanks for the detailed feedback. My comments are included: ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Lisa Piper Sent: Monday, June 04, 2007 8:21 PM To: Kulshrestha, Manisha; sv-ac@eda-stds.org Subject: RE: [sv-ac] uploaded updated proposals for 1361 Hi Manisha, The proposal looks good overall but I do have some comments and questions: 1. 16.3 on Immediate assertions also has a paragraph on action blocks (immediately below Syntax 16-1) The note for 16.14.1 should apply here too so it is clear these apply to both immediate and concurrent assertions. I assume that is the intent, though I don't think that vacuous applies to immediates. OK, I'll take care of this in the proposal. 2. 1460 added the action block to the assume statement so 16.14.2 will have a similar statement. OK, I'll take care of this in the proposal. 3. this will impact the 1768 proposal for adding "cover sequence" as there are a couple references to the action blocks in it. Depending on which one is approved first, we'll have to edit one or the other. I'll add a note about this in the proposal. [Lisa Piper >>>] I'll do the same for 1768. 4. In 19.12, there is no default behavior described and I don't understand what this means: "These system tasks shall not affect the execution of pass or fail actions until the task is executed." This is the default behavior. This means that the execution of the action blocks will happen the way it happens now unless one of these tasks is executed. Do you suggest any better wording for this ? [Lisa Piper >>>] I think it should be clarified here so you don't have to go hunt in the earlier sections. How about (black text is a cut and paste from 16.14.1): "By default, When the property for the assert statement is evaluated to be true (vacuously or nonvacuously), the pass statements of the action block are executed. When the property for the assert statement is evaluated to be false, the fail statements of the action_block are executed. These tasks can be used to override the default." Do you think it is clear from the original spec that the current definition (e.g. the new default) is that the pass is executed on vacuous and non-vacuous passes? That was not how I interpreted it initially because the pass counter did not include vacuous. While I'm not willing to fight this one, I just can't imagine why anyone would want to execute the pass statements on a vacuous pass. 5. Isn't $assertpasson really enabling it for both vacuous and non-vacuous successes, whereas $assertnonvacuouson enables execution for nonvacuous only. This should be stated explicitely. Yes it does. Will new wording like "$assertpasson shall enable execution of pass action for vacuous and nonvacuous success for all the specified assertions." Be better ? Any suggestions ? [Lisa Piper >>>] sounds great. Thanks! 6. why is it $assertnonvacuouson and $assertvacuousoff We have passon/passoff and failon/failoff. The switch from vacuous to nonvacuous seems like an error. Earlier we had $assertvacuouson and $assertvacuousoff. But Doron objected to that during last ballot (and ballot was not approved due to his objection). He wanted to rename the functions such that there is no way a user can switch on execution of action blocks only for vacuous successes. 7. I assume that when there are two calls, the last one wins. If the HDL gives a command and the VPI gives and opposing command, the last one wins. Yes. 8. In 19.1, there is a reference to assertion control tasks. I assume there should be a similar one for assertion action control tasks. OK, I'll update that. 9. in 38.4.2, add a reference to the section that describes the "control action" to reference 38.5.2 so it is clear that the callback only occurs as a result of vpi controls and not as a result of assert_action_control_tasks (to be consistent with others, which is not to say that I agree with this). 10. on the previous point, why are call backs limited to control actions. I obviously don't have much experience with how they are used. I would think if I were trying to debug why an assertion was becoming disabled, I would want to set the callback and have it react to anything that might disable it. (This question applies to this and to 1599) I think Bassam has already answered 9 and 10. Lisa ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Kulshrestha, Manisha Sent: Saturday, June 02, 2007 1:06 PM To: sv-ac@eda-stds.org Subject: [sv-ac] uploaded updated proposals for 1361 Hi, I have aligned the proposal to draft3. Also, I have uploaded Word docs (2007 and 2003 versions) along with pdf file as pdf file is not perfect. I think this proposal is ready to be voted in sv-ac. Also, probably we need to send it to sv-cc as it has some API changes. Thanks. Manisha -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jun 12 07:52:05 2007
This archive was generated by hypermail 2.1.8 : Tue Jun 12 2007 - 07:52:15 PDT