AWhooley Posted September 13, 2011 Report Share Posted September 13, 2011 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 Quote Link to comment Share on other sites More sharing options...
mea1201 Posted September 13, 2011 Report Share Posted September 13, 2011 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 Quote Link to comment Share on other sites More sharing options...
sri.cvcblr Posted September 18, 2011 Report Share Posted September 18, 2011 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] Quote Link to comment Share on other sites More sharing options...
AWhooley Posted September 20, 2011 Author Report Share Posted September 20, 2011 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 Quote Link to comment Share on other sites More sharing options...
mea1201 Posted September 20, 2011 Report Share Posted September 20, 2011 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. Quote Link to comment Share on other sites More sharing options...
AWhooley Posted September 21, 2011 Author Report Share Posted September 21, 2011 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 Quote Link to comment Share on other sites More sharing options...
mea1201 Posted September 21, 2011 Report Share Posted September 21, 2011 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. Quote Link to comment Share on other sites More sharing options...
AWhooley Posted September 21, 2011 Author Report Share Posted September 21, 2011 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 Quote Link to comment Share on other sites More sharing options...
ssr1 Posted August 2, 2016 Report Share Posted August 2, 2016 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 : newfunction void build_phase(uvm_phase phase);comparator = new("comparator", this);endfunction : build_phasefunction 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_phaseendclass : scoreboardIn 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 : newfunction 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_phasefunction void connect_phase(uvm_phase phase);master.mon.ap.connect(sb.comparator.before_export);slave.mon.ap.connect(sb.comparator.after_export);endfunction : connect_phaseendclass : env in the scorebaord before_export and after-export should be declared? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.