1.

uvm_object :->

The uvm_object class in the Universal Verification Methodology (UVM) is the root class for all UVM components and transactions. It provides
essential functionality for object management and verification tasks.

Its built-in functions include:

Copy : Allows creating a deep copy of the object.

Clone : Enables creating a shallow copy of the object.

Compare : Facilitates comparing two objects for equality.

Factory methods : Standardizes object creation through factory methods.

Printing : Provides a standard way to print object information.

ID : uvm_object is a unique identifier assigned to each object instance. It's useful for tracking and debugging during simulation.
2. Transactions :->

Transactions are essential for modeling the behavior of the system under test. The base transaction typically extends from the lowest level,
which is a sequence item. Sequence items serve as the building blocks for constructing stimulus in verification environments.

Sequence items interact with both sequences and sequencers, facilitating communication between different verification
components. They also provide functionality for setting up sequence stacks, which determine the order of execution for sequence items.

To build stimulus, multiple sequence items are concatenated to form complex sequences. The sequence class in UVM provides a
range of methods and tests for creating and controlling sequence execution. These include features such as locking, prioritization, and methods
for executing sequence items.

The uvm_sequence_class library offers a set of ready-to-use functions and tests for building up complex sequence items and
controlling their execution within the verification environment. This library streamlines the process of generating stimulus and managing
sequence execution, enhancing the efficiency of the verification process.

Lets us build up our actual verification testbench

3. uvm_component :->

The uvm_component class in UVM serves as the base class for all UVM components within a testbench. Its main contributions lie in providing
functionality for the phasing mechanism, facilitating the construction, connection, and coordination of components within the testbench.

Here are the key functionalities provided by the uvm_component class:

Phasing Mechanism : The uvm_component class implements the UVM phasing mechanism, which organizes the execution flow of testbench
components. Phases such as build, connect, run, and shutdown are predefined, allowing components to synchronize their activities at specific
points during simulation.

Construction and Initialization : Components derived from uvm_component can override the build_phase() method to initialize their internal
state and set up necessary resources during the build phase. This phase occurs before simulation begins.

Component Connection : During the connect_phase(), components establish connections with other components in the testbench hierarchy.
This phase is crucial for configuring inter-component communication and dependencies.

Runtime Execution : The run_phase() method allows components to perform their designated tasks during simulation. This phase typically
includes activities such as generating stimulus, driving the DUT, and monitoring behavior.

Shutdown and Cleanup : After simulation completes, the uvm_component class provides the shutdown_phase() method for performing
cleanup tasks and releasing resources acquired during simulation.

Hierarchical Organization : Components can be hierarchically organized within the testbench, allowing for a structured and modular approach
to verification.

4. uvm_env :->

The uvm_env class serves as a container class for organizing and structuring the components within a testbench or UVC (Universal Verification
Component). Unlike the uvm_component class, it doesn't inherently add any incremental functionality beyond what's provided by its parent
class.

The primary purpose of uvm_env is to provide a distinct type for representing the testbench environment, making it easier to identify and
differentiate from other components in the testbench hierarchy. It helps maintain clarity and modularity in the testbench architecture.

Here's how uvm_env is typically used:

Component Composition : Testbench components such as agents, sequences, and scoreboards are typically instantiated within the uvm_env.
This allows for a structured approach to testbench construction and facilitates easy access and management of components.

Functional Grouping : Components within the uvm_env are logically grouped based on their functionality. For example, all components related
to a particular interface or protocol may be contained within a specific environment.

Hierarchical Phasing : While the uvm_env itself doesn't add new functionality, it participates in the UVM phasing mechanism inherited from
uvm_component. This means it can define its own build_phase(), connect_phase(), run_phase(), and shutdown_phase() methods to
orchestrate the initialization, connection, execution, and cleanup of its contained components.

5. uvm_test :->

Tests within UVM are similar to environments but are often specialized for specific verification tasks.

let's break down the functionalities of uvm_agent, uvm_driver, and uvm_sequencer:

6. uvm_agent: ->

- It inherits from uvm_env, thus sharing similar functionalities.

- Provides incremental functionality such as a bit named is_active, which controls whether the agent is actively driving transactions or only
observing or monitoring them.

- Typically contains components like drivers, sequencers, and possibly other specialized components like scoreboards.

7. uvm_driver:->

- Specialized component responsible for driving transactions onto the DUT.

- Features built-in TLM ports, ready for communication with the sequencer.

- Capable of receiving sequence items from the sequencer and driving them onto the DUT.

- These TLM ports are readily accessible and usable in user-written code, simplifying the integration of drivers into the testbench
architecture.

8. uvm_sequencer:->

- Complementary component to the driver, responsible for receiving requests from sequences and managing the flow of transactions.

- Features TLM ports that interact with those of the driver, facilitating communication between the sequencer and the driver.

- Provides built-in functionality for controlling sequence execution, including features such as arbitration schemes for managing sequence
access and execution.

- Utilizes control flow mechanisms to ensure proper coordination and sequencing of transactions within the testbench.
Additionally, the uvm_sequence class encapsulates functionality related to sequencing, including the ability to hold sequences, manage
arbitration, and control sequence execution. This class provides a standardized framework for defining and executing sequences within the
testbench, enhancing code reusability and maintainability.

Overall, these components work together within the UVM testbench to manage the flow of transactions, coordinate interactions between
components, and facilitate efficient verification of the DUT.