Change as shown in red:
SystemVerilog 3.1 adds string, chandle and class
data types, and enhances the Verilog event
and SystemVerilog 3.0 enum
data types. SystemVerilog 3.1 also
extends the user defined types by providing support for object-oriented class.
Change as shown in red:
3.7 chandle data type
The chandle data type represents storage for pointers passed using DPI. The size of this type is platform dependent
and must be at least large enough to hold a pointer on the machine in which the
simulator is running. The syntax to declare a handle is as follows:
chandle variable_name ;
where variable_name is
a valid identifier. Handles shall always be initialized to the value null, which has a value of 0 on the C side, which represents a non-existent handle. chandles
are very restricted on their usage, with the only legal uses being as follows:
only
the following operators are valid on chandle variables:
equality
(==), inequality (!=) with another chandle or with null
case equality (===), case inequality with another chandle
or with null (same semantics as == and !=)
can be tested for a Boolean value that will
be 0 if the chandle
is null and 1 otherwise
only
the following assigments can be made to a handle
assignment
from another chandle
assigment to null
chandles can be inserted into associative arrays
(refer to section 4.9), but no guarantees will be made on relative ordering of
any two entries in such an associative array, even between successive runs of
the same simulation.
chandles can be used within a class
chandles may be passed as arguments to
functions or tasks
chandles can be returned from functions
The use of chandles is restricted
as follows:
ports
may not have the chandle data type
chandles may not be assigned to variables of
any other type
chandles
cannot be used:
in
any expression other than as permited above
as
a ports
in
sensitivity lists or event expressions
in
continuous assigments
in
structures or unions
in
packed arrays
Change 3rd paragraph as shown in red:
A singular type includes
packed arrays (and structures) and all other data types except unpacked
structures, unpacked arrays, and chandles
(used for the C interface).
Change 4th paragraph as shown in red:
If a variable or net is not of type
logic, then posedge and
negedge
refer to transitions from 0 and to 0 respectively. If the variable
or net is a packed array or structure, it is zero if all elements are 0. If the expression denotes a
clocking-domain input or inout (see section 13), the
event control operator uses the synchronous values, that is, the values sampled
by the clocking event. The expression may also
denote a clocking-domain name (with no edge qualifier) to be triggered by the
clocking event.
Change as shown in red:
SystemVerilog 3.1 adds
dynamic processes by enhancing the fork...join construct, in a way that is more natural to Verilog
users. SystemVerilog 3.1 also introduces dynamic process control constructs
that can terminate or wait for processes using their dynamic, parent-child
relationship. These are wait fork and disable
fork.
Change as shown in red:
SystemVerilog provides several
constructs that allow one process to terminate or wait for the completion of
other processes. The wait fork
construct waits for the completion of processes. The disable fork construct stops the
execution of processes. The $suspend_thread system task temporarily suspends a thread.
Change as shown in red:
In the example below the
function get_first spawns three versions of a function that will wait for
a particular device (1, 7, or 13). The function wait_device function waits for a particular device to become ready and then returns the
devices address. When the first device becomes available, the get_first function
will resume execution and proceed to kill the outstanding wait_device processes.
Remove this whole section.
Change, in Table 11-2, the header of the 3rd column from SV handle to SV chandle.
Change as shown in red:
An input skew of #0
forces a skew of zero. Inputs with
zero skew are sampled at the same time as their corresponding clocking event,
but to avoid races, they are sampled in the Observe
region. Likewise, outputs with zero skew are driven at the same time as
their specified clocking event, as nonblocking
assignments (in the NBA region). A detailed
explanation for this event ordering is covered in Section 15.7.
Change as shown in red:
Explicit synchronization is
done via the event control operator, @, operator,
which allows a process to wait for a particular signal value change, or a
clocking event (see section 13.9).
The syntax is for the synchronization
operator is given in Section 8.9.:
event_control ::=
@ event_identifier
| @ ( event_expression )
| @*
| @ (*)
event_expression ::=
expression [ iff expression ]
| hierarchical_identifier
[ iff expression ]
| [ edge ]
expression [ iff expression ]
| event_expression
or event_expression
| event_expression , event_expression
The expression used with the event control can denote clocking-domain
input (input or inout),
or a slice thereof. Slices can include dynamic indices, which are evaluated
once, when the @ expression executes.
Change as shown in red:
All clocking domain inputs
(input or inout) are sampled at the corresponding
clocking event. If the input skew is non-zero then the value sampled
corresponds to the signal value at the Postponed region
of the time step skew time-units prior to the clocking event (see figure
13-1 in section 13.3). If the input skew is zero then the value sampled
corresponds to the signal value in the Observe region.
Change as shown in red:
The syntax to specify a
synchronous drive is similar to an assignment:
[ ##
event_count ] clockvar_expression
<=
expression;
or
clockvar_expression <=
[ ##
event_count ] expression;
The clockvar_expression
is either or a bit-select,
slice, or the entire clocking domain output whose corresponding signal is to be
driven (concatenation is not allowed):
and
The event_count
is an integral expression that optionally specifies the number of clocking
events (i.e. cycles) that must pass before the statement executes. Specifying a
non-zero event_count blocks the current process until
the specified number of clocking events have elapsed otherwise the statement
executes at the current time. The event_count uses a syntax similar to the
cycle-delay operator (see section 13.10), however, the synchronous drive uses theclocking domain of the signal being driven and not the
default clocking.
and
Examples:
bus.data[3:0] <= 4h5;
// drive in current cycle
##1 bus.data <= 8hz; // wait 1 (bus)
cycle and then drive
##[2]; bus.data <= 2; // wait 2
default clocking cycles, then drive
bus.data <= ##2 r; // sample r, wait 2 (bus) cycles, the
drive
Move the entire Section 13.14.1 as new paragraphs in Section 13.14. This results in Section 13.14.2 becoming 13.14.1.
Replace the entire paragraph as shown in red:
Synchronous signal drives
are queued and processed as non-blocking assignments. at
the end of the verification phase, like nonblocking assignments, that is, they
are propagated in one fell swoop without process execution in between drives.
A key feature of inout
clocking domain variables and
synchronous drives is that a driven signal value does not change the clock domain input. This is
because reading the input always yields the last sampled value, and not the driven value. In this
respect, an inout clocking
domain variable resembles nonblocking assignments since reading the variable
immediately after it has been assigned will yield the previous value, not the
assigned value.
// bus.data
is a clock domain inout, y is a variable
if( bus.data ==
5 ) if( y == 5 )
bus.data = 0; y <= 0;
$display( bus.data ); $display( y ); // both display 5
Change as shown in red (Note that this will be the new 13.14.1 due to the change above):
When more than one synchronous
drive is applied to the same clocking domain output (or inout) at the same simulation time, the driven values are
checked for conflicts. When conflicting drives are detected a runtime error is
issued, and each conflicting bit is driven to X (or 0 for a 2-state port).
For
example:
clocking pe @(posedge clk);
output nibble; //
four bit output
endclocking
pe.nibble <=
4b0101;
pe.nibble <=
4b0011;
The driven value of nibble is 4b0xx1,
regardless of whether nibble is a reg
or a wire.
When the same variable is
an output from multiple clocking domains, the last drive determines the value
of the variable. This allows a single module to model multi-rate devices, such
as a DDR memory, using a different clocking domain to model each active edge. Naturally, clock-domain outputs driving a net (i.e., through
different ports) cause the net to be driven to its resolved signal value. For example:
reg j;
clocking pe @(posedge clk);
output j;
endclocking
clocking ne @(negedge
clk);
output j;
endclocking
The variable j is an output to two
clocking domains using different clocking events (posedge vs. negedge). When driven, the variable j will take on the
value most recently assigned by either clocking domain.
Clock-domain outputs driving a net (i.e.
through different ports) cause the net to be driven to its resolved signal
value. When a clock-domain output corresponds to a wire a driver for that wire
is created that is updated as if by a continuous assignment from a register
inside the clock-domain that is updated as a non-blocking assignment.
Change handle to chandle.