General Comment: Are all of these Mantis items dealing with issues that were raised in ballot comments? It is not clear in the Mantis descriptions that some of them are ballot issues. If some are not, we should not be voting on them at this time. If they are, it should be made clear in the Mantis title for the bug just which ballot comment it is addressing. > > SVDB 1651 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=1651 From my user/trainer perspective, I could care less what we call this system task, and it does not bother me to have an $psprintf be an alias for $sformats. We have other aliases in the language, and this does reserve yet another keyword. > > SVDB 1791 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2791 > > SVDB 2501 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2501 > > SVDB 2568 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2568 > > SVDB 2593 ___Yes _X_No > http://www.eda.org/svdb/view.php?id=2593 I am voting no because I find the new wording to be confusing and conflicting with the first sentence of the paragraph containing the proposed change. The first sentence states "If a port declaration does not include a net or variable type...". The proposed statement states "Aside from the signed attribute mentioned below, the data types between the two declarations of a port shall match." How can the two declarations match if the declaration in the port list can only specify the sign and vector range? > > SVDB 2611 ___Yes _X_No > http://www.eda.org/svdb/view.php?id=2611 I do not like the proposed wording of the change. Does "If the prefix name is resolved using the normal scope resolution rules,..." mean that a tool can arbitrarily chose whether to follow the normal scope resolution rules? Should "is" be replaced with "can be"? Also, do declarations in $unit fall under "normal scope resolution rules", and therefore take priority of an explicit reference to a package with this proposed change? > > SVDB 2674 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2674 > > SVDB 2678 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2678 > > SVDB 2681 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2681 > > SVDB 2721 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2721 > > The following Mantis items are proposed to be resolved as: > > "The committee read and considered this feedback. the committee believes it > is too broad for the scope of the draft to implement at this time but may > be considered for future revisions." > > SVDB 2580 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2580 > > SVDB 2669 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2669 > > SVDB 2671 ___Yes _X_No > http://www.eda.org/svdb/view.php?id=2671 I think the committee should respond that this request to deprecate `define was considered and decided that the construct has practical applications and therefore should not be deprecated. > > SVDB 2673 ___Yes _X_No > http://www.eda.org/svdb/view.php?id=2673 I think the committee should act on this ballot request to deprecate defparam. Deprecation, of course, does not remove it from the language. I merely makes it an obsolete construct and allows tools to warn that there is a more preferred construct that should be used. > > SVDB 2679 ___Yes _X_No > http://www.eda.org/svdb/view.php?id=2679 I think the committee should act on this ballot request and state that it was considered and no change was necessary. > > SVDB 2684 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2684 > > SVDB 2686 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2686 > > SVDB 2687 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2687 > > SVDB 2688 ___Yes _X_No > http://www.eda.org/svdb/view.php?id=2688 I think the committee should address this ballot comment. > > SVDB 2689 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2689 > > SVDB 2690 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2690 > > SVDB 2691 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2691 > > SVDB 2697 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2697 > > SVDB 2720 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2720 > Stu ~~~~~~~~~~~~~~ Stuart Sutherland stuart@sutherland-hdl.com (503) 692-0898 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon, 11 May 2009 07:59:08 -0700
This archive was generated by hypermail 2.1.8 : Mon May 11 2009 - 08:01:39 PDT