SystemVerilog Constants

In previous post of this SystemVerilog Tutorial we talked about enumerated type in detail. Now we will look at the constants in SystemVerilog. There are several types of constants in systemVerilog. The classic Verilog way to create a constant is with a text macro. 

On the plus side, macros have global scope and can be used for bit field definitions and type definitions.

On the negative side, macros are global, so they can cause conflicts if you just need a local constant. 

Lastly, a macro requires the ` character so that it will be recognized and expanded.

In SystemVerilog, parameters can be declared at the $root level so they can be global. This approach can replace many Verilog macros that were just being used as constants. You can use a typedef to replace those large macros. The next choice is a parameter. A Verilog parameter was loosely typed and was limited in scope to a single module. Verilog-2001 added typed parameters, but the limited scope kept parameters from being widely used.

SystemVerilog allows you to declare constant identifiers. You can declare an identifier as constant by prefixing the usual identifier definition with the keyword const. At the time of defining a constant, the user needs to provide a value for the identifier. At any later stage in the code, a SystemVerilog compiler disallows any modification to the value bound to the identifier.

// Constant bit 
const bit [63:0] data_bus='hB6AB31E0;
// Constant int bus width
const int bus_width = 8;
// Constant String VLSI Encyclopedia
const string name = "VLSI Encyclopedia";
// Constant method
function int count (const ref bytes[]);

In addition to a normal identifier declaration, the const modifier can be used to declare function/task arguments as constants. An argument to a function may be of either a pass-by-value or pass-by-reference type. When using pass-by-value semantics, the const modifier has the usual meaning; the locally bound parameter's value can not be changed in the given function.

When using pass-by-reference semantic (as is the case with const ref arrays), the SV compiler ensures that the referenced value is not modified by the code in the function. Normally arrays (even dynamic ones) are passed by value. 

Since arrays could be very big, SystemVerilog allows you to declare an array parameter type as a reference, by prefixing the function parameter with keyword ref. But this introduces the danger of a user inadvertently altering the arrays (actually it's elements) value. By prefix const to the reference array parameter, you can avoid this danger. The compiler would ensure that inside the function, a user can not alter the arrays value.

Note :

Constant identifiers in SystemVerilog are not compile time constants. As a result it is not allowed to use a constant as a range parameter for an array. This is much unlike C++, wherein constants are compile time constants. As an alternative, SystemVerilog users are allowed to use parameters (aka parameterized functions and classes) as range specifiers for an array.

Previous : SystemVerilog Enumerated Types
Next : SystemVerilog Strings

SystemVerilog Enumerated Types

An enumeration creates a strong variable type that is limited to a set of specified names such as the instruction opcodes or state machine values. Using these names, such as ADD, MOVE, or STATE, makes your code easier to write and maintain than using literals such as 8’h01.

The simplest enumerated type declaration contains a list of constant names and one or more variables. This creates an anonymous enumerated type.

Example 1:

A simple enumerated type

enum {RED, BLUE, GREEN} color;

You usually want to create a named enumerated type to easily declare multiple variables, especially if these are used as routine arguments or module ports. You first create the enumerated type, and then the variables of this type.

You can get the string representation of an enumerated variable with the function name().

Example 2: Enumerated Type

module enum_method; 
  typedef enum {RED,BLUE,GREEN} colour; 
  colour c; 
  initial begin 
    c = c.first(); 
    $display(" %s ",c.name); 
    c = c.next(); 
    $display(" %s ",c.name); 
    c = c.last(); 
    $display(" %s ",c.name); 
    c = c.prev(); 
    $display(" %s ",c.name); 
  end 
endmodule 

Output :

RED

BLUE

GREEN

BLUE

Run Simulation

Defining enumerated values

The actual values default to integers starting at 0 and then increase. You can choose your own enumerated values. The below line uses the default value of 0 for RED, then 2 for BLUE, and 3 for GREEN.

typedef enum {RED, BLUE=2, GREEN} color_e;

Enumerated constants, such as RED above, follow the same scoping rules as variables. Consequently, if you use the same name in several enumerated types (such as RED in different state machines), they have to be declared in different scopes such as modules, program blocks, routines, or classes.

Enumerated types are stored as int unless you specify otherwise. Be careful when assigning values to enumerated constants, as the default value of an int is 0. In Example 3 below, position is initialized to 0, which is not a legal ordinal_e variable. This behavior is not a tool bug – it is

how the language is specified. So always specify an enumerated constant with the value of 0, just to catch this error.

Example 3 Incorrectly specifying enumerated values

typedef enum {FIRST=1, SECOND, THIRD} ordinal_e;
ordinal_e position;

Example 4 Correctly specifying enumerated values

typedef enum {ERR_O=0, FIRST=1, SECOND, THIRD} ordinal_e;
ordinal_e position;

Enumerated methods : Methods associated with enumerated types

SystemVerilog also includes a set of specialized methods0 associated with enumerated types to enable iterating over the values of enumerated. 

The first() method returns the value of the first member of the enumeration. 

The last() method returns the value of the last member of the enumeration. 

The next() method returns the Nth next enumeration value (default is the next one) starting from the current value of the given variable. 

The prev() method returns the Nth previous enumeration value (default is the previous one) starting from the current value of the given variable. 

The name() method returns the string representation of the given enumeration value. If the given value is not a member of the enumeration, the name() method returns the empty string.

The functions next() and prev() wrap around when they reach the beginning or end of the enumeration.

Note that there is no easy way to write a for loop that steps through all members of an enumerated type if you use an enumerated loop variable. You get the starting member with first() and the next() member with next(). The problem is creating a comparison for the final iteration through the loop. If you use the test current!=current.last, the loop ends before using the last value. If you use current<=current.last, you get an infinite loop, as next never gives you a value that is greater than the final value. You can use a do...while loop to step through all the values.

Converting to and from enumerated types

The default type for an enumerated type is int (2-state). You can take the value of an enumerated variable and put it in an integer or int with a simple assignment. But SystemVerilog does not let you store a 4-state integer in an enum without explicitly changing the type. SystemVerilog requires you to explicitly cast the value to make you realize that you could be writing an out-of-bounds value.

Example 5:  Assignments between integers and enumerated types

module enum_method; 
  typedef enum {RED, BLUE, GREEN} COLOR_E;
  COLOR_E color, c2;
  integer c;
  initial begin
    c = color; // Convert from enum to integer
    c++; // Increment integer
    if (!$cast(color, c)) begin // Cast integer back to enum
      $display("Cast failed for c=%0d", c);
    end
    $display("Color is %0d & %0s", color, color.name);
    c2 = COLOR_E'(c); // No type checking done
  end

endmodule 

Output : 
Color is 1 & BLUE

Run Simulation

In above Example 5, $cast tried to assign from the right value to the left. If the assignment succeeds, $cast returns 1. If the assignment fails because of an out-of-bounds value, no assignment is made and the function returns 0. If you use $cast as a task and the operation fails, SystemVerilog prints an error.

You can also cast the value using the type’(val) as shown above, but this does not do any type checking, so the result may be out of bounds. You should not use this style.

Previous : SystemVerilog Built-in Data Types
Next : SystemVerilog Constants

SystemVerilog Built-In Data Types

Verilog-1995 has two basic data types: variables (reg) and nets, that hold four-state values: 0, 1, Z, and X. RTL code uses variables to store combinational and sequential values. Variables can be unsigned single or multi-bit (reg [7:0] m), signed 32-bit variables (integer), unsigned 64-bit variables (time), and floating point numbers (real). Variables can be grouped together into arrays that have a fixed size. All storage is static, meaning that all variables are alive for the entire simulation and routines cannot use a stack to hold arguments and local values. A net is used to connect parts of a design such as gate primitives and module instances. Nets come in many flavors, but most designers use scalar and vector wires to connect together the ports of design blocks.

SystemVerilog adds many new data types to help both hardware designers and verification engineers.

The logic type

The one thing in Verilog that always leaves new users scratching their heads is the difference between a reg and a wire. When driving a port, which should you use? How about when you are connecting blocks? System-Verilog improves the classic reg data type so that it can be driven by continuous assignments, gates and modules, in addition to being a variable. It is given the new name logic so that it does not look like a register declaration. The one limitation is that a logic variable cannot be driven by multiple drivers such as when you are modeling a bidirectional bus. In this case, the variable needs to be a net-type such as wire.

Example: shows the SystemVerilog logic type.
module logic_data_type(input logic rst_h);
  parameter CYCLE = 20;
  logic q, q_l, d, clk, rst_l;

initial begin
  clk <= 0; // Procedural assignment
  forever #(CYCLE/2) clk = ~clk;
end

assign rst_l = ~rst_h; // Continuous assignment
not n1(q_l, q); // q_l is driven by gate
my_dff d1(q, d, clk, rst_l); // d is driven by module

endmodule

Two-state types

SystemVerilog introduces several two-state data types to improve simulator performance and reduce memory usage, over four-state types. The simplest type is the bit, which is always unsigned. There are four signed types: byte, shortint, int, and longint.

shortint i                // 2-state, 16-bit signed
int i                        // 2-state, 32-bit signed
longint i                 // 2-state, 64-bit signed
byte b                    // 2-state, 8-bit signed
bit b;                      // 2-state, single-bit
bit [31:0] b32;       // 2-state, 32-bit unsigned

Tips:
You might be tempted to use types such as byte to replace more verbose declarations such as logic [7:0]. Hardware designers should be careful as these new types are signed variables, so a byte variable can only count up to 127, not Chapter 2: Data Types 29 the 255 you may expect. (It has the range -128 to +127.) You could use byte unsigned, but that is more verbose than just bit [7:0]. Signed variables may cause unexpected results with randomization, as discussed in Chapter 6. Be careful connecting two-state variables to the design under test, especially its outputs. If the hardware tries to drive an X or Z, these values are converted to a two-state value, and your testbench code may never know. Don’t try to remember if they are converted to 0 or 1; instead, always check for propagation of unknown values. Use the $isunknown operator that returns 1 if any bit of the expression is X or Z.

Example: Checking for four-state values

if ($isunknown(iport)
$display("@%0d: 4-state value detected on input port",
$time, iport);

Next : SystemVerilog Enumerated Types

Button-Size Wearable Computer by Intel

It just got a lot easier to build wearable gadgets that aren’t so bulky or awkward.

Intel CEO Brian Krzanich showed off a minuscule computer, dubbed Curie, during a keynote speech at the International Consumer Electronics Show in Las Vegas on Tuesday. Krzanich plucked a button off his blazer before explaining that it contained a Curie demo module.

Curie is a sure sign that hardware makers are eager to build wearable devices of all kinds. It also points to the unwelcome size of many existing smart watches and smart glasses.

Intel’s new device will include a Bluetooth low-energy radio, motion sensors, and components designed to rapidly and precisely differentiate between different types of physical activity. Krzanich said Curie will run “for extended periods of time” on a coin-size battery and would be available in the second half of the year.

Curie appeared much smaller than a postage-stamp-size computer, called Edison, that Krzanich showed off at last year’s CES.

The world’s largest chip maker evidently sees wearables as one of the most important categories in consumer electronics. It’s a belief held by a lot of other companies at CES, where gadgets meant to be worn on the body or clipped to clothing were all over the show floor this year (see “CES 2015: Wearables Everywhere”).

To make it clear that Curie is already functional, the company built a simple step-tracking smartphone app to go with the module Krzanich had on him; at one point he pulled the phone out of his pocket, and its display indicated he’d taken 1,788 steps during the keynote.

As part of its wearables push, Intel has partnered with a number of companies in the fashion and accessories businesses, including Luxottica Group, which is the world’s largest eyeglass maker with brands such as Ray-Ban and Oakley. Krzanich said Luxottica will use Curie to make “truly consumer-friendly” smart glasses—a notoriously tricky thing to do, in part because of the size of components needed to make them work.

Oakley CEO Colin Baden joined Krzanich on stage to talk about wearables, which Oakley has built in the form of devices like ski goggles that include a head-up display. When you put a wearable device on your face, Baden said, it becomes part of your personality. “It’s important the form factor compress so the electronic component of it doesn’t become burdensome,” he said.

OSVVM – Thinking beyond constrained random

What is OSVVM?

OSVVM stands for "Open Source VHDL Verification Methodology". OSVVM is a set of VHDL packages, initially developed by Jim Lewis of Synthworks. OSVVM helps you adopt modern constrained random verification techniques using VHDL.

Constraint random verification approach :

In testbenches, we generally want one each of a large set of test cases (transactions and/or sequences). Uniform randomization does not generate one each. Instead it has a significant amount of repetition. In general, uniform randomization takes O(N*LogN) randomizations to generate N unique test cases. As a result, it repeats Log N test cases. Even for small numbers such 64 test cases, constrained random will generate more than 4X more test cases than needed - actual results will vary with the randomization seed. Constrained random comes with this fundamental problem. Randomization is intended to be uniform over time. However constraint random verification has a number of benefits:

• If you simulate longer, you generate more test vectors.
• You may find bugs due to unexpected combinations of inputs, or extreme input values. With directed testing, it is all too easy just to test what you expect to happen, rather than trying to test what you don't expect to happen.
• Once you have developed an automated test, it can still be used for directed testing.

Still what we need is an approach that only requires O(N) randomizations to generate N unique test cases. Generally these approaches are referred to as being Intelligent Testbenches. Indeed there are some tools out there that handle this. However, when we use a tool based approach we end up with a vendor specific solution. This removes one of the major benefits of a programming language based approach - encounter a issue (pricing or functionality) with one vendor and you can easily switch to another.

What we really need is a methodology for Intelligent Testbenches that is based on a standard language and works on numerous vendor tools.

OSVVM :

VHDL's Open Source VHDL Verification Methodology (OSVVM). OSVVM's methodology leverages the functional coverage you must write when you are using any randomization based approach. Intelligent Coverage™, the main randomization methodology for OSVVM, randomly selects a hole in the coverage and passes this to the stimulus generation process. The stimulus generation process uses this information, perhaps refines it using any methodology (directed, algorithmic, constrained random or file based), and then generates one or more transactions to accomplish generate the item that needs covered.

OSVVM can be used in your current VHDL testbench, in part or in whole as needed.  It allows mixing of our signature “Intelligent Coverage” methodology with other verification methodologies, such as directed, algorithmic, file based, and constrained random. Don’t throw out your existing VHDL testbench or testbench models, re-use them.

There is no new language to learn. There are no specialized “OO” approaches – just plain old VHDL entities and architectures. As a result, it is accessible to RTL designers. In fact, it is our goal to make our testbenches readable to verification (testbench), design (RTL), system, and software engineers.

OSVVM works with any VHDL testbench and is particularly effective when coupled with a transaction based testbench. For us, VHDL and OSVVM are the step beyond constrained random and SystemVerilog. Maybe it is time we update VHDL's acronym to mean Verification and Hardware Design Language.

Intelligent Coverage™ Methodology :

Verification starts with a test plan that identifies all items in a design that need to be tested.  OSVVM, like other advanced methodologies, uses functional coverage to observe conditions on interfaces and within the design to validate that the items identified in the test plan have occurred.  As such, functional coverage helps determine when testing is done.

Unlike other methodologies, in OSVVM’s Intelligent Coverage methodology,  functional coverage is the prime directive – it is where we start our process.  Intelligent Coverage is done in the following steps.

• Write a high fidelity functional coverage (FC) model
• Randomly select a hole in the functional coverage 
• Refine the initial randomization with sequential code 
• Apply the refined sequence (one or more transactions) 
• Observe Coverage

The key point of Intelligent Coverage is that we randomize using the functional coverage. Then, if necessary, we refine the randomization using sequential code and any sequence generation method, including constrained random, algorithmic, directed, or file reading methods.

OSVVM is a Low Cost Solution :

The packages are free. OSVVM works on regular VHDL simulators (such as Mentor’s ModelSim and Aldec’s Active-HDL) without additional licenses. The only special language support required is VHDL-2002 protected types and VHDL-2008 type integer_vector (for older simulators, we have a work around for this).

To learn more about OSVVM, see:

• The OSVVM Community Forum
• SynthWorks' OSVVM Blog
• OSVVM Webinar on July 18th (US time zones)
• OSVVM Webinar on July 18th (European time zones)
• The packages are available here:  OSVVM.zip

OSVVM is an open source VHDL library that is free to use (no license fees) and works with any simulator that supports VHDL-2008 (or VHDL-2002 with a little work).
What is currently in the OSVVM library is only the beginning. Over time, I will be releasing our generic scoreboard package, memory modeling package, and others.

Intel funding to develop printer for blind

A 13-year-old Indian-origin boy has received a huge investment from Intel for developing a low-cost printer for the blind, making him the youngest tech entrepreneur funded by a venture capital firm.

Shubham Banerjee, CEO of the Braille printer maker Braigo Labs, had closed an early round funding with Intel Capital, the company's venture capital arm, last month to develop a prototype of low-cost Braille printer.

But to attend the event, Banerjee had to take the day off from middle school. That’s because he’s just 13 years old — making him, quite possibly, the youngest recipient of venture capital in Silicon Valley history. (He’s definitely the youngest to receive an investment from Intel Capital.)

“I would like all of us to get together and help the visually impaired, because people have been taking advantage of them for a long time,” Banerjee said. “So I would like that to stop.”

By “taking advantage,” Banerjee is referring to the high price of Braille printers today, usually above $2,000. By contrast, Braigo Labs plans to bring its printer to market for less than $500.

Banerjee has invented a new technology that will facilitate this price cut. Patent applications are still pending, so he wouldn’t divulge any of the details. But the technology could also be used to create a dynamic Braille display — something that shows one line of text at a time by pushing small, physical pixels up and down, and which currently costs $6,500, according to Braigo advisor Henry Wedler, who is blind.

Banerjee also figures that volume production will help keep the price low. Currently, Braille printers cost so much because the demand is low, so current manufacturers need to set a high price in order to recoup their costs.

“The truth is that demand is low in the U.S.,” Banerjee told me. But, he added, if you brought the price low enough there would be huge demand outside the U.S.

Banerjee built the version version of his Lego Braille printer for a science fair. He didn’t know anything about Braille beforehand. In fact, he’d asked his parents how blind people read, he said onstage, and they were too busy to answer. “Go Google it,” he said they told him, so he did.

After learning about Braille, he came up with the idea to make a Braille printer. He showed it at his school’s science fair, then later entered it into the Synopsys Science & Technology Championship, where he won first prize, which included a big trophy and a $500 check.

After that, he started getting a lot of attention on his Facebook page. People kept asking him if they could buy one, he said, which led to the idea of creating a company.

Lego was just for the first prototype, by the way: Future versions will be made with more traditional materials.

So how did Intel come to invest in such a young inventor? His father, Niloy, works for Intel — but that’s not exactly how it happened, according to Niloy.

After working with the beta version of Intel Edison (the chip company’s tiny embeddable microprocessor) at a summer camp, Banerjee’s project came to the attention of Intel, which invited him to show off his printer at the Intel Developer Forum. After appearing at IDF, Intel Capital came calling.

Young Banerjee seems composed in front of crowds, which should serve him well. (That’s not surprising, given that Braigo’s website touts coverage on everything from BoingBoing and SlashGear to CNN and NPR.) When asked onstage, in front of 1,000 entrepreneurs, investors, and Intel employees, how he knew that the printer worked even though he doesn’t read Braille, Banerjee answered immediately, “I Googled it.” The crowd laughed.

“I’m happy that I live in Silicon Valley,” Banerjee said. “So many smart people.”

UVM - Driver

The driver is a block whose role is to interact with the DUT. The driver pulls transactions from the sequencer and sends them repetitively to the signal-level interface. This interaction will be observed and evaluated by another block, the monitor, and as a result, the driver’s functionality should only be limited to send the necessary data to the DUT.

In order to interact with our adder, the driver will execute the following operations: control the en_i signal, send the transactions pulled from the sequencer to the DUT inputs and wait for the adder to finish the operation.

So, we are going to follow these steps:

1. Derive the driver class from the uvm_driver base class
2. Connect the driver to the signal interface
3. Get the item data from the sequencer, drive it to the interface and wait for the DUT execution
4. Add UVM macros

In Code 5.1 you can find the base code pattern which is going to be used in our driver.

class simpleadder_driver extends uvm_driver#(simpleadder_transaction);
     `uvm_component_utils(simpleadder_driver)   //Interface declaration
     protected virtual simpleadder_if vif;   function new(string name, uvm_component parent);
          super.new(name, parent);
     endfunction: new   function void build_phase(uvm_phase phase);
          super.build_phase(phase);
     void'(uvm_resource_db#(virtual simpleadder_if)::read_by_name(.scope("ifs"), .name("simpleadder_if"), .val(vif)));
     endfunction: build_phase   task run_phase(uvm_phase phase);
          //Our code here
     endtask: run_phase
