Re: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 2007

From: Steven Sharp <sharp_at_.....>
Date: Sun Sep 30 2007 - 11:02:23 PDT
>SVDB  699 _X_Yes   ___No  
>http://www.eda.org/svdb/view.php?id=699
>
>SVDB  907 ___Yes   _X_No  
>http://www.eda.org/svdb/view.php?id=907

Need clearer wording on not implicitly instantiating these modules.

>SVDB 1035 _X_Yes   ___No  
>http://www.eda.org/svdb/view.php?id=1035
>
>SVDB 1228 _X_Yes   ___No  
>http://www.eda.org/svdb/view.php?id=1228
>
>SVDB 1425 ___Yes   _X_No  
>http://www.eda.org/svdb/view.php?id=1425

The blue paragraph refers to the expression 1'b1+2'b00, while the
example contains 1'b1-2'b00.  However, this should be easy to amend.

>SVDB 1468 _X_Yes   ___No  
>http://www.eda.org/svdb/view.php?id=1468
>
>SVDB 1710 _X_Yes   ___No  
>http://www.eda.org/svdb/view.php?id=1710
>
>SVDB 1747 ___Yes   _X_No  
>http://www.eda.org/svdb/view.php?id=1747

I am in favor of adding this functionality, as it addresses the main
difficulty with using `default_nettype.  But I agree with other comments
that the mechanism in the proposal is likely to be confusing.

>SVDB 1846 ___Yes   _X_No  
>http://www.eda.org/svdb/view.php?id=1846

I do think that it would be valuable to have a "1364-2005-noconfig"
version specifier.  The config keywords are still the only thing that
creates significant keyword conflicts between 1364-2005 and 1364-1995.

I don't think that this reasoning extends to a "1800-2005-noconfig" or
"1800-2008-noconfig" specifier.  The new 1800-2005 keywords create so
many keyword conflicts that there seems little point in eliminating
the config keywords.


>SVDB 1940 _X_Yes   ___No  
>http://www.eda.org/svdb/view.php?id=1940

I think the concerns about whether the LRM says you can declare vector
nets is handled in section 6.6, where it says that "Any 4-state data type
can be used to declare a net."

>SVDB 1949 _X_Yes   ___No  
>http://www.eda.org/svdb/view.php?id=1949


Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Sep 30 11:02:44 2007

This archive was generated by hypermail 2.1.8 : Sun Sep 30 2007 - 11:03:18 PDT