Creative ways to solve problems
Sometimes user will face a situation where you need some of the components from environment to demote error message means user want to disable error from a specific component. Of course user don’t want to change every uvm_error message to uvm_info.. It will take care of one of the amazing features from UVM i.e. uvm_report_catcher […]
Continue ReadingToday I’m going to share something which is so common to almost every concept of UVM. In other way, we can say that this concept is the backbone of the UVM Verification Methodology. This is related to the process which deals from the starting of the simulation till end of the simulation. So in this […]
Continue ReadingTo start a UVM Testbench, the run_test() method has to be called from the static part of the Testbench i.e called from an initial block in the top module of the Testbench. Once the run_test() method is called, it constructs the root component of the UVM environment & then triggers the UVM Phasing process. The […]
Continue ReadingMacros: The UVM Library has built-in utility and field automation macros that allow objects to be created by the factory and have access to common functions such as copy( ) or clone( ). To understand how the macros work, let’s build a simple data packet for the DUT. If we were not using the UVM, […]
Continue ReadingAs we know that in Traditional Directed Testbenches, we used to terminate a Test by calling a Verilog System Task i.e. $finish after the required steps like reset, configuration, data transfer and self-checking are completed. But UVM way is different in terms of finishing a Test as UVM is different in almost every aspect of […]
Continue ReadingThe recommended method in UVM for creating components or transaction objects is to use the built-in method::type_id::create() instead of calling the constructor new() directly. The create method internally makes a call to the factory to look up the requested type and then calls the constructor new() to actually create an object. This allows type overriding […]
Continue Reading
Factory stimulates everyone’s imagination to fall down on industrial settings and mechanical setup of machineries & processing units with products getting made and packaged before running on the transport rail & to be delivered to the warehouses. Hence the word “Factory” makes us curious to know about this jargon in Verification Methodology Context i.e. UVM. […]
Continue ReadingCallbacks 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 Reading