Archive for November, 2009

Dr. Ambar Sarkar, Chief Verification Technologist, Paradigm Works Inc.

Ever get stuck trying to configure an object deep inside a verification environment? More likely than not, someone else created the environment, changed it drastically over time, and did not leave a description of the object hierarchy. It is quite time-consuming to unravel the whole hierarchical path from the root to that object. The phrase “needle in a haystack” comes to mind.

I will share some tips on how the vmm_object class, recently added to VMM1.2, can help.

As you are most likely aware, a typical verification environment today contains hundreds of classes defined by the user. Many of these are related to each other in parent/child relationships, creating several hierarchies.

As you are most likely aware, a typical verification environment today contains hundreds of classes defined by the user. Many of these are related to each other in parent/child relationships, creating several hierarchies.

So how does the vmm_object class help in traversing these hierarchies? In a nutshell, it is the base class for all classes defined in the VMM library. This means that for every object derived from a class in the VMM library, you can use the same API for:

• Finding its type
• Finding its ancestors and children
• Avoiding name clashes ( a new feature called namespace and we will save this topic for another post)
• Displaying the hierarchy
• Iterate over the objects
• Find object by a regular expression search

The last two bullets above are what I feel help me most, because:
a. I do not have to write separate code for traversing the hierarchy of different types of objects.
b. I can locate an object easily without having to remember or figure out the exact path to it.

Here is an example. I wanted to access all the atomic generators in my environment and they were all named with the suffix GEN.

There are at least two ways to accomplish this:

1. Use the `foreach_vmm_object macro:

// Configuration phasefor test

virtual function void configure_ph();

string pattern = “@%*GEN”; // regular expression used to search for generator name

// Just iterate over all `VMM_ATOMIC_GEN objects that end with “GEN”
`foreach_vmm_object(`VMM_ATOMIC_GEN, pattern, env)
begin
// Do something with this generator
`vmm_note(log, $psprintf(“Found %s\n”, obj.get_object_name()));
end

When applicable, this approach seems like a quite concise way to get things done. Do note that the implementation of `foreach_vmm_object macro requires it to be the first statement following the declarations in a method or following a begin keyword due to the way it is implemented.

Of course, you can avoid the macro if you are so inclined as shown below. Sometimes I do this to get better visibility while debugging.

2. Use iteration class vmm_object_iter provided with this release:

… vmm_object_iter iter; // iterator object vmm_object obj; `VMM_ATOMIC_GEN at_gen; string pattern = “@%*GEN”; // regular expression used to search for generator name // Just iterate over all `VMM_ATOMIC_GEN objects that end with “GEN” iter = new(env, pattern); // Get a pointer to the iterator obj = iter.first(); // Get the first in the list while (obj != null) begin // Always check type! if (!$cast(at_gen, obj)) `vmm_error(log, $psprintf(“Unexpected type for %s. \n”, obj.get_object_name())); // Do something with this generator `vmm_note(log, $psprintf(“Found %s\n”, obj.get_object_name())); obj = iter.next(); // Get the next one end

Pretty much similar to what I expected as a use model for an iterator class.

Of course, your mileage/opinion may differ from mine. Please share how you plan on using the common vmm_object base class in your daily verification tasks.

This article is the 2^nd in the Verification in the trenches series. Hope you found this article useful. If you would like to hear about any other related topic, please comment or drop me a line at ambar.sarkar@paradigm-works.com. Also, if you are starting out fresh, please check out the free VMM1.2 environment generator at http://resourceworks.paradigm-works.com/svftg/vmm .

JL Gray, Verilab, Inc.

In my last post I discussed the difference between phases and threads in the VMM. Phases and threads are conventions used to simplify testbench development. The classic VMM approach has been to use the vmm_env and vmm_subenv classes to manage phases of testbench components, leaving vmm_xactor to deal with thread management. Phases were managed “explicitly”, that is to say, users had complete control over when to step the environment and its subcomponents through individual phases via function and task calls.

The VMM 1.2 introduces the concept of “implicit” phasing. Both implicit and explicit phasing can be used to accomplish many of the same goals, albeit in different ways. In an implicitly-phased testbench, functions and tasks representing phases are called automatically at the appropriate times. A global controller (vmm_simulation) works in conjunction with specially configured schedulers (vmm_timeline) to walk all testbench components through relevant phases. vmm_simulation acts like a conductor, keeping all of the various testbench components in sync during pre-test, test, and post-test portions of a typical simulation.

