The behavior of a system can be written as an assertion that should be true at all times. Hence assertions are used to validate the behavior of a system defined as properties, and can also be used in functional coverage.

What are properties of a design ?

If a property of the design that is being checked for by an assertion does not behave in the expected way, the assertion fails. For example, assume the design requests for grant and expects to receive an ack within the next four cycles. But if the design gets an ack on the fifth cycle, the property that an ack should be returned within 4 clocks is violated and the assertion fails.

If a property of the design that is being checked for by an assertion is forbidden from happening, the assertion fails. For example, assume a small processor decodes instructions read from memory, encounters an unknown instruction and results in a fatal error. If such a scenario is never expected from the design, the property of the design that only valid instructions can be read from memory is violated and the assertion fails.

As evident from the two examples above, properties of a given design is checked for by writing SystemVerilog assertions.

Why do we need assertions ?

An assertion is nothing but a more concise representation of a functional checker. The functionality represented by an assertion can also be written as a SystemVerilog task or checker that involves more line of code. Some disadvantages of doing so are listed below:

• SystemVerilog is verbose and difficult to maintain and scale code with the number of properties
• Being a procedural language, it is difficult to write checkers that involve many parallel events in the same period of time

  
  
// A property written in Verilog/SystemVerilog
always @ (posedge clk) begin
	if (!(a && b))
		$display ("Assertion failed");
end

  

SystemVerilog Assertions is a declarative language used to specify temporal conditions, and is very concise and easier to maintain.

  
  
// The property above written in SystemVerilog Assertions syntax
assert property(@(posedge clk) a && b);

  

Types of Assertion Statements

An assertion statement can be of the following types:

Building Blocks of Assertions

Sequence

A sequence of multiple logical events typically form the functionality of any design. These events may span across multiple clocks or exist for just a single clock cycle. To keep things simple, smaller events can be depicted using simple assertions which can then be used to build more complex behavior patterns.

  
  
// Sequence syntax
sequence <name_of_sequence>
  <test expression>
endsequence

// Assert the sequence
assert property (<name_of_sequence>);

  

Property

These events can be represented as a sequence and a number of sequences can be combined to create more complex sequences or properties.

It is necessary to include a clocking event inside a sequence or property in order to assert it.

  
  
// Property syntax
property <name_of_property>
  <test expression> or
  <sequence expressions>
endproperty

// Assert the property
assert property (<name_of_property>);

  

There are two kinds of assertions - Immediate and Concurrent.

Immediate Assertion

Immediate assertions are executed like a statement in a procedural block and follow simulation event semantics. These are used to verify an immediate property during simulation.

  
  
	always @ (<some_event>) begin
		...
		// This is an immediate assertion executed only
		// at this point in the execution flow
		$assert(!fifo_empty);      // Assert that fifo is not empty at this point
		...
	end

  

Concurrent Assertions

Concurrent assertions are based on clock semantics and use sampled values of their expressions. Circuit behavior is described using SystemVerilog properties that gets evaluated everytime on the given clock and a failure in simulation indicates that the described functional behavior got violated.

  
  

// Define a property to specify that an ack should be 
// returned for every grant within 1:4 clocks
property p_ack;
	@(posedge clk) gnt ##[1:4] ack;
endproperty

assert property(p_ack);    // Assert the given property is true always

  

Steps to create assertions

Following are the steps to create assertions:

• Step 1: Create boolean expressions
• Step 2: Create sequence expressions
• Step 3: Create property
• Step 4: Assert property

Example

The first sequence s_ab validates that b is high the next clock when a is high, and the second sequence s_cd validates that d is high 2 clocks after c is found high. The property asserts that the second sequence is on the next cycle after the first sequence.

  
  
module tb;
  bit a, b, c, d;
  bit clk;
  
  always #10 clk = ~clk;
  
  initial begin
    for (int i = 0; i < 20; i++) begin
      {a, b, c, d} = $random;
      $display("%0t a=%0d b=%0d c=%0d d=%0d", $time, a, b, c, d);
      @(posedge clk);
    end
    #10 $finish;
  end
  
  sequence s_ab;
    a ##1 b;
  endsequence
  
  sequence s_cd;
    c ##2 d;
  endsequence
  
  property p_expr;
    @(posedge clk) s_ab ##1 s_cd;
  endproperty
  
  assert property (p_expr);
endmodule

  

Note that there are some violations for the property that is asserted using assert statement.

