Hi Dave, I think that $assertoff is enough because there is an ability to specify exact statements that you want to turn off. At least I cannot see a scenario when all assertions (in the module) should be enabled, but assumptions still checked. The coverage collection is a different thing and controlling it separately might be useful. The users will certainly like if is possible to specify wildcards in the assertion name. Thanks, Dmitry ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Rich, Dave Sent: Friday, February 16, 2007 9:35 PM To: Bassam Tabbara; Surrendra Dudani Cc: sv-ac@server.eda.org Subject: RE: [sv-ac] Effect of assetion control system tasks Yes, in the VPI section, it's much clearer that they were designed for concurrent assertions since immediate assertions have no state and do not have existing attempts. BTW, why is there no $assumeoff or $coveroff? Dave ________________________________ From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] Sent: Friday, February 16, 2007 10:36 AM To: Surrendra Dudani; Rich, Dave Cc: sv-ac@eda.org Subject: RE: [sv-ac] Effect of assetion control system tasks Indeed. VPI control does same. In the LRM sentence/whole paragraph "checking"/"executing" is used interchangeably. Thx. -Bassam. ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Surrendra Dudani Sent: Friday, February 16, 2007 10:09 AM To: Rich, Dave Cc: sv-ac@eda.org Subject: RE: [sv-ac] Effect of assetion control system tasks My understanding of $asserton and $assertoff is to turn on/off assertion evaluations/executions. It is not about reporting. Surrendra ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Rich, Dave Sent: Friday, February 16, 2007 12:47 PM To: Bassam Tabbara; Singh, Tej; Kulshrestha, Manisha; sv-ac@eda-stds.org Subject: RE: [sv-ac] Effect of assetion control system tasks I don't think it's that clear. It is understandable that "currently executing" assertions is referring to concurrent assertions since no immediate assertion could be executing at the same time as the $assertoff. It would have be clearer to use the language of clause 17 and say that all current attempted evaluations of assertions are disabled as well as future attempts. To say "stop checking" at best implies that results of the expression is not checked and therefore no action shall be taken. It says nothing about whether the expression is or isn't evaluated. In the software world, people like and have been using the immediate assertions in their code, and you would be doing them a disservice if side-effects were not executed as a result of $assertoff. The main purpose of $assertoff is to filter messages and actions from assertions during a specific unstable time and possibly improving performance of dynamic simulation by reducing the overhead of numerous assertion threads. I don't see much of an impact in explicitly requiring that immediate assertion expression always be evaluated. Dave ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Bassam Tabbara Sent: Wednesday, February 14, 2007 3:36 PM To: Singh, Tej; Bassam Tabbara; Kulshrestha, Manisha; sv-ac@server.eda-stds.org Subject: RE: [sv-ac] Effect of assetion control system tasks I believe this is clearly stated in $assertoff clause -- stop checking meaning stop executing which would stop side-effects if any. Thx. -Bassam. ________________________________ From: Singh, Tej [mailto:tej_singh@mentor.com] Sent: Wednesday, February 14, 2007 3:19 PM To: Bassam Tabbara; Kulshrestha, Manisha; sv-ac@eda-stds.org Subject: RE: [sv-ac] Effect of assetion control system tasks What does it mean to $assertoff an immediate assertion? For e.g assert (bus.randomize() == 1) else $error("randomization failed"); Does $assertoff means it should stop randomizing (i.e. stop checking for expression) or should it stop reporting error? I think it should stop checking for the expression but then does it imply to not assert on an expression that has side effects? Regards Tej ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Bassam Tabbara Sent: Wednesday, February 14, 2007 12:40 PM To: Kulshrestha, Manisha; sv-ac@server.eda-stds.org Subject: RE: [sv-ac] Effect of assetion control system tasks Yes they should -- same goes for VPI control. Thx. -Bassam. ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Kulshrestha, Manisha Sent: Wednesday, February 14, 2007 12:34 PM To: sv-ac@eda-stds.org Subject: [sv-ac] Effect of assetion control system tasks Hi, Do assertion control system tasks affect immediate assertions ? It is not very clear from the LRM. The immediate assertion section only has the following statement: "Note: The assertion control system tasks are described in 24.9." 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 <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 Thu Feb 22 12:20:29 2007
This archive was generated by hypermail 2.1.8 : Thu Feb 22 2007 - 12:20:42 PST