Monitors, Monitors Everywhere – Who Is Monitoring the Monitors

The reader of this paper should be interested in predicting the behavior of his hardware or is interested in monitoring his hardware. This paper will review phase-level monitoring, transaction-level monitoring, and general monitoring. In-order and out-of-order transaction-level monitors and UVM constructs for single and multiple port monitors will be demonstrated, including discussion about simple function implementations versus FIFO and threaded implementations. A protocol specific AXI monitor written at the transaction-level of abstraction will be demonstrated. This monitor and scoreboard can model many AXI interactions, but under certain AXI usages, problems arise. For example, partially written data may be read by an overlapping READ. This kind of behavior cannot be modeled by the "complete transaction" kind of monitor; it must be modeled by a phase-level monitor. Such a phase-level monitor will be demonstrated. All of these monitoring and scoreboard discussions can be widely applied to many protocols and many monitoring situations.

Introduction to Monitoring:

In a verification environment the task of a monitor is to monitor activity on a set of DUT pins. This could be as simple as looking at READ/WRITE pins or as complex as a complete protocol bus, such as AXI or PCIe. In a very simple case a monitor can be looking at a pin or a set of pins and generating an event or raising a flag every time there is a change in signal values. The flag or event can trigger a scoreboard or coverage collector to perform an activity. This sort of monitor is typically very slow and not very useful as it generates a lot of irrelevant data.

At a higher level the monitor can be looking at a set of signals and generating an event when an activity or transaction completes for example a read or write transaction. In this case the monitor has to be smart to recognize the start and end of a transaction not just look at changes in signal values. Once a transaction is complete it not only raises a flag but passes the details of the transaction to any component in the design who wants to observe it. The details can be as simple as the address and data in a read/write transaction or as complex as all the fields in a PCIe transaction like address/data/requester ID/CRC/Error status etc. This kind of monitor is harder to write but yields the best results in quality of data generated as well as speed of execution by the components which use the data – for example a scoreboard. A monitor in a modern UVM based verification environment is usually a component of an agent which is described later.

Generally monitoring is used to generate data for scoreboarding, for debug, for coverage collection, and for further downstream processing. A scoreboard is usually used to predict or check behavior. A typical scoreboard listens to a monitor and is written to receive the same format of data being generated by the monitor. In most cases it is processing two or more streams of data coming in. One stream of data can be coming as a result of a write transaction and the other from a read transaction. The scoreboard in this case will compare if the data being read from a slave address is the same as the data which was written In a simple scoreboard you might only be looking at one specific protocol eg, both the data being written and read is of type AXI.

In a more complex case you might generate a write using a AXI but that might get morphed into a USB bulk out. Similarly a read might begin as a USB bulk in and translate into an AXI read. The scoreboard in this case will be dealing with multiple streams of traffic being generated by several different monitors each snooping different sections of the design. The task of writing effective scoreboards has always been a vexing one. Yet, the problem actually begins with the data being sent to the scoreboard from the monitor.