Noobe : Connecting agent and scoreboard question

[AWhooley]

Hi,

I am new to UVM so apologies if I make a mess of trying to ask this question.

From what I understand the interaction of the test environment to particular interface (e.g. SPI) to a design should be captured within an agent. The agent should contain a sequencer, a driver and a monitor. My understanding is that the environment would then contain an object of this agent as well as your scoreboard for checking. This scoreboard will receive transactions from the monitor in the agent through an analysis port.

Hope I am making sense so far!

Anyway here is where I get confused. My simple DUT takes transactions in and passes them straight through. My scoreboard simply has to check that what comes out of the DUT matches what went in. My monitor catches the DUT output in a transaction and sends that out through an analysis port. Thus my scoreboard knows what came out of the DUT. Question: How should I tell the scoreboard what went into the DUT? Should the driver send the transaction it sends to the DUT out through an analysis port also? Should the monitor watch the DUT inputs and send what it sees out on a second analysis_port i.e. the monitor would have 2 analysis ports? Should an agent only contain one analysis port to allow ease of reuse and consistency across agents and if so then what do I do?

I hope this makes sense. I have been trying to find code examples of a basic UVM environment but all the examples I find seems to miss something (e.g. have an agent but no scoreboard, have a scoreboard but no agent).

Thanks

Alan

[mea1201]

Hey Alan,

I would instantiate an agent configured as a master to drive your DUT, and instantiate the same agent configured as a slave to receive the DUT output. In both instances, you can use the same monitor, unless you have master/slave-specific characteristics you want to build into the monitor. Then, connect the analysis ports from each of these monitor instances to your scoreboard. The scoreboard will then receive transactions driven into the DUT, and transactions driven by the DUT. If you want to simply compare the two transactions as identical, you can use the uvm_in_order_comparator, provided that order is expected to be the same at the input and the output. Check the class reference doc for the gory details on comparators, or roll your own if you wish.

Hi,

I am new to UVM so apologies if I make a mess of trying to ask this question.

From what I understand the interaction of the test environment to particular interface (e.g. SPI) to a design should be captured within an agent. The agent should contain a sequencer, a driver and a monitor. My understanding is that the environment would then contain an object of this agent as well as your scoreboard for checking. This scoreboard will receive transactions from the monitor in the agent through an analysis port.

Hope I am making sense so far!

Anyway here is where I get confused. My simple DUT takes transactions in and passes them straight through. My scoreboard simply has to check that what comes out of the DUT matches what went in. My monitor catches the DUT output in a transaction and sends that out through an analysis port. Thus my scoreboard knows what came out of the DUT. Question: How should I tell the scoreboard what went into the DUT? Should the driver send the transaction it sends to the DUT out through an analysis port also? Should the monitor watch the DUT inputs and send what it sees out on a second analysis_port i.e. the monitor would have 2 analysis ports? Should an agent only contain one analysis port to allow ease of reuse and consistency across agents and if so then what do I do?

I hope this makes sense. I have been trying to find code examples of a basic UVM environment but all the examples I find seems to miss something (e.g. have an agent but no scoreboard, have a scoreboard but no agent).

Thanks

Alan

[sri.cvcblr]

Hi Alan,

Hi,

I am new to UVM so apologies if I make a mess of trying to ask this question.

From what I understand the interaction of the test environment to particular interface (e.g. SPI) to a design should be captured within an agent. The agent should contain a sequencer, a driver and a monitor. My understanding is that the environment would then contain an object of this agent as well as your scoreboard for checking. This scoreboard will receive transactions from the monitor in the agent through an analysis port.

Hope I am making sense so far!

Yes, so far so good, you are no longer:

>> I am new to UVM

<SNIP>. Question: How should I tell the scoreboard what went into the DUT? Should the driver send the transaction it sends to the DUT out through an analysis port also?

That's an easy/good option - if you believe this scoreboard doesn't have to be reused above/later when the "driver" maynot be needed.

Should the monitor watch the DUT inputs and send what it sees out on a second analysis_port i.e. the monitor would have 2 analysis ports? Should an agent only contain one analysis port to allow ease of reuse and consistency across agents and if so then what do I do?

This is certainly more portable, reusable - though extra work (of recreating the transaction, kind of reversing what the driver just did).

Ideally I would recommend you build 2 monitors one for input side and one for output side - if that makes sense for your DUT.

Your question is very valid from first time UVM/OVM user. Actually using more than 1 analysis ports requires the `uvm_analysis_imp macros and makes it more "interesting" - to say the least. Usually I see that many first level training sessions do not cover that (we do that in our advanced OVM/UVM sessions). Below is a screenshot from our training material on this very topic.

[ATTACH]30[/ATTACH]

[AWhooley]

Ideally I would recommend you build 2 monitors one for input side and one for output side - if that makes sense for your DUT.

Are you suggesting that I place 2 monitors in my agent or are you proposing something similar to 'mea1201' and have two agents?

What is the "normal" approach for getting the driver side data into the scoreboard? I think I need to buy a good book.

Thanks

Alan

[mea1201]

Are you suggesting that I place 2 monitors in my agent or are you proposing something similar to 'mea1201' and have two agents?

What is the "normal" approach for getting the driver side data into the scoreboard? I think I need to buy a good book.

Thanks

Alan

Hi Alan,

Here's one way to model a simple scoreboard if in-order comparison is all that is needed:

class scoreboard extends uvm_scoreboard;
  `uvm_component_utils(scoreboard)
  uvm_in_order_class_comparator#(transaction) comparator;
  function new(string name="scoreboard", uvm_component parent=null);
    super.new(name, parent);
  endfunction : new
  function void build_phase(uvm_phase phase);
    comparator = new("comparator", this);
  endfunction : build_phase
  function void report_phase(uvm_phase phase);
    `uvm_info(get_type_name(), $psprintf("Matches:  %0d", comparator.m_matches), UVM_LOW)
    `uvm_info(get_type_name(), $psprintf("Mismatches:  %0d", comparator.m_mismatches), UVM_LOW)
  endfunction : report_phase
