Re: [sv-ec] email ballot: response due by 11:00am PDT Friday May 1 2009

From: Steven Sharp <sharp_at_.....>
Date: Thu Apr 30 2009 - 18:19:30 PDT
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