Data processing method for UVM verification environment, storage medium and electronic equipment

Abstract

The invention discloses a data processing method for a UVM verification environment, a storage medium and electronic equipment. The method comprises the following steps: instantiating a target object of a lightweight data encapsulation class in a sending end component, and encapsulating target data to the target object to obtain a data object; a global event is triggered in the sending end component, a data object is transmitted to the receiving end component through the global event, the sending end component and the receiving end component are two verification components with different roles and achieved through software codes in the UVM verification environment, and the receiving end component is used for transmitting the data object to the receiving end component under the condition that the global event is monitored in the receiving end component. And obtaining the data object from the global event, wherein the receiving end component is also used for extracting the target data from the data object. According to the invention, the technical problems of high complexity and low efficiency of data interaction between the components in the UVM verification environment are solved.

Description

Technical Field

[0001] This invention relates to the field of verification methodology, and more specifically, to a data processing method, storage medium, and electronic device for a UVM verification environment. Background Technology

[0002] In the verification phase of integrated circuits, especially in complex verification environments employing Universal Verification Methodology (UVM), data interaction between components is crucial for ensuring the comprehensiveness and efficiency of verification. However, the data interaction methods of related technologies face numerous challenges, significantly reducing the flexibility and efficiency of the verification process. On the one hand, while the static configuration (uvm_config_db) in the UVM verification platform is suitable for setting initialization parameters, its hierarchical path requirements and static attributes limit the transmission of dynamic data flows. Especially in complex and ever-changing verification scenarios, static configuration struggles to meet the demands of real-time communication and data updates. On the other hand, while Transaction Level Modeling (TLM) communication mechanisms can achieve cross-component data transmission, their encapsulation based on complete transaction objects introduces unnecessary overhead. This not only consumes more memory resources but also increases the complexity of transaction object lifecycle management and transaction definition, especially in scenarios requiring frequent, small-volume data interactions. Furthermore, while the use of direct callback interfaces enables rapid communication between components, this tightly coupled design reduces system reusability and scalability, and increases maintenance difficulty. In summary, the relevant technologies suffer from problems such as high complexity and low efficiency in data interaction between components in the UVM verification environment.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a data processing method, storage medium, and electronic device for a UVM verification environment, to at least solve the technical problems of high complexity and low efficiency in data interaction between components in a UVM verification environment.

[0005] According to one aspect of the present invention, a data processing method for a UVM verification environment is provided, comprising: instantiating a target object of a lightweight data encapsulation class in a sending component, encapsulating target data into the target object to obtain a data object; triggering a global event in the sending component, and passing the data object to a receiving component through the global event, wherein the sending component and the receiving component are two different roles of verification components implemented by software code in the UVM verification environment, the receiving component is used to obtain the data object from the global event when it listens for the global event, and the receiving component is also used to extract target data from the data object.

[0006] According to another aspect of the present invention, another data processing method for a UVM verification environment is also provided, comprising: when a global event is detected in the receiving component, obtaining a data object from the global event, wherein the global event is triggered in the sending component and is used to pass the data object to the receiving component, the data object is obtained by encapsulating target data into a target object, and the target object is obtained by instantiating a lightweight data encapsulation class in the sending component; and extracting target data from the data object.

[0007] According to another aspect of the present invention, a non-volatile storage medium is also provided, which stores a plurality of instructions adapted for a data processing method of a UVM verification environment, any one of which is loaded by a processor.

[0008] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any one of the data processing methods for a UVM verification environment.

[0009] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of a data processing method for any of the UVM verification environments.

[0010] In this embodiment of the invention, a lightweight data encapsulation class is created; a target object of the lightweight data encapsulation class is instantiated in the sending component, and the target data is encapsulated into the target object to obtain a data object; a global event is triggered in the sending component, and the data object is passed to the receiving component through the global event. The sending component and the receiving component are two different roles of verification components implemented in software code within the UVM verification environment. The receiving component is used to obtain the data object from the global event when it listens for the global event. The receiving component is also used to extract the target data from the data object. This achieves the goal of efficient, flexible, and loosely coupled data transfer between verification components implemented in software code by creating a lightweight data encapsulation class and using the global event mechanism to asynchronously transfer data. This reduces the complexity of data interaction between components in the UVM verification environment while improving efficiency, thus solving the technical problem of high complexity and low efficiency in data interaction between components in the UVM verification environment. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0012] Figure 1 This is a flowchart of a data processing method for a UVM verification environment according to an embodiment of the present invention;

[0013] Figure 2 This is a flowchart of another data processing method for a UVM verification environment according to an embodiment of the present invention;

[0014] Figure 3 This is a flowchart of an optional data processing method for a UVM verification environment according to an embodiment of the present invention;

[0015] Figure 4 This is a schematic diagram of a data processing device for a UVM verification environment according to an embodiment of the present invention;

[0016] Figure 5 This is a schematic diagram of a data processing apparatus for another UVM verification environment according to an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] According to an embodiment of the present invention, a method embodiment for data processing in a UVM verification environment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] Figure 1 This is a flowchart of a data processing method for a UVM verification environment according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0021] Step S102: Instantiate the target object of the lightweight data encapsulation class in the sending component, encapsulate the target data into the target object, and obtain the data object.

