Korchemny, Dmitry wrote: [...] > [Korchemny, Dmitry] The checkers may appear where concurrent assertions > may appear, but according to 2091, concurrent assertions cannot appear > in fork..join[any,none] blocks. I think you are relying on an indirect argument. Unless a checker is *required* to contain an assertion, there is no rule or implication saying that a checker instantiation cannot be in a fork...join. In either case, it would be much more obvious to state the restriction clearly rather than listing places where a checker may be instantiated. Why not just say explicitly -- a checker may be instantiated in places where a concurrent assertion may appear (see 16.4). If there are any differences, list those. That would be much more clear and would eliminate reliance on a questionable indirect reason for legality. >> I agree that all variable references in the final block should be > static. >> The Mantis 1900 proposal says (sec 16.18.6) >> "All checker variables in a checker body shall have a static >> lifetime" > > But that is immaterial to my question. If you have an auto declaration > in the enclosing scope, can a checker instance refer to that? No > one has (yet) made any restrictions regarding the resolution rules, > so I am assuming that the answer is yes. > > [Korchemny, Dmitry] Could you suggest a scenario when this can happen? > The names in checkers are resolved according to the checker declaration > context, and not according to its instantiation. E.g., > > always begin > automatic logic a; > ... > mycheck c1(...); > ... > end > > How can mycheck reference a? As far as I know it is illegal to reference > automatic variables from outside. But this was at the core of my earlier questions to which Tom replied that covergroup references do NOT bind outside the checker declaration. If *all* references require binding at the declaration point, then this is likely not a problem since the context of the checker decl can't have automatics visible. The model that you have is not really one of "instantiation" in the module sense (in which case point of instantiation is important), but rather something closer to object construction in which case all resolution occurs at the point of the *type*. So, in that sense, is it correct that name resolution within the context of the checker is like a "type" definition? By the way, I noticed that checkers can also be in interfaces. Is is possible, as with an interface type, to instantiate a checker from an interface by appealing to the interface port? >> Can you explain what a class-static property is? I think I have an >> idea what it means, but I need to really understand it. > > It is a property that is shared across all objects of that type (there > is only one per type not per object). > > For a covergroup, see 18.7 for things like the "goal" and the > "strobe" options. Actually the "strobe" might be interesting in and > of itself in this context. Is "strobe" even reasonable for a > covergroup on checker vars? > > [Korchemny, Dmitry] Yes, strobe may be reasonable, though it is not the > only option. But how do you modify the statics? You can't do so within the "initial_check" since that doesn't allow assignment. Assuming that hierarchical reference into a checker instance name is legal (is it???), I guess you could modify the static options post-covergroup construction be going through the instance, but that seems pretty artificial. >>> I haven't yet thought through potential issues with having the >>> covergroup be able to see the context of the checker declaration >>> at the time of definition and the relationship of covergroup >>> ref args for sampling semantics. I don't know if there are > referencing >>> issues there. >>> >> Sorry if I misled you here. The covergroup is not able to see the >> context of the checker declaration. > > I don't understand this claim at all. Where is that statement made > in the proposals? > > Clearly a checker can have names resolve to, say, the package > context. The 1900 proposal explicitly says: > > Variables used in a checker that are neither formal arguments to the > checker nor internal variables of the checker are resolved according > to the scoping rules from the scope in which the checker is > declared. > > Are you saying that the normal resolution scoping rules do NOT > apply to a covergroup embedded within a checker declaration? > > [Korchemny, Dmitry] It looks like there is some misunderstanding here. I > don't see any reason why the normal resolution scoping rules do not > apply to a covergroup. Gord, could you restate the original problem? I was simply observing that I have not yet had time to determine whether there were different kinds of issues here. I don't know if there are yet; Tom's response indicated that he didn't think such references were possible which led to my confusion. > [Korchemny, Dmitry] The basic checker proposal is 1900, and it should be > taken as a reference. All stated in 1900 is valid unless another > proposal explicitly modifies its text. Each proposal contains > information about the Mantis item on whose top it is written. I see that in the latest version you've added: When the checker is instantiated its contents are conceptually inserted at its instantiation point: if a checker is instantiated in a procedure, its contents are inserted after this procedure, otherwise they are inserted in place. Note that the checker instantiation rewriting is only conceptual since the code allowed in a checker is not legal outside it. The variables referenced in a checker are resolved according to the checker declaration context. The first two parts of this seem to contradict each other. Did you intend to say that an instantiation in a non-procedural context inserts at that point and in a procedural context it follows? In the procedural case, is the "after" part true for all the contents or just the non-assertion contents? I thought the the assertions components were just like having a concurrent assertion at that point. In addition, I would likely want to claim not just that "variables referenced in a checker are resolved according to the checker declaration context" but that **all** names and hierarchical references are resolved in that manner (assuming that hierarchical names are valid). That would reduce potential confusion about talking about checker "instantiations" where that is really quite different conceptually than any kind of other module, program, or interface instantiation. 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 Thu Feb 21 10:15:53 2008
This archive was generated by hypermail 2.1.8 : Thu Feb 21 2008 - 10:16:12 PST