Compiler version P-2019.06-1; Runtime version P-2019.06-1;  Jan  8 05:02 2020
Warning : License for product VCSRuntime_Net(725) will expire within 10 days, on: 17-jan-2020.

If you would like to temporarily disable this message, set 
 the VCS_LIC_EXPIRE_WARNING environment variable to the number of days
before expiration that you want this message to start (the minimum is 0).
0 a=0 b=1 c=0 d=0
10 a=0 b=0 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 10ns failed at 10ns
	Offending 'a'
30 a=1 b=0 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 30ns failed at 30ns
	Offending 'a'
50 a=0 b=0 c=1 d=1
70 a=1 b=1 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 70ns failed at 70ns
	Offending 'a'
"testbench.sv", 28: tb.unnamed$$_3: started at 50ns failed at 70ns
	Offending 'b'
90 a=1 b=1 c=0 d=1
110 a=0 b=1 c=0 d=1
130 a=0 b=0 c=1 d=0
"testbench.sv", 28: tb.unnamed$$_3: started at 130ns failed at 130ns
	Offending 'a'
"testbench.sv", 28: tb.unnamed$$_3: started at 90ns failed at 130ns
	Offending 'c'
150 a=0 b=0 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 150ns failed at 150ns
	Offending 'a'
170 a=1 b=1 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 170ns failed at 170ns
	Offending 'a'
190 a=0 b=1 c=1 d=0
210 a=1 b=1 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 210ns failed at 210ns
	Offending 'a'
230 a=1 b=1 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 190ns failed at 230ns
	Offending 'c'
250 a=1 b=1 c=0 d=0
270 a=1 b=0 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 230ns failed at 270ns
	Offending 'c'
290 a=0 b=1 c=1 d=0
"testbench.sv", 28: tb.unnamed$$_3: started at 270ns failed at 290ns
	Offending 'b'
"testbench.sv", 28: tb.unnamed$$_3: started at 250ns failed at 290ns
	Offending 'c'
310 a=0 b=1 c=0 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 310ns failed at 310ns
	Offending 'a'
330 a=1 b=0 c=1 d=0
"testbench.sv", 28: tb.unnamed$$_3: started at 330ns failed at 330ns
	Offending 'a'
"testbench.sv", 28: tb.unnamed$$_3: started at 290ns failed at 330ns
	Offending 'c'
350 a=0 b=1 c=0 d=1
370 a=0 b=1 c=1 d=1
"testbench.sv", 28: tb.unnamed$$_3: started at 370ns failed at 370ns
	Offending 'a'
"testbench.sv", 28: tb.unnamed$$_3: started at 390ns failed at 390ns
	Offending 'a'
$finish called from file "testbench.sv", line 13.
$finish at simulation time                  400
           V C S   S i m u l a t i o n   R e p o r t 

This session is a real example of how design and verification happens in the real industry. We'll go through the design specification, write a test plan that details how the design will be tested, develop a UVM testbench structure and verify the design.

Design

This is a simple pattern detector written in Verilog to identify a pattern in a stream of input values. On every clock, there is a new input to the design and when it matches the pattern '1011', the output out will be set to 1. For this purpose, the design is implemented as a state machine which moves through different stages as it progresses through pattern identification sequence.

Read more: UVM Verification Testbench Example

Here is an example of how a SystemVerilog testbench can be constructed to verify functionality of a simple adder. Remember that the goal here is to develop a modular and scalable testbench architecture with all the standard verification components in a testbench.

You can also write Verilog code for testing such simple circuits, but bigger and more complex designs typically require a scalable testbench architecture and this is an example of how to build a scalable testbench. Different designs require different driver, monitor and scoreboard implementation that depends on design specifics.

Design

  
  
// An adder is combinational logic and does not
// have a clock

module my_adder (adder_if _if);
  always_comb begin
    if (_if.rstn) begin
      _if.sum <= 0;
      _if.carry <= 0;
    end else begin
      {_if.carry, _if.sum} <= _if.a + _if.b;
    end
  end
endmodule

  

Transaction Object

  
  
// To verify that the adder adds, we also need to check that it 
// does not add when rstn is 0, and hence rstn should also be 
// randomized along with a and b.
class Packet;
  rand bit 		rstn;
  rand bit[7:0] a;
  rand bit[7:0] b;
  bit [7:0] 	sum;
  bit 			carry;
  
  // Print contents of the data packet
  function void print(string tag="");
    $display ("T=%0t %s a=0x%0h b=0x%0h sum=0x%0h carry=0x%0h", $time, tag, a, b, sum, carry);
  endfunction
  
  // This is a utility function to allow copying contents in 
  // one Packet variable to another.
  function void copy(Packet tmp);
    this.a = tmp.a;
    this.b = tmp.b;
    this.rstn = tmp.rstn;
    this.sum = tmp.sum;
    this.carry = tmp.carry;
  endfunction
