Hi Dmitry, the user can always use $sampled() on whatever arg to the cg. I am not sure we have to say anything really. ed ________________________________ From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] Sent: Thursday, December 06, 2007 12:32 PM To: Eduard Cerny; Seligman, Erik; Thomas.Thatcher@sun.com Cc: sv-ac@eda.org Subject: RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker) Hi Ed, Right now it is not stated that every input argument of checker is sampled. More than that, events and continuous free variables are never sampled. Therefore some text explaining CG sampling is needed. It might be even OK to sample CG in the Postponed region in checkers. Thanks, Dmitry ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Eduard Cerny Sent: Thursday, December 06, 2007 6:51 PM To: Korchemny, Dmitry; Seligman, Erik; Eduard Cerny; Thomas.Thatcher@sun.com Cc: sv-ac@server.eda.org Subject: RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker) Hi Dmitry et al, Covergroups sample when they are triggered, unless the option strobe is set to 1 in which case it is the postponed region). If we sample by default all variables that enter the checker in the preponed region, then in fact the covergroup would automatically use these sampled values. But this woudl have to be stated somewhere in the proposal. Best... ed ________________________________ From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] Sent: Thursday, December 06, 2007 11:35 AM To: Seligman, Erik; Eduard Cerny; Thomas.Thatcher@sun.com Cc: sv-ac@eda.org Subject: RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker) Hi Tom, Unfortunately I haven't managed to thoroughly review your proposals yet. But I would like mention an important point that needs to be explicitly addressed, the issue of sampling: where the signals in covergroups and in final procedures are sampled. In what region does the corresponding code in the checker execute? Thanks, Dmitry ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Seligman, Erik Sent: Wednesday, December 05, 2007 7:47 PM To: Eduard Cerny; Thomas.Thatcher@sun.com Cc: sv-ac@server.eda.org Subject: RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker) Yeah, it's probably not an issue. I just wanted to make sure we have explicitly considered it. ________________________________ From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] Sent: Tuesday, December 04, 2007 2:59 PM To: Seligman, Erik; Eduard Cerny; Thomas.Thatcher@sun.com Cc: sv-ac@eda.org Subject: RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker) I do not think so, because you woudl have to do that also for the assignments and always / initial blocks. I think that it does say that the checker only infers certaing things from the context, but essentially lives outside the procedural context, like assertions. No? ed ________________________________ From: Seligman, Erik [mailto:erik.seligman@intel.com] Sent: Tuesday, December 04, 2007 4:57 PM To: Eduard Cerny; Thomas.Thatcher@sun.com Cc: sv-ac@eda.org Subject: RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker) Well, I obviously posted a bad phrasing... but I think the question remains: do we need to explicitly clarify the role (or non-role) of the procedural code surrounding the checker? ________________________________ From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] Sent: Tuesday, December 04, 2007 1:45 PM To: Seligman, Erik; Thomas.Thatcher@sun.com Cc: sv-ac@eda.org Subject: RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker) Hi Erik, covergroups: there should be no restriction saying that the cg must be controlled by its explicit clocking event because in checkers they may often be controlled by the sample() method. ed ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Seligman, Erik Sent: Tuesday, December 04, 2007 4:40 PM To: Thomas.Thatcher@sun.com Cc: sv-ac@eda.org Subject: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker) Hi Tom-- these proposals look good to me overall. A couple of comments: 2088 (covergroups in checker): - 16.18.6: some instances of 'bins' are not boldfaced, and the 'b' in one 1'b0 is; should fix. - In general, as alluded to in earlier email conversations, do we have to worry about the fact that by virtue of being in a checker, the covergroup may be effectively within procedural code? I'm wondering if we might want some statement like "The covergroup's timing shall be controlled only by its explicit clocking event, regardless of any procedural context in which the checker in instantiated." On the other hand, maybe we don't need to bother, since it's consistent with how concurrent assertions in checkers are treated anyway. 2089 (final in checker): - 16.18.4: The last sentence reads "There is one limitation on final procedures inside a checker: Statements within final procedures shall not write into free variables." The phrase "one limitation" sounds very absolute-- maybe it would be better to simply state "Statements within final procedures shall not write into free variables." without the preceding clause. (Also remember that this is technically true of *all* final procedures, since ones outside checkers are never in a scope with legal free variables anyway.) - Also, referring to the same paragraph: is it the case that all code allowed in final procedures outside checkers is also allowed in final procedures within checkers? If so, this is a bit different from the initial_check and always_check procedures described in the two paragraphs above, which disallow general procedural code. So I think we should have an explicit statement clarifying this. Something like "All code which is allowed in a non-checker final block is also allowed in final blocks within checkers." Erik Seligman Formal Verification Architect Corporate Design Solutions Design Technology and Solutions M.S. JF4-402 2111 NE 25th Ave Hillsboro, OR 97124 Phone: (503) 712-3134 -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , 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 <http://www.mailscanner.info/> , 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 <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 Dec 6 11:09:19 2007
This archive was generated by hypermail 2.1.8 : Thu Dec 06 2007 - 11:10:03 PST