Section 11.1

 

Replace the first two sentences of the first paragraph with:

SystemVerilog introduces the object-oriented class framework.

 

Section 11.3

 

Replace the first sentence of the first paragraph with:

A class is a type that includes data and subroutines that operate on that data.

 

Section 11.4

 

Add the following to the end of the section:

 

Accessing non-static members or virtual methods via a null object handle is illegal. The result of an illegal access via a null object is indeterminate, and implementations may issue an error.

 

System Verilog objects are referenced using an "object handle". There are some differences between a C pointer and a System Verilog object handle. C pointers give programmers a lot of latitude in how a pointer may be used. The rules governing the usage of System Verilog object handles are much more restrictive. A C pointer may be incremented for example, but a System Verilog object handle may not. In addition to object handles Section 3.7 introduces the handle data type for use with the DirectC interface.

 

C pointer 

SV object handle   

SV Handle

Operation

Allowed   

Not allowed 

Not allowed

Arithmetic operations (such as incrementing)

Allowed   

Not allowed 

Not allowed

For arbitrary data types

Error     

Not allowed 

Not allowed

Dereference when null

Allowed   

Limited     

Not allowed

Casting

Allowed   

Not allowed 

Not allowed

Assignment to an address of a data type

No        

Yes         

Yes

Unreferenced objects are garbage collected

Undefined 

null        

null

Default value

(C++)     

Allowed     

Not allowed

For classes

 

 

Section 11.7

 

In example make changes in blue:

 

function new(int cmd = IDLE, bit[12:0] adrs = 0, int cmd_time );

command = cmd;

address = adrs;

time_requested = cmd_time;

endfunction

 

Section 11.8

 

In the last line make the changes in blue:

 

c = $fgetc( p.fileId );

 

Section 11.9

 

Change the last two lines of the example (make bold) as shown in blue:

 

endfunction

endclass

 

Section 11.10

 

Change section as shown in blue:

 

11.10 Assignment, renaming and copying

 

Change the sentence before the fourth example, the fourth example and the following sentence as shown in blue:

 

If, however, the example above is re-written as shown below, it will make a copy of p1:

 

Packet p1;

Packet p2;

p1 = new;

p2 = new p1;

 

The last statement has new executing a second time, thus creating a new object p2 whose properties are copied from p1, known as a shallow copy.

 

Change task definition in example as shown in blue:

 

integer function test;

 

and change endtask as shown in blue:

 

endfunction

 

Section 11.14

 

Change the first sentence of the first paragraph as shown in blue:

 

It is always legal to assign a subclass variable to a variable of a class higher in the inheritance tree.

 

Change syntax as shown in blue:

 

task $cast( singular dest_handle, singular source_handle );

or

function int $cast( singular dest_handle, singular source_handle );

 

In last sentence of the last paragraph make change shown in blue:

 

if it is not, $cast()generates a runtime error occurs and leaves the destination variable unchanged.

 

In the last sentence of the last paragraph make change shown in blue:

 

Otherwise, no runtime error occurs, the destination variable is left unchanged, and the function returns 0.

 

Section 11.16:

 

Delete the following:

 

In summary:

— Wherever possible, use local members. Hide members that the outside world doesn’t need to know about.

— Use protected members if the outside world doesn’t have a need to know, but subclasses might.

— Public access should only be allowed when it is absolutely necessary, and the access should be limited as much as possible. Generally, don’t provide direct access to properties but rather provide access methods— provide, for example, only read access if a variable should never be written. This provides an extra level of protection and preserves flexibility for future changes.

 

Change second sentence of the first paragraph from:

However, for most data (and subroutines) one wants to hide them from the outside world.

to:

Often, it is desirable to restrict access to properties and methods from outside the class by hiding their names.

 

Section 11.18:

 

Change the second sentence of the next to the last paragraph as shown in blue:

 

In general, if an abstract class has any virtual methods, all of the methods must be overridden (and provided with a method body) for the subclass to be instantiated. If any virtual methods have no implementation, the subclass needs to be abstract.

 

Change the second sentence of the second paragraph as shown in blue:

 

Since the base class is not intended to be instantiated, it can be made abstract by specifying the class to be virtual.

 

In the last paragraph delete the last sentence (the following one):

However, if the subclass overrides the virtual method, then the new method must exactly match the super-class’s prototype.

 

Section 11.20:

 

Replace the last sentence:

The first lines of each part of the method declaration are nearly identical, except for the attributes and class-reference

fields.

with:

The out of block method declaration must match the prototype declaration exactly; the only syntactical difference is that the method name is preceded by the class name and scope operator (::).

 

Delete the first paragraph.

 

Change the first sentence of the second paragraph as shown in blue:

 

It is convenient to be able to move method definitions out of the body of the class declaration.

 

Section 11.22:

 

Fix font on the first line of the example as shown in blue:

typedef class C2; // C2 is declared to be of type class

class C1

C2 c;

endclass

class C2

C1 c;

endclass

 

Section  11.23:

 

Delete first sentence of first paragraph.

 

Change all SystemVerilog 3.1 reference to SystemVerilog.

 

Section 11.24:

 

Change the third sentence as shown in blue:

 

When an object is no longer needed,