endclass

  

Driver

  
  
class driver;
  virtual adder_if m_adder_vif;
  virtual clk_if  m_clk_vif;
  event drv_done;
  mailbox drv_mbx;
  
  task run();
    $display ("T=%0t [Driver] starting ...", $time);
    
    // Try to get a new transaction every time and then assign 
    // packet contents to the interface. But do this only if the 
    // design is ready to accept new transactions
    forever begin
      Packet item;
      
      $display ("T=%0t [Driver] waiting for item ...", $time);
      drv_mbx.get(item);
      @ (posedge m_clk_vif.tb_clk);
	  item.print("Driver");
      m_adder_vif.rstn <= item.rstn;
      m_adder_vif.a <= item.a;
      m_adder_vif.b <= item.b; ->drv_done;
    end   
  endtask
endclass

  

Monitor

  
  
// The monitor has a virtual interface handle with which it can monitor
// the events happening on the interface. It sees new transactions and then
// captures information into a packet and sends it to the scoreboard
// using another mailbox.
class monitor;
  virtual adder_if 	m_adder_vif;
  virtual clk_if 	m_clk_vif;
  
  mailbox scb_mbx; 		// Mailbox connected to scoreboard
  
  task run();
    $display ("T=%0t [Monitor] starting ...", $time);
    
    // Check forever at every clock edge to see if there is a 
    // valid transaction and if yes, capture info into a class
    // object and send it to the scoreboard when the transaction 
    // is over.
    forever begin
	  Packet m_pkt = new();
      @(posedge m_clk_vif.tb_clk);
      #1;
        m_pkt.a 	= m_adder_vif.a;
        m_pkt.b 	= m_adder_vif.b;
      	m_pkt.rstn 	= m_adder_vif.rstn;
        m_pkt.sum 	= m_adder_vif.sum;
        m_pkt.carry = m_adder_vif.carry;
        m_pkt.print("Monitor");
      scb_mbx.put(m_pkt);
    end
  endtask
endclass

  

Scoreboard

  
  
// The scoreboard is responsible to check data integrity. Since the design
// simple adds inputs to give sum and carry, scoreboard helps to check if the
// output has changed for given set of inputs based on expected logic
class scoreboard;
  mailbox scb_mbx;
  
  task run();
    forever begin
      Packet item, ref_item;
      scb_mbx.get(item);
      item.print("Scoreboard");
      
      // Copy contents from received packet into a new packet so
      // just to get a and b.
      ref_item = new();
      ref_item.copy(item);
      
      // Let us calculate the expected values in carry and sum
      if (ref_item.rstn) 
      	{ref_item.carry, ref_item.sum} = ref_item.a + ref_item.b;
      else
      {ref_item.carry, ref_item.sum} = 0;
      
      // Now, carry and sum outputs in the reference variable can be compared
      // with those in the received packet
      if (ref_item.carry != item.carry) begin
        $display("[%0t] Scoreboard Error! Carry mismatch ref_item=0x%0h item=0x%0h", $time, ref_item.carry, item.carry);
      end else begin
        $display("[%0t] Scoreboard Pass! Carry match ref_item=0x%0h item=0x%0h", $time, ref_item.carry, item.carry);
      end
      
      if (ref_item.sum != item.sum) begin
        $display("[%0t] Scoreboard Error! Sum mismatch ref_item=0x%0h item=0x%0h", $time, ref_item.sum, item.sum);
      end else begin
        $display("[%0t] Scoreboard Pass! Sum match ref_item=0x%0h item=0x%0h", $time, ref_item.sum, item.sum);
      end
    end
  endtask
endclass

  

Generator

  
  
// Sometimes we simply need to generate N random transactions to random
// locations so a generator would be useful to do just that. In this case
// loop determines how many transactions need to be sent
class generator;
  int 	loop = 10;
  event drv_done;
  mailbox drv_mbx;
  
  task run();
    for (int i = 0; i < loop; i++) begin
      Packet item = new;
      item.randomize();
      $display ("T=%0t [Generator] Loop:%0d/%0d create next item", $time, i+1, loop);
      drv_mbx.put(item);
      $display ("T=%0t [Generator] Wait for driver to be done", $time);
      @(drv_done);
    end
  endtask