endclass: simpleadder_driver

Code 5.1 – Driver component – simpleadder_driver.sv

The code might look complex already but what it’s represented it’s the usual code patterns from UVM. We are going to focus mainly on the run_phase() task which is where the behaviour of the driver will be stated. But before that, a simple explanation of the existing lines will be given:

• Line 1 derives a class named simpleadder_driver from the UVM class uvm_driver. The #(simpleadder_transaction) is a SystemVerilog parameter and it represents the data type that it will be retrieved from the sequencer.

• Line 2 refers to the UVM utilities macro explained on chapter 2.

• Lines 7 to 9 are the class constructor.

• Line 11 starts the build phase of the class, this phase is executed before the run phase.

• Line 13 gets the interface from the factory database. This is the same interface we instantiated earlier in the top block.

• Line 16 is the run phase, where the code of the driver will be executed.

Now that the driver class was explained, you might be wondering: “What exactly should I write in the run phase?”

Consulting the state machine from the chapter 1, we can see that the DUT waits for the signal en_i to be triggered before listening to the ina and inb inputs, so we need to emulate the states 0 and 1. Although we don’t intend to sample  the output of the DUT with the driver, we still need to respect it, which means, before we send another sequence, we need to wait for the DUT to output the result.

To sum up, in the run phase the following actions must be taken into account:

