Thought Leadership

Why are UVM transactions built with uvm_sequence_item?

What is a UVM transaction?

A transaction in UVM is a class with properties for the signals, such as address and data, plus extra information such as errors or delays. This is great for sending in one piece of stimulus, but you can’t verify a design with a single transaction. You need groups of related transactions.

What is a UVM sequence?

A group of related transactions in UVM is called a sequence, and the individual members are called sequence items. When you write your transaction classes, extend uvm_sequence_item, not uvm_transaction. Here is the OOP hierarchy for these classes, including your transaction class, called tx_item.

Advantages of uvm_sequence_item

The class uvm_transaction is left over from an older methodology and has no context, no knowledge of being part of a group of transactions. The class uvm_sequence_item has several properties that connect it to the outside world. These properties are not in uvm_transaction. UVM has set()/get() methods for them, so don’t read or write them directly.

  • When you send a transaction to a driver, that is called a “request”. For something like a memory read, there is a “response”, which is an object that holds the data coming back from memory. The driver might be processing several requests concurrently and needs to route the response to the proper sequence. The class uvm_sequence_item has a property with the sequence ID so the response is sent to the correct place.
  • The UVM sequencer is the “traffic cop” that arbitrates between concurrent sequences that want to send through the same driver. uvm_sequence_item has a handle to the sequencer that you passed to the sequence’s start() method, as in:
     my_sequence.start(env.agt.sqr);
  • Sequences can be layered, where a single operation could be made of many smaller transactions. A sequence can start other sequences. So every uvm_sequence_item has a handle to its parent sequence, if any.

Conclusion

When you design your UVM testbench, have your transaction classes extend from uvm_sequence_item, not the Jurassic era uvm_transaction.

Sign up now for my October 8 webinar on UVM Sequences. Take your transactions to a new level!

Enjoy your verification journey,
Chris Spear

Keep learning at http://mentor.com/training

Any questions or ideas? https://verificationacademy.com/content/uvm-systemverilog-ask-chris-spear

View my recent webinars including an overview of UVM Transactions.

Chris Spear

Chris brings over forty years of EDA expertise to Siemens customers. Holding a degree in electrical engineering from Cornell University, Chris has developed deep roots in the EDA industry, including as a Principal Application Consultant. Chris is also an industry author, writing the 2012 best-selling “SystemVerilog for Verification” and developing the IEEE standard for random seeding and File I/O PLI package that is part of SystemVerilog. Having taught thousands of engineers around the world, Chris is driven by a passion for learning new techniques and then helping others learn best practices for hardware verification. Outside of work, you may see Chris bicycling over 12,000-foot mountain passes.

More from this author

Comments

One thought about “Why are UVM transactions built with uvm_sequence_item?

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.stage.sw.siemens.com/verificationhorizons/2020/09/28/why-are-uvm-transactions-built-with-uvm_sequence_item/