UVM Driver and Sequencer Handshaking

In UVM, there is a mechanism to be followed when we want to send the transactions from the sequencer to the Driver in order to provide stimulus to the DUT.
The transfer of request and response sequence items between sequences and their target driver is facilitated by a TLM communication mechanism implemented in the sequencer.

Sending a sequence_item to a driver:

To send a sequence_item to a driver there are four steps that need to occur:

Step 1 - Creation
The sequence_item is derived from uvm_object and should be created via the factory:
Using the factory creation method allows the sequence_item to be overridden with a sequence_item of a derived type if required.

Step 2 - Ready - start_item()
The start_item() call is made, passing the sequence_item handle as an argument. This call blocks until the sequencer grants the sequence and the sequence_item access to the driver.

Step 3 - Set
The sequence_item is prepared for use, usually through randomization, but it may also be initialised by setting properties directly.

Step 4 - Go - finish_item()
The finish_item() call is made, which blocks until the driver has completed its side of the transfer protocol for the item. No simulation time should be consumed between start_item() and finish_item().

Step 5 - Response - get_response()
This step is optional, and is only used if the driver sends a response to indicate to indicate that it has completed transaction associated with the sequence_item. The get_response() call blocks until a response item is available from the sequencers response FIFO.

Late Randomization

In the sequence_item flow above, steps 2 and 3 could be done in any order. However, leaving the randomization of the sequence_item until just before the finish_item() method call has the potential to allow the sequence_item to be randomized according to conditions true at the time of generation. This is sometimes referred to as late randomization.
The alternative approach is to generate the sequence_item before the start_item() call, in this case the item is generated before it is necessarily clearhow it is going to be used.
 

In previous generation verification methodologies, such as Specman and the AVM, generation was done at the beginning of the simulation and a stream of pre-prepared sequence_items was sent across to the driver. With late randomization, sequence_items are generated just in time and on demand.

Driver side Operation:

Multiple APIs used by driver code to interact with the sequencer. First go through these APIs,

get_next_item()
This method blocks until a REQ sequence_item is available in the sequencers request FIFO and then returns with a pointer to the REQ object.
The get_next_item() call implements half of the driver-sequencer protocol handshake, and it must be followed by an item_done() call which completes the handshake. Making another get_next_item() call before issuing an item_done() call will result in a protocol error and driver-sequencer deadlock.

try_next_item()
This is a non-blocking variant of the get_next_item() method. It will return a null pointer if there is no REQ sequence_item available in the sequencers request FIFO. However, if there is a REQ sequence_item available it will complete the first half of the driver-sequencer handshake and must be followed by an item_done() call to complete the handshake.

item_done()
The non-blocking item_done() method completes the driver-sequencer handshake and it should be called after a get_next_item() or a successful try_next_item() call.

If it is passed no argument or a null pointer it will complete the handshake without placing anything in the sequencer's response FIFO. If it is passed a pointer to a RSP sequence_item as an argument, then that pointer will be placed in the sequencer's response FIFO.

The get_next_item() method initiate the sequencer arbitration process, which results in a sequence_item being returned from the active sequence which has selected. This means that the driver is effectively pulling sequence_items from the active sequences as it needs them.

When the handle to a sequence_item is passed as an argument to
the finish_item() method the drivers get_next_item() method call completes with a pointer to the same sequence_item. When the driver makes any changes to the sequence_item it is really updating the object inside the sequence. The drivers call to item_done() unblocks the finish_item() call in the sequence and then the sequence can access the fields in the
sequence_item, including those which the driver may have updated as part of the response side of the pin level transaction.

The connection between a driver and a sequencer is typically made in the connect_phase() method of an agent. With the standard UVM driver and sequencer base classes, the TLM connection between a driver and sequencer is a one to one connection - multiple drivers are not connected to a sequencer, nor are multiple sequencers connected to a driver.


