RE: [sv-champions] Email vote ending October 2

From: Stuart Sutherland <stuart@sutherland-hdl.com>
Date: Sun Oct 02 2011 - 00:10:06 PDT

1. 1356 <http://www.eda-twiki.org/svdb/view.php?id=1356> SV-EC Multiple
inheritance
There is a proposal (11 pages)
Unanimously approved in sv-ec September 12 2011 meeting.
1356_Interface_Classes_rev12.pdf

Approve _X_ Oppose __

Comment: The proposal needs a few editorial corrections such as using
Courier font for identifier names and cross references that do not follow
the LRM convention (e.g.: "See 8.25.5 Partial implementations" should be
"see 8.25.5). There are also a number of places where the proposal uses the
Courier-bold keyword font for words that are being used as regular English
words rather than as keywords (such as in 8.25.6). Finally, the changes to
8.3 Syntax are not duplicated in Annex A.1.2.

These simple editorial corrections can be dealt with when I (as the editor)
add the proposal to the LRM without creating another draft of the proposal,
so long as the EC committee is OK with the editor making such corrections.
It would take longer to list all these font and wordng friendly amendments
to the proposal than it would to just fix them as the proposal is added to
the LRM.

2. 2081 <http://www.eda-twiki.org/svdb/view.php?id=2081> SV-BC Not clear
enough which kinds of statements are prohibited in always_comb
There is a proposal (1 page)
On September 12, 2011 the SV-BC unanimously approved the attached proposal.

Approve _X_ Oppose __

 

3. 2547 <http://www.eda-twiki.org/svdb/view.php?id=2547> SV-AC local
variable read before write
No change required
Passed by voice vote 2011-08-16: 9y/0n/0a.

Approve _X_ Oppose __

 

4. 3015 <http://www.eda-twiki.org/svdb/view.php?id=3015> SV-AC Examples of
$fatal have bad arguments
There is a proposal (1 page)
The amended proposal passed by voice vote 2011-08-18: 9y/0n/0a.

Approve _X_ Oppose __

 

5. 3202 <http://www.eda-twiki.org/svdb/view.php?id=3202> SV-AC Clarify on
whether certain system functions are allowed in classes, 'let', and other
corner cases
Duplicate of 2476
Approved by voice vote 2011-08-02: 7y/0n/0a.

Approve _X_ Oppose __

 

6. 3213 <http://www.eda-twiki.org/svdb/view.php?id=3213> SV-AC Update
definition of sampled value
There is a proposal (11 pages)
Amended proposal passed by email vote 2011-08-01: 8y/0n/0a.

Approve __ Oppose _X_

OBJECTION: The proposed 16.5.1 says "The default sampled value of sequence
methods triggered and matched is 1'b0." All other references to these
methods only say that they return "true or false". The default return
value should be consistent with the other descriptions, either by making the
default return "false", or by defining a prototype for the methods that show
a 1-bit return value (presumably of type bit).

GENERAL COMMENT: Many of the rules described in proposed 16.5.1 make no
sense to me. I'm sure that some of the rules are backward compatible with
1800-2009 (such as the last "exception" bullet at the bottom of page 3,
which seems like it is adding restrictions that did not exist before). I am
not qualified to determine if the rules make sense to tool implementers, if
they are reasonable to implement, and if there are backward compatibility
issues.

 

7. 3326 <http://www.eda-twiki.org/svdb/view.php?id=3326> SV-BC LRM in BNF
allows parameters declaration under generate, while in generate chapter it
is forbidden
There is a proposal (a 2-line change)
On July 18, 2011 the SV-BC unanimously approved the attached proposal.

Approve _X_ Oppose __

 

8. 2289 <http://www.eda-twiki.org/svdb/view.php?id=2289> SV-BC 6.20.1 should
say that generate block and compilation unit-scope parameters are local
There is a proposal (a 2-line change)
On July 18, 2011 the SV-BC unanimously approved the attached proposal.

Approve _X_ Oppose __

 

9. 2093 <http://www.eda-twiki.org/svdb/view.php?id=2093> SV-AC Checker
construct should permit output arguments
There is a proposal (6 pages)
Approved by voice vote 2011-09-20: 10y/0n/0a.

Approve __ Oppose __ Abstain _X_

I am concerned about the following new rule about checker output port
connections being similar to continuous assignments.

"Checker actual output arguments shall be variable_lvalue or net_lvalue. The
checker instantiation should be treated as if there were continuous
assignments, executed in the Reactive region, of the checker's output formal
arguments to their corresponding actual arguments."

I believe checker outputs can use types that have no continuous assignment
rules. I do not feel qualified to say that this is a problem, and so I am
abstaining and leaving it to other experts to object if there is a a problem
here.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Oct 2 00:10:58 2011

This archive was generated by hypermail 2.1.8 : Sun Oct 02 2011 - 00:11:00 PDT