Chapter 6 – Monitor

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

The monitor is a passive component, it doesn’t drive any signals into the DUT, its purpose is to extract signal information and translate it into meaningful information to be evaluated by other components. A verification environment isn’t limited to just one monitor, it can have multiple of them.

The monitors should cover:

The outputs of the DUT for protocol adherence

The inputs of the DUT for functional coverage analysis

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

Consequently, we are 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 the code for both monitors can be seen in Code 6.1 and in Code 6.2.

The skeleton of both monitors is very similar to the driver, except for Lines 4. They represent one of the existing UVM communication ports. These ports allow different objects to pass transactions between them. In the section 6.0.1 you can consult a brief explanation of UVM ports.

The monitors will collect transactions from the virtual interface and use the analysis ports to send those transactions to the scoreboard. The code for the run phase can be designed the same way as for the driver but it was omitted in this section.

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

Figure 6.1 – State of the verification environment after the monitors

Chapter 6.0.1 – TLM ports

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

TLM stands for Transaction Level Modeling and it’s a high-level approach to modeling communication between digital systems. This approach is represented by two main aspects: ports and exports.

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

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

Figure 6.2 – Port-export communication

The communication is very easy to understand. The consumer implements a function that accepts a transaction as an argument and the producer calls that very function while passing the expected transaction as argument. The top block connects the producer to the consumer.

A sample code is provided in Table 6.1.

Table 6.1 – Sample code for ports and exports

The class topclass connects the producer’s test_port to the consumer’s test_export using the connect() method. Then, the producer executes the consumer’s function testfunc() through test_port.

A particular characteristic of this kind of communication is that a port can only be connected to a single export. But there are cases when we might be interested in having a special port that can be plugged into several exports.

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

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

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

Figure 6.2 – Analysis port communication

The communication 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.

13 thoughts to “Chapter 6 – Monitor”

Once you press the “Home” button, you will be prompted to use the
fingerprint sensor in order to view anything on your phone.
Insert a simcard from a different service provider and power on the cell phone.
Almost all the gadgets launched by the brand are amazing in features and
incredible in looks.

You actually make it appear really easy together with your presentation however I find this topic to be actually one thing that I feel I would never understand. It kind of feels too complex and extremely wide for me. I am having a look forward to your subsequent submit, I’ll attempt to get the cling of it!

Everything said was actually very logical. But, consider this, suppose you wrote a catchier title?
I ain’t saying your information isn’t solid, however what if
you added something that makes people want more?
I mean Chapter 6 – Monitor – Pedro Araújo is a little boring.
You should glance at Yahoo’s home page and note how they create news titles
to get people interested. You might try adding a video or
a related picture or two to get people interested about what you’ve written. Just my opinion,
it could bring your posts a little livelier.