[0022] Optionally, steps S102 to S104 can be applied to the UVM verification platform, based on the interaction between the sending component and the receiving component. The execution entity of steps S102 to S104 can be the server (or hardware device) where the sending component resides. In the UVM verification environment, the sending component and the receiving component run in a software simulator used to verify the hardware design. These components are implemented through software code to simulate the behavior of the hardware device and verify its functionality. The sending component and the receiving component can reside on the same server (or hardware device) or on different servers (or hardware devices). In this step, the sending component, i.e., the verification component that generates data and needs to transmit it to other components, first instantiates the lightweight data encapsulation class (i.e., the light_data class) defined above. Next, the target data to be sent (such as an integer value or other basic data type) is written into the object field of this light_data instance. In this way, the raw data is encapsulated into a data object that can be recognized by the UVM verification environment.

[0023] Optionally, the target object of the lightweight data wrapper class can be instantiated during the execution of the sending component (i.e., during the execution of a task or process). In other words, the instantiation and data population operations of the lightweight data wrapper class occur during the runtime of the sending component, rather than during initialization, thereby supporting the real-time transmission of dynamic data streams.

[0024] Optionally, a lightweight data wrapper class can be created before executing step S102. This class inherits from the verification object uvm_object in the UVM verification platform and is used to encapsulate and carry basic data types (such as integers, floating-point numbers, etc.). Unlike the full transaction class used in Transaction Level Modeling (TLM) in related technologies, this lightweight data wrapper class light_data only contains the necessary data fields, thereby reducing memory consumption and improving data processing efficiency.

[0025] Optionally, this lightweight data wrapper class can be created, but is not limited to, in the following ways:

[0026] class light_data extends uvm_object;

[0027] int data; / / The actual data member to be passed

