Home > Community > Blogs > Functional Verification > uvm testflow phases debugging part i identifying blocking activities
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

UVM Testflow Phase Debugging- Identifying Blocking Activities

Comments(0)Filed under: Functional Verification, Specman, IES-XL, uvm, methodology, e language, advanced verification, Testflow, blocking activities, testflow phases, testflow phase debugging, AFUVM Testflow debugging capabilities have been recently enhanced through the addition of more information to the output of the show domain command. In this post, we demonstrate how this information can be used to answer such questions as  
  • 1. What domains are in the environment? What units do they contain?
  • 2. What phase is running now?
  • 3. Why are we still in this phase? Which activity is still running, and blocking us from proceeding?
  • 4. ... and more...
The following screen shot shows the output of a show domain command, where blocking activity prevented a domain from proceeding to the next phase.

 

Notice that from the output of this command, we can learn the following:

  • There is a domain named ENV_A_DOMAIN, and it contains three units: my_bfm-@2, my_driver-@1, and env_a-@3.
  • The domain is running the phase MAIN_TEST.
  • The domain has not proceeded to the next phase because of the following blocking activities:   
    • The unit env_a is running the blocking thread tf_main_test.
    • There is also a blocking sequence: my_seq-@7.
    • As you can see, there are also blue hyper links to the sources of the two blocking threads
      1. We can also see that the timeout value of this phase is 1 millisecond, and that we are at the beginning of the phase – still ~999 microseconds before the watchdog timer will expire.

        It may happen that a domain had finished all its current phase activities, but is not proceeding to the next phase, because it waits for a domain it depends on. The show domain command gives this information.

        In the following screenshot example, the ENV_B_DOMAIN completed its FINISH_TEST phase activities, but waits for ENV_A_DOMAIN to finish its FINISH_TEST activities before it can proceed to the next phase.

         

          

        To display all defined dependencies at any time during the test, you use the show dependencies command. The following show dependencies screenshot example lists these dependencies between the three domains defined in this environment:

         

        Read more about Testflow, defining domains activities and domains dependencies, in the UVM e Reference Manual.

        Enjoy verification! 

        Efrat Shneydor,

        UVM e

        Comments(0)

        Leave a Comment


        Name
        E-mail (will not be published)
        Comment
         I have read and agree to the Terms of use and Community Guidelines.
        Community Guidelines
        The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.