A natural question to ask is, “Are there any benefits to implicit phasing over and above the explicit phasing techniques I’m using today?” When testbench components are walked through phases automatically, there are a few interesting possibilities that arise. For starters, it becomes possible to add and remove phases. Let’s imagine a simulation that has the following phases¹:

• reset_ph
• training_ph
• config_dut_ph
• start_ph
• shutdown_ph

What happens if I need to use a piece of verification IP that has implemented a training phase that is not applicable in my test environment? In an explicitly phased environment, I’d need to have control of the code that called the sub-component’s training phase in order to ensure the task in question was not called. In an implicitly-phased environment, I can simply delete the phase from being executed on that component:

my_enet_component.override_phase(“training”, vmm_null_phase_def);

In addition to adding and removing phases, you can also alias one phase to another so that the two phases overlap. For example, let’s say I need the reset phase of one portion of my design to overlap with the training phase of another. I could reconfigure the phasing of the components so they occurred in parallel instead of serially. Here are the steps:

• Disable the reset phase for the group 1
  
  group1.override_phase(“reset”, vmm_null_phase_def);

• Create a new user-defined phase for group 1 called “reset_during_training”
  
  class reset_during_training_phase_def extends
  vmm_fork_task_phase_def #(group1);
  `vmm_typename(reset_during_training_phase_def)

  virtual task do_task_phase(group1 obj);
  if(obj.is_unit_enabled())
  obj.reset_ph();
  endtask:do_task_phase

  endclass:reset_during_training_phase_def
  

• Alias the new user-defined phase to the “training” phase
  
  vmm_timeline tl = vmm_simulation::get_top_timeline();
  tl.add_phase(“training”, reset_during_training_phase_def);

Another benefit of implicit phasing is that vmm_xactor, which normally manages threads, is also phased. Because of this, your transactors are now aware of the stage of the simulation we are in at any given moment. They can then change their behavior based on this knowledge. Because of this, VIP developer could configure a transactor to automatically start during the reset phase, stop during training, and continue during the start phase. Users could easily reconfigure the transactor to start and stop at other times as needed.

One thing to note is that implicitly phased components can be phased explicitly if desired by the user. This means that implicit phasing provides a superset of the explicit functionality provided by vmm_env and vmm_subenv.

The addition of implicit phasing means developers now have a choice to make when building a verification environment. Should you build it based on implicitly or explicitly-phased components? Luckily, it is possible to use implicitly-phased components in an explicitly-phased environment, and vice versa. My recommendation is for users to create all new testbench code using implicit phasing. If you are used to explicit phasing, the new development style can seem perplexing. However, as I mentioned, implicit phasing is effectively a superset of explicit phasing in its capabilities. Adopting the new methodology across your entire team will ensure the additional capabilities discussed above are available in your testbench in the future without users having to make changes down the road.

¹ The listed phases are a subset of the actual pre-defined implicit phases available

John Aynsley, CTO, Doulos

You may have noticed that the public release of VMM 1.2 is just around the corner, and with this new version of VMM comes the introduction of features inspired by the SystemC TLM-2.0 standard.

Excuse me! TLM-2.0? What? Why do we need features from SystemC in VMM?

I will set out to answer that question fully in a series of blog posts over the coming months. But first off I will remark that the idea is not so strange. After all, VMM has always been transaction-level (with a small ‘t’ and ‘I’). Communication within a VMM verification environment exploits transaction-level modeling for speed and productivity, because “TLM” is about abstracting the model of communication used in a simulation. If we can adopt a common standard for transaction-level modeling across both SystemC and SystemVerilog, that has to be a good thing for everyone. It is evident that the design and verification community demands more than one language standard (witness VHDL, SystemVerilog, C/C++, and SystemC). Each individual language standards has progressed over time by borrowing the best features from the others. Having VMM borrow features from SystemC makes it easier to learn and work with both standards.

The other natural link between VMM and SystemC is that mixed-language simulation environments and C/C++ reference models are not unusual. Virtual platform models, as used for software development and architectural exploration, are growing in importance, and the SystemC TLM-2.0 standard is used to achieve interoperability between the components of a virtual platform model. If a constrained random VMM environment is to be used with a reference model that consists of a virtual platform adhering to the SystemC TLM-2.0 standard, then having TLM-2.0 support within VMM promises to make life easier for the VMM programmer.

Besides interoperability, the other main objective of the SystemC TLM-2.0 standard is simulation speed. The combination of speed and interoperability is achieved by the technical details of the ways in which transactions are passed between components. Fortunately, those technical details are a good fit with the way communication has always worked in VMM. In particular, both VMM and TLM-2.0 support the idea that each transaction has a finite lifetime with a well-defined time-of-birth and time-of-death.

The SystemC TLM-2.0 standard is based on C++. Unfortunately, not all C++ coding idioms translate naturally into SystemVerilog, so the transaction-level communication in VMM 1.2 is “inspired by” the TLM-2.0 standard rather than being a literal rendition of it.

So what are these new features? If you are already a SystemC user you may recognize ports and exports, borrowed directly from the SystemC standard, and analysis ports, transport interfaces, sockets and the generic payload, borrowed from the TLM-2.0 standard. I will explain how VMM is able to exploit each of these features in future blog posts, so watch this space…

Avinash Agrawal, Corporate Applications, Synopsys

Is it possible to find out which VMM callbacks are registered with a particular vmm_xactor instance?

The answer is yes. Here’s how:

The vmm_xactor base class in VMM instantiates a queue of vmm_xactor_callbacks, callbacks[$]. So, it is possible to use the queue methods to find out details on the callbacks associated with an instance of the vmm_xactor class. To find out the number of callbacks associated with a vmm_xactor instance, we can use the size() function on the callbacks queue. And to list the names of the callbacks associated with the vmm_xactor instance, we can add a new string member (that would carry the name associated with the callback) to the classes derived from vmm_xactor_callbacks, and display this string variable as needed.

Here is an example. Assume that we have extended the vmm_xactor_callbacks class as follows. We also add a string name, that would carry the name associated
with the callback.

class atm_driver_callbacks extends vmm_xactor_callbacks ;
string name;
// Called before a transaction is executed
virtual task pre_trans_t(atm_driver master, atm_cell tr, ref bit drop); endtask
// Called after a transaction has been executed
virtual task post_trans_t(atm_driver master, atm_cell tr);endtask
endclass

The vmm_xactor instance can have a task as follows that displays the callbacks associated with that vmm_xactor instance, as the following example code shows:

task atm_driver::displaycallbacks;
begin
atm_driver_callbacks mycb = new();
$display(“2LOG : number of callbacks is %d\n”, callbacks.size());
$cast(mycb,callbacks[0]);
$display(“2LOG : callback[0] is %s\n”, mycb.name);
$cast(mycb,callbacks[1]);
$display(“2LOG : callback[1] %s\n”, mycb.name);
end
endtask

And, in the build() method of the environment, we have the following code:

//Instantiate the callback objects
atm_sb_callbacks atm_sb_cb = new();
atm_cov_callbacks atm_cov_cb = new();
atm_driver_callbacks mycb = new();
atm_cov_cb.name = “CBNAME1″;
atm_sb_cb.name =”CBNAME2″;

//Register the callbacks to the driver instance drv
this.drv.append_callback(atm_cov_cb);
this.drv.append_callback(atm_sb_cb);
//Call the xactor instance class method that displays the callbacks as follows:
this.drv.displaycallbacks;

This will produce the following output:
LOG : number of callbacks is 2
LOG : callback[0] is CBNAME1
LOG : callback[1] CBNAME2

As seen in the output pasted above, the names and the number of VMM callbacks are registered with the particular vmm_xactor instance, are displayed.

Dr. Ambar Sarkar, Chief Verification Technologist, Paradigm Works Inc.

As a soup-to-nuts functional verification consultant, I always find myself as an integral member of my client’s verification team, be it during the project planning stage or during the mad rush end of the tape-out. The roles include everything; being an individual test writer, a verification architect, or even as the verification lead for a globally dispersed large verification team. And yes, the schedules are invariably aggressive, and the budgets tight.

So how does having a sound verification methodology such as VMM help? Broadly speaking, it offers a framework within which the verification engineer can get the job done efficiently. Instead of spending time on environment and methodology issues such as wondering about how to configure all the verification components to the same setting, he or she can focus more on identifying the application specific scenarios and easily configuring the environment to generate those. The challenge, of course, is being able to understand exactly how the methodology helps within the context of a given project.

Given this challenge, I often find myself explaining to teams, in terms of their existing verification environments, how a methodology or a feature can help and the corresponding trade-offs involved. Of course, not every feature is applicable to the needs of a given team, so I pay extra attention in explaining how a feature helps, its pros-and-cons, and how to best integrate it with the current verification environment.

In this series of blog posts, I will share my opinions on how the features newly introduced with the VMM1.2 release can help or could have helped the projects I have been directly involved with so far. Of course, I will not share the gory details, but I hope to share enough so that anyone looking at these new features can evaluate them from an end-user’s perspective.

So what’s new with VMM1.2? And how does it help? Check out the table below where it identifies some of the key features, and a “one-line” description for each. This table reflects how I see these features potentially benefit the projects I have worked with; your mileage may vary.

Feature	Description
vmm_object	A base class for all object types, making it easy to traverse hierarchies and locate objects by name
vmm_unit	A base class for all structural elements such as generators, transactors etc, making it easier to synchronize their actions when executing the phases of a test
vmm_timeline	Allows users to coordinate and even define custom phases
vmm_test	Adds support for multi-test management
`vmm_unit_config_xxx	Macros to configure and build verification environment structure in a top-down manner
vmm_opts	Flexible options handling, command-line or otherwise
vmm_rtl_config	Facilitates covering cases where a number of structural configurations for the RTL exist
vmm_tlm	Making sure your components can really connect to each other and foreign objects in a “plug and play” manner
regular expressions	A very convenient way to access objects by name and set specific properties to them
`vmm_class_factory	Macros to replace and extend object functionality anywhere in the code hierarchy conveniently, and support top-down build process

Table 1. VMM 1.2 Features

While the “one-liner”s above help get an overall idea about the feature, the Verification in the trenches series of blog posts will describe each in further detail starting with their motivation, pros and cons, and how to incorporate them quickly. The hope is that you will be able to judge for yourself how some of the features described can help your current and future project needs.

Feel free to comment/share your opinions and experiences. I will be very interested in hearing from folks in the trenches. How are these features working out for you? Are you getting the benefits as you had hoped? Which one of these features you can use today? Drop me a line! Share!

Ajeetha Kumari & Srinivasan Venkataramanan, Contemporary Verification Consultants (CVC),

Ramanathan Sambamurthy, Cisco Systems

As verification specialists, like some of our readers, we thrive on solving challenging problems. Specifically Debug is an area that fascinates us a lot. Here is one of them, using VCS’s Aspect Oriented Extensions (AOE) to SystemVerilog to debug a Memory blow-up in SV-TB code. The problem statement was elaborated in our previous entry: http://www.vmmcentral.org/vmartialarts/?p=385

We brainstormed on potential improvements in order to shorten debug cycles in the future. One option we explored was the use of SIZED mailboxes, when applicable:

function new();

// parameter MBOX_SIZE = 100;

this.out_mbx = new(MBOX_SIZE);

endfunction : new

A better, scalable option is to use a wrapper class around plain SV Mailboxes. That would then allow AOE to aid in debug around the “put”. For instance, consider a simple class-wrapper around a SV Mailbox:

class mbox_c;

mailbox mbox;

function new(string name);

this.name = name;

this mbox = new();

endfunction : new

virtual task put (my_xactn x0);

this.mobx.put(x0);

endtask : put

// Similarly get(), new() etc.

endclass : mbox_c

Now, instead of a plain mailbox, we have a wrapper around it called mbox_c. Assuming that this wrapper was used all across the environment instead of the mailboxes, one can leverage the VCS’s Aspect Oriented Extensions to SystemVerilog to the rescue. In a separate file one can write:

extends chan_dbg(mbox_c);

before task put(my_xactn x0);

$display (“%m AOE: Mailbox %s size is %0d”, this. name,

this.num());

endtask : put

endextends

In contrast to standard OOP, AOE allows “in-place extensions” and hence adds to existing class code without creating hierarchy new class type. This means no factory is needed to swap the base class with a derived class and other associated extra code. Instead, just an additional file with few lines and you are set to go! While some of us may debate whether this is a good coding style for developing reusable environments, for throw away code like debug this is very handy as it requires no intervention to existing code. For instance, with the above code, a typical VCS run (with the dbg.sv code included in command line) produces the following output:

mbox_c::put_before AOE: Channel S2P_BFM_IN_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_SER_MON_OUT_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_PAR_MON_OUT_CHANNEL level is 1

mbox_c::put_before AOE: Channel S2P_BFM_IN_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_SER_MON_OUT_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_PAR_MON_OUT_CHANNEL level is 2

mbox_c::put_before AOE: Channel S2P_BFM_IN_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_SER_MON_OUT_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_PAR_MON_OUT_CHANNEL level is 3

mbox_c::put_before AOE: Channel S2P_BFM_IN_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_SER_MON_OUT_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_PAR_MON_OUT_CHANNEL level is 4

mbox_c::put_before AOE: Channel S2P_BFM_IN_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_SER_MON_OUT_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_PAR_MON_OUT_CHANNEL level is 5

mbox_c::put_before AOE: Channel S2P_SER_MON_OUT_CHANNEL level is 0

mbox_c::put_before AOE: Channel S2P_PAR_MON_OUT_CHANNEL level is 6

Of course, there are few safe-guards for such common pit-falls. We address this topic in our VMM adoption book (http://www.systemverilog.us/vmm_adoption) in Chapter-8, Advanced Topics (Section 8.3).

· A vmm_channel (equivalent of a Mailbox in SV) is blocking and has a default size of 1 (can be increased, reconfigured at run time as well)

· It includes built-in debug messages that can be turned on via command line

· It provides a vmm_channel::sink() routine – can be useful if the consumer is not available for integration

· It allows similar AOE debug extension, a code snippet is shown below:

extends chan_dbg(vmm_channel);

before task put(vmm_data obj, int offset = -1,

`VMM_SCENARIO grabber = null);