[0028] `uvm_object_utils(light_data)

[0029] function new(string name = "light_data");

[0030] super.new(name);

[0031] endfunction.

[0032] In the code above, `class light_data extends uvm_object` declares a new class `light_data` that inherits from the UVM base class `uvm_object`. This means that `light_data` automatically acquires the basic functionalities of UVM objects, such as serialization, cloning, and comparison, while also supporting UVM's factory mechanism and various configuration management features. `int data; / / The actual data member to be passed` indicates that the `light_data` class contains a member variable `data` of type `int`. This variable stores the data that actually needs to be passed between UVM components. For example, if one component needs to tell another component a certain numerical information, this value will be stored in the `data` member. `uvm_object_utils(light_data)` is a UVM macro used to automatically generate some commonly used UVM infrastructure code, such as printing and copying methods, to facilitate the use of the `light_data` class. The `uvm_object_utils` macro generates a default printing function to print all fields of the object, as well as some helper functions for serialization and deserialization, allowing the `light_data` object to be serialized and cloned like any other UVM object. `function new(string name ="light_data")` is a constructor function used to create a new instance of the `light_data` object. The function name `new` is the constructor name by convention in UVM. This constructor accepts a string parameter `name`, which defaults to "light_data", used to name the created object. Within the constructor, `super.new(name)` calls the constructor of the parent class `uvm_object` to perform basic initialization operations, such as setting the object's name. `super.new` is the standard call for UVM base class initialization, ensuring that all initialization actions of the `uvm_object` class are executed correctly, including registering the object with the UVM factory and recording creation information. The lines `endfunction` and `endclass` mark the end of the constructor and class definition, respectively. `endfunction` ends the definition of the `new` constructor, while `endclass` completes the definition of the entire `light_data` class. The code example above defines a simple `light_data` UVM class, which can be used to encapsulate and pass integer data. By inheriting from the `uvm_object` class, it ensures compatibility and manageability with other UVM components, while utilizing the `uvm_object_utils` macro to simplify object usage.

[0033] In one optional embodiment, instantiating a target object of a lightweight data encapsulation class in the sending component and encapsulating the target data into the target object to obtain a data object includes: instantiating the target object in the sending component, detecting whether the data type of the target data is a preset basic type, wherein the preset basic type includes at least one of the following: integer, floating-point, and string types; if the data type of the target data is a preset basic type, encapsulating the target data into the target object to obtain a data object.

[0034] Optionally, before sending data, an instance of the `light_data` class can be created within any UVM sender component to ensure there is an appropriate container to load and transmit the data (such as the target data). Before encapsulating the data, the sender component needs to check whether the target data to be encapsulated belongs to one of the preset basic types, including but not limited to integer (int), floating-point (real or float), and string (string), to ensure that only basic data types can be encapsulated and transmitted through the global event mechanism, because the `light_data` class is specifically designed to hold this type of data. If the data type of the target data is indeed a preset basic type, it can be assigned to the corresponding member variable of the `light_data` instance. In this way, the data of the sender component is safely encapsulated into a class instance derived from `uvm_object`, forming a data object.

[0035] By employing the above methods, it can be ensured that only data meeting specific type requirements is correctly encapsulated, which is crucial for maintaining the stability and efficiency of the verification environment. Simultaneously, this means that light_data objects can be effectively triggered and monitored within the UVM environment without causing errors or exceptions due to data type mismatches. This approach guarantees the applicability and reliability of the lightweight data encapsulation mechanism by restricting data types, while simplifying the data transmission process and avoiding the unnecessary overhead of complex transaction-level model encapsulation in related verification methods.

[0036] In an optional embodiment, the method further includes: converting the target data into basic type data when the target data is not a preset basic type, wherein the data type of the basic type data is a preset basic type; and encapsulating the basic type data into a target object to obtain a data object.

[0037] Optionally, if the target data is not a preset basic type (i.e., the target data to be encapsulated is not a preset basic type supported by the lightweight data encapsulation class (such as integer, floating-point, string, etc.), the sending component needs to perform data conversion to convert the data into a basic data type. During the conversion process, certain key information about complex data types in the target data can be extracted and converted into basic data types such as integer, floating-point, or string. For example, for a custom class object, it may be necessary to extract the value of a certain member as basic data type to pass. Once the target data is successfully converted into basic data type, this basic data type is assigned to the data member of the light_data instance object (i.e., the target object), thus completing the data encapsulation and forming a data object that can be passed across components.

[0038] The steps outlined above ensure the flexibility and broad applicability of the lightweight data encapsulation method. Even if the target data to be transmitted is not a simple basic type, it can be made to meet encapsulation requirements through data conversion, allowing data transmission using the `light_data` class and global event mechanism. This provides a solution for data that cannot be directly transmitted in basic type form in the UVM verification environment. For example, when transmitting a field of a custom class object, this field can be converted to an integer or other basic type before encapsulation and transmission using the `light_data` class. This ensures both the efficiency and security of data transmission while expanding the applicability of the lightweight data transmission method.

[0039] Step S104: Trigger a global event in the sending component and pass the data object to the receiving component through the global event. The sending component and the receiving component are two different roles of verification components implemented by software code in the UVM verification environment. The receiving component is used to obtain the data object from the global event when it listens for the global event. The receiving component is also used to extract the target data from the data object.

[0040] In this step, the sending component utilizes the global event mechanism (uvm_event) provided by the UVM verification platform to trigger a global event and pass the encapsulated light_data object as a parameter through this event. Global events allow data transfer across components without relying on a strict hierarchical structure, providing a more flexible data communication method. The receiving component, upon detecting a global event, retrieves the data object from the global event and extracts the target data from it. At the receiving end, which is the verification component that needs to receive and process the data, by listening to a global event with the same name, it can receive the passed data object when the event is triggered and securely access and extract the original target data from the global event.

[0041] In one alternative embodiment, global events are deployed in a UVM event pool, which stores and manages global events so that they can be accessed and triggered by any component in the UVM verification environment in the form of asynchronous many-to-many communication.

[0042] Optionally, in the UVM validation platform, global events (uvm_event) are a special mechanism used to implement asynchronous communication between components. These global events are deployed in a central location—the UVM event pool (uvm_event_pool). The event pool serves as a centralized storage and management place for events, enabling any UVM component to access and trigger global events through a standard interface. The UVM event pool not only stores global events but also manages their lifecycle, including event creation, destruction, and state tracking. It provides a shared storage space for events, ensuring that events can be discovered and used by components globally, regardless of their specific storage location. Furthermore, the event pool provides key services such as event retrieval (get_global), triggering (trigger), and listening (wait_trigger). The usage pattern of global events is a typical asynchronous many-to-many communication, allowing events to be triggered by any component at any time, while other components can independently listen to and respond to these events without needing to establish strict connections or communication protocols beforehand. This pattern is well-suited for dynamic data flows and asynchronous event-driven scenarios in UVM environments because components are no longer limited to direct, synchronous interactions. Instead, they can autonomously decide when and where to act based on the triggering of global events. Since global events are stored in the UVM event pool, any component in the UVM validation environment can access and trigger these events as long as it knows their names. This provides significant flexibility for communication between components, allowing each component to react independently to global events without needing direct knowledge of the sender's existence or state.

[0043] This embodiment provides a global event deployment and communication mechanism in the UVM verification environment, emphasizing the core role of the UVM event pool in achieving asynchronous many-to-many communication. This makes data transfer in the UVM environment more efficient, flexible, and easier to manage, especially for scenarios requiring cross-component, dynamic, and asynchronous communication. Global events and their management model within the event pool provide an advanced, decentralized data exchange mechanism for the UVM verification environment, improving the overall performance and scalability of the verification system.

[0044] This embodiment provides an efficient, flexible, and loosely coupled solution for data interaction between components in a UVM verification environment by combining lightweight data encapsulation and global event asynchronous communication. It can reduce the overhead of data transmission, improve the decoupling of component logic, support dynamic multi-component reception and asynchronous communication, and is particularly suitable for scenarios with small data transmission volume and flexible timing requirements. It can significantly improve the performance and maintainability of integrated circuit verification.

[0045] According to embodiments of the present invention, another embodiment of a data processing method for a UVM verification environment is also provided. Figure 2 This is a flowchart of another data processing method for a UVM verification environment according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps:

[0046] Step S202: When a global event is detected in the receiving component, a data object is obtained from the global event. The global event is triggered in the sending component and is used to pass the data object to the receiving component. The data object is obtained by encapsulating the target data into a target object. The target object is obtained by instantiating a lightweight data encapsulation class in the sending component.

[0047] Step S204: Extract the target data from the data object.

[0048] The executing entity for steps S202 to S204 can be the server (or hardware device) where the receiving component resides. Through steps S202 to S204, the goal of efficient, flexible, and loosely coupled data transfer between verification components implemented in software code can be achieved by creating a lightweight data encapsulation class and asynchronously transmitting data using a global event mechanism. This reduces the complexity of data interaction between components in the UVM verification environment, improves efficiency, and solves the technical problem of high complexity and low efficiency in data interaction between components in the UVM verification environment. In other words, this embodiment provides an efficient, flexible, and loosely coupled solution for data interaction between components in the UVM verification environment by combining lightweight data encapsulation and asynchronous global event communication. It reduces data transmission overhead, improves the decoupling of component logic, supports dynamic multi-component reception and asynchronous communication, and is particularly suitable for scenarios with small data transmission volumes and flexible timing requirements. It can significantly improve the performance and maintainability of integrated circuit verification.

[0049] In an optional embodiment, before obtaining a data object from the global event and extracting target data from the data object when a global event is detected in the receiving component, the method further includes: controlling the receiving component to enter a waiting state and continuously listening to the global event until a global event is detected, wherein the waiting state refers to the state of stopping the execution of subsequent tasks or processes.

[0050] Optionally, when the receiving component wants to receive data transmitted via a global event, it first needs to enter a waiting state. This waiting state means that the receiving component will pause its normal execution flow while listening for global events until it receives the specific global event. This mechanism ensures synchronous data reception, guaranteeing that the component processes the latest or expected data at the correct time. The receiving component can use the blocking call `wait_trigger()` method provided by the UVM verification platform to continuously listen for specific global events, meaning that once called, the receiving component will wait until the global event is triggered. During this period, the receiving component will not execute other tasks or processes, remaining in the waiting state and focusing on receiving and processing the upcoming event. When the global event is triggered, the receiving component can extract the actual target data from the global event for processing. By implementing the waiting mechanism, it is ensured that the receiving component can accurately receive the data object transmitted by the sending component via the global event, thereby extracting the target data and avoiding verification errors or exceptions caused by outdated or lost data.

[0051] Within the sending component, the aforementioned data encapsulation object (light_data) needs to be instantiated, and then a global event needs to be obtained (or created). Next, the data to be sent (such as the target data) needs to be populated into the corresponding members of the data object. Finally, the global event is triggered using the trigger() method, with the encapsulated data object appended as a parameter. A corresponding example is as follows:

[0052] light_data data_obj;

[0053] uvm_event data_event = uvm_event_pool::get_global("data_event"); ......

[0055] data_obj.data = new_data;

[0056] data_event.trigger(data_obj).

[0057] In the code above, `light_data data_obj` declares an object `data_obj` of type `light_data`. `light_data` is a custom class that inherits from `uvm_object`, primarily used to encapsulate and carry simpler basic data types, such as integers and floating-point numbers. Instances of this class will become the carriers in the data transfer process. The line `uvm_event data_event = uvm_event_pool::get_global("data_event")` instructs the retriever of a global event `data_event` from the UVM event pool. `uvm_event` is an event type provided by UVM for asynchronous communication. `uvm_event_pool::get_global` is the global access function for the UVM event pool. By passing in the event name (here, "data_event"), it retrieves an event instance that can be used across multiple components. This allows events to be shared and triggered across multiple components throughout the validation environment. The statement `data_obj.data = new_data` assigns a new data value `new_data` (assuming it's a basic data type, such as `int` or another basic data type) to the `data` member variable of the `data_obj` object. This means that the `data_obj` object is used to carry this `new_data` value, preparing for subsequent event triggering and data transfer. The line of code `data_event.trigger(data_obj)` uses the `trigger` method to trigger the `data_event` event, passing `data_obj` as a parameter. In UVM, when an event is triggered, all components registered to listen for that event are notified and can process the event and its carried data. `data_obj` serves as the carrier of the data; once `data_event` is triggered, all components listening for this event will have the opportunity to receive the `data_obj` object through the event handling mechanism and then read the `new_data` value from it. In summary, this code demonstrates how to achieve efficient and flexible dynamic data transfer on the UVM platform through lightweight data encapsulation and a global event mechanism. Compared to static configuration or complete transaction delivery in related technologies, this approach can significantly reduce communication overhead, improve the flexibility of data transmission, and enhance the decoupling of components.

[0058] In one optional embodiment, when a global event is detected in the receiving component, obtaining a data object from the global event and extracting target data from the data object includes: when a global event is detected in the receiving component, obtaining a data object from the global event, converting the data object into the type of a lightweight data encapsulation class to obtain a converted data object; and extracting target data from the converted data object.

[0059] Optionally, if the receiving component detects a global event, it means that the receiving component has already used the uvm_event mechanism and is in a waiting state by calling the wait_trigger() method in a blocking manner until it detects a specific global event triggered by the sending component. wait_trigger() is a method provided by UVM to block the execution of the current component until the specified event is triggered. When the receiving component detects that a global event has been triggered, it can call the get_trigger_data() method to retrieve the previously sent data object from the event. This data object has been instantiated as an instance of the light_data class on the sending side and contains the target data. The get_trigger_data() method returns a uvm_object type because the UVM event mechanism requires that the data type passed must be a subclass of uvm_object. Since get_trigger_data() returns a uvm_object, in order to access the target data encapsulated in the light_data class, the receiving component can use a type conversion cast operation to convert the uvm_object type data object to the specific light_data type. `cast` is a system-level type conversion function in the Verilog language. It can be used to safely attempt to convert an object of a base class type to a derived class type. If the conversion succeeds, the data object can be safely used as a `light_data` object. If the conversion fails, meaning the data object is not of type `light_data`, it indicates a type error, and this exception needs to be handled in the code. This can be done by setting up an error handling mechanism (such as the `uvm_error()` function in the UVM verification platform) to report and handle type conversion failures. Once the data object is successfully converted to the `light_data` type, the receiving component can access the `light_data` object's member variables (such as `data`) to extract the originally encapsulated target data. This step ensures that the receiving end can correctly use and process the data passed through global events.

[0060] In the above method, the receiving component obtains the data object from the listened global event, converts it to the light_data type, and then extracts the target data. This process not only ensures the correct transmission of data, but also guarantees the security and reliability of data use through the type conversion mechanism.

[0061] Optionally, within the receiving component, first obtain the same global event instance (using the same `get_global("event_name")` call); then, use the `wait_trigger()` method to block and wait for the event to trigger. After the event triggers, obtain the additional data object (of type base class `uvm_object`) using `get_trigger_data()`; then use... `cast` safely converts the base class object back to the specific `light_data` type; finally, it extracts the original data from the converted object. The corresponding code example is as follows:

[0062] uvm_event data_event = uvm_event_pool::get_global("data_event");

[0063] uvm_object generic_obj; / / Used to accept base class objects

[0064] light_data receive_data; / / Used to receive the converted object ........

[0066] data_event.wait_trigger();

[0067] generic_obj = data_event.get_trigger_data(); / / Get data

[0068] if (! cast(received_data, generic_obj)) begin / / Type conversion

[0069] `uvm_error("CAST", "fail to cast")

