While developing verification environments for master-slave, it is always confusing on how to start slave sequences, since they have to be triggered based on DUT outputs and are monitored in Monitor. Below Webinar gives a clear picture on how to do that.
Often in an UVM
agent, a sequencer is considered just to initiate stimulus on an
interface, but an in-depth study of its behavior reveals that it can be
modelled in multiple other ways; for example, as a responder to traffic
from DUT. In UVM, the functionality of sequencers can be
encapsulated such that they can be controlled from the test without
replacing the agent connected to the DUT, thus enhancing the reuse. This
is possible by having different types of sequencers (other than normal
ones) such as Slave and Interrupt sequencers. I was impressed with a webinar on this presented by Tom Fitzpatrick, a renowned Verification Technologist, at Mentor Graphics. Let’s look at some details about how exactly this is done.
In general, a sequence is generated by a sequencer and the stimulus sent to driver. The driver then converts the sequence item to pin wiggles and puts it on the bus to DUT. A sample code for handshake between sequencer and driver is shown on the right in the above picture. Look at the optional part, it’s possible if driver provides separate response object.
Now let’s consider a situation where a transaction is initiated by DUT; here the sequencer has to respond on the request filled by the driver. By exploiting this phenomenon and putting a phase shift between the request, driver, bus and response as shown on the right side of the above picture, the slave functionality of a sequencer can be easily realized.
Above is a sample code which implements the functionality of a Slave Driver and Slave Sequence. By using this out of phase mechanism, multiple start and finish items can be done with a single request on bus.
Above is a waveform representation where two transactions are filled in one bus cycle. The part shown in blue represents the objects in UVM.
Similarly the code for slave driver and slave sequence can be written alternatively with phase level sequence items, slave setup and slave access (request and response objects) which are different but use the same type of transaction (uvm_sequence_item) and hence the item has to be casted to either request or response type as the case may be. The details can be looked at in the on-line webinar.
The Slave Sequence can be started like any other sequence with different sequence in different test without any structural change to the environment. Alternatively, slave sequence can be started from an environment by using config object to pass in slave sequence type/instance from test or by using factory to override slave sequence type.
Interrupt Sequence is an interesting item where an existing sequence has to be blocked until interrupt sequence is processed. In this case detecting an interrupt is an important task which is done by using a Virtual Interface Pointer in the config object. Then separate code is implemented for Virtual Sequence and ISR (Interrupt Service Routine) Sequence. The Virtual Sequence has code for starting normal sequence, spawning blocking tasks to wait for interrupt and starting ISR Sequence. The ISR Sequence has code for catching the sequencer, determining the cause of interrupt, processing prioritized interrupts and releasing the sequencer.
Thus the sequencer behavior can be changed according to the need without changing the testbench. This enhances the power of reusability in UVM. Verification engineers and professionals can go through the webinar to know more and actual details presented very elaborately by Tom. Also, Verification Academy constituted by Mentor can be referred for more trainings, downloads, video courses and verification methodology cookbooks.
Use Sequences to Model Multiple Behaviors in UVM
In general, a sequence is generated by a sequencer and the stimulus sent to driver. The driver then converts the sequence item to pin wiggles and puts it on the bus to DUT. A sample code for handshake between sequencer and driver is shown on the right in the above picture. Look at the optional part, it’s possible if driver provides separate response object.
Now let’s consider a situation where a transaction is initiated by DUT; here the sequencer has to respond on the request filled by the driver. By exploiting this phenomenon and putting a phase shift between the request, driver, bus and response as shown on the right side of the above picture, the slave functionality of a sequencer can be easily realized.
Above is a sample code which implements the functionality of a Slave Driver and Slave Sequence. By using this out of phase mechanism, multiple start and finish items can be done with a single request on bus.
Above is a waveform representation where two transactions are filled in one bus cycle. The part shown in blue represents the objects in UVM.
Similarly the code for slave driver and slave sequence can be written alternatively with phase level sequence items, slave setup and slave access (request and response objects) which are different but use the same type of transaction (uvm_sequence_item) and hence the item has to be casted to either request or response type as the case may be. The details can be looked at in the on-line webinar.
The Slave Sequence can be started like any other sequence with different sequence in different test without any structural change to the environment. Alternatively, slave sequence can be started from an environment by using config object to pass in slave sequence type/instance from test or by using factory to override slave sequence type.
Interrupt Sequence is an interesting item where an existing sequence has to be blocked until interrupt sequence is processed. In this case detecting an interrupt is an important task which is done by using a Virtual Interface Pointer in the config object. Then separate code is implemented for Virtual Sequence and ISR (Interrupt Service Routine) Sequence. The Virtual Sequence has code for starting normal sequence, spawning blocking tasks to wait for interrupt and starting ISR Sequence. The ISR Sequence has code for catching the sequencer, determining the cause of interrupt, processing prioritized interrupts and releasing the sequencer.
Thus the sequencer behavior can be changed according to the need without changing the testbench. This enhances the power of reusability in UVM. Verification engineers and professionals can go through the webinar to know more and actual details presented very elaborately by Tom. Also, Verification Academy constituted by Mentor can be referred for more trainings, downloads, video courses and verification methodology cookbooks.