endclass

  

Environment

  
  
// Lets say that the environment class was already there, and generator is 
// a new component that needs to be included in the ENV. 
class env;
  generator 		g0; 			// Generate transactions
  driver 			d0; 			// Driver to design
  monitor 			m0; 			// Monitor from design
  scoreboard 		s0; 			// Scoreboard connected to monitor
  mailbox 			scb_mbx; 		// Top level mailbox for SCB <-> MON 
  virtual adder_if 	m_adder_vif; 	// Virtual interface handle
  virtual clk_if 	m_clk_vif; 		// TB clk
  
  event drv_done;
  mailbox drv_mbx;
  
  function new();
    d0 = new;
    m0 = new;
    s0 = new;
    scb_mbx = new();
    g0 = new;
    drv_mbx = new;
  endfunction
  
  virtual task run();
    // Connect virtual interface handles
    d0.m_adder_vif = m_adder_vif;
    m0.m_adder_vif = m_adder_vif;
    d0.m_clk_vif = m_clk_vif;
    m0.m_clk_vif = m_clk_vif;
    
    // Connect mailboxes between each component
    d0.drv_mbx = drv_mbx;
    g0.drv_mbx = drv_mbx;
    
    m0.scb_mbx = scb_mbx;
    s0.scb_mbx = scb_mbx;
    
    // Connect event handles
    d0.drv_done = drv_done;
    g0.drv_done = drv_done;
    
    // Start all components - a fork join_any is used because 
    // the stimulus is generated by the generator and we want the
    // simulation to exit only when the generator has finished 
    // creating all transactions. Until then all other components
    // have to run in the background.
    fork
    	s0.run();
		d0.run();
    	m0.run();
      	g0.run();
    join_any
  endtask
endclass

  

Test

  
  
// The test can instantiate any environment. In this test, we are using
// an environment without the generator and hence the stimulus should be 
// written in the test. 
class test;
  env e0;
  mailbox drv_mbx;
  
  function new();
    drv_mbx = new();
    e0 = new();
  endfunction
  
  virtual task run();
    e0.d0.drv_mbx = drv_mbx;
    e0.run();
  endtask
endclass

  

Interface

  
  
// Adder interface contains all signals that the adder requires
// to operate
interface adder_if();
  logic 		rstn;
  logic [7:0] 	a;
  logic [7:0] 	b;
  logic [7:0] 	sum;
  logic 		carry;
endinterface

// Although an adder does not have a clock, let us create a mock clock 
// used in the testbench to synchronize when value is driven and when 
// value is sampled. Typically combinational logic is used between 
// sequential elements like FF in a real circuit. So, let us assume
// that inputs to the adder is provided at some posedge clock. But because
// the design does not have clock in its input, we will keep this clock
// in a separate interface that is available only to testbench components
interface clk_if();
  logic tb_clk;
  
  initial tb_clk <= 0;
  
  always #10 tb_clk = ~tb_clk;
endinterface

  

Testbench Top

  
  
module tb;
  bit tb_clk;
  
  clk_if 	m_clk_if 	();
  adder_if 	m_adder_if	();
  my_adder 	u0 			(m_adder_if);
  
  initial begin
    test t0;

    t0 = new;
    t0.e0.m_adder_vif = m_adder_if;
    t0.e0.m_clk_vif = m_clk_if;
    t0.run();
    
    // Once the main stimulus is over, wait for some time
    // until all transactions are finished and then end 
    // simulation. Note that $finish is required because
    // there are components that are running forever in 
    // the background like clk, monitor, driver, etc
    #50 $finish;
  end
endmodule

  

