Tech Tip: Setup Your OVM e Environment So Even Your 16 Year Old Can Use Sequences

A few months ago we introduced the Sequences API in OVM e in the post “OVM e Sequence API Brings Increased Flexibility”.

As described in that post, the Specman docs, and in code examples, one can use the API to create interesting complex scenarios – layering, priorities, accelerating performance, and more. While there are many who dove right in and explored the wide range of benefits that sequences and the API provide, sadly we see many others who believe sequences are “complicated”, especially for short timers brought in to help in the last few weeks of verification before tape out.

Specifically, we’ve heard some verification engineers say, “Sequences are ok for *me* to use, but the test writers are new/part-time-workers/designers, they can not, and do not, want to learn Sequences. It would be easier to get my 16 year old to do something more productive on the computer then hack scripts to pirate music than to get an RTL designer to write Sequences”. If you feel this way, then today’s post is for you, since you clearly:

• Yearn for simple yet efficient way to define a complete test scenario.
• Want a test writing interface which does not require learning new language features.
• Need an interface that does not require knowledge of “Aspect Oriented”, “Object-Oriented, nor “Constraints Driven Generation” programming methodologies.
• In summary, you need something that any programmer, regardless of their language background, can implement immediately with no learning curve.

But before showing the magic of this new API that makes the all of the above possible, let me remind you why you want to use sequences in the first place.

Sequences were introduced about 8 years ago, solving one of the biggest challenges in verification: namely, scheduling multiple tasks when simultaneously driving stimuli into the DUT. Specifically, verification environments need a way to schedule several processes driving input to the DUT such that:

• Some of the processes run independently, in parallel.
• Sometimes there are dependencies between different threads; such as in tests defined as “Write to DUT control register, poll the status register until the DUT entered the new mode, and then send to the DUT illegal data”.
• Some times the threads have relations, such as layered protocols – stimuli generated by one thread is processed by another thread, and then driven to the DUT.

The more complex your device is, the larger number of interfaces your DUT has, the more you need some utility to perform the scheduling for you. If you decide that your verification environment shall not use sequences – someone will have to implement the scheduler with some funky state-machine kludge ….

So let’s go back to this post’s topic – how can the verification environment employ sequences if the test writers do not know how to use them? The answer: we have created a set of methods especially for such test writers, allowing them to define the test scenario:

• From any time consuming method (TCM), i.e. no need to extend a sequence
• Generation knowledge is not required
• They can send items to several drivers from one place

The simplest of the Sequence API methods is the execute_item() method. This method:

1. Adds a data item to the driver’s queue of data items
2. Waits until the item is done (handled by the BFM).

The test writer does not need to know anything about the underlying sequences. As you can see in the code example below – the word “sequence” is not even mentioned. The test writer also does not have to generate the data item using “do” and defining constraints -- they can create the item anyway they prefer. All the test writer needs are two things:

• To know how to create a data item o Each test writer can use their preferred way for creating a data item – For example, they can call new() and assign the fields, then copy() from another place. They can also use “gen” if they are familiar with the constraints solver.
• A pointer to the required driver o Just let your test writers know the location of the required driver

In the following code example, the time consuming method (TCM) creates a packet using new(), and sends it to the packet_driver. Then, it creates a transfer by coping it from a pre-prepared list, and sends it to the transfer_driver.

      extend sys {
          my_test()@clock is {
              var my_packet : packet;
              my_packet = new packet with {
                     //… Assign all packet’s fields
              };
      sve.p_driver.execute_item(my_packet);

             var my_transfer : transfer;
      for each (t) in
               pre_prepared_transfers {
          my_transfer = t.copy();
          sve.t_driver.
               execute_item(my_transfer);
      };
     };

           run() is also {
     start my_test();
     };
   };

The method execute_item() is the shortest coding style, and gives a basic control on the driver. Of course some test writers want finer control and synchronization with the driver. These writers can use more of the driver methods, such as wait_for_grant(), which indicates that my turn in the queue had arrived, meaning “my item is the next item to be sent”. For example:

      extend sys {
     my_test()@clock is {
        var my_packet : packet;

                // wait for my turn
       sve.p_driver.wait_for_grant();

              // only now, when I know I am
       // the next to be served by the
       // driver – create my packet
       // and send it
       my_packet = new packet with {
       //… Assign all packet’s fields
       };
       sve.p_driver.send_item(my_packet);
     };

           run() is also {
       start my_test();
     };
   };

The two examples shown above demonstrate three of the API methods – execute_item(), wait_for_grant() and send_item(). These 3 methods should get your test writers (and your 16 year old) started. To see the full API, please refer to OVM e Reference Manual in the Specman/IES-XL online help. Note that this guide is also provided within the SoC Verification Kit which shows some more common use models of the Sequences API.

Happy coding!

Efrat Shneydor
Specman & Methodology R&D