uvm_cookbook--DUT-Testbench Connections--Abstract-Concrete Class Connections

抽象和具体class的连接

An alternative to using a virtual interface handle for DUT to UVM testbench connections is to use an abstract concrete class pair. The abstract version of the class defines templates for all the methods that are available in the BFM. The concrete version of the class is declared in the BFM and it extends the abstract version, providing an implementation of the methods. The handle of the concrete class is assigned to the abstract handle in the agent classes via the uvm_config_db. The properties of class object polymorphism allow the abstract class handle to interact with the BFM using the method implementations in the concrete version of the class.

If a class is defined inside an interface or a module, it can reference any of the variables within the interface or module scope. This can be used to simplify the handling of parameters.

The following code snippets show the Abstract and Concrete versions of the sfr_master class:

// The abstract class for the SFR master driver/BFM

class sfr_master_abstract;

 

virtual task execute(sfr_seq_item item);

 

endtask

 

endclass

 

// The implementation for the SFR master BFM, containing the concrete implementation of the sfr_master

module sfr_master_bfm  #(ADDR_WIDTH = 8,

                         DATA_WIDTH = 8)

                        (input clk,

                         input reset,

                         output logic[ADDR_WIDTH-1:0] address,

                         output logic[DATA_WIDTH-1:0] write_data,

                         input logic[DATA_WIDTH-1:0] read_data,

                         output logic we,

                         output logic re);

 

  import uvm_pkg::*;

  import sfr_agent_pkg::*;

 

  always @(reset or posedge clk) begin

    if(reset == 1) begin

      re <= 0;

      we <= 0;

      address <= 0;

      write_data <= 0;

    end

  end

 

// Definition of the concrete version of the sfr_master class:

class sfr_master_concrete extends sfr_master_abstract;

 

  task execute(sfr_seq_item item);

    if(reset == 1) begin

      wait(reset == 0);

    end

    else begin

      @(posedge clk);

      address = item.address;

      we <= item.we;

      write_data <= item.write_data;

      re <= item.re;

      @(posedge clk);

      if(re == 1) begin

        item.read_data = read_data;

        re <= 0;

      end

      we <= 0;

    end

  endtask: execute

endclass

 

// Declaration of the SFR_MASTER class handle

sfr_master_concrete SFR_MASTER;

 

// Initial block, constructing the SFR_MASTER object and assigning the handle into the uvm_config_db

// Note the use of the sfr_master_abstract handle as the uvm_config_db parameter

initial begin

  SFR_MASTER = new();

  uvm_config_db #(sfr_master_abstract)::set(null, "uvm_test_top", "SFR_MASTER", SFR_MASTER);

end

 

endmodule: sfr_master_bfm

Note that in the above code, the BFM has been changed to a module from an interface, this is another freedom that using the abstract-concrete pattern enables. Modules allow the BFM to have hierarchy.

Inside the SFR agent classes, any reference to the BFM is via handles of the sfr_master_abstract type:在agent中，使用抽象类

class sfr_driver extends uvm_driver #(sfr_seq_item);

 

// Abstract version of the sfr_master class:

sfr_master_abstract SFR;

 

extern task run_phase(uvm_phase phase);

 

endclass: sfr_driver

 

task sfr_driver::run_phase(uvm_phase phase);

  sfr_seq_item item;

 

  forever begin

    seq_item_port.get_next_item(item);

    SFR.execute(item);

    seq_item_port.item_done();

  end

 

endtask: run_phase

The handle to the sfr_master_abstract object is passed via the agent config object via the uvm_config_db, note that in the following code snippet, the sfr_monitor uses the same connection pattern:

class sfr_test extends uvm_component;

 

 

sfr_env_config env_cfg;

sfr_config_object sfr_agent_cfg;

 

sfr_env env;

 

extern function void build_phase(uvm_phase phase);

extern task run_phase(uvm_phase phase);

 

endclass: sfr_test

 

function void sfr_test::build_phase(uvm_phase phase);

  env_cfg = sfr_env_config::type_id::create("env_cfg");

  sfr_agent_cfg = sfr_config_object:: type_id::create("sfr_agent_cfg");

 

  // Assigning the handle to the concrete implementations of the sfr_master and sfr_monitor classes to their abstract counterparts

  if(!uvm_config_db #(sfr_master_abstract)::get(this, "", "SFR_MASTER", sfr_agent_cfg.SFR_MASTER)) begin

    `uvm_error("BUILD_PHASE", "Unable to find virtual interface sfr_master_bfm in the uvm_config_db")

  end

  if(!uvm_config_db #(sfr_monitor_abstract)::get(this, "", "SFR_MONITOR", sfr_agent_cfg.SFR_MONITOR)) begin

    `uvm_error("BUILD_PHASE", "Unable to find virtual interface sfr_master_bfm in the uvm_config_db")

  end

 

  sfr_agent_cfg.is_active = 1;

  env_cfg.sfr_agent_cfg = sfr_agent_cfg;

  env = sfr_env::type_id::create("env", this);

  env.cfg = env_cfg;

endfunction: build_phase

When the abstract-concrete class connection pattern is used, the agent does not have to be parameterised, since class handles are used to make the connection.

In summary, the abstract concrete class approach works by passing a class object handle from the hdl_top part of the testbench to the UVM testbench.

巴特西

uvm_cookbook--DUT-Testbench Connections--Abstract-Concrete Class Connections

最新文章

热门文章