ncsim> run
T=0 [Driver] starting ...
T=0 [Driver] waiting for item ...
T=0 [Monitor] starting ...
T=0 [Generator] Loop:1/5 create next item
T=0 [Generator] Wait for driver to be done
T=10 Driver a=0x16 b=0x11 sum=0x0 carry=0x0
T=10 [Driver] waiting for item ...
T=10 [Generator] Loop:2/5 create next item
T=10 [Generator] Wait for driver to be done
T=11 Monitor a=0x16 b=0x11 sum=0x0 carry=0x0
T=11 Scoreboard a=0x16 b=0x11 sum=0x0 carry=0x0
[11] Scoreboard Pass! Carry match ref_item=0x0 item=0x0
[11] Scoreboard Pass! Sum match ref_item=0x0 item=0x0
T=30 Driver a=0xde b=0x6 sum=0x0 carry=0x0
T=30 [Driver] waiting for item ...
T=30 [Generator] Loop:3/5 create next item
T=30 [Generator] Wait for driver to be done
T=31 Monitor a=0xde b=0x6 sum=0x0 carry=0x0
T=31 Scoreboard a=0xde b=0x6 sum=0x0 carry=0x0
[31] Scoreboard Pass! Carry match ref_item=0x0 item=0x0
[31] Scoreboard Pass! Sum match ref_item=0x0 item=0x0
T=50 Driver a=0xb1 b=0xbd sum=0x0 carry=0x0
T=50 [Driver] waiting for item ...
T=50 [Generator] Loop:4/5 create next item
T=50 [Generator] Wait for driver to be done
T=51 Monitor a=0xb1 b=0xbd sum=0x0 carry=0x0
T=51 Scoreboard a=0xb1 b=0xbd sum=0x0 carry=0x0
[51] Scoreboard Pass! Carry match ref_item=0x0 item=0x0
[51] Scoreboard Pass! Sum match ref_item=0x0 item=0x0
T=70 Driver a=0x63 b=0xfb sum=0x0 carry=0x0
T=70 [Driver] waiting for item ...
T=70 [Generator] Loop:5/5 create next item
T=70 [Generator] Wait for driver to be done
T=71 Monitor a=0x63 b=0xfb sum=0x5e carry=0x1
T=71 Scoreboard a=0x63 b=0xfb sum=0x5e carry=0x1
[71] Scoreboard Pass! Carry match ref_item=0x1 item=0x1
[71] Scoreboard Pass! Sum match ref_item=0x5e item=0x5e
T=90 Driver a=0x71 b=0xbc sum=0x0 carry=0x0
T=90 [Driver] waiting for item ...
T=91 Monitor a=0x71 b=0xbc sum=0x0 carry=0x0
T=91 Scoreboard a=0x71 b=0xbc sum=0x0 carry=0x0
[91] Scoreboard Pass! Carry match ref_item=0x0 item=0x0
[91] Scoreboard Pass! Sum match ref_item=0x0 item=0x0
T=111 Monitor a=0x71 b=0xbc sum=0x0 carry=0x0
T=111 Scoreboard a=0x71 b=0xbc sum=0x0 carry=0x0
[111] Scoreboard Pass! Carry match ref_item=0x0 item=0x0
[111] Scoreboard Pass! Sum match ref_item=0x0 item=0x0
T=131 Monitor a=0x71 b=0xbc sum=0x0 carry=0x0
T=131 Scoreboard a=0x71 b=0xbc sum=0x0 carry=0x0
[131] Scoreboard Pass! Carry match ref_item=0x0 item=0x0
[131] Scoreboard Pass! Sum match ref_item=0x0 item=0x0
Simulation complete via $finish(1) at time 140 NS + 0
./testbench.sv:265     #50 $finish;

Buggy Design

Although the previous simulation showed everything as pass, how do we know if there is a bug in the checker ? Let us introduce a bug in the design to see if the checker fails.

  
  
module my_adder (adder_if _if);
  always_comb begin
  	// Let sum and carry be reset when rstn is 1 instead of 0
  	// A simple but yet possible design bug
    if (_if.rstn) begin
      _if.sum <= 0;
      _if.carry <= 0;
    end else begin
      {_if.carry, _if.sum} <= _if.a + _if.b;
    end
  end
endmodule

  

See that the checker now reports an error which proves that the checker is implemented correctly.