endclass : scoreboard

In the env class, the scoreboard is connected to the master and slave agents' monitors like so:

class env extends uvm_env;
  `uvm_component_utils(env)
  scoreboard sb;
  agent master, slave;
  function new(string name="env", uvm_component parent=null);
    super.new(name, parent);
  endfunction : new
  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    master = agent::type_id::create("master", this);
    slave = agent::type_id::create("slave", this);
    sb = scoreboard::type_id::create("sb", this);
  endfunction : build_phase
  function void connect_phase(uvm_phase phase);
    master.mon.ap.connect(sb.comparator.before_export);
    slave.mon.ap.connect(sb.comparator.after_export);
  endfunction : connect_phase
endclass : env

If the comparison is going to be much more complicated, then you can either use analysis FIFOs, imp declaration macros, or subscribers in the scoreboard. In any case, you do have two agents with each monitor sending before and after transactions to the scoreboard.

[AWhooley]

Hi again,

First of all thanks for taking the time to guide me through this mental deficiency on my part! What you say makes complete sense to me. However does this mean that even for the most basic of designs a user will always require 2 agents, a master and a slave where the slave's only job is to monitor the DUT inputs and pass its observations onto the scoreboard. Also, lets say I had both an SPI and I2C interface in my design, I would then have to code up an I2C agent and and SPI agent. Would my test environment then have to contain 2 objects of both i.e. a matser I2C, a slace I2C, a mater SPI and and slaVe SPI? This seems to be a very complicated way of achiving what could be achived by, for example, the sequencer sending its transactions out on an analysis port just before passing them to the driver?

I have no doubt I am missing a fundamental concept of UVM and am looking forward to my eurika moment

Thanks

Alan

[mea1201]

Hi again,

First of all thanks for taking the time to guide me through this mental deficiency on my part! What you say makes complete sense to me. However does this mean that even for the most basic of designs a user will always require 2 agents, a master and a slave where the slave's only job is to monitor the DUT inputs and pass its observations onto the scoreboard. Also, lets say I had both an SPI and I2C interface in my design, I would then have to code up an I2C agent and and SPI agent. Would my test environment then have to contain 2 objects of both i.e. a matser I2C, a slace I2C, a mater SPI and and slaVe SPI? This seems to be a very complicated way of achiving what could be achived by, for example, the sequencer sending its transactions out on an analysis port just before passing them to the driver?

I have no doubt I am missing a fundamental concept of UVM and am looking forward to my eurika moment

Thanks

Alan

The master/slave suggestion was based on the specific example you gave to start this thread. If your DUT just passes transactions through, like a SystemVerilog interface implementing some protocol, then I assumed you would have one agent that conforms to that protocol, and you would instantiate it twice -- one to initiate transactions on the master side (input side of DUT), and the other to act as the target, possibly respond on the slave side (output side of DUT).

In the SPI/I2C example, you only need one instance of the SPI agent to interact with the SPI interface, and one instance of the I2C agent to interact with the I2C interface. You can design the monitor in each of these agents to capture the serial response, and annotate that into a transaction initially copied from the request. Then, the monitor sends out on its analysis port one transaction with request and response info that can be checked by the scoreboard. The UBUS example that is bundled with the UVM installation illustrates how a peek port can be used to convey request/response info between the sequencer and the monitor within an agent.

Bottom line is that how you architect your UVM components depends on the application and your ideas for re-use.

[AWhooley]

The UBUS example that is bundled with the UVM installation illustrates how a peek port can be used to convey request/response info between the sequencer and the monitor within an agent.

Cheers. I'll take a more in-depth look at this example. Felt it was over my head at first but I might make a better go of it now.

Thanks for your time.

Alan

[ssr1]

mea1201 said:

 

Here's one way to model a simple scoreboard if in-order comparison is all that is needed:

class scoreboard extends uvm_scoreboard;
`uvm_component_utils(scoreboard)
uvm_in_order_class_comparator#(transaction) comparator;
function new(string name="scoreboard", uvm_component parent=null);
super.new(name, parent);
endfunction : new
function void build_phase(uvm_phase phase);
comparator = new("comparator", this);
endfunction : build_phase
function void report_phase(uvm_phase phase);
`uvm_info(get_type_name(), $psprintf("Matches: %0d", comparator.m_matches), UVM_LOW)
`uvm_info(get_type_name(), $psprintf("Mismatches: %0d", comparator.m_mismatches), UVM_LOW)
endfunction : report_phase
endclass : scoreboard
In the env class, the scoreboard is connected to the master and slave agents' monitors like so:

class env extends uvm_env;
`uvm_component_utils(env)
scoreboard sb;
agent master, slave;
function new(string name="env", uvm_component parent=null);
super.new(name, parent);
endfunction : new
function void build_phase(uvm_phase phase);
super.build_phase(phase);
master = agent::type_id::create("master", this);
slave = agent::type_id::create("slave", this);
sb = scoreboard::type_id::create("sb", this);
endfunction : build_phase
function void connect_phase(uvm_phase phase);
master.mon.ap.connect(sb.comparator.before_export);
slave.mon.ap.connect(sb.comparator.after_export);
endfunction : connect_phase
endclass : env

 

in the scorebaord before_export and after-export should be declared?