Korchemny, Dmitry wrote: > Yes, this is correct. The let proposal says that let may be used in > other let only and in assertions. The checkers proposal adds that "The > right-hand side of a checker variable assignment or initialization may > contain let expressions". In all other constructs let is forbidden. But if the covergroup is inside the assertion construct (the checker), the let becomes invalid. All (?) other uses of let are valid in the checker, right? The rules here are becoming increasingly convoluted. A "let" is valid inside a checker but only if the context of its use is not a covergroup. What other exceptions and irregularities are going to show up? This gets right at my original complaints -- "let" is such a bizarre construct in terms of the rest of the language that it just will not compose well. The covergroup issue is, I suspect, only the first such situation in which we'll have to introduce special exceptions, etc. The original argument from AC (and why I stopped arguing against "let") was that the assertions constructs were "closed" enough that no new interactions would show up. That is no longer the case. Gord. > > Unfortunately, I am not an expert in covergroups, so I won't be able to > address all your concerns, and I hope that Tom will do it much better > than I. I will try to contribute to this discussion as it develops where > I can help. > > Thanks, > Dmitry > > -----Original Message----- > From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On > Behalf Of Gordon Vreugdenhil > Sent: Monday, February 18, 2008 4:58 PM > To: Korchemny, Dmitry > Cc: Mehdi Mohtashemi; sv-ec@server.eda-stds.org; sv-ac@server.eda.org > Subject: [sv-ac] Re: [sv-ec]e-mail ballot Closes Wednesday February 20 > 2008, 11:59pm PST > > Are you saying that let can't be used *at all*? What about > in bins declarations, etc? I don't see that kind of restriction. > > My concerns other than "let" are still open. > > Gord. > > Korchemny, Dmitry wrote: >> 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.Received on Mon Feb 18 07:33:14 2008
This archive was generated by hypermail 2.1.8 : Mon Feb 18 2008 - 07:33:48 PST