$display (“%m AOE: Channel %s level is %0d”,

this.log.get_name(),

this.size());

endtask : put

endextends

Janick Bergeron, Synopsys

Two years ago, Francoise left her job as a VMM/verification CAE with Synopsys. Her husband Pierre similarly quit his job at a large semi-conductor company. They embarked on a career change, the magnitude of which few of us undertake voluntarily: they traded high-tech careers and their Porsches for a tractor and ATV and took over Francoise’s father’s vineyard in south-western France

I had the pleasure of working with Francoise for several years before and, upon hearing the news, the wine-enthusiast in me quickly promised to help her with her harvest. This year, I made good on my promise. On October 27th, at 12:30pm, my girlfriend and I landed at the Pau airport, full of energy and anticipation at the prospect of experiencing a tiny sliver of a winemaking tradition that goes back 400 years.

North Americans have a very distorted sense of time. One hundred years is “old” to us. Very few can trace their ancestry on this continent beyond a few generations.

Francoise’s winery, Domaine Guirardel, is housed in the original home and barn. They were built at the same time Samuel de Champlain was busy establishing Quebec City. The “new” house is 300-years old. Both are nestled on a south-facing hill with an incredible view of the Pyrenees. The domaine has never been sold: it has always been passed down through generations.

 

The postcard atmosphere of the place immediately reminded me of the movie “A Good Year”. A hammock is hung between two palm trees. Jean, Francoise’s father, is at work in an immense garden that is the source of many of the vegetables we will be eating throughout our stay. Lunch is often served on the front patio, under the protective shade of a huge oleander tree.