ncsim> run
T=0 [Driver] starting ...
T=0 [Driver] waiting for item ...
T=0 [Monitor] starting ...
T=0 [Generator] Loop:1/5 create next item
T=0 [Generator] Wait for driver to be done
T=10 Driver a=0x16 b=0x11 sum=0x0 carry=0x0
T=10 [Driver] waiting for item ...
T=10 [Generator] Loop:2/5 create next item
T=10 [Generator] Wait for driver to be done
T=11 Monitor a=0x16 b=0x11 sum=0x27 carry=0x0
T=11 Scoreboard a=0x16 b=0x11 sum=0x27 carry=0x0
[11] Scoreboard Pass! Carry match ref_item=0x0 item=0x0
[11] Scoreboard Error! Sum mismatch ref_item=0x0 item=0x27
T=30 Driver a=0xde b=0x6 sum=0x0 carry=0x0
T=30 [Driver] waiting for item ...
T=30 [Generator] Loop:3/5 create next item
T=30 [Generator] Wait for driver to be done
T=31 Monitor a=0xde b=0x6 sum=0xe4 carry=0x0
T=31 Scoreboard a=0xde b=0x6 sum=0xe4 carry=0x0
[31] Scoreboard Pass! Carry match ref_item=0x0 item=0x0
[31] Scoreboard Error! Sum mismatch ref_item=0x0 item=0xe4
T=50 Driver a=0xb1 b=0xbd sum=0x0 carry=0x0
T=50 [Driver] waiting for item ...
T=50 [Generator] Loop:4/5 create next item
T=50 [Generator] Wait for driver to be done
T=51 Monitor a=0xb1 b=0xbd sum=0x6e carry=0x1
T=51 Scoreboard a=0xb1 b=0xbd sum=0x6e carry=0x1
[51] Scoreboard Error! Carry mismatch ref_item=0x0 item=0x1
[51] Scoreboard Error! Sum mismatch ref_item=0x0 item=0x6e
T=70 Driver a=0x63 b=0xfb sum=0x0 carry=0x0
T=70 [Driver] waiting for item ...
T=70 [Generator] Loop:5/5 create next item
T=70 [Generator] Wait for driver to be done
T=71 Monitor a=0x63 b=0xfb sum=0x0 carry=0x0
T=71 Scoreboard a=0x63 b=0xfb sum=0x0 carry=0x0
[71] Scoreboard Error! Carry mismatch ref_item=0x1 item=0x0
[71] Scoreboard Error! Sum mismatch ref_item=0x5e item=0x0
T=90 Driver a=0x71 b=0xbc sum=0x0 carry=0x0
T=90 [Driver] waiting for item ...
T=91 Monitor a=0x71 b=0xbc sum=0x2d carry=0x1
T=91 Scoreboard a=0x71 b=0xbc sum=0x2d carry=0x1
[91] Scoreboard Error! Carry mismatch ref_item=0x0 item=0x1
[91] Scoreboard Error! Sum mismatch ref_item=0x0 item=0x2d
T=111 Monitor a=0x71 b=0xbc sum=0x2d carry=0x1
T=111 Scoreboard a=0x71 b=0xbc sum=0x2d carry=0x1
[111] Scoreboard Error! Carry mismatch ref_item=0x0 item=0x1
[111] Scoreboard Error! Sum mismatch ref_item=0x0 item=0x2d
T=131 Monitor a=0x71 b=0xbc sum=0x2d carry=0x1
T=131 Scoreboard a=0x71 b=0xbc sum=0x2d carry=0x1
[131] Scoreboard Error! Carry mismatch ref_item=0x0 item=0x1
[131] Scoreboard Error! Sum mismatch ref_item=0x0 item=0x2d
Simulation complete via $finish(1) at time 140 NS + 0
./testbench.sv:265     #50 $finish;

A previous article showed examples of using a uvm_blocking_get_port TLM port that was blocking in nature where the receiver gets stalled until the sender finishes with the get task.

Similarly, UVM TLM also has a non-blocking method of type uvm_nonblocking_get_port where the sender has to use try_get to see if the get was successful or can_get method to see if the sender is ready to start a transfer. Like before, the UVM TLM non-blocking get port should ultimately be connected to a non-blocking get implementation port.

UVM TLM Nonblocking Get Example

A class called Packet is defined below to act as the data item that will be transferred from one component to another. This class object will have two random variables that can be randomized before sending.

  
  
// Create a class data object that can be sent from one 
// component to another
class Packet extends uvm_object;
  rand bit[7:0] addr;
  rand bit[7:0] data;
  
  `uvm_object_utils_begin(Packet)
  	`uvm_field_int(addr, UVM_ALL_ON)
  	`uvm_field_int(data, UVM_ALL_ON)
  `uvm_object_utils_end
  
  function new(string name = "Packet");
    super.new(name);
  endfunction
endclass

  

A class called componentB is created which has a uvm_nonblocking_get_port parameterized to accept a data object of type Packet. The port has to be instantiated with the new() method preferably in the build_phase of the same component.

In this example, a class object of type Packet is received via the get_port handle by calling the try_get method. Many such packets can be received using a simple loop controlled by a configurable variable. The try_get function should ideally return 1 if the transfer was successful and 0 if it failed and should be provided by the sender which implements the function.

  
  
