Hi Gord, Gordon Vreugdenhil wrote: > > > Thomas Thatcher wrote: >> Hi Gord, >> >> Let me handle the easier problems first: 2089 >> >> The 2110 proposal: "Checkers inside loops" states that when checkers >> are instantiated inside a procedural loop, only the assertion >> components are executed multiple times. Procedures are not executed >> multiple times, once for each set of loop index variables, but are >> executed according to their timing control. >> >> In addition, My understanding is that the default disable or inferred >> enable are not used to control the execution of procedures. Thus, an >> always_check, or a final procedure will execute the same regardless of >> the place of instantiation of the checker. (Correct, Dmitry?) Of >> course, an always_check procedure could use a $inferred_clock, in its >> timing control, but this does not apply to final procedures. >> >> The final procedure should be very straightforward. It is triggered >> by the end of simulation. It will execute once, regardless of the >> location of the instance. > > So a "final" inside a checker that is instantiated in a task/function > that is never used will still be run at the end of simulation. In > addition it will only execute ONCE independent of the number or context > of the calls to the enclosing task/function. I think that this needs > to explicitly stated since users might (reasonably) expect that a > sequentially unreachable checker instantiation would not have its > "final" run. The Mantis 1900 proposal states: "A checker may be declared in one of the following: a module, an interface, a program, a checker, a package, a generate block, or a compilation unit scope and "A checker may be instantiated in one of the following: An always procedure or initial procedure, a module, an interface, a program, a checker, a generate block. so I don't believe that a checker may be instantiated in a task or function. (Dmitry?) Also, the Mantis 2110 proposal, which would allow checkers to be instantiated within procedural loops, does contain statements that only the assertion elements are triggered multiple times, as determined by the loop indices. Procedures are executed according to their timing control. > > 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? 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" I also believe that port connections to the checker must be static as well. > >> Now for 2088. I assure you that this was not intended as a sneaky way >> to get type declarations into procedural contexts :-) It was >> developed to enable coverage-driven methodology. The idea was that a >> verification units could be developed that contained all the necessary >> assertions, cover properties and covergroup instances all in one package >> >> What assumptions are being made? I guess I did assume that multiple >> instances of a checker would NOT create multiple type definitions for >> the covergroup. Is this a fundamentally flawed assumption? Is there >> some clarification in the proposal that is needed on this? > > > Absolutely this needs to be clarified (at least). There are > still lots of visibility issues here. Since a covergroup has > class-static properties and calculations that depend on that > staticness, it is crucial to determine how many distinct types > there are and how such types (including class static properties) > can be manipulated. If a covergroup is permitted, clearly to > have a "single" type, the covergroup can't refer to anything > that isn't static. Normally this isn't an issue since a > covergroup's declaration context makes that impossible. Now that > you've opened the door and have to explicitly add text that > makes such references illegal. > 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. I can definitely clarify in the proposal that only one distinct type is created for a covergroup, even when there are multiple instances of the checker that contains it. Checker variables (free or otherwise are static), and actual arguments to a checker instantiation must also be stable, with one exception. In Mantis 2110, which would allow checker instances within a loop, the loop index variable(s) is(are) allowed to be passed as actual arguments to the checker. However, the 2110 proposal forbids the use of loop control variable arguments by any construct other than assertions: > > I need to go back yet again and look at the checker/assertion > assumptions. I thought that the assumptions regarding the > rest of the checker constructs (assertions, etc) were that > those constructs *are* distinct for each loop iteration > and/or condition. Does this mean that we now have some > things that are unique per iteration and some that are not? Here's the text from the 2110 proposal: > A checker in a procedural loop evaluates its inputs and executes its assertion statements for each possible > valid set of loop control variables. Checker elements other than assertion statements, such as > always_check blocks and assign statements, are not repeated for multiple loop iterations: it is still a > single checker, and thus a single instance of its contents. To make this behavior safe, a checker in a > procedural loop shall obey the following restriction: > --If a checker input port is connected to or dependent on a loop control variable, that port shall only > be used within assertion statement instantiations, and shall not be used otherwise in the body of the > checker. > >> >> The intent was that, as much as possible, covergroups would work the >> same within a checker definition as they do outside. For example, >> covergroup operation is not affected by default clocking, inferred >> disables or inferred enables. That is still the case within a checker. >> Although a checker containing a covergroup instance may be >> instantiated in a loop, there is still only one instance of the >> covergroup. Like procedural blocks, they are not "replicated". > > So in what context can I refer to the covergroup's static properties? > Clearly I can't do "loop_name.checker.covergroup_type::..." since that > would be illegal. I can't even do that within the loop. So can > I only do that in a checker "new"? 16.18.5 seems to state that a checker's > initial can't have any sequential assignments, so as far as I can tell, > there is no reasonable to modify a covergroup's static properties. > I think I need more clarification of this question. In what ways are the covergroup's static properties referred to or modified? > > > Likewise, if a checker >> containing a covergroup instance is instantiated in a unreachable >> section of a case statement, the covergroup new() will be executed >> once, just as if the covergroup instance were outside the checker. > > ???? > > Pardon? A covergroup is NOT implicitly constructed in any context. > Even an embedded covergroup in a class requires a "new" to "activate" > the covergroup. Are you assuming that a covergroup acts like > an embedded covergroup in the context of a checker? If so, I have > lots of questions on that. > No, I was not implying an implicit construction. I was thinking that given an instance of a covergroup inside a checker with the new() coded, the new function would be executed once, regardless of the declaration context or the instantiation context of the checker that contains it. > 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 can put additional text in the proposal to clarify this. >> >> The covergroup is allowed to observe checker variables (free or >> otherwise). There are some possible timing race conditions with this. >> In one case we did forbid an interaction (using a checker variable in >> the clocking event of the covergroup). We have also documented some >> of the other unexpected results that might occur because of the >> different timing of checker variables. Do you see other problematic >> interactions other than timing? > > > I don't know yet. The interactions between the assumed static nature > of the covergroup and the non-static instantiation context make much > of this very difficult to reason about since there are all sorts > of interactions that don't appear anywhere else in the language. I > am really trying to figure out why this is so deeply compelling > as to require all this complexity and special case language. > > What fails to work by defining a covergroup as a sibling declaration > to the checker and then just having the checker use that? I > know that you lose the untyped aspects, but that is also exactly > where all the assumptions come in. So, just define the covergroup outside the checker definition, and simply allow instances of that covergroup inside the checker? This is a possibility. If it really simplifies things, I could do that. > > Gord > > Tom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Feb 20 18:13:40 2008
This archive was generated by hypermail 2.1.8 : Wed Feb 20 2008 - 18:14:12 PST