RE: [sv-bc] E-Mail Vote - Closes Midnight Oct 10

________________________________

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Maidment, Matthew R
Sent: Monday, October 04, 2004 10:59 AM
To: sv-bc@eda.org
Subject: [sv-bc] E-Mail Vote - Closes Midnight Oct 10

Hello All.

It's time to conduct an email vote to decide on accepting
the proposed resolution for a host of issues.

Please remember that the operating guidelines specify:
-You have 1 week to respond (Midnight Oct 10)
-An issue passes if there are zero NO votes and half of the eligible
 voters respond with a YES vote.
-If you vote NO on any issue, your vote must be accompanied by a reason.
 The issue will then be up for discussion at the next conference call.

As of the September 27th meeting, the eligible voters are:

213 Day
730
000 Month
998
000 Year
444
  
aaa Brad Pierce
a-a Karen Pieper
aaa Dan Jacobi
aa- Dave Rich
aaa Francoise Martinolle
aaa Mark Hartoog
a-a Rishiyur Nikhil
aaa Cliff Cummings
aaa Steven Sharp
a-a Stuart Sutherland
a-a Don Mills
aa- Logie Ramachandran
aa- Surrendra Dudani
-aa Doug Warmke

Below is the ballot. Appreciate your prompt response. Thanks!

015 _ XXX __Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000015

016 _ XXX __Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000016

039 _ XXX __Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000039

043 ___Yes __ XXX _No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000043

I do not see what is being accomplished by this change. It does not change all references to 'argument passing' to 'argument binding', and it does not mention output arguments. I would rather leave it the way it is.

076 ___Yes _XXX__No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000076
There is a minor problem in the .pdf proposal. The final change states that the change is needed in 19.6.1. But the real section which needs the change is 27.3. This appears to be a simple cut-n-paste error. YES, with friendly amendment to correct the above flaw.

087 _XXX__Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000087

089 _XXX__Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000089

153 _XXX__Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000153

157 ___Yes _XXX__No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000157

Although the correction is a true statement, it is not the same meaning of what the original statement had intended.

A clearer correction would be
 
And, elements of a packed structure or array can be assigned with multiple continuous assignments, provided that each element is covered by no more than a single continuous assignment.

The example in the LRM shows multiple *not* primitives continuously assigning individual bits of a packed array.

164 _XXX__Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000164

166 _XXX__Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000166

170 ___Yes _XXX__No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000170

I think of bit stream casting whenever at least one type is unpacked, meaning that you are looking at the values as a stream of bits, not as an integral value. Padding or truncation is not performed, so the total number of bits must be preserved. That would be a better correction.

209 _XXX__Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000209

222 _XXX__Yes ___No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000222

226 ___Yes _XXX__No
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000226

I think they should be fatal if the error can be determined at compile time, which usually means a gross error.

-- 
Matt Maidment 
mmaidmen@ichips.intel.com