Upcoming RDC Assist Webinar

Questa RDC Assist – Improving designer productivity and enabling faster RDC verification closure with machine learning

Wednesday, May 22nd | 8:00 AM US/Pacific

Learn more and register.

  1. Body

    Authors: Rich Edelman - Mentor GraphicsRaghu Ardeishar - Mentor Graphics Abstract: The reader of this paper is interested to use UVM sequences to achieve his test writing goals. Examples of UVM sequences will be used to demonstrate basic and advanced techniques for creating interesting, reusable sequences and tests. Introduction: Sequences have become the basic test writing technique as UVM [2] development is continuing. When a functional verification engineer writes a test using the SystemVerilog [1] UVM, he will be writing a UVM Sequence. A sequence is simply a SystemVerilog task call which can consume time, and which has one of two jobs. It can either cause other sequences to be started, or it can generate a transaction to be passed to a driver. A sequence is implemented as a SystemVerilog task named 'body()' in a class derived from a uvm_sequence. In programming terms a sequence is a functor[5][6]. The implementation of the body is free to perform any function it desires, from creating a single transaction and sending to the driver, to creating multiple transactions, to creating and starting sub-sequences. It could create no transaction but simply print a message. A sequence is most useful when it is creating a related sequence of information or causing other activity on the driver and interface that represents traffic or tests. A UVM Testbench: A UVM testbench has many parts (agent, driver, monitor, sequencer, sequences and virtual interfaces) as shown in Figure 1 below. This paper will focus on the transactions and sequences with some discussion about building drivers to support various kinds of stimulus. In a UVM testbench a sequence is started that "runs" on a sequencer. The sequences may cause transactions, also known as sequence_items or just items; to be sent to the driver. If multiple sequences wish to send transactions to the driver at the same time, the sequencer will arbitrate who gets to go first. The default arbitration is first-come-first-served. View & Download: Read the entire Sequence, Sequence on the Wall – Who's the Fairest of Them All? technical paper. Source: DVCon 2013