No PDF yet. I sent it to the reflector as a doc
From: Alsop, Thomas R
Sent: Monday, August 29, 2011 11:19 AM
To: Tipp, Brandon P; Francoise Martinolle
Cc: sv-ec@eda.org; Tipp, Brandon P
Subject: RE: comments on 1356
Do you have a PDF generated yet? Rev11 that we can discuss in this meeting? Thanks Brandon. -Tom
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Tipp, Brandon P
Sent: Monday, August 29, 2011 11:15 AM
To: Francoise Martinolle
Cc: sv-ec@eda.org; Tipp, Brandon P
Subject: [sv-ec] RE: comments on 1356
Franciose,
No big deal. There is a lot of good feedback here. I managed to get most of it in just before the start of the meeting.
Thanks,
-Brandon
From: Francoise Martinolle [mailto:fm@cadence.com]
Sent: Monday, August 29, 2011 11:13 AM
To: Tipp, Brandon P
Cc: sv-ec@eda.org
Subject: RE: comments on 1356
Brandon,
I apologize for procastinating until the last day for reviewing this. I will try to be more
proactive next time.
Francoise
'
________________________________
From: Tipp, Brandon P [mailto:brandon.p.tipp@intel.com]
Sent: Monday, August 29, 2011 1:47 PM
To: Francoise Martinolle
Cc: sv-ec@eda.org; Tipp, Brandon P
Subject: RE: comments on 1356
I was really hoping that we would have had a few days to get this feedback in. See below:
I left #3, #13, #16, #20, #25 open for quick discussion in the meeting.
Will post the latest rev to the reflector as a word document with revision tracking when I get through the other feedback as well.
-Brandon
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Francoise Martinolle
Sent: Friday, August 26, 2011 5:25 PM
To: francoise martinolle
Cc: sv-ec@eda.org
Subject: [sv-ec] comments on 1356
Here some comments on the latest proposal
COMMENT #1
===========
Section 8.25
page 1:
I would recommend to reword the 1st paragraph to be more precise and more LRM language like.
I propose to change:
"SystemVerilog introduces a type of class called an interface class.
This is not to be confused with the
interface construct (see section 3.5 Interfaces). An interface class is a requirement to provide
implementations for a set of methods. The provided implementations shall satisfy the requirements of a
virtual method override (see 8.19). An interface class makes it unnecessary for related classes to share a
common abstract superclass or for that superclass to contain all method definitions needed by all subclasses.
This interface implementation allows classes to support common behaviors without sharing any
implementation."
TO:
"SystemVerilog defines a new type of class called an interface class. A regular (non interface) class can be declared as implementing an interface class. This creates a requirement for the non interface class to provide implementations for a set
of methods of the interface class as if the methods were virtual (see 8.19). An interface class makes it unnecessary for related classes to share a commont abstract superclass or for that superclass to contain all method declarations needed by all subclasses. An interface class allows classes to support common behaviours without sharing any implementation."
[Tipp, Brandon P] I made changes very similar to the above.
COMMENT #2
===========
Page 2:
typo:
cover groups should be covergroups
[Tipp, Brandon P] Fixed everywhere
COMMENT #3
===========
Change:
Constraint blocks, cover groups and nested classes (see 8.22) shall not be allowed in an interface class.
to:
Constraint blocks, cover groups and nested classes (see 8.22) are illegal in an interface class.
[Tipp, Brandon P] This can be fixed quickly, so I'm inclined to leave it alone until the meeting.
COMMENT #4
===========
Page 2 question about this sentence:
"An interface class can inherit from one or more interface classes through the extends keyword, meaning that it inherits all the
member types, pure virtual methods and parameters of the interface classes it extends, except for any member
types and parameters that it may hide."
I would add a reference to the section that talks about name conflict resolution.
[Tipp, Brandon P] I thought the 2nd paragraph might be a little early to try to introduce the nuances and details including name conflicts. However, if others agree, I can add "In the case of multiple inheritance, name conflicts may occur which must be resolved (see 8.25.6)."
COMMENT #5
===========
Page 2
"All pure virtual methods from an interface class shall have overridden implementations in order to be implemented by a non-abstract class."
The sentence above suggests that one can have an abstract class implementing an interface class but the abstract class is NOT
required to provide implementations of the virtual methods of the interface class. Is that right? Is the scenario of an abstract class implementing an interface class legal?
[Tipp, Brandon P] Yes, and abstract class may implement an interface class. After that sentence was added, a requirement was added that the abstract class must at least cut-and-paste the method prototypes of the interface class, but implementations are not required to be provided until you get down to the non-abstract class. FYI... the sentence above was stolen and slightly modified from the LRM section regarding abstract classes being extended by a non-abstract class.
COMMENT #6
===========
Page 2
"A subclass implicitly implements all of the interface classes implemented by its superclass. An implementation may be
provided by an inherited virtual method implementation in a superclass of the implementing class."
Why saying "implicitly"? I think it would be better to say " shall implement" and drop implicitly. The sentences after
define that the subclass may inherit or define the implemention from its superclass.
[Tipp, Brandon P] Perhaps the intent here would be clearer if I made "implements" bold courier. The sentence is trying to say that this example of polymorphism is legal.
interface class A;
endlcass
class B implements A;
endclass
class C extends B;
endclass
A A_i;
C C_i;
C = new();
A = C;
An handle of type C can be assigned to a handle of type A because class C implicitly implements A from the fact that it extends B which implements A. I think that the wording "shall implement" implies a requirement that class C must explicitly "implements" A in the above example.
COMMENT # 7
===========
Page 2
Missing "the"
An implementation may be
provided by an inherited virtual method implementation in a superclass of the implementing class. A
virtual class shall define or inherit a pure virtual method prototype or virtual method
implementation for each pure virtual method prototype in each implemented interface class. The
keyword virtual shall be used unless the virtual method is inherited.
[Tipp, Brandon P] Fixed
COMMENT # 8
===========
Page 3
You probably should add the superscript 7 and add the footnote to the syntax (no need to have it in green)
[Tipp, Brandon P] I'm not entirely sure why Tom did this. Possibly to not have to worry about keeping the numbering consistent. I'm not going to change it right now.
COMMENT # 9
===========
Page 4
An interface class may extend, but not implement, one or more interface classes; meaning that the sub
interface class aggregates interface class members and can add additional member types, pure virtual method
prototypes and parameters.
The term "aggregates" is awkward here. I suggests to say "includes all". I think "can" needs to be changed to "may" I would suggest the following wording:
meaning that the sub interface class includes all interface class members and may add additional member types, pure virtual method prototypes and parameters.
[Tipp, Brandon P] Changing "aggregates interface class members" to "inherits multiple interface class' members". Changed can to may.
COMMENT # 10
===========
Page 5
I suggest to change "the definition" to "the implementation" in the sentence below:
Ex tClass fulfills its requirement to implement IntfClass by providing an implementation of funcExt
and by inheriting the definition of funcBase from BaseClass.
[Tipp, Brandon P] Changed to "an implementation".
COMMENT # 11
===========
Page 5
I think that "cannot provide" is not right. It should have been "does not provide". Since this is legal to have a non-virtual method in a
class which does not implements an interface class.
" An inherited non-virtual method cannot provide an implementation for a method of an implemented interface class. "
[Tipp, Brandon P] Fixed
COMMENT # 12
===========
Page 5
The following sentence is awkward.
" Parameters and typedefs within an interface class are inherited into the scope of extending interface classes,
but are not inherited into the scope of implementing classes. "
I suggest to reword as:
Parameters and typedefs within an interface class are inherited by the derived interface classes,
but are not inherited by the implementing classes.
[Tipp, Brandon P] I definitely want to keep the contrast between "extending" and "implementing" here, but "into the scope of" is awkward. I'm changing it to "Parameters and typedefs within an interface class are inherited by extending interface classes but are not inherited by implementing interface classes."
COMMENT # 13
===========
Page 5
I would replace this
Example 1: type definitions and parameters are inherited by extends
with:
Example 1: type and parameter declarations are inherited by extends
[Tipp, Brandon P] I could agree to changing "type definitions" to "typedefs". I don't think that it makes sense to say that the "declarations" are inherited. I'm going to leave this one and the next open right now.
COMMENT # 14
===========
Page 5
SImilarly:
Change:
Example 2: type definition and parameters are not inherited by implements and must be specified with scope
to:
Example 2: type and parameter declarations are not inherited by implements and must be specified with scope operator
COMMENT # 15
===========
Page 6
The usage of "parameter" means both value and type parameters, in the sentence below, the intent of using parameter
should be limited to "type parameter".
Change parameter to type parameter in the sentence below.
Also change" demonstrate" to "illustrate"
8.25.4 Type Usage Restrictions
A class shall not implement a type parameter, nor shall an interface class extend a type parameter; even if the type parameter
or defined type resolves to an interface class.The following examples illustrate this restriction and are
illegal:
[Tipp, Brandon P] Fixed (although I would argue that you can't implement or extend a value parameter in any context already)
COMMENT # 16
===========
Page 6
This is probably beyond the scope of this mantis item, but I would like to see the restriction for fwd typedef
to also apply to non interface classes.
Are we allowing forward typedefs of interface classes? If we are not, they it would be better to state that forward typedefs of interface classes are illegal. It seems that it is the net effect of the restrictions described below.
typedef class INTF;
interface class INTF;
endclass
[Tipp, Brandon P] I don't think that the above should be illegal. A class cannot implement a forward typedef'd interface class, but it might be necessary for a class to contain a forward typedef'd interface class.
I would also rephrase the paragraph:
A forward typedef shall not be used as an implemented or extended interface class. All interface class
definitions shall be declared before the implementation or extension of the interface class is reached.
TO:
A class cannot implement a forward typedef for an interface class. An interface class cannot extend from a forward typedef of an interface class.
[Tipp, Brandon P] Fixed (I never liked the original wording here.) However, I would like to keep open the possibility of changing "forward typedef" to "typedef class".
I would also change:
" All interface class definitions shall be declared before the implementation or extension of the interface class is reached. "
TO:
" All interface class declarations shall appear before the ir use as implementation or extensio n . "
[Tipp, Brandon P] I don't like the words "appear" or "use". Changing to "An interface class shall be declared before it is implemented or extended."
COMMENT # 17
===========
Page 6
It would be nice if the partial example would refer to the section containing the complete example for the class
declarations.
[Tipp, Brandon P] Adding the following:
class Fifo #(type T = int) implements PutImp#(T), GetImp#(T);
endclass
Also filling in all the paratmer types with int, just to be sure.
COMMENT # 18
===========
Page 7, section 8.25.6
The keywords interface class should be bold and in courier font:
interface class extends
[Tipp, Brandon P] Fixed
COMMENT # 19
===========
Page 7, section 8.25.6.1
typo:
implemenationof
[Tipp, Brandon P] Fixed
COMMENT # 20
===========
Page 7, section 8.25.6.1
I would change parameter to "arguments" and "will" to "shall"
If the argument and/or return types of the methods involved in a method name collision are of incompatible
[Tipp, Brandon P] Fixed, but see below...
types, an error shall occur. Example:
What is an incompatible type? Should we refer to virtual method prototype matching instead (manits item 2950)
[Tipp, Brandon P] There was another e-mail which commented on this same section. I'll need to make a relatively large change to the wording here. The point is that it is possible to have a name collision between two methods with prototypes which are so different that it is impossible to provide a single implementation which follows the virtual method override rules for both.
COMMENT # 21
===========
Page 8, section 8.25.6.2
Change definition to declaration
8.25.6.2 Parameter and type declaration Inheritance Conflicts and Resolution
Interface classes may inherit parameters and type declarations from multiple interface classes. A name
collision will occur if the same name is inherited from different interface classes. The subclass shall provide
parameter and/or type declarations which override all such name collisions.
...
PutGetIntf overrides T with a type declaration to resolve the conflict.
[Tipp, Brandon P] Fixed by Changing "type definition" to "typedef declaration"
COMMENT # 22
===========
Page 8, section 8.25.6.3
I think that the sentence below should not use "shall". I think it meant to say that diamond inheritance never causes a name
conflict.
I would rewrite:
In no case shall diamond inheritance cause a conflict requiring resolution.
as:
Diamond inheritance never causes a name conflict.
[Tipp, Brandon P] Fixed
COMMENT # 22
===========
Page 8, section 8.25.6.3
Please remove the extra semi colon in the class declaration
interface class IntfExt3 extends IntfExt1, IntfExt2;
;
endclass
[Tipp, Brandon P] Fixed
COMMENT # 23
===========
Page 9
A given parameterization of a class is called a specialization. We should use the proper terms in the paragraphs below:
Change
Each unique parameterization of a parameterized interface class is a unique interface class. Therefore, it shall
be a conflict if a parameterized interface class is inherited from different paths using any different parameter
values. For example:
to:
Each parameterization of a parameterized interface class is a interface class specialization . Therefore, it shall
be a conflict if a parameterized interface class is inherited from different paths using different parameter izations . For example
And change:
In the above example, there are two different parameterizations of the interface class IntfBase. Each of
these parameterized versions of IntfBase is a unique class, therefore there is no diamond inheritance and
there is a conflict of the parameter T which must be resolved.
to:
In the above example, there are two different parameterizations of the interface class IntfBase. Each of
these parameteriz ations of IntfBase is a unique class specialization , therefore there is no diamond inheritance and
there is a conflict of the type parameter T which must be resolved.
[Tipp, Brandon P] Fixed
COMMENT # 24
===========
Page 9
I would reword this:
It shall be illegal to use an interface class to partially define a virtual class without fulfilling the interface
class prototype requirements. In other words, when an interface class is implemented, the virtual class must
do one of the following:
* Fully define the method as per the prototype requirement
* Declare the method as pure and re-declare the method prototype.
As:
It shall be illegal to use an interface class to partially define a virtual class without fulfilling the interface
class prototype requirements. In other words, when an interface class is implemented by a virtual class , the virtual class must
do one of the following:
* Provide the method implementation for the declared method prototype
* Re-declare the method prototype with the pure qualifier.
[Tipp, Brandon P] Changed, but a little differently.
Added "for each interface class method prototype"
"Provide a method implementation"
COMMENT # 25
===========
Page 10
I would change subroutine to method in the following sentence.
Method declarations within Interface Classes may have default argument values. The default expression shall
be constant and is evaluated in the scope containing the subroutine declaration.
Do we mean "shall be a constant expression" instead of "shall be constant"
[Tipp, Brandon P] I'm not sure. Some mention of the definition of "a constant expression" has come up on the reflector recently. This can be fixed easily after discussion..
COMMENT # 26
===========
Page 10 section 8.25.9
change cover group to covergroup, instead of "shall not be allowed" use " shall be illegal"
or say: Constraint blocks and coverroups shall not be declared in interface classes.
8.25.9 Constraint Blocks, Cover Groups, and Randomization
Constraint blocks and cover groups shall not be allowed in interface classes.
[Tipp, Brandon P] changed "allowed" to "declared"
COMMENT # 27
===========
Page 10 section 8.25.9 The whole paragraph needs rewording,
While inline constraints shall also be
legal, interface classes cannot contain any data meaning that inline constraints will only be able to express
conditions related to state variables and are therefore of very limited utility. Use of rand_mode and
constraint_mode shall not be legal as a consequence of the name resolution rules and the fact that interface
classes are not permitted to contain data members.
Proposed change:
Inlined constraints for a randomize call of a interface class handle are of limited use since interface classes cannot contain any data member. rand_mode and constraint_mode calls are illegal for an interface class object.
[Tipp, Brandon P] See Gord's comments on this one. (I personally didn't see the point of much of the paragraph, since the limitations of randomize() on an interface class handle are obvious to me).
-- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Aug 29 11:23:22 2011
This archive was generated by hypermail 2.1.8 : Mon Aug 29 2011 - 11:23:26 PDT