Hi Gord, I don't think that let is an issue here since the let construct cannot be used to define covergroup elements even in checkers, so from this point of view the situation should not be different from covergroups in modules. Regards, Dmitry -----Original Message----- From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Gordon Vreugdenhil Sent: Friday, February 15, 2008 1:30 AM To: Mehdi Mohtashemi Cc: sv-ec@server.eda-stds.org Subject: Re: [sv-ec]e-mail ballot Closes Wednesday February 20 2008, 11:59pm PST Mehdi Mohtashemi wrote: > We are conducting an email based on request from SV-AC on the following > mantis items: 2088 and 2089. > > the latest documents associated with the mantis items are: > 2088_covergroups_20080211.pdf > 2089_finalInChecker_20080129.pdf ... > > Please mark your vote below by an x. If No, then specify a reason. > Send it to the reflector. > > 2088 ___ Yes _X_ No > http://www.eda.org/svdb/view.php?id=2088 No for a couple of reasons. First, I need more time to be able to adequately review this. Second, the interactions between the type space (the covergroup type) and the checker "instantiations" are not obvious to me. Is a checker now a sneaky way of introducing type declarations (covergroups) into a procedural (even conditional) block? What assumptions are being made about whether new covergroup types are introduced with such checker "instantiations"? Remember -- covergroups have class-static properties so type uniqueness is important to have absolutely clear. Are unreachable (sequentially dead) covergroup types still alive? When are they created (via the "new") in such scenarios? Can a covergroup look at a free var from the checker? I am also concerned that there might be lurking assumptions about essentially having "macro like" expansions involving "let" and other untyped aspects. All of this is related to my early serious objections to "let" and checkers as a whole and how they interact with the rest of the language. "let" was tied down to only be used in assertions constructs but now AC needs to inject a non-assertions construct back into an assertions context. Many of my earlier concerns are likely going to reappear in this context as well. In short, there are all sorts of interactions here that are not at all obvious to me and could pose major issues unless the instantiation points of checkers with covergroups are restricted to contexts in which a covergroup type itself is a legal declaration. > 2089 ___ Yes _X_ No > http://www.eda.org/svdb/view.php?id=2089 Similarly here, there are unanswered questions. If checker is "instantiated" in a loop or conditional sequential construct, in what state is its "final" block? What if the checker is not sequentially reachable? The final is allowed to read from checker vars -- does that include free vars? Gord -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, 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, and is believed to be clean.Received on Sun Feb 17 23:53:47 2008
This archive was generated by hypermail 2.1.8 : Sun Feb 17 2008 - 23:54:21 PST