[0070] end

[0071] int re_data = received_data.data; / / Extract raw data

[0072] The code `uvm_event data_event = uvm_event_pool::get_global("data_event")` creates an object `data_event` of type `uvm_event` and retrieves a global event instance named "data_event" from the UVM event pool using the `uvm_event_pool::get_global` function. The global event mechanism allows for asynchronous data and event notification transmission across components. The code `uvm_object generic_obj; / / used to receive base class objects` declares an object `generic_obj` of type `uvm_object`, where `uvm_object` is the base class for all data and configuration objects in UVM. The data object retrieved from `data_event` will be temporarily stored in `generic_obj`, and its specific type is unknown at this point. The code `light_data receive_data; / / used to receive the transformed concrete object` declares an object `receive_data` of type `light_data`. `light_data` is a user-defined class that encapsulates the data to be transmitted; it inherits from `uvm_object`. `receive_data` will be used to store the type-converted data object for subsequent processing and data retrieval. `data_event.wait_trigger();` calls the `wait_trigger` method of `data_event`, putting the current sending component into a waiting state until `data_event` is triggered. `generic_obj = data_event.get_trigger_data(); / / Get data` means that after `data_event` is triggered, the `get_trigger_data` method is called to retrieve the transmitted data object from the event and store it in `generic_obj`. At this point, `generic_obj` contains the `light_data` object transmitted by the sending end, but its type information is not yet determined. `if (!cast(receive_data, generic_obj)) begin / / Type conversion` attempts to convert the data object in `generic_obj` to the `light_data` type using the `cast` function, i.e., `cast(receive data, generic, obj))begin / / Type conversion` attempts to convert the data object in `generic obj` to the `light data` type. If the conversion fails (i.e., the type of generic_obj is not light_data), then proceed to the block of the if statement.The purpose of type conversion is to ensure that if the conversion fails, this line of code will log an error message using the UVM macro `uvm_error`, which outputs the error message to the console or log file to aid in debugging and problem localization. Here, the error message is "fail to cast" under the "CAST" category. `int re_data=received_data.data; / / extract raw data` means that if the type conversion succeeds, this line of code extracts the specific data to be transmitted from the `received_data` object and stores it in the `re_data` variable. `received_data.data` is a basic type variable (such as `int`) that carries the raw data that the sending component wants to transmit. Through this code, the receiving component asynchronously receives the lightweight encapsulated data under the global event mechanism and performs type checking and data extraction. This mechanism greatly improves the flexibility and efficiency of the verification environment, and is particularly suitable for scenarios requiring asynchronous data communication across components.