1. 
   
   Get a sequence item
   
   
2. 
   
   Control the en_i signal
   
   
3. 
   
   Drive the sequence item to the bus
   
   
4. 
   
   Wait a few cycles for a possible DUT response and tell the sequencer to send the next sequence item

The driver will end its operation the moment the sequencer stops sending transactions. This is done automatically by the UVM API, so the designer doesn’t need to to worry with this kind of details.

In order to write the driver, it’s easier to implement the code directly as a normal testbench and observe its behaviour through waveforms. As a result, in the next subchapter (chapter 5.1), the driver will first be implemented as a normal testbench and then we will reuse the code to implement the run phase (chapter 5.2).

Chapter 5.1 – Creating the driver as a normal testbench

For our normal testbench we will use regular Verilog code. We will need two things: generate the clock and idesginate an end for the simulation. A simulation of 30 clock cycles was defined for this testbench.

The code is represented in Code 5.2.

//Generates clock
initial begin
     #20;
    forever #20 clk = ! clk;
end   //Stops testbench after 30 clock cyles
always@(posedge clk)
begin
    counter_finish = counter_finish + 1;   if(counter_finish == 30) $finish;
end

Code 5.2 – Clock generation for the normal testbench

The behaviour of the driver follows in Code 5.3.

//Driver
always@(posedge clk)
begin
    //State 0: Drives the signal en_o
    if(counter_drv==0)
    begin
        en_i = 1'b1;
        state_drv = 1;
    end   if(counter_drv==1)
    begin
        en_i = 1'b0;
    end   case(state_drv)
        //State 1: Transmits the two inputs ina and inb
        1: begin
            ina = tx_ina[1];
            inb = tx_inb[1];   tx_ina = tx_ina << 1;
            tx_inb = tx_inb << 1;   counter_drv = counter_drv + 1;
            if(counter_drv==2) state_drv = 2;
        end   //State 2: Waits for the DUT to respond
        2: begin
            ina = 1'b0;
            inb = 1'b0;
            counter_drv = counter_drv + 1;   //After the supposed response, the TB starts over
            if(counter_drv==6)
            begin
                counter_drv = 0;
                state_drv = 0;   //Restores the values of ina and inb
                //to send again to the DUT
                tx_ina <= 2'b11;
                tx_inb = 2'b10;
            end
        end
    endcase