class componentB extends uvm_component;
   `uvm_component_utils (componentB)
 
   // Create a get_port to request for data from componentA
   uvm_nonblocking_get_port #(Packet) m_get_port;
   int m_num_tx = 2;
 
  function new (string name, uvm_component parent);
      super.new (name, parent);
   endfunction
 
   virtual function void build_phase (uvm_phase phase);
      super.build_phase (phase);
     m_get_port = new ("m_get_port", this);
   endfunction
 
   virtual task run_phase (uvm_phase phase);
      Packet pkt;
     phase.raise_objection(this);
     
     // Try to get a transaction which does not consume simulation time
     // as try_get() is a function
     repeat (m_num_tx) begin
       if (m_get_port.try_get(pkt))
       	`uvm_info ("COMPB", "ComponentA just gave me the packet", UVM_LOW)
       else
         `uvm_info ("COMPB", "ComponentA did not give packet", UVM_LOW)
        pkt.print (uvm_default_line_printer);
      end
     phase.drop_objection(this);
   endtask
endclass

  

The sender class needs to define an implementation port using uvm_nonblocking_get_imp. Since the port is nonblocking in nature, the try_get implementation is a function which has to be defined by this component.

  
  
class componentA extends uvm_component;
   `uvm_component_utils (componentA)
 
   uvm_nonblocking_get_imp #(Packet, componentA) m_get_imp;
 
  function new (string name, uvm_component parent);
      super.new (name, parent);
   endfunction
 
   virtual function void build_phase (uvm_phase phase);
      super.build_phase (phase);
      m_get_imp = new ("m_get_imp", this);
   endfunction
 
   virtual function bit try_get (output Packet pkt);
      pkt = new();
      assert (pkt.randomize());
      `uvm_info ("COMPA", "ComponentB has requested for a packet", UVM_LOW)
      pkt.print (uvm_default_line_printer);
      return 1;
   endfunction
     
     virtual function bit can_get();
     endfunction
endclass

  

The connection between a port and its implementation has to be done at a higher hierarchical level. Since both components are instantiated directly within the test class in this example, the connection between them can be done during the connect_phase of the test. If these two components were instantiated in another component or environment, they have to be connected during the connect_phase of that component or environment.

  
  
class my_test extends uvm_test;
  `uvm_component_utils (my_test)
 
   componentA compA;
   componentB compB;
 
  function new (string name = "my_test", uvm_component parent = null);
      super.new (name, parent);
   endfunction
 
   // Create objects of both components, set number of transfers
   virtual function void build_phase (uvm_phase phase);
      super.build_phase (phase);
      compA = componentA::type_id::create ("compA", this);
      compB = componentB::type_id::create ("compB", this);
   endfunction
 
   // Connection between componentA and componentB is done here
   virtual function void connect_phase (uvm_phase phase);
     compB.m_get_port.connect (compA.m_get_imp);  
   endfunction
  
   virtual function void end_of_elaboration_phase(uvm_phase phase);
    super.end_of_elaboration_phase(phase);
    uvm_top.print_topology();
  endfunction
endclass

  

UVM_INFO @ 0: reporter [RNTST] Running test my_test...
UVM_INFO /playground_lib/uvm-1.2/src/base/uvm_root.svh(579) @ 0: reporter [UVMTOP] UVM testbench topology:
-----------------------------------------------------
Name            Type                      Size  Value
-----------------------------------------------------
uvm_test_top    my_test                   -     @1836
  compA         componentA                -     @1905
    m_get_imp   uvm_nonblocking_get_imp   -     @1971
  compB         componentB                -     @1936
    m_get_port  uvm_nonblocking_get_port  -     @2010
-----------------------------------------------------

UVM_INFO testbench.sv(97) @ 0: uvm_test_top.compA [COMPA] ComponentB has requested for a packet
Packet: ([email protected]) { addr: 'he8  data: 'hc5  } 
UVM_INFO testbench.sv(67) @ 0: uvm_test_top.compB [COMPB] ComponentA just gave me the packet
Packet: ([email protected]) { addr: 'he8  data: 'hc5  } 
UVM_INFO testbench.sv(97) @ 0: uvm_test_top.compA [COMPA] ComponentB has requested for a packet
Packet: ([email protected]) { addr: 'hd6  data: 'hd  } 
UVM_INFO testbench.sv(67) @ 0: uvm_test_top.compB [COMPB] ComponentA just gave me the packet
Packet: ([email protected]) { addr: 'hd6  data: 'hd  } 
UVM_INFO /playground_lib/uvm-1.2/src/base/uvm_objection.svh(1271) @ 0: reporter [TEST_DONE] 'run' phase is ready to proceed to the 'extract' phase
UVM_INFO /playground_lib/uvm-1.2/src/base/uvm_report_server.svh(847) @ 0: reporter [UVM/REPORT/SERVER] 
--- UVM Report Summary ---