The vineyard is small: 5 hectares planted with Petit Manseng and Gros Manseng, two of the five varietals that make up the Jurancon appelation. The harvest is done entirely by hand by uncles, aunts, in-laws, cousins and friends, most of whom have been helping with the harvest for many years. Of the 20 or so harvesters, it is a first experience for only four of us.

The work is simple: armed with shears, one cuts the bunches of golden grapes from the vines into plastic buckets. The content of full buckets is then transferred to a large bin behind the tractor.

The day starts at 9am. We break for lunch at 1pm, then resume at 3pm until 5pm. It is intense but not hard work. Despite the physical nature of the work, shuffling along the vines shifting buckets up the hill and untangling twisted bunches of grapes, I was surprised to discover that it is accomplished in a very social and jovial atmosphere. Everyone is chatting and updating one another on common acquaintances.

 

 

 

Lunch is reminiscent of a Thanksgiving dinner in the U.S. Everyone gathers in the dinning room, in front of a fireplace large enough to roast an entire cow, and share in a feast of delicacies from various French regions: home-made peach wine, raw oysters from Brittany, sausages from Corsica, wine from Bordeaux, Bearn pork bellies and many others.

Going back to the fields filled with so much great food is not easy! But the grapes cannot wait and we must make the best of the ideal weather conditions. Francoise and her father have been working in the chais since 7am, busily cleaning the press to receive the freshly-picked grape. And they will continue to work after dinner to complete the last pressing of the day.

