Next: Built-in methods in Semaphore

Starting the execution of a block of code while an event triggers is a basic building block in any hardware description language. Verilog provides two such mechanisms: @ and ->. These two operators are adequate for synchronizing hardware related events (and subsequently for writing synthesizable code). But their limitations become apparent while writing complex testbenches, such as a reactive testbench. The main drawback of these two operators is that they can only work on and can create static events (i.e. events that are known at compile or 'elaboration' time).

SystemVerilog offers a set of capabilities that allows you to do just that. This article in two parts describes these capabilities and teaches you how to create inter-process synchronization and communication dynamically (i.e. during run-time), and how to reclaim the resource once their utilities are over. In the first part, we will learn about how to use Semaphores and Mailboxes to synchronize the allocation of a resource (typically a task or function). In the next part, we will explore more on event type that already exists in Verilog but has been enhanced in SystemVerilog.

Imagine a hotel swimming pool that any valid guest can use. However, to comply with the local city law, the hotel management can allow only upto a fixed maximum number of simultaneous users. To restrict the use to this certain maximum number of users at any given time, the hotel management has installed a key system. Every guest who wants to use the pool needs to come to the front desk and take a key to open the gate to the swimming pool. Only a fixed number of keys are issued at a time, as dictated by the city law. When a guest is done, she returns the key to the front desk and that key is then issued to another guest.

A semaphore is equivalent of a key (or a set of keys) in the above example when a process tries to access a shared resource (swimming pool, as in our example). By enforcing a common set of rules to access a resource, a semaphore acts as a common gateway for all the processes that want that resource. This is how it works. A semaphore is first associated with a resource that needs to be protected. Whenever a process wants to access this resource, it seeks a key from the semaphore. (It is possible that to access a resource, a process may need more than one key. In such case, the process will ask for as many keys as it needs). Depending on how many keys have been already alloted to other similar processes, if there is a free key available to the semaphore, it will now be alloted to the current process. When this process is done with using the resource, it will give back the key to the semaphore and that key may be alloted to other processes who are waiting for a key.

Syntactically, semaphore is a built-in class that allows only certain pre-defined operations on the keys by external processes. Just as any other class, a semaphore should be declared before its use. A semaphore declaration is shown below.

semaphore sema4_proc1;

Next: Built-in methods in Semaphore