Chapter 6 – Monitor

The monitor is aself-contained model that observes the communication of the DUT with thetestbench. At most, it should observe the outputs of the design and, in case ofnot respecting the protocol’s rules, the monitor must return an error.

The monitor is apassive component, it doesn’t drive any signals into the DUT, its purpose is toextract signal information and translate it into meaningful information to beevaluated by other components. A verification environment isn’t limited to justone monitor, it can have multiple of them.

The monitorsshould cover:

• The outputs of the DUT for protocol adherence
• The inputs of the DUT for functional coverage analysis

The approach weare going to follow for this verification plan is: sample both inputs, make aprediction of the expected result and compare it with the result of the DUT.

Consequently, weare going to create two different monitors:

• The first monitor, monitor_before, will look solely for the output of the device and it will pass the result to the scoreboard.

•  The second monitor, monitor_after, will get both inputs and make a prediction of the expected result. The scoreboard will get this predicted result as well and make a comparison between the two values.

A portion of thecode for both monitors can be seen in Code 6.1 and in Code 6.2.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class simpleadder_monitor_before extends uvm_monitor;      `uvm_component_utils(simpleadder_monitor_before)        uvm_analysis_port#(simpleadder_transaction) mon_ap_before;        virtual simpleadder_if vif;        function new(string name, uvm_component parent);           super.new(name, parent);      endfunction: new        function void build_phase(uvm_phase phase);           super.build_phase(phase);             void'(uvm_resource_db#(virtual simpleadder_if)::read_by_name  (.scope("ifs"), .name("simpleadder_if"), .val(vif)));           mon_ap_before = new(.name("mon_ap_before"), .parent(this));      endfunction: build_phase        task run_phase(uvm_phase phase);           //Our code here      endtask: run_phase endclass: simpleadder_monitor_before

Code 6.1 – Code for monitor_before

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

class simpleadder_monitor_after extends uvm_monitor;      `uvm_component_utils(simpleadder_monitor_after)        uvm_analysis_port#(simpleadder_transaction) mon_ap_after;        virtual simpleadder_if vif;        simpleadder_transaction sa_tx_cg;        covergroup simpleadder_cg;           ina_cp:     coverpoint sa_tx_cg.ina;           inb_cp:     coverpoint sa_tx_cg.inb;           cross ina_cp, inb_cp;      endgroup: simpleadder_cg        function new(string name, uvm_component parent);           super.new(name, parent);           simpleadder_cg = new;      endfunction: new        function void build_phase(uvm_phase phase);           super.build_phase(phase);             void'(uvm_resource_db#(virtual simpleadder_if)::read_by_name (.scope("ifs"), .name("simpleadder_if"), .val(vif)));           mon_ap_after= new(.name("mon_ap_after"), .parent(this));      endfunction: build_phase        task run_phase(uvm_phase phase);           //Our code here      endtask: run_phase endclass: simpleadder_monitor_after

Code 6.2 – Code for monitor_after

The skeleton ofboth monitors is very similar to the driver, except for Lines 4. They representone of the existing UVM communication ports. These ports allow differentobjects to pass transactions between them. In the section 6.0.1 you can consulta brief explanation of UVM ports.

The monitorswill collect transactions from the virtual interface and use the analysis portsto send those transactions to the scoreboard. The code for the run phase can bedesigned the same way as for the driver but it was omitted in this section.

The the state ofour verification environment after the monitors can be consulted in Figure 6.1.

Figure 6.1 - State ofthe verification environment after the monitors

Chapter 6.0.1 – TLM ports

In chapter 4, it was mentioned that transactions arethe most basic data transfer in a verification environment but another questionarises: how do transactions are moved between components? We have alreadytalked about TLM before when we were designing the driver. The way the drivergets transactions from the sequencer, it’s the same way the scoreboard getsthem from the monitors: through TLM.

TLM standsfor Transaction Level Modeling and it’s a high-level approachto modeling communication between digital systems. This approach is representedby two main aspects:ports and exports.

A TLM portdefines a set of methods and functions to be used for a particular connection,while an export supplies the implementation of those methods. Ports and exportsuse transaction objects as arguments.

We can see arepresentation of a TLM connection in Figure 6.2.

Figure 6.2– Port-export communication

Thecommunication is very easy to understand. The consumer implements a functionthat accepts a transaction as an argument and the producer calls that veryfunction while passing the expected transaction as argument. The top blockconnects the producer to the consumer.

A sample code isprovided in Table 6.1.

Table 6.1– Sample code for ports and exports

The class topclass connectsthe producer’s test_port to the consumer’s test_export usingthe connect() method. Then, the producer executes theconsumer’s function testfunc() throughtest_port.

A particularcharacteristic of this kind of communication is that a port can only beconnected to a single export. But there are cases when we might be interestedin having a special port that can be plugged into several exports.

A third type ofTLM port exists to cover these kind of cases: the analysis port.

An analysis portworks exactly like a normal port but it can detect the number of exports thatare connected to it and every time a required function is asked through thisport, all other components whose exports are connected to an analysis port aregoing to be triggered.

In Figure 6.2it’s represented an analysis port communication.

Figure 6.2– Analysis port communication

Thecommunication models mentioned here are part of Transaction Level Modeling 1.0.There is another variant, TLM 2.0, that works with sockets instead of ports,but they aren’t going to be mentioned in this training guide.

A brief summaryof these ports and exports can be seen in Table 6.2.

Table 6.2– Sum up of TLM-1.0 ports

For moreinformation about TLM, you can consult: