Thomas Thatcher wrote: > Hi Gord, > [...] >> I assume that is also true for fork..join_none or similar contexts. >> What is the expected state of visible variable in such contexts? >> I assume that the final is not permitted to reference and visible >> non-static variables. Is that a correct assumption? Is that >> stated anywhere? >> >> > I don't think a checker is allowed in a fork-join. Would the list above > admit that possibility? Sure - it is allowed in an initial or always as a statement. An initial or always allows a fork..join[any,none] *statement* which in turn admits other statements. > 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. [...] > > 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? [...] >> 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? I would really like someone to describe the full model that they have in their head for how this is all supposed to fit together. It seems that there are still a large number of assumptions, ties to other in-progress proposals, and special case rules all over the place that make me extremely concerned about how this all fits together. As I've said before, and will continue to say, name resolution and overall elaboration modeling is very complex in Verilog. Inconsistencies, special cases, and introduction of new relationships cannot be done lightly and takes a very substantial amount of time to really make sure is sound. 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 07:14:30 2008
This archive was generated by hypermail 2.1.8 : Thu Feb 21 2008 - 07:15:14 PST