uvm_sequence and uvm_driver have predefined sequence_item for both request and response.
So, you can directly use predefined variables for sequence_item,

Difference between wire, reg and logic in SystemVerilog

Wire:-

1.     Wires are used for connecting different elements
2.     They can be treated as a physical wire
3.     They can be read or assigned
4.     No values get stored in them
5.     They need to be driven by either continuous assign statement or from a port of a module

Reg:-

1.     Contrary to their name, regs doesn't necessarily corresponds to physical registers
2.     They represents data storage elements in Verilog/SystemVerilog
3.     They retain their value till next value is assigned to them (not through assign statement)
4.     They can be synthesized to FF, latch or computational circuit (They might not be synthesizable !!!)

Wires and Regs are present from Verilog time-frame. SystemVerilog added a new data type called logic to them. So the next question is what is this logic data type and how it is different from our good old wire/reg.

Logic:-

    As we have seen, reg data type is bit mis-leading in Verilog. SystemVerilog's logic data type addition is to remove the above confusion. The idea behind having a new data type called logic which at least doesn't give an impression that it is hardware synthesizable

    Logic data type doesn't permit multiple driver. It has a last assignment wins behavior in case of multiple assignment (which implies it has no hardware equivalence). Reg/Wire data type give X if multiple driver try to drive them with different value. Logic data type simply assign the last assignment value.

The next difference between reg/wire and logic is that logic can be both driven by assign block, output of a port and inside a procedural block like this

Barrier in UVM and Usage of uvm_barrier

uvm_barrier can be used to force a set of independently executing processes (e.g. virtual sequences) to wait until they have all reached a particular point.
The barrier provides a flexible synchronization mechanism between the processes: its threshold can be programmed to set the number of processes that must reach the synchronization point before the barrier is 'lifted'.

A barrier is like a semaphore in reverse. It simply blocks until a threshold number of requests.

The uvm_barrier class provides a multi-process synchronization mechanism.  It enables a set of processes to block until the desired number of processes get to the synchronization point, at which time all of the processes are released.

APIs of uvm_barrier class

1. wait_for : Waits for enough processes to reach the barrier before continuing. 
2. reset : Resets the barrier. This sets the waiter count back to zero. 
3. set_auto_reset : Determines if the barrier should reset itself after the threshold is reached. Default is on 
4. set_threshold : Sets the process threshold. 
5. get_threshold : Gets the current threshold setting for the barrier. 
6. get_num_waiters : Returns the number of processes currently waiting at the barrier. 
7. cancel : Decrements the waiter count by one. This is used when a process that is waiting on the barrier is killed or activated by some other means.

Consider following examples,

Difference between setenv and set in csh

To findout difference between set and setenv first look at below example.

So, from above example, it can be conclude that set is setting a variable ,which has scope only to that terminal. Variable using set has no scope in scripts running from that terminal.

setenv has scope in terminal as well as in running scripts from that terminal. But any variable with same name is setting using set command and setenv command then set command is overwrite the value of that variable for terminal, but from scripts only variables using setenv can be access.

So, set has visibility only to terminal and can't be access from scripts.
setenv has visibility to both to terminal  and scripts, but set has more priority than setenv for terminal.

How to Format Source Code in Blogger

I had a problem embedding code snippets and inline code examples to my blog. I surfed and found a simple solution as below:

• Using https://gist.github.com/

1. Create an account on github.com
2. After logging in to github, click on Gist
3. Add a file-name with an extension (extension will be used to add syntax highlighting)
4. Add your code snippet which need to be added to your blog post
5. Click “Create Public Gist” button at the button
6. Click on the “embed” link and copy the script generated
   
   
   This is all from Gist side. Now to Blogger,
   
   
   
   1. Paste the script where you need to add the code snippet
   2. Make sure to select the option “Interpret typed HTML” under Post Options -> Compose Settings

•  Using http://hilite.me/

• Using http://codeformatter.blogspot.in/2009/06/about-code-formatter.html