hi SV-EC, > Based on April 16th, 2007 sv-ec meeting, we are conducting an > email vote on the following mantis items. > 1500, 1556, 1580, 1608, 1609, 1612, 1715 Once again I'm not eligible to vote but I've tried to review the content anyway. 1500 ~~~~ I'd like to suggest that the sentence This is consistent with common C++ use. should be struck out - it adds nothing to the standard. Also, I don't think any tools currently support typedef T; // instead of typedef class T; so this might be a good moment to get rid of it? 1556 ~~~~ This seems to me to be an example of "arranging the deckchairs on the Titanic" - there are so many other places where 'static' or 'automatic' are implicit in a non-obvious way. I can't see the point in plugging just this one. I 100% agree that "data" should be replaced by "variables" in the text, though. 1580 ~~~~ While I completely agree that tasks/functions should be accessible through a virtual interface, I'm very confused about the proposed text. Is it saying that, having hooked a virtual interface variable to a modport, I can then access non-modport-ish things in the interface (for example, enum literals) through that same virtual interface variable? Or is it saying that the existence of the modport doesn't suppress the ability to access other parts of the interface by static hierarchical reference? And if you want to be able to get at all identifiers in an interface through a virtual interface that is *not* of modport type, then what about types that are declared in the interface? I'm fairly sure sv-bc has already agreed that types declared in an interface can be referenced using hierarchical names, but I don't think I understand what it means to reference a type through a virtual interface variable. (An analogy: if a type is defined in a class, surely we can't reference that type through a handle of the class type, but only through classname:: scope resolution?) 1608 ~~~~ This looks OK to me, but I lack the expertise to comment in any detail. 1609 ~~~~ Looks OK to me. 1612 ~~~~ OK. 1715 ~~~~ I thought we had agreed to drop this one altogether, since the same effect can be achieved with existing language features. I'm not exactly sure what the procedure is for rescinding or abandoning a Mantis item, but as the instigator of this item I'd be happy to support getting rid of it. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Apr 30 07:46:32 2007
This archive was generated by hypermail 2.1.8 : Mon Apr 30 2007 - 07:47:03 PDT