RE: [sv-ec]E-mail Vote (part 2) Closes 12am PST May 2 2007

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Mon Apr 30 2007 - 07:46:02 PDT
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