[0073] In one optional embodiment, when a global event is detected in the receiving component, obtaining a data object from the global event and extracting target data from the data object includes: when a global event is detected in the receiving component, detecting whether the global event meets preset conditions, wherein the preset conditions include at least one of the following: the trigger time of the global event is within a preset time range, or the global event is triggered after a predetermined event; when the global event meets the preset conditions, obtaining a data object from the global event and extracting target data from the data object.

[0074] Optionally, when the receiving component detects a global event being triggered, it does not immediately process the data. Instead, it first checks whether the event meets a set of preset conditions. Setting these preset conditions helps filter out irrelevant events, ensuring that the receiving component only responds to events that meet the expected behavior. Preset conditions are set from two perspectives: trigger time and event triggering order. Specifically, setting preset conditions includes ensuring the global event triggers within a preset time range. This means the receiving component can define a time window, specifying that only global events triggered within a specific time period are valid. For example, the component might only care about events during the execution of a test sequence, not events outside the sequence. Setting preset conditions also includes ensuring the global event triggers after a predetermined event. This is a condition based on event sequence, ensuring that the global event is processed only after another specific event (the predetermined event). This dependency can be used to implement complex event processing logic. For example, the receiving component might only process a data transmission event after a configuration update event, ensuring all data is up-to-date. Only when a global event meets one or more of the above preset conditions will the receiving component further execute the data acquisition and processing steps. First, you can retrieve the data object from the global event using the `get_trigger_data()` method, and then perform a type conversion (via...). The `cast` function converts a data object to the `light_data` type, and finally extracts the target data from the converted object for appropriate processing.