end

Code 5.3 – Part of the driver

For this testbench, we are sending the values of tx_ina and  tx_inb to the DUT, they are defined in the beginning of the testbench (you can see the complete code attached to this guide).

We are sending the same value multiple times to see how the driver behaves by sending consecutive transactions.

After the execution of the Makefile, a file named simpleadder.dump will be created by VCS. To see the waveforms of the simulation, we just need to open it with DVE.

The waveform for the driver is represented on Figure 5.1.

It’s possible to see that the driver is working as expected: it drives the signal en_i on and off as well the DUT inputs ina and inb and it waits for a response of the DUT before sending the transaction again.

Chapter 5.2 – Implementing the UVM driver

After we have verified that our driver behaves as expected, we are ready to move the code into the run phase as seen in Code 5.4.

virtual task drive();
    simpleadder_transaction sa_tx;
    integer counter = 0, state = 0;
    vif.sig_ina = 0'b0;
    vif.sig_inb = 0'b0;
    vif.sig_en_i = 1'b0;   forever begin
        if(counter==0) begin
            //Gets a transaction from the sequencer and
            //stores it in the variable 'sa_tx'
            seq_item_port.get_next_item(sa_tx);
        end   @(posedge vif.sig_clock)
        begin
            if(counter==0) begin
                vif.sig_en_i = 1'b1;
                state = 1;
            end   if(counter==1) begin
                vif.sig_en_i = 1'b0;
            end   case(state)
                1: begin
                    vif.sig_ina = sa_tx.ina[1];
                    vif.sig_inb = sa_tx.inb[1];   sa_tx.ina = sa_tx.ina << 1;
                    sa_tx.inb = sa_tx.inb << 1;   counter = counter + 1;
                    if(counter==2) state = 2;
                end   2: begin
                    vif.sig_ina = 1'b0;
                    vif.sig_inb = 1'b0;
                    counter = counter + 1;   if(counter==6) begin
                        counter = 0;
                        state = 0;   //Informs the sequencer that the
                        //current operation with
                        //the transaction was finished
                        seq_item_port.item_done();
                    end
                end
            endcase
        end
    end
endtask: drive

Code 5.4 - Task for the run_phase()

The ports of the DUT are acessed through the virtual interface with vif.<signal> as can be seen in lines 4 to 6.

Lines 12 and 50 use a special variable from UVM, the seq_item_port to communicate with the sequencer. The driver calls the method get_next_item() to get a new transaction and once the operation is finished with the current transaction, it calls the method item_done(). If the driver calls get_next_item() but the sequencer doesn’t have any transactions left to transmit, the current task returns.

This variable is actually a UVM port and it connects to the export from the sequencer named seq_item_export. The connection is made by an upper class, in our case, the agent. Ports and exports are going to be further explained in chapter 6.0.1.

This concludes our driver, the full code for the driver can be found in the filesimpleadder_driver.sv. In Figure 5.2, the state of the verification environment with the driver can be seen.

Figure 5.2 – State of the verification environment with the driver