Hi Gord, Time is short. I will modify my proposal to state that only instances of covergroups may appear within a checker. Definitions of a covergroup type must occur externally to the checker. I believe that this still enables my intended use of covergroups, although with a little overhead. Will this simplify things for you? It should at least take care of the type problems. One question for my examples: A covergroup cannot be defined in a compilation unit scope, correct? Tom Gordon Vreugdenhil wrote: > > 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. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Feb 21 13:45:42 2008
This archive was generated by hypermail 2.1.8 : Thu Feb 21 2008 - 13:47:14 PST