Re: [sv-bc] Email ballot: Respond by Friday, Februrary 29, 8am PST

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Sat Feb 23 2008 - 09:52:23 PST
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