You are on page 1of 3

ftp://mtidl:bUul6@ftp.model.com/EDU/modelsim-pe_student_edition.exe Phases Versus Threads :Building a testbench for personal use is easy.

Building a testbench that can be used by others is much more difficult. To ma e it easier for verification IP wri tten by different people to interoperate, modern verification methodologies supp ort the concept of standardized phases during a simulation run. Phases are a way t o help verification engineers communicate in a standard language about what is m eant to be ta ing place at any given time during a simulation. For example, an explicitly phased VMM testbench built using vmm_env contains the following phase s 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 rese t logic. Similarly, the bul of the simulation activity will li ely occur durin g the wait_for_end phase. The VMM now has support for implicit phasing. In an i mplicitly-phased system, components in the verification environment are stepped through each phase automatically by a global controller called vmm_simulation (a nd its associated timelines). In both the explicit and implicitly phased cases, the phases serve as guides thr ough the simulation. However, most of the real wor of the testbench will be acc omplished by threads spawned off from these phases. It is easy to spawn threads using a simple for /join, but the VMM provides tools to ma e 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 t o 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 sto p the transactor during the same or a later phase. The transactor could then que ry the current phase and change its behavior depending on the state of the simul ation. Users can also modify their behavior via the use of callbac s. Here is a diagram demonstrating the interaction between threads and an example subset of the new VMM implicit phases. The diagram demonstrates activities that ta e place during specific phases of th e 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 s hutdown phase). The astute reader will note that I didnt really need standardize d phases at all to handle this. I could have done all of the activities describe d above in the run phase. In fact, thats what many people do, even today where othe r 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 verificat ion IP will be easier to reuse in other compatible environments.

Implicit versus Explicit :Phases and threads are conventions used to simplify testbench development. The c

lassic 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 manageme nt. Phases were managed explicitly, that is to say, users had complete control ove r when to step the environment and its subcomponents through individual phases v ia function and tas 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 w ays. In an implicitly-phased testbench, functions and tas s representing phases are called automatically at the appropriate times. A global controller (vmm_simu lation) wor s in conjunction with specially configured schedulers (vmm_timeline) to wal all testbench components through relevant phases. vmm_simulation acts l i e a conductor, eeping all of the various testbench components in sync during pre-test, test, and post-test portions of a typical simulation. A natural question to as is, Are there any benefits to implicit phasing over and above the explicit phasing techniques Im using today? When testbench components a re wal ed through phases automatically, there are a few interesting possibilitie s that arise. For starters, it becomes possible to add and remove phases. Lets im agine a simulation that has the following phases1: 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 p hased environment, Id need to have control of the code that called the sub-compon ents training phase in order to ensure the tas in question was not called. In an implicitly-phased environment, I can simply delete the phase from being execute d 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 anoth er so that the two phases overlap. For example, lets say I need the reset phase o f one portion of my design to overlap with the training phase of another. I coul d 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_for _tas _phase_def #(group1); `vmm_typename(reset_during_training_phase_def) virtual tas do_tas _phase(group1 obj); if(obj.is_unit_enabled()) obj.reset_ph(); endtas :do_tas _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 t hreads, is also phased. Because of this, your transactors are now aware of the s tage of the simulation we are in at any given moment. They can then change their behavior based on this nowledge. Because of this, VIP developer could configur e a transactor to automatically start during the reset phase, stop during traini ng, and continue during the start phase. Users could easily reconfigure the tran sactor 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 ma e when building a verification environment. Should you build it based on implicitly or explicitly-phased components? Luc ily, it is possible to use implicitly-phased components in an explicitly-phased environment, and vice versa. My recommendatio n is for users to create all new testbench code using implicit phasing. If you a re used to explicit phasing, the new development style can seem perplexing. Howe ver, as I mentioned, implicit phasing is effectively a superset of explicit phas ing in its capabilities. Adopting the new methodology across your entire team wi ll ensure the additional capabilities discussed above are available in your test bench in the future without users having to ma e changes down the road.

You might also like