Expectations of a Verification IP User: Transaction Modeling

In my blog posts, I will be sharing my expectations from a Verification IP. I will begin with Transaction Modeling.

Having played a role in both developing as well as in using Verification IPs, I consider the transaction class to be the most important component of a VIP. The quality of a transaction class defines the quality of the VIP. Be it UVM, or any other methodology, deciding on the transaction class structure requires sufficient planning as it affects the overall VIP architecture and the verification environment.

Here’s where you can find more information on our Verification IP.

Let me list down some of the guidelines which I think are relevant:

• All the variants of the protocol should be defined in the transaction class. This enables the transaction class to be used to generate all possible kinds of stimulus (while driving the DUT). The bus functional model of the monitor is also then able to extract information from the DUT interface and populate the relevant fields of the transaction class. Specifically for bus protocols, we should have random properties in the transaction class not just for the signal values, but also for all possible delays. This will enable the generators to use constraint random generation to model different speeds as well as to create different delays across transactions. The BFMs can then use the information embedded in the transaction class, rather than generating any on their own.

• Hierarchical vs. Flattened transaction model: Flattened transactions are easy to maintain and are easier to add new constraints. However when the protocol is complex and there is a need to randomize fields procedurally, it is better to have a parent class instantiating an array of children class objects.
  In the example below, the AXI burst class instantiates a queue of data class specific to each beat of the burst. Once the burst fields are generated, data fields get generated in the post randomize() method of the burst. If this transaction model is flattened, then all the fields of axi_data class would have been arrays in the axi_burst class. What would be the drawback here? If a random burst had to be generated, all of the arrays would have been generated in parallel. This can cause additional performance overhead if you have complex constraints.

• Configuration information should be accessible from within transaction class. Any reusable VIP has to be configurable and usually has a configuration descriptor associated with it. Different transactions needs to generate information based on the configuration of the VIP. So, pass the VIP configuration handle to the transaction as a reference either through the hierarchical options (VMM) or from the resource/configuration database (UVM).

• Provide a rich set of utility methods: UVM provides a set of predefined macros which define utility methods like copy, compare, display, etc inside the transaction. Specifically for transactions used in Verification IPs, additional utility methods relevant to the bus protocol being verified can be very useful . This can be used across different components of the VIP. In the AXI example below, method get_trans_addr_by_idx() calculates and provides the address of the ‘data beat’ and the user need not have to worry about whether the ‘burst’ is of wrapped, fixed or increment type. Similarly, you can have a get_data() method which can provide a queue of bytes along with the corresponding data. So the user need not calculate this information separately in his scoreboard.

We can refine these further. Finally what is important is to know that architecting an efficient transaction model would result in an efficient Verification IP. Here I have laid down my thoughts. Depending on the protocol to be verified and the complexity involved, different folks might want to structure their transaction classes differently. However, I believe the above guidelines can be incorporated in most of the protocols in use today. Hope this was useful for you and I would definitely be interested to know what your thoughts are on this topic.

Here’s where you can find more information on our Verification IP.

Authored by S. Prashanth