Maidment, Matthew R wrote: > > SVDB 1526 _X_Yes ___No > SVDB 1709 _X_Yes ___No > SVDB 1769 ___Yes ___No > http://www.eda.org/svdb/view.php?id=1769 I'll abstain on 1769. I don't have an technical complaints as such. I'd prefer to see the examples be simpler (not including assertions constructs). Say something like: if (WIDTH > 0) ... else begin $error("Invalid width provided"); end That would be more obvious to the average reader. With that change I would change to "yes". > SVDB 2089 ___Yes _X_No > http://www.eda.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. 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 Sat Feb 23 09:52:52 2008
This archive was generated by hypermail 2.1.8 : Sat Feb 23 2008 - 09:53:03 PST