Gord,
Applied the second round of feedback to the proposal. See my notes below. I won't be able to work on this anymore so I'll send the latest version of the proposal to Brandon in word format so he can continue next week to make any further clarifications. Really appreciate your inputs here. I think we are getting close.
-Tom
For Question 8:
I think that I'd prefer something like:
It shall also be legal to cast from an object handle to an interface
class type handle if the actual object implements the interface
class type.
That is closer to the $cast wording and avoids a new term
"implemented object".
talsop> DONE. Changed to your wording.
For Question 9:
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. All parameters and typedefs within an interface class are implicitly static and can be accessed through the class scope resolution operator :: (see 8.22). It shall be illegal to access interface class parameters or localparams through an interface class select (a dotted reference).
talsop> I added your further clarification (highlighted)
For Questions 16-18:
In particular, yes, there would be an enforced "cut-and-paste"
type of prototype duplication with abstract classes implementing
interface classes. There were several people on the committee
that believed that such duplication is in fact good as it brings
the requirements "closer" to the implementing class hierarchy
and makes future obligations from the abstract class to its
descendents become clear and in one location rather than inferred
from the interface classes. If you disagree, we can discuss that
in the next meeting.
talsop> I don't disagree. Just wanted to make sure I understood the requirement. I have changed the example under "8.25.7 Partial Implementation" and added the following:
interface class IntfClass;
pure virtual function bit funcA();
pure virtual function bit funcB();
endclass
// Partial implementation of IntfClass
virtual class ClassA implements IntfClass;
virtual function bit funcA();
return (1);
endfunction
pure virtual function bit funcB();
endclass
// Complete implementation of IntfClass
class ClassB extends ClassA;
virtual function bit funcB();
return (1);
endfunction
endclass
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.
In the example above ClassA fully defines funcA, but re-declares the prototype funcB.
talsop> Let me know what you want to change WRT to wording to clarify or details things better. I thought about adding and illegal example. Is this all that we need to clarify in the proposal for 16-18?
One additional comment that you made was of concern:
if you wanted to explicitly override the base method to be virtual.
You can never change a base method to become virtual. Not with
regular inheritance (and I don't want that to be part of implements).
If an extended class overrides a non-virtual method in a base class
with a virtual prototype, that new virtual prototype *hides* the
base method, it does not coerce the base method into a becoming
virtual.
talsop> Thank you for this clarification. I didn't know this. Makes sense. So polymorphism only happens from the point in which virtual was introduced. If the implementations are using the non-virtual base method then it cannot be changed.
For Question 19:
8.25.9 Constraint Blocks, Cover Groups, and Randomization
Constraint blocks and cover groups shall not be allowed in interface classes.
A randomize method call shall be legal with interface class handles. 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.
For Question 20:
Change sub-clause 20.6.2 as follows:
FROM:
The $bits system function returns 0 when called with a dynamically sized expression that is currently
empty. It shall be an error to use the $bits system function directly with a dynamically sized data type
identifier.
TO:
The $bits system function returns 0 when called with a dynamically sized expression that is currently
empty. It shall be an error to:
* Use the $bits system function directly with a dynamically sized data type identifier.
* Use the $bits system function on an object of an interface class type (see section 8.25 Interface Classes)
For questions 21 and 22:
Change sub-clause 21.2.1.7 as follows:
A chandle, class handle, interface class handle, event, or virtual interface shall print its value in an implementation dependent format, except that a null handle value shall print the word null.
Change sub-clause 6.22.5 as follows:
6.22.5 Type incompatible
Type incompatible includes all the remaining nonequivalent types that have no defined implicit or explicit
casting rules. Class handles, interface class handles, and chandles are type incompatible with all other types.
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Thursday, August 04, 2011 7:32 AM
To: Alsop, Thomas R
Cc: SV_EC List
Subject: Re: {Disarmed} [sv-ec] Additional 1356 review (interface classes)
Tom, a few detailed comments on proposed changes below.
In terms of the 16-18 issues, I thought that my detailed
comments from the committee discussion addressed most of your
earlier questions.
In particular, yes, there would be an enforced "cut-and-paste"
type of prototype duplication with abstract classes implementing
interface classes. There were several people on the committee
that believed that such duplication is in fact good as it brings
the requirements "closer" to the implementing class hierarchy
and makes future obligations from the abstract class to its
descendents become clear and in one location rather than inferred
from the interface classes. If you disagree, we can discuss that
in the next meeting.
One additional comment that you made was of concern:
if you wanted to explicitly override the base method to be virtual.
You can never change a base method to become virtual. Not with
regular inheritance (and I don't want that to be part of implements).
If an extended class overrides a non-virtual method in a base class
with a virtual prototype, that new virtual prototype *hides* the
base method, it does not coerce the base method into a becoming
virtual.
Detailed comments on the rest:
On 8/3/2011 5:11 PM, Alsop, Thomas R wrote:
[...]
8) 8.25.4 What is a "prototype interface class handles"? More
generally, the entire sentence "It shall also be legal to
cast implemented objects onto their prototype interface class
handles" is not careful enough about object and type
distinction. See comment 8.
talsop> I think we meant to say this "It shall also be legal to cast implemented objects to a variable of an interface class type that the object implements"
talsop> So I updated with this change.
I think that I'd prefer something like:
It shall also be legal to cast from an object handle to an interface
class type handle if the actual object implements the interface
class type.
That is closer to the $cast wording and avoids a new term
"implemented object".
9) It is legal to access parameters in an interface class
as "IntfClass::param_name". Is it legal to have:
IntfClass ic = some_object;
int x = ic.param_name;
In other words, are static data members (such as parameters)
accessible as a select from a variable of an interface
class type?
Notes: While it is likely that there are no substantive issues
in allowing dotted parameter name references, it was the
committee consensus that we are likely better off to
make such references illegal for now in order to reduce
potential confusion for users. The "::" qualified reference
makes it more clear that this parameter is related to the
*type* of the reference, not to the object. Since
interface class variables cannot have other non-method dotted
refereces (since there are no other data members), it seems
more reasonable for the time-being to keep interface class
parameter references closely couple to the type and require
a "::" reference.
talsop> I thought we made this abundantly clear in 8.25.3, second sentence... "All parameters and typedefs within an interface class are implicitly static and can be accessed through the class scope resolution operator :: (see 8.22). " Perhaps we can clarify this further by saying "All parameters and typedefs within an interface class are implicitly static and can only be accessed through the class scope resolution operator :: (see 8.22). "
I'm fine with adding "only" but I'd prefer to make this
even stronger by adding the explicit restriction that:
It shall not be legal to access interface class parameters
or localparams through an interface class select (a
dotted reference).
[...]
> talsop> I added this under section 8.25.9 after changing the clause heading:
8.25.9 Constraint Blocks, Cover Groups, and Randomization
Constraint blocks and cover groups shall not be allowed in interface classes.
Randomization shall be legal on interface class handles, however the method will not address any data members of the interface class as the interface class has no data members.
talsop> Is this what is needed? Do we want to clarify when randomize would actually be applicable, like in implemented class object that are assigned to the handle?
How about something like the following:
A randomize method call shall be legal with interface class handles.
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.
20) What does $bits return for an interface class handle? How
does this relate to streaming operators? Can one stream
from/into an interface class handle? 11.4.14.1 needs to
define streaming behavior for interface class handles.
Notes: The current status of $bits and streaming for classes
is pretty bad already. There was at least weak
consensus that we should make these illegal in this
PAR for references through interface class variables.
Trying to define something rational here is likely
to require substantial work in the core existing
definitions.
We were out of time on this one so if anyone disagrees
with my understanding of the agreement, please say so.
talsop> Do I need to add a statement at the end of this clause declaring the use of $bits() on interface class handles illegal?
That would be my preference. If anyone else disagrees
I hope they speak up.
21) 21.2.1.7 should permit interface class handles as well.
talsop> So do we change this:
A chandle, class handle, event, or virtual interface shall print its value in an implementation dependent
format, except that a null handle value shall print the word null.
to this:
A chandle, class handle, interface class handle, event, or virtual interface shall print its value in an implementation dependent
format, except that a null handle value shall print the word null.
Yes.
22) 6.22.5 should include interface class
talsop> So do we change this:
6.22.5 Type incompatible
Type incompatible includes all the remaining nonequivalent types that have no defined implicit or explicit
casting rules. Class handles and chandles are type incompatible with all other types.
to this:
6.22.5 Type incompatible
Type incompatible includes all the remaining nonequivalent types that have no defined implicit or explicit
casting rules. Class handles, interface class handles, and chandles are type incompatible with all other types.
Yes.
Gord.
-- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com<mailto:gordonv@model.com> ________________________________ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Aug 4 17:54:53 2011
This archive was generated by hypermail 2.1.8 : Thu Aug 04 2011 - 17:54:57 PDT