Creative ways to solve problems
Callbacks and factory both addresses different areas of reusability in UVM. Callback: Add functionality to existing logic. Suitable for rare or minimal feature need to be enhanced in focus Popular for error injection/to corrupt the sequence from VIP. Easy to maintain callbacks Factory: It used to substitute the existing component before build, keeps environment same. […]
Continue ReadingCallback mechanism is used for altering the behavior of the transactor/BFM without modifying the existing BFM/transactor. Callback gives flexibility to plug-and-play and reuse the components i.e. driver, monitor etc.. Sometimes requirements are often unpredictable when the BFM/transactor is first written. So a transactor should provide some kind of hooks for executing the code which is […]
Continue ReadingM_sequencer: When a sequence is started, it is always associated with a sequencer on which it is started. The m_sequencer handle contains the reference to the sequencer on which sequence is running. Using this handle, the sequence can access any information and other resource handles in the UVM component hierarchy. P_sequencer and how it is […]
Continue Readinguvm_resource_db: uvm_resource_db is base class and uvm_config_db is extended from uvm_resource_db. Using the resource_db requires that the scope (arbitrary string) for the set and get a match. For trivial environments, this isn’t difficult. However, for complex environments, including IP from different sources, it’s more difficult to manage. That, along with some other non-intuitive behaviors of […]
Continue ReadingMultiple sequences can interact concurrently with a driver connected to a single interface. The sequencer supports an arbitration mechanism to ensure that at any point of time only one sequence has access to the driver. The choice of which sequence can send a sequence_item is dependent on a user selectable sequencer arbitration algorithm. There are […]
Continue ReadingIntroduction: It is necessary to manage most of the verification tasks, such as generating stimulus and collecting coverage data, at the transaction level, which is the natural way of verification engineers tend to think of the activity of a system. UVM provides a set of transaction-level communication interfaces and channels that you can use to […]
Continue ReadingThe UVM sequence-driver API majorly uses blocking methods on sequencer and driver side as explained below for transferring a sequence item from sequencer to driver and collecting response back from driver. Sequencer side operations: There are two methods as follows: start_item(<item>): This requests the sequencer to have access to the driver for the sequence item […]
Continue ReadingVariable uvm_sequence_base::starting_phase is deprecated and replaced by two new methods set_starting_phase and get_starting_phase, which prevent starting_phase from being modified in the middle of a phase. This change is not backward-compatible with UVM 1.1, though variable starting_phase, although deprecated, has not yet been removed from the base class library. New method uvm_sequence_base::set_automatic_phase_objection causes raise_objection and drop_objection […]
Continue ReadingReset testing is a crucial element of functional sign-off for any chip. The architectural components of the entire verification environment need to be correctly synchronized to be made aware of the reset condition. Scoreboards, drivers and monitors need to be tidied up, and the complex stimulus generation needs to be killed gracefully. As we know, […]
Continue ReadingToday I am going to talk about virtual sequences and the virtual sequencer. Common questions I hear from users include: why do we need a virtual sequence? How can we use it effectively? Most UVM testbenches are composed of reusable verification components unless we are working on block-level verification of a simple protocol like MIPI-CSI. […]
Continue Reading