UVM TLM can_get Example

Instead of directly trying to get a packet, the receiver can first query to see if the sender is ready or not with can_get function and then get the packet.

  
  
class componentB extends uvm_component;
   `uvm_component_utils (componentB)
 
   // Create a get_port to request for data from componentA
   uvm_nonblocking_get_port #(Packet) m_get_port;
   int m_num_tx = 2;
 
  function new (string name, uvm_component parent);
      super.new (name, parent);
   endfunction
 
   virtual function void build_phase (uvm_phase phase);
      super.build_phase (phase);
     m_get_port = new ("m_get_port", this);
   endfunction
 
   virtual task run_phase (uvm_phase phase);
      Packet pkt;
     phase.raise_objection(this);
     
     // Try to get a transaction which does not consume simulation time
     // as try_get() is a function
     repeat (m_num_tx) begin
       while (!m_get_port.can_get()) begin
         #10 `uvm_info("COMPB", $sformatf("See if can_get() is ready"), UVM_LOW)
       end
       
       `uvm_info("COMPB", $sformatf("COMPA ready, get packet now"), UVM_LOW)
       m_get_port.try_get(pkt);
       pkt.print (uvm_default_line_printer);
      end
     phase.drop_objection(this);
   endtask
endclass

  

The can_get function in componentA is set to return a random value in this example to model readiness of the receiver.

  
  
class componentA extends uvm_component;
   `uvm_component_utils (componentA)
 
   uvm_nonblocking_get_imp #(Packet, componentA) m_get_imp;
 
  // Rest of the code remains same
 
   virtual function bit try_get (output Packet pkt);
      pkt = new();
      assert (pkt.randomize());
      `uvm_info ("COMPA", "ComponentB has requested for a packet", UVM_LOW)
      pkt.print (uvm_default_line_printer);
      return 1;
   endfunction
     
     virtual function bit can_get();
       bit ready;
       std::randomize(ready) with { ready dist {0:/70, 1:/30}; };
       return ready;
     endfunction
endclass

  

UVM_INFO @ 0: reporter [RNTST] Running test my_test...
UVM_INFO /playground_lib/uvm-1.2/src/base/uvm_root.svh(579) @ 0: reporter [UVMTOP] UVM testbench topology:
-----------------------------------------------------
Name            Type                      Size  Value
-----------------------------------------------------
uvm_test_top    my_test                   -     @1837
  compA         componentA                -     @1906
    m_get_imp   uvm_nonblocking_get_imp   -     @1972
  compB         componentB                -     @1937
    m_get_port  uvm_nonblocking_get_port  -     @2011
-----------------------------------------------------

UVM_INFO testbench.sv(60) @ 10: uvm_test_top.compB [COMPB] See if can_get() is ready
UVM_INFO testbench.sv(60) @ 20: uvm_test_top.compB [COMPB] See if can_get() is ready
UVM_INFO testbench.sv(60) @ 30: uvm_test_top.compB [COMPB] See if can_get() is ready
UVM_INFO testbench.sv(62) @ 30: uvm_test_top.compB [COMPB] COMPA ready, get packet now
UVM_INFO testbench.sv(97) @ 30: uvm_test_top.compA [COMPA] ComponentB has requested for a packet
Packet: ([email protected]) { addr: 'h8c  data: 'h99  } 
Packet: ([email protected]) { addr: 'h8c  data: 'h99  } 
UVM_INFO testbench.sv(62) @ 30: uvm_test_top.compB [COMPB] COMPA ready, get packet now
UVM_INFO testbench.sv(97) @ 30: uvm_test_top.compA [COMPA] ComponentB has requested for a packet
Packet: ([email protected]) { addr: 'h97  data: 'hb8  } 
Packet: ([email protected]) { addr: 'h97  data: 'hb8  } 
UVM_INFO /playground_lib/uvm-1.2/src/base/uvm_objection.svh(1271) @ 30: reporter [TEST_DONE] 'run' phase is ready to proceed to the 'extract' phase
UVM_INFO /playground_lib/uvm-1.2/src/base/uvm_report_server.svh(847) @ 30: reporter [UVM/REPORT/SERVER] 
--- UVM Report Summary ---