Section 13.1

LRM-237 238

Changes:

High-level and easy-to-use synchronization and communication mechanisms are essential to control the kinds of interactions that occur between dynamic processes used to model a complex system or a highly reactive testbench test-bench. Verilog provides basic synchronization mechanisms (i.e., -> and @), but they are all limited to static objects and are adequate for synchronization at the hardware level, but fall short of the needs of a highly dynamic, reactive testbench test-bench. At the system level, an essential limitation of Verilog is its inability to create dynamic events and communication channels, which match the capability to create dynamic processes.

LRM-1

Changes:

Lastly, SystemVerilog adds the wait_var mechanism that can be used to synchronize processes using dynamic data.

Section 13.2

LRM-233

Changes:

Conceptually, a semaphore is a bucket. When a semaphore is allocated, a bucket that contains a fixed number of keys is created. Processes using semaphores must first procure a key from the bucket before they can continue to execute. If a specific process requires a key, only a fixed number of occurrences of that process can be in progress simultaneously. All others must wait until a sufficient number of keys is returned to the bucket. Semaphores are typically used for mutual exclusion, access control to shared resources, and for basic synchronization.

 

An example of creating a semaphore is:

 

semaphore  smTx;

 

Semaphore is a built-in class that provides the following methods:

LRM-151

Changes:

— Try to obtain one or more keys a key without blocking: try_get()

Section 13.2.1

LRM-239

Changes:

The syntax for semaphore new() is:

 

function new(int keyCount key_count = 0 );

 

The keyCount key_count specifies the number of keys initially allocated to the semaphore bucket. The number of keys in the bucket can increase beyond keyCount key_count when more keys are put into the semaphore than are removed. The default value for key_count is 0.

Section 13.3

LRM-234

Changes:

Conceptually, mailboxes behave like real mailboxes. When a letter is delivered and put into the mailbox, one can retrieve the letter (and any data stored within). However, if the letter has not been delivered when one checks the mailbox, one must choose whether to wait for the letter or retrieve the letter on subsequent trips to the mailbox. Similarly, SystemVerilog’s mailboxes provide processes to transfer and retrieve data in a controlled manner. Mailboxes are created as having either a bounded or unbounded queue size. A bounded mailbox becomes full when it contains the bounded number of messages. A process that attempts to place a message into a full mailbox will be suspended until enough room becomes available in the mailbox queue. Unbounded mailboxes never suspend a thread in a send operation.

 

An example of creating a mailbox is:

 

mailbox  mbxRcv;

 

Mailbox is a built-in class that provides the following methods:

Section 13.3.3

LRM-133

Changes:

The message is any singular (non-unpacked array) expression, including object handles.

Section 13.3.4

LRM-133

Changes:

The message is any singular (non-unpacked array) expression, including object handles.

Section 13.3.5

LRM-134

Changes:

The message can be any singular expression, and it must be a valid left-hand side expression l-value.

Section 13.3.5

LRM-134

Changes:

The message can be any singular expression, and it must be a valid left-hand side expression l-value.

Section 13.3.6

LRM-134

Changes:

The message can be any singular expression, and it must be a valid left-hand side expression l-value.

Section 13.3.7

LRM-134

Changes:

The message can be any singular expression, and it must be a valid left-hand side expression l-value.

Section 13.4

LRM-86

Changes:

Where dynamic_type represents a special type-less that enables run-time type-checking (the default).

Section 13.8

LRM-1

Changes:

Delete entire section.