At the end of the day, under Francoise’s watchful eyes, everyone gathers again in the Tasting Room for a glass of the proprietor’s wine. It gives us a glimpse of what our (and her) labor will yield in two years.

 

 

 

Trading a keyboard, mouse and a well-paying secure job for a mechanical press, half a dozen stainless steel vats, oak barrels and the uncertainties of climate vagaries requires more courage than I possess! They are bringing their technical and marketing savoir-faire to this artisanal enterprise in the hopes of ensuring the future of their two children. For example, they are continuing the production of a late-harvest version of their wine, an experiment that was started back in 2005 and repeated only once in 2007. They are also planning to reclaim vines currently leased to another producer and, under the aegis of being a “young farmer”, plant additional vines in a new parcel of land.

She produces three wines: Tradition, Bi de Prat and Vendanges Tardives. They are very fruity, syrupy white wines similar to Sauterne, excellent with foie gras. Unlike most white wines, hers will improve with age, up to 20 years. A few years ago, I had the great fortune of tasting the 1967 vintage: it was the color of maple syrup and was totally sublime. Unfortunately, her wines are not available in North America (which makes the dozen or so bottles I have in my cellar even more precious!).

The French have a poor reputation when it comes to visitors. But it has never been my experience – nor mustn’t it be for the majority of visitors that continue to make France the single-most visited country in the world. And it most definitely has not been the case for our 6-day stay with Francoise and Pierre. We were welcomed in their home and immediately treated like family. It has been a wonderful experience that I hope I’ll be able to repeat next year.

