An interesting thing happened on the way to arriving at a completed article about the AMIQ APB VIP: the code-base changed completely removing a layer of abstraction! It’s a pretty cool little testament to the age of open source coding, and perhaps also to the agile manifesto which reads, in part, “…we have come to value…working software over comprehensive documentation.” I’ll save the—maybe obvious—digression into inheritance vs. duplication of code for another post. For now, I’ll go ahead and post the original article—a bit of a historical anachronism even if only by five days—because it provides perspectives into the design and construction of UVM objects that are hopefully still valuable examples.
by Hamilton Carter – Senior Editor
Why UVM and reuse?
Build it once, use it anywhere? You can have that, but you’ll have to pay. The good news is that if you do your job correctly, you only have to pay once. The really good news is that the authors of UVM have already done most of the heavy lifting.
As you build each gleaming piece of your verification environment, there are a few reuse goals you should keep in mind:
- If at all possible, you don’t want to ever touch the code again… not ever. You’ve got better things to do with your life, not the least of which is to create the next piece of gleaming verification goodness.
- You’ll want to be able to pass it around. It’s good stuff! Your buddies should totally get the benefit of knowing you—by having easier verification lives—through reuse of your stuff.
- Since you’re going to pass the code around, you’ll want it to seamlessly play with other pieces of verification IP. This will make it easier for your buddies to use it and make you look like a genius! It will also cut down on the number of support calls you get because—you know—you’re already working on the next great thing!
Amiq’s recent open source release of their AMBA-APB, UVM-compliant verification IP, (acronyms! Everywhere acronyms!!!), gives us a nice platform to play around with and have discussions about UVM without the usual ‘invented here’ and NDA burdens to carry. As an example of what UVM can buy for you, and what you have to pay to get it, let’s review an otherwise rather innocuous part of the APB UVC’s architecture: the connection between the monitor and coverage collector.
The above-mentioned reuse goals are accomplished for the APB bus monitor and its associated coverage collector. Either of the two pieces can be used independently of the other. It’s all done through the use of TLM ports and the factory. Let’s walk through the code to get a good firm grounding of what’s there and how it’s done. As we do, I’ll sprinkle in architectural and procedural details.
If you want to follow along in your code editor, you’ll need to pull the code repository for the AMBA APB project from https://github.com/amiq-consulting/amiq_apb as well as the supporting abstraction layer, (also from AMIQ), at https://github.com/amiq-consulting/cagt. We’ll be rooting around in the sv subdirectory in each case.
NOTE: With the recent code changes to the AMIQ APB VIP, to follow along clone the historical version of the APB code from https://github.com/hcarter333/amiq_apb.git.
Broadcast News
First, a few introductions: The monitor’s job is to watch the APB bus and report, (broadcast actually), everything that’s happening. The coverage collector’s job is to receive information from the monitor and format it into a cogent picture of the functional coverage generated by a given testcase.
A little bit of scrounging in the coverage collector code quickly reveals that it’s activated when the write_item_from_mon function is called.
function void write_item_from_mon(amiq_apb_mon_item transfer);
if(transfer.end_time != 0) begin
cover_item.sample(transfer);
This is also where the mysteries begin. Who calls this function? Since we’re collecting coverage based on what the monitor sees, the monitor would be the logical culprit. A quick look at the monitor though reveals nothing. The function is never mentioned. The monitor does call a write function, but not write_item_from_mon. Could the two be related? Yup, they are.
Here’s what’s going on. At the end of the day, you’d like to be able to use the monitor minus its associated coverage collector, (in an accelerated environment for example), without the monitor being any the wiser. To pull this off, the authors used something called a TLM analysis port.
Image may be NSFW.
Clik here to view.
Monitor and coverage collector each with their associated TLM ports
The TLM port instantiated within the monitor provides a broadcast method named ‘write’. The monitor calls this method without a clue as to whether anyone else is listening. He proudly proclaims his latest APB news, and couldn’t care less if anyone hears.
The write method lives inside the monitor’s output_port and this brings up our next mystery. Try to find where in the monitor the output_port was instantiated. I dare you! It’s just not there. Careful attention to the figure above reveals answer. The output port is declared in an abstract version of the monitor defined in the cagt package mentioned at the start of the article.
Amiq encapsulated the most basic, (and by basic I mean foundational, and by foundational, I mean the literal foundation of the environment), elements of the verification environment in the cagt package. Almost all verification environments have monitors right? Consequently, we’d like to have to write the foundational monitor code once and then leave it alone. To accomplish this, the basics for the monitor are setup in the more abstract cagt package instead of the AMB/APB package.
A look at the cagt monitor reveals the declaration and instantiation of the monitor’s output port. Now we know how the monitor is sending it’s messages out—using the output ports write method—as well as where the output port is declared—in cagt_monitor.sv.
Next: Tuning the Receiver