Modeling transactions
Contents are extracted from the Advanced UVM sessions by Verification Academy.
Separating stimulus from the testbench
*Key to reusability is to separate Behavior from Structure
Transactions (Sequence items) ⇒ The main communication vehicle across the boundary
Sequences
Decouple stimulus specification from structural hierarchy
- Add/remove/modify stimulus scenarios independent of testbench
- Simplify test writer API
Sequences define transaction streams
- May start on any sequencer
Sequences can call children
Sequences & transactions can be customize via the factory
Designing a sequence item
Methods
do_copy()
do_compare()
convert2string()
do_print()
Not recommended for usage since it will provide some overhead
do_record()
do_pack() and do_unpack()
Not use very often
Sequence item composition
Layering: Use another sequence item inside a sequence item
Summary
Encapsulate the information needed to process an operation
- Whatever that means for the application
Helper functions (mentioned above)
Do not use uvm_field* macros
- Decreases performance
- Hinders debug
Use inheritance for similar transactions
Use composition when needed
Rules for sequence items
Define sequence items by specifying data members only
- Do not override
pre/mid/post_do
Create items via their type_id (using factory only)
my_item::type_id::create("tx");
Execute items using start_item()/finish_item()