How to implement more than 1 Analysis Implementation Ports in a Class in UVM

Hi All,

In this post, we will discuss about how to include more than 1 Analysis Implementation Port in a Class in UVM.

Analysis Ports are used for many purposes like Coverage Collection, Received/Transmitted Packet Checking. And sometimes, you may need to take coverage on different packets (so you will require different analysis implementation ports) and you do not want to define 2 different class, just for coverage.

So if there are more than 1 (suppose 2) analysis implementation ports in a class, then obvious (and the first also !!!) question arises in the mind is that, how to implement 2 write methods in the same class.

Well, in UVM, we have 2 different methods to address the problem.


Method - 1 : Use "imp" Suffix defined via Macro

  • Declare Macro `uvm_analysis_imp_decl(<Postfix>) outside of the component. This macro adds post-fix to the analysis implementation port class name and associated write method.
  • Instantiate Analysis Implementation Port with uvm_analysis_imp_<Postfix> class name.
  • Implement write_<Postfix> method.
 Now Example,

`uvm_analysis_imp_decl(_port1)
`uvm_analysis_imp_decl(_port2)

class x extends uvm_component;
  // Other Stuff, like registering in Factory, new method

  uvm_analysis_imp_port1 #(packet1, x) a1;
  uvm_analysis_imp_port2 #(packet2, x) a2;

  virtual function void write_port1 (packet1 p);
    // Write Method for a1 Analysis Implementation Port
  endfunction : write_port1

  virtual function void write_port2 (packet2 p);
    // Write Method for a2 Analysis Implementation Port
  endfunction : write_port2
endclass : x


Method - 2 : Use Analysis FIFO

  • Declare Analysis Export Ports & Analysis FIFOs.
  • Connect Analysis Exports to the Analysis FIFOs in connect_phase.
  • run_phase must pull data from Analysis FIFOs, for further processing.
 Now Example,

class x extends uvm_component;
  // Other Stuff, like registering in Factory, new method

  uvm_tlm_analysis_fifo #(packet1) port1_fifo;
  uvm_tlm_analysis_fifo #(packet2) port2_fifo;
  uvm_analysis_export #(packet1) a1;
  uvm_analysis_export #(packet2) a2;

  function void connect_phase (uvm_phase phase);
    // Analysis Exports will connect to the analysis_export of FIFOs
    a1.connect(port1_fifo.analysis_export);
    a2.connect(port2_fifo.analysis_export);
  endfunction : connect_phase

  task run_phase (uvm_phase phase);
    // Pull data from FIFOs for further processing
    port1_fifo.get(p1);
    port2_fifo.get(p2);
  endfunction : connect_phase
endclass : x

Comments

Post a Comment

Popular posts from this blog

SystemVerilog Event Regions

Image
Hi All, In the last post, we had discussed the Verilog Event Regions. Today we'll discuss the event regions in SystemVerilog, which are somewhat similar to the Verilog Event regions only, plus there are some additional regions as well. Similar to Verilog, in Systemverilog also the event queue is divided into 5 different regions. A SystemVerilog simulator, shall maintain some form of data structure that allows events to be dynamically scheduled, executed, and removed as the simulator advances through time. Simulation proceeds by executing and removing all events in the current simulation time slot before moving on to the next nonempty time slot, in time order. And in that given simulation timeslot, it is necessary to execute events of all of the above mentioned regions. Most important thing is that these regions encompass the Verilog Event Regions and hence the legacy Verilog code should run correctly without any modification in SystemVerilog simulator. Prepone Region
Read more

Standard Cell Based ASIC Design Flow

Image
Hi All,  Today we will discuss about ASIC Design Flow, as it is one of the most important and crucial thing to understand. ASIC Design Flow Now, we will try to get brief idea about each steps in the above image. Specification  - Specification of the system, like what is the functionality of system, what is the desired speed of the system, area constraint of the system, whether it has any power constraint or not, tolerances of various constraints, operative conditions of the system. RTL Description  - Generally after specification, the system is partitioned into various blocks and RTL description (HDL Code like Verilog or VHDL), mostly in behaviour form is written. Sometimes Higher Level Language Code like C/C++ is also written, and in that case, a High Level Synthesis Tool is used, which converts the Higher Language Code into RTL Level Code. After RTL Coding, Functional Verification is done to check the correctness of the functionality. Logic Synthesis  - Now, wh
Read more

Verilog Event Regions

Image
Hi All, Today we'll see about something important about Verilog language. We'll see the event regions of the Verilog and how does it affect the simulation process. Verilog Event Regions Please note that this is a conceptual model as per IEEE standard and how each vendor implemets this model, is completely proprietary. Verilog is divided in the 4 event regions. And for any given time stamp, it is necessary to execute events of all region, before moving to the next time stamp (So if timescale is 1ns/10ps, then at every 10ps, events in all of the regions are evaluated, before moving to next simulation time) Active Region  -  The active event region is the event region, where most of the Verilog events are scheduled including Blocking Assignment, Evaluation of RHS side of Nonblocking Assignments, Continuous Assignments, $display command execution and evaluation of i/p & o/p of primitives.  However all of the sub events of the active region, can be executed in
Read more