Posted by Fabian Delguste on 29th May 2009
Fabian Delguste / Synopsys Verification Group
Controlling VMM transactors can sometimes be a bit hectic. A typical situation I see is when I have registered a list of transactors for driving some DUT interfaces but only want to start a few of them. Another common situation is when I want to turn off scenario generators and replay transactions directly from a file. Yet another task I often face is registering transactor callbacks without knowing where they are exactly located in the environment.
As you can see, there are many situations where fine-grain functional control of transactors is necessary.
Since VMM 1.1 came out, I have been using a new base class called vmm_xactor_iter that allows accessing any transactor directly by name. In this case all I need to do is to construct a vmm_xactor_iter with regular expression and use the iterator to loop thru all matching transactors.
To understand better how this base class works, I’ll show you a real life example. The scope of this example is to show how to start generators only when vmm_channel playback has not been turned on. As you know vmm_channel can be used to replay transactions directly from files that contain transactions that were recorded in a previous session. This can speed up simulation by turning off constraint solving.
1. string match_xactors = (cfg.mode == tb_cfg::PLAYBACK) ? /Drivers/” : “/./”;
3. `foreach_vmm_xactor(vmm_xactor, “/./”, match_xactors)
5. `vmm_note(log, $psprintf(“Starting %s”, xact.get_instance()));
- In line 1, match_xactors string takes “Drivers*” value when playback mode is selected otherwise it takes “.” when no this mode is not selected. In the first case, transactors named “Drivers” match otherwise all transactors, including generators match
- In line 3, `foreach_vmm_xactor macro is used to create a vmm_xactor_iter using previous regular expression. This macro can be used to traverse and start all matching objects by using the xact object to access transactors
In case you’d like to have more control over vmm_xactor_iter, it’s possible to use its first() / next() / xactor() methods to traverse matching transactors. Also it’s possible to ensure the regular expression returns at least one transactor. Here is the same example written using these methods.
1. string match_xactors = (cfg.mode == tb_cfg::PLAYBACK) ? “/Drivers/” : “/./”;
3. vmm_xactor_iter iter = new(“/./”, match_xactors);
5. `vmm_fatal(log, $psprintf(“No matching transactors for ‘%s’”, match_xactors));
7. while(iter.xactor()!=null) begin
8. xact = iter.xactor();
Should you need to reclaim the memory allocation required to store all transactors, it’s possible to enable garbage collection by invoking vmm_xactor::kill().
The good news is that vmm_xactor_iter allows me to:
- Configure the transactor without knowing its hierarchy
- Provide dynamic access to transactors
- Reduce code for multiple configurations and callback extensions
- Use powerful regular expressions for name matching
- Reuse transactors: no need to modify code when changing the environment content
I hope you find vmm_xactor_iter, and all of the other VMM features, as useful as I do