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

 

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Gordon Vreugdenhil
Sent: Saturday, February 23, 2008 7:52 PM
To: Maidment, Matthew R
Cc: sv-bc@server.eda.org
Subject: Re: [sv-bc] Email ballot: Respond by Friday, Februrary 29, 8am
PST



Maidment, Matthew R wrote:
> 
> SVDB 1526 _X_Yes   ___No
> SVDB 1709 _X_Yes   ___No


> SVDB 1769 ___Yes   ___No
> http://www.eda-twiki.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-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.

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.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.