Tom, I think that is close enough for now. I don't particularly like the qualifier "unique" in this context since one could then think that two identical checkers (even in different contexts) might only cause one final block (similar to unique specializations of a parameterized class). That isn't the case here (I hope!). Dropping the word "unique" doesn't hurt and removes possible misunderstanding. Gord. Thomas Thatcher wrote: > Hi Gord, > > I have added the following sentences to the draft. Do these > sufficiently clarify the operatin of final procedures in checkers? > > > > The operation of the final procedure is independent of the instantiation > context of the checker that contains it. It will be executed once at the > end of simulation for every unique instantiation statement of that > checker. There is no implied ordering in the execution of multiple > final blocks. > > . . . code within a final procedure is allowed to reference (but not > write to) any visible static variable, including checker variables > declared in the checker body which contains the procedure. > > Tom > > >>> SVDB 2089 ___Yes _X_No >>> http://www.eda-twiki.org/svdb/view.php?id=2089 >> >> I'm going to vote NO on 2089 in its current form. >> >> As with my comments in EC, I'd likely be willing to change >> to YES if the nature of the finals is substantially >> clarified to cover what I think is the expectation: >> - a final can only reference visible static variables >> - a final in a checker is executed exactly once per >> instantiation *statement* of the checker. It isn't >> "unrolled" or conditionally created or anything similar. >> The sequential reachability of a procedurally instantiated >> checker is immaterial (although clearly the elaboration >> of the enclosing design unit/generate context must be). >> - there is no assumption about "ordering" of the finals >> with respect to their sequential appearance -- they are >> normal final procedures from a scheduling perspective. >> >> It isn't quite clear to me yet which parts of the internals >> of the checkers are "static" enough to be Ok and whether >> there should be semantic restrictions on any of those (freevars?). >> >> Some of those concerns relate to how much freedom simulators >> have to make arbitrary choices and whether resulting output >> is going to be reproducible and/or consistent across tools. >> Perhaps, as with constrained random behavior, only limited >> levels of consistency are expected. > -- -------------------------------------------------------------------- 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 Tue Feb 26 07:02:00 2008
This archive was generated by hypermail 2.1.8 : Tue Feb 26 2008 - 07:02:50 PST