For further reading (in french): http://www.sudouest.com/accueil/actualite/vin/article/757483/mil/5310416.html

JL Gray, Consultant, Verilab, Austin, Texas, and Author of Cool Verification

Building a testbench for personal use is easy. Building a testbench that can be used by others is much more difficult. To make it easier for verification IP written by different people to interoperate, modern verification methodologies support the concept of standardized “phases” during a simulation run. Phases are a way to help verification engineers communicate in a standard language about what is meant to be taking place at any given time during a simulation.  For example, an explicitly phased VMM testbench built using vmm_env contains the following phases of execution:

· gen_cfg

· build

· reset

· config_dut

· start

· wait_for_end

· stop

· cleanup

· report

Ideally, each of these phases serves a clear purpose. If I want to reset the DUT, a good way to do it is to instrument the reset phase with the appropriate reset logic.  Similarly, the bulk of the simulation activity will likely occur during the wait_for_end phase.  The VMM now has support for implicit phasing. In an implicitly-phased system, components in the verification environment are stepped through each phase automatically by a global controller called vmm_simulation (and its associated “timelines”).  I will discuss timelines in a separate post.  In both the explicit and implicitly phased cases, the phases serve as guides through the simulation. However, most of the real work of the testbench will be accomplished by threads spawned off from these phases.

It is easy to spawn threads using a simple fork/join, but the VMM provides tools to make managing threads easier. In the VMM, the vmm_xactor base class provides support for managing threads and is at the same time phase-aware.  How does it do this?  For starters, vmm_xactor is now implicitly phased by the top level vmm_simulation controller.  However, users maintain full control over the ability to start and stop the transactor, just as they did in earlier versions of the VMM.  That means that a user could start a transactor during any VMM phase, and stop the transactor during the same or a later phase. The transactor could then query the current phase and change its behavior depending on the state of the simulation. Users can also modify their behavior via the use of callbacks.

Here is a diagram demonstrating the interaction between threads and an example subset of the new VMM implicit phases.

The diagram demonstrates activities that take place during specific phases of the testbench. It also shows that threads may start in one phase (such as the host generator starting in the reset phase) and stop in another (in this case, the shutdown phase).  The astute reader will note that I didn’t really need standardized phases at all to handle this. I could have done all of the activities described above in the “run” phase. In fact, that’s what many people do, even today where other phases are available.  The issue, as I stated at the beginning of the article, is that by standardizing when we do specific types of activities, our verification IP will be easier to reuse in other compatible environments.