[0075] In this embodiment, by adding condition checks for global events, components in the UVM verification environment are provided with more granular event handling capabilities. This not only reduces unnecessary data processing and improves verification efficiency, but also ensures that components process data at the correct time and in the correct context, enhancing the stability and reliability of the UVM verification platform. For example, in complex system verification, ensuring that data processing occurs at the correct time point can avoid misleading test results and ensure the accuracy of the verification process. Simultaneously, by setting validity conditions for global events, components can better coordinate their work, avoid unnecessary synchronization overhead, and optimize overall verification performance.

[0076] UVM is a SystemVerilog-based verification methodology designed to provide a unified, efficient, and reusable framework for hardware verification. The core objective of UVM is to simplify the verification process and improve verification efficiency and quality through standardized components and workflows. As the complexity of the Device Under Test (DUT) increases, the UVM platform needs to provide more refined data processing methods, making efficient and convenient data transfer within the platform extremely important. In existing UVM verification methods, cross-component parameter transfer mainly relies on the following technologies: 1) Static configuration (uvm_config_db): Setting global parameters through hierarchical paths, but only suitable for static initialization scenarios, unable to support dynamic data flows, and requiring settings from the top level, involving many components; 2) TLM communication: A transaction-based port communication mechanism, requiring the data to be transmitted to be defined as a complete transaction class, introducing additional overhead, and complex transaction object lifecycle management, requiring connections between multiple components; 3) Direct callback interfaces: Direct calls between components via interfaces lead to tight coupling and reduced reusability. However, the above methods have at least the following problems: 1) The overhead is too large. It requires a complete transaction class to encapsulate the complete data fields, which will cause memory and performance waste; 2) The flexibility is low. Static configuration cannot pass dynamic data. When passing data, it is necessary to strictly follow the hierarchical relationship. The TLM interface also needs to be explicitly connected, involving many components and complex structure; 3) It has a large dependence on time sequence. Components need to be strictly synchronized, making it difficult to support asynchronous event-driven scenarios.

[0077] Based on the above embodiments and optional embodiments, the present invention proposes an optional implementation method. Figure 3 This is a data processing diagram of an optional UVM verification environment according to an embodiment of the present invention, such as... Figure 3 As shown, the method includes:

[0078] S1, Data Encapsulation: Since the UVM event mechanism requires the transmitted data type to be uvm_object, the original data (such as basic types like integers int) needs to be simply encapsulated. The encapsulation doesn't need to be as complex as a full transaction; simply create a lightweight data class that inherits from uvm_object. The specific code example is the same as in the previous embodiment and will not be repeated here.

[0079] S2, the sending end operation, requires instantiating the aforementioned data encapsulation object (light_data) within the sending end component, and then obtaining (or creating) the global event; next, filling the corresponding members of the data object with the data to be transmitted (such as the target data); finally, triggering the global event through the trigger() method, and passing the encapsulated data object as an append parameter. The specific code example is the same as the aforementioned embodiment, and will not be repeated here.

[0080] S3, Receiver Operations: Within the receiver component, first, the same global event instance is obtained (via the same `get_global("event_name")` call); then, the `wait_trigger()` method is used to block and wait for the event to trigger. After the event triggers, the attached data object (of type base class `uvm_object`) is obtained via `get_trigger_data()`; then... The `cast` function safely converts the base class object back to the specific `light_data` type; finally, it extracts the original data from the converted object. The specific code example is the same as the previous embodiment and will not be repeated here.

[0081] It should be noted that this embodiment proposes a lightweight parameter passing method. By using asynchronous global event communication combined with generic data packet classes to achieve dynamic data transmission, it offers the following advantages: 1) Reduced communication overhead: Passing necessary data on demand avoids redundant transaction encapsulation; 2) Decoupling component logic: The global event mechanism eliminates the need for transmission through the platform's top layer, removing dependencies between components; 3) Support for dynamic multi-component reception: Allows multiple components to listen to the same event and process data independently. Asynchronous reception is also possible. When some components, such as sequences, cannot use transmission methods like `config_db`, other simpler methods are needed to pass data. This method does not require strict hierarchical parameter passing within UVM, offers flexible timing, and does not require configuring numerous ports and transaction definitions for transmitting small amounts of data, making transmission efficient and convenient.

[0082] This embodiment also provides a data processing apparatus for a UVM verification environment, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the terms "module" and "apparatus" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0083] According to an embodiment of the present invention, an apparatus embodiment for implementing the data processing method for the above-described UVM verification environment is also provided. Figure 4 This is a schematic diagram of the structure of a data processing device for a UVM verification environment according to an embodiment of the present invention, as shown below. Figure 4 As shown, the data processing device for the aforementioned UVM verification environment includes: a data object acquisition module 402 and a data object transfer module 404, wherein:

[0084] The data object acquisition module 402 is used to instantiate the target object of the lightweight data encapsulation class in the sending component, encapsulate the target data into the target object, and obtain the data object.

[0085] The data object transmission module 404 is connected to the data object acquisition module 402. It is used to trigger a global event in the sending component and transmit the data object to the receiving component through the global event. The sending component and the receiving component are two different roles of verification components implemented by software code in the UVM verification environment. The receiving component is used to obtain the data object from the global event when it listens for the global event. The receiving component is also used to extract the target data from the data object.

[0086] In this embodiment of the invention, by setting up the data object acquisition module 402, it is used to instantiate a target object of a lightweight data encapsulation class in the sending component, encapsulate the target data into the target object, and obtain a data object; the data object transmission module 404, connected to the data object acquisition module 402, is used to trigger a global event in the sending component and transmit the data object to the receiving component through the global event. The sending component and the receiving component are two different roles of verification components implemented by software code in the UVM verification environment. The receiving component is used to obtain the data object from the global event when it listens for the global event. The receiving component is also used to extract the target data from the data object. This achieves the goal of efficient, flexible and loosely coupled data transmission between verification components implemented by software code by creating a lightweight data encapsulation class and using the global event mechanism to transmit data asynchronously. This reduces the complexity of data interaction between components in the UVM verification environment and improves the technical effect of low efficiency, thereby solving the technical problem of high complexity and low efficiency of data interaction between components in the UVM verification environment.

[0087] According to an embodiment of the present invention, another apparatus embodiment for implementing the above-described UVM verification environment data processing method is also provided. Figure 5 This is a schematic diagram of the structure of a data processing device for a UVM verification environment according to an embodiment of the present invention, as shown below. Figure 5 As shown, the data processing device for the aforementioned UVM verification environment includes: a data object extraction module 502 and a target data extraction module 504, wherein:

[0088] The data object extraction module 502 is used to obtain the data object from the global event when the global event is detected in the receiving component. The global event is triggered in the sending component and is used to pass the data object to the receiving component. The data object is obtained by encapsulating the target data into a target object. The target object is obtained by instantiating a lightweight data encapsulation class in the sending component.

[0089] The target data extraction module 504 is connected to the data object extraction module 502 and is used to extract target data from the data object.

[0090] In this embodiment of the invention, by setting up the data object extraction module 502, it is used to obtain data objects from global events when global events are detected in the receiving component. The global events are triggered in the sending component and are used to pass data objects to the receiving component. The data objects are obtained by encapsulating target data into target objects, and the target objects are obtained by instantiating a lightweight data encapsulation class in the sending component. The target data extraction module 504 is connected to the data object extraction module 502 and is used to extract target data from the data objects. This achieves the goal of efficient, flexible and loosely coupled data transmission between verification components implemented in software code by creating a lightweight data encapsulation class and using the global event mechanism to asynchronously transmit data. This reduces the complexity of data interaction between components in the UVM verification environment and improves the technical effect of low efficiency, thereby solving the technical problem of high complexity and low efficiency of data interaction between components in the UVM verification environment.

[0091] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0092] It should be noted that the data object acquisition module 402 and data object transfer module 404 mentioned above correspond to steps S102 to S104 in the embodiments, and the data object extraction module 502 and target data extraction module 504 correspond to steps S202 to S204 in the embodiments. The instances and application scenarios implemented by the above modules and their corresponding steps are the same, but they are not limited to the content disclosed in the above embodiments. It should be noted that the above modules, as part of the device, can run in a computer terminal.

[0093] It should be noted that the optional or preferred implementation methods of this embodiment can be found in the relevant descriptions in the embodiments, and will not be repeated here.

[0094] The data processing device for the UVM verification environment described above may also include a processor and a memory. The data object acquisition module 402, data object transfer module 404, data object extraction module 502, target data extraction module 504, etc., are all stored in the memory as program modules, and the processor executes the program modules stored in the memory to realize the corresponding functions.

[0095] The processor contains a core that retrieves the corresponding program modules from memory. One or more cores may be configured. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory includes at least one memory chip.

[0096] According to an embodiment of this application, an embodiment of a non-volatile storage medium is also provided. Optionally, in this embodiment, the non-volatile storage medium includes a stored program, wherein, when the program runs, it controls the device where the non-volatile storage medium is located to execute any of the data processing methods of the UVM verification environment.

[0097] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals, and the non-volatile storage medium includes stored programs.

[0098] Optionally, a program that controls the device containing the non-volatile storage medium to execute any of the above-mentioned UVM verification environment data processing method steps during program execution.

[0099] According to an embodiment of this application, an embodiment of a processor is also provided. Optionally, in this embodiment, the processor is used to run a program, wherein the program executes any of the data processing methods for the UVM verification environment described above.

[0100] According to an embodiment of this application, an embodiment of a computer program product is also provided, which, when executed on a data processing device, is adapted to execute the data processing method steps for initializing a UVM verification environment having any of the above-described steps.

[0101] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the data processing method steps of any of the above-described UVM verification environments.

[0102] The order of the above embodiments of the present invention is merely for description and does not represent the superiority or inferiority of the embodiments.

[0103] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0104] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of modules described above can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between modules, and may be electrical or other forms.

[0105] The modules described above as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0106] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0107] If the aforementioned integrated modules are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable non-volatile storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a non-volatile storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned non-volatile storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0108] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A data processing method based on the Universal Validation Methodology (UVM) validation environment, characterized in that, include: In the sending component, instantiate a target object of a lightweight data encapsulation class, encapsulate the target data into the target object, and obtain a data object. A global event is triggered in the sending component, and the data object is passed to the receiving component through the global event. The sending component and the receiving component are two different verification components with different roles implemented by software code in the UVM verification environment. The receiving component is used to obtain the data object from the global event when it listens for the global event. The receiving component is also used to extract the target data from the data object.

2. The method according to claim 1, characterized in that, The step of instantiating the target object of the lightweight data encapsulation class in the sending component, and encapsulating the target data into the target object to obtain a data object includes: The target object is instantiated in the sending component, and the data type of the target data is detected as a preset basic type, wherein the preset basic type includes at least one of the following: integer, floating-point, and string type; If the data type of the target data is the preset basic type, the target data is encapsulated into the target object to obtain the data object.

3. The method according to claim 2, characterized in that, The method further includes: If the target data is not of the preset basic type, the target data is converted into basic type data, wherein the data type of the basic type data is the preset basic type; The basic data type is encapsulated into the target object to obtain the data object.

4. The method according to claim 1, characterized in that, The global events are deployed in the UVM event pool, which stores and manages the global events so that they can be accessed and triggered by any component in the UVM verification environment in the form of asynchronous many-to-many communication.

5. A data processing method based on a UVM verification environment, characterized in that, include: When a global event is detected in the receiving component, a data object is obtained from the global event. The global event is triggered in the sending component and is used to pass the data object to the receiving component. The data object is obtained by encapsulating target data into a target object. The target object is obtained by instantiating a lightweight data encapsulation class in the sending component. Extract the target data from the data object.

6. The method according to claim 5, characterized in that, Before obtaining the data object from the global event and extracting the target data from the data object when the global event is detected in the receiving component, the method further includes: The receiving component is controlled to enter a waiting state and continuously listen to the global event until the global event is detected. The waiting state refers to the state of stopping the execution of subsequent tasks or processes.

7. The method according to claim 5, characterized in that, When the global event is detected in the receiving component, obtaining the data object from the global event and extracting the target data from the data object includes: When the global event is detected in the receiving component, the data object is obtained from the global event, and the data object is converted into the type of the lightweight data encapsulation class to obtain the converted data object. Extract the target data from the transformed data object.

8. The method according to any one of claims 5 to 7, characterized in that, When the global event is detected in the receiving component, obtaining the data object from the global event and extracting the target data from the data object includes: When the global event is detected in the receiving component, it is checked whether the global event meets a preset condition, wherein the preset condition includes at least one of the following: the trigger time of the global event is within a preset time range, or the global event is triggered after a predetermined event; When the global event meets the preset conditions, the data object is obtained from the global event, and the target data is extracted from the data object.

9. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores multiple instructions adapted for loading by a processor and executing the data processing method for the UVM verification environment according to any one of claims 1 to 8.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the data processing method for the UVM verification environment according to any one of claims 1 to 8.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the data processing method for the UVM verification environment as described in any one of claims 1 to 8.

Images