Summary: I abstained on id 102 I voted NO on 107, 181, 182, 183, 185, 186 My reasons are given with the votes. My apologies for not doing this earlier, to give more time to address my concerns. >id 48 allow for future enhancement > > __X__ YES _____ No > > > >id 54 allow for future enhancement > > __X__ YES _____ No > > > >id 16, 17 > > sv-ec agrees with sv-cc resolution to keep these regions for future use. > > Reject svdb 2632 statement. > > __X__ YES _____ No > > > >id 19 No action required > > __X__ YES _____ No > > > >id 20 svdb 2634 (svbc issue) > > sv-ec votes as well to accept the proposal as well. > > __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2634 > > > >id 105 (id 110 is duplicate of 105) > > No action required > > __X__ YES _____ No > > > >id 115 No action required > > __X__ YES _____ No > > > > > >id 35, svdb 2705 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2705 > > > > > >ids 36,37,38,39,40 > >svdb 2700 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2700 > > > > > >id 41, svdb 2681 __X__ YES _____ No > >[both svbc and svec will vote on this] > >http://www.eda.org/svdb/view.php?id=2681 > > > > > >id 42, svdb 2682 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2682 > > > > > >id 43 and id 45, > >svdb 2430 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2430 > > > > > >id 44, svdb 2701 __X__ YES _____ No > >[both svbc and svec will vote on this] > >http://www.eda.org/svdb/view.php?id=2701 > > Note: this vote is for proposal named 2701-1a.pdf > > >id 46, svdb 2706 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2706 > > > >id 47, svdb 2713 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2713 > > > >id 57, svdb 2698 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2698 > > > >id 65, svdb 2723 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2723 > > > >id 67, svdb 2358 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2358 > > > >id 80, svdb 2596 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2596 > Note: this vote is for proposal named 2596-1a.pdf > >id 102, svdb 2718 _____ YES _____ No > >http://www.eda.org/svdb/view.php?id=2718 > Abstaining because I have not had a chance to investigate enough. > >id 106, svdb 2710 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2710 > > > >id 107, svdb 2711 _____ YES __X__ No > >http://www.eda.org/svdb/view.php?id=2711 I will not approve any further creep in the functionality of ref args of covergroups, until it has been specified that the actuals to such arguments must be static variables. At present there is nothing to prevent passing an actual whose lifetime is shorter than the covergroup. >id 181, svdb 2035 _____ YES __X__ No > >http://www.eda.org/svdb/view.php?id=2035 While I tend to agree that these are not very useful, and that the distinction between static methods and static lifetimes is confusing to users, the fact is that they were allowed before. Therefore this is not backward compatible. While it may still be reasonable to do this, I am not willing to do it hastily as part of the ballot review. >id 182, svdb 2514 _____ YES __X__ No > >http://www.eda.org/svdb/view.php?id=2514 I don't have an objection to most of the proposal, which I thought was very well thought out and written. However, I find the syntax "pure constraint" to be misleading. For a "pure virtual" function, the "pure" modifies the "virtual", so that it doesn't appear to suggest that the function is pure. It suggests to me that it is purely virtual, not real yet. But "pure constraint" seems to suggest that there is something pure about the constraint. Was the possibility of the syntax "pure virtual constraint" considered? Would there be any problems with that syntax, aside from being wordier? >id 183, svdb 2510 _____ YES __X__ No > >http://www.eda.org/svdb/view.php?id=2510 It may not be clear enough that 6.21 disallows these things from being clocking variables. We have run into issues elsewhere with what is considered a procedural context. If the problem is that this text is more restrictive than the text in 6.21, then why not just use text more like that section. Leave the sentence, but change "dynamic variables" to "elements or members of dynamic variables", and change "or dynamic arrays" to "or elements of dynamic arrays". >id 184, svdb 2473 > >CLOSE 2473, id 184 requires no further action: > >[ Draft8 says > > An associative array type or class shall be illegal as a > > destination type. So this has already been made illegal.] > > __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=2473 > > > >id 185, svdb 2342 _____ YES __X__ No > >http://www.eda.org/svdb/view.php?id=2342 I am fine with disallowing virtual and static for constructors. I agree that these make no sense. But the proposal explicitly allows local and protected, and I think there are some problems with this. The first problem is that by the formal definitions of these in the LRM, I don't think they would have the expected effect on a constructor. They are described as preventing access by hiding the name of the member. But the constructor doesn't actually have a name. It is invoked with the reserved keyword "new", which is not technically a name. Since it is not an identifier, it doesn't follow normal symbol table type rules. It is a reserved word that is always available, so it cannot be hidden. To get the desired effect, I think you would need to revise the description of how these qualifiers work. If you try to define the qualifiers by saying that these methods simply cannot be called from those places, then I think you run into another problem with "local". You have to be able to call the super.new from the derived class new. But that would not be allowed if the super.new were declared to be "local". If you aren't allowed to call it, as opposed to not being allowed to use the name, then that would apply to the implicit super.new call also. The whole mechanism of chained constructors would fail. If the idea is to disallow only an explicit super.new, but allow the implicit one, then more special wording is needed. Ditto if the idea is to allow calling it only from the derived class constructor but noplace else in the derived class. Though my previous issue could be dismissed as pedantic on the basis that everyone knows what is meant, I really don't know what is meant here. Frankly, I don't know that the idea of a "local" constructor is useful, and it is not clear to me what meaning is intended. I do agree that the idea of a "protected" constructor is useful, and I understand what is meant by it, even though I think there are issues with the LRM there. If "protected" is the only qualifier allowed, then there is no need for a semantic rule for this. Just replace {method_qualifier} with [protected] in the productions for constructor declarations. >id 186, svdb 2288 _____ YES __X__ No > >http://www.eda.org/svdb/view.php?id=2288 If we are being pedantic, it is not the entry that is smallest or largest, but its index. >id 192, svdb 1256 __X__ YES _____ No > >http://www.eda.org/svdb/view.php?id=1256 > > > > > >svdb 2719 for the following ids > >id 58 __X__ YES _____ No > >id 60 __X__ YES _____ No > >id 61 __X__ YES _____ No > >id 104 __X__ YES _____ No > >id 108 __X__ YES _____ No > >id 112 __X__ YES _____ No > >id 117 __X__ YES _____ No > >id 118 __X__ YES _____ No > >id 119 __X__ YES _____ No > >id 122 __X__ YES _____ No > >id 137 __X__ YES _____ No >http://www.eda.org/svdb/view.php?id=2719 > > > > > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. > 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 Thu Apr 30 18:20:27 2009
This archive was generated by hypermail 2.1.8 : Thu Apr 30 2009 - 18:21:14 PDT