Method, device, equipment, medium and program product for verifying performance simulator

Abstract

The application discloses a performance simulator verification method, device, equipment, medium and program product, and belongs to the chip verification field. The method comprises the following steps: calling a general verification program, the general verification program supports object-oriented instantiation operation as a class file, and supports parameter specification through a configuration file, which is used to obtain a verification program of a performance simulator of each subsystem in a system on chip; when the object-oriented instantiation operation is performed on the general verification program, parameters of a first performance simulator are injected through the configuration file, a first verification program corresponding to the first performance simulator is obtained, and the first performance simulator is a performance simulator in any one of the subsystems in the system on chip; and a verification process for the first performance simulator is performed through the first verification program. The application provides a general performance simulator verification method.

Description

Technical Field

[0001] This application relates to the field of chip verification, and in particular to a verification method, apparatus, device, medium, and program product for a performance simulator. Background Technology

[0002] Performance simulators (Perf Monitor, PFM) are widely used in various subsystems of a System-on-a-Chip (SoC) to monitor various events executed by the execution device. The performance simulator sends the number of events executed by the execution device within a statistics window to the processor, which then flexibly schedules compiler instructions to the execution device based on the statistics, thereby improving the task completion efficiency of the execution device.

[0003] During the development of a system-on-a-chip (SoC), the performance simulators in each subsystem need to be effectively verified. However, given the increasingly complex designs and the growing number of subsystems, the number of performance simulators on the SoC will increase dramatically. Verifying a large number of performance simulators on the SoC will then consume significant verification resources and time. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and program product for verifying a performance simulator. The embodiments of this application provide a general method for verifying a performance simulator.

[0005] According to one aspect of this application, a method for verifying a performance simulator is provided, the method comprising the following steps.

[0006] The general verification program is invoked. As a class file, the general verification program supports object-oriented instantiation operations and supports specifying parameters through configuration files. It is used to obtain the verification program of the performance simulator of each subsystem in the on-chip system.

[0007] When performing object-oriented instantiation on the general verification program, the parameters of the first performance simulator are injected through the configuration file to obtain the first verification program corresponding to the first performance simulator. The first performance simulator is the performance simulator of any subsystem in the system on chip.

[0008] The verification process for the first performance simulator is performed through the first verification procedure.

[0009] According to one aspect of this application, a verification apparatus for a performance simulator is provided, the apparatus comprising the following modules.

[0010] The calling module is used to call the general verification program. The general verification program, as a class file, supports the execution of object-oriented instantiation operations and supports specifying parameters through configuration files. It is used to obtain the verification program of the performance simulator of each subsystem in the on-chip system.

[0011] The processing module is used to inject the parameters of the first performance simulator through the configuration file when performing object-oriented instantiation operation on the general verification program, so as to obtain the first verification program corresponding to the first performance simulator. The first performance simulator is the performance simulator of any subsystem in the system on chip.

[0012] The verification module is used to perform a verification process against the first performance simulator through the first verification program.

[0013] According to one aspect of this application, a computer device is provided, the computer device comprising: a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the performance simulator verification method as described above.

[0014] According to one aspect of this application, a computer-readable storage medium is provided that stores a computer program, which is loaded and executed by a processor to implement the performance simulator verification method as described above.

[0015] According to one aspect of this application, a computer program product is provided, the computer program product storing a computer program that is loaded and executed by a processor to implement the performance simulator verification method as described above.

[0016] The beneficial effects of the technical solutions provided in this application include at least the following:

[0017] This application provides a general verification program. The general verification program, as a class file, supports the execution of object-oriented instantiation operations and supports specifying parameters through a configuration file to obtain the verification program for the performance simulator of each subsystem in the on-chip system. For the first performance simulator in the first subsystem, the instantiated first verification program will be used to verify the first performance simulator.

[0018] This application provides a general verification scheme for performance simulators. The general verification program provided in this application unifies the verification environment of various performance simulators and can meet the verification call requirements of various performance simulators. This application provides a highly reusable and easily portable general verification program. The unified general verification program improves code reusability and reduces the amount of code development required for verification programs of various performance simulators.

[0019] The general verification program provided in this application can verify the performance simulators of at least two subsystems. Users only need to pass the corresponding parameters to the general verification program to continuously and automatically verify the performance simulators. The general verification program provided in this application can efficiently meet the verification requirements of all subsystems for the performance simulator, shorten the verification cycle, reduce code redundancy, and improve the reusability of the general verification program. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of a performance simulator verification method provided in one embodiment of this application.

[0022] Figure 2 This is a schematic diagram of a performance simulator verification method provided in another embodiment of this application.

[0023] Figure 3 This is a flowchart of a performance simulator verification method provided in one embodiment of this application.

[0024] Figure 4 This is a flowchart of a performance simulator verification method provided in another embodiment of this application.

[0025] Figure 5 This is a flowchart of a verification method for verifying a first performance simulator through a first verification procedure, provided in one embodiment of this application.

[0026] Figure 6 This is a schematic diagram of a performance simulator verification method provided in another embodiment of this application.

[0027] Figure 7 This is a flowchart of a statistical method for simulating event signals provided in one embodiment of this application.

[0028] Figure 8 This is a schematic diagram of a method for comparing predicted transaction packets and actual transaction packets provided in one embodiment of this application.

[0029] Figure 9 This is a structural block diagram of a performance simulator verification device provided in one embodiment of this application.

[0030] Figure 10 This is a schematic diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0032] First, some terms used in the embodiments of this application will be introduced.

[0033] Performance Simulator: A performance simulator is a device that can be embedded into a subsystem of a SoC. Within each subsystem, the performance simulator monitors and statistically analyzes various events executed by the execution device. When it receives a send request, the performance simulator packages the statistical data collected within the statistical period into a transaction packet and sends it to the processor in the subsystem. The processor, based on the received transaction packet, flexibly schedules the compiler's instructions and dispatches the scheduled instructions to the execution device to improve its execution efficiency. In other words, the performance simulator monitors the running status of the execution device and sends this status information to the processor.

[0034] Transaction packet comparison mechanism: When verifying the first performance simulator, the first performance simulator will receive simulated event signals and obtain actual transaction packets by statistically analyzing the simulated event signals; while the first verification program will receive simulated event signals and obtain predicted transaction packets by statistically analyzing the simulated event signals. The transaction packet comparison mechanism is the mechanism that compares the actual transaction packets and the predicted transaction packets.

[0035] Predicted transaction packet: refers to the transaction packet predicted by the first verification program when verifying the first performance simulator. Optionally, the predicted transaction packet includes statistical data of various simulated event signals. Optionally, the predicted transaction packet includes the number of times various simulated event signals are triggered. For example, the predicted transaction packet may include data such as simulated event signal A being triggered 5 times and simulated event signal B being triggered 2 times.

[0036] Actual transaction packet: refers to the transaction packet output by the first performance simulator during verification. Optionally, the actual transaction packet includes statistical data of various simulated event signals. Optionally, the actual transaction packet includes the trigger count of various simulated event signals. For example, the actual transaction packet may include data such as simulated event signal A being triggered 4 times and simulated event signal B being triggered 3 times.

[0037] Figure 1This illustration shows a schematic diagram of a general verification platform provided in an exemplary embodiment of this application, illustratively applied to a computer device. Optionally, the computer device includes at least one of a central processing unit (CPU), a graphics processing unit (GPU), a server, a server cluster, and a terminal device. Optionally, the terminal device includes at least one of a smartphone, tablet computer, laptop computer, and desktop computer. This application provides a general verification platform that supports performance simulators for verifying at least two subsystems.

[0038] like Figure 1 As shown, Figure 1 A first subsystem 10 and a second subsystem 20 are shown. The first subsystem 10 embeds a first performance simulator 11, and the second subsystem 20 embeds a second performance simulator 21. Figure 1 In the middle, the general verification platform 100 encapsulates a general configuration file 110, a general verification program 120, and a general interface file 130.

[0039] Optionally, the general configuration file 110, as a class file, supports object-oriented instantiation operations to obtain the verification configurations of the performance simulators for each subsystem in the on-chip system. For example, based on the parameters of the first performance simulator 11 input by the user, the general configuration file 110 is instantiated using object-oriented methods to obtain the first verification configuration corresponding to the first performance simulator 11 of the first subsystem 10; based on the parameters of the second performance simulator 21 input by the user, the general configuration file 110 is instantiated using object-oriented methods to obtain the second verification configuration corresponding to the second performance simulator 21 of the second subsystem 20.

[0040] In illustrative terms, the general configuration file 110 is a class file that receives parameters from the performance simulator input by the user and can be instantiated into a verification configuration that can be accepted by the general verification program 120.

[0041] Understandably, the general configuration file 110, as a class file, encapsulates the common code for the configuration information required by various performance simulators, reducing the amount of code users need to generate their own configurations.

[0042] Optionally, the general verification program 120, as a class file, supports object-oriented instantiation operations and receiving verification configurations to obtain verification programs for the performance simulators of various subsystems in the on-chip system. For example, based on the type of the first performance simulator 11 input by the user, the general verification program 120 performs object-oriented instantiation operations and receives the first verification configuration corresponding to the first performance simulator 11 to obtain the first verification program corresponding to the first performance simulator 11 of the first subsystem 10; based on the type of the second performance simulator 21 input by the user, the general verification program 120 performs object-oriented instantiation operations and receives the second verification configuration corresponding to the second performance simulator 21 to obtain the second verification program corresponding to the second performance simulator 21 of the second subsystem 20.

[0043] Understandably, the Universal Verifier 120, as a class file, encapsulates the common code for the verification programs required by various performance simulators, reducing the amount of code users need to design their own verification programs.

[0044] Optionally, the general interface file 130 is a class file that supports object-oriented instantiation operations to obtain the transmission interfaces corresponding to the performance simulators of each subsystem in the on-chip system. The transmission interface is used to pass relevant signals from the user design code to the verification program. For example, based on the type of event signal required by the first performance simulator 11, the general interface file 130 is instantiated using object-oriented methods to obtain the first transmission interface corresponding to the first performance simulator 11 of the first subsystem 10; based on the type of event signal required by the second performance simulator 21, the general interface file 130 is instantiated using object-oriented methods to obtain the second transmission interface corresponding to the second performance simulator 21 of the second subsystem 20.

[0045] Understandably, the generic interface file 130, as a class file, encapsulates the generic code for the transmission interfaces required by various performance simulators, reducing the amount of code users need to create their own interfaces.

[0046] In one embodiment, an object-oriented instantiation operation is performed on the general configuration file 110 to obtain the first verification configuration corresponding to the first performance simulator 11; an object-oriented instantiation operation is performed on the general verification program 120 and the first verification configuration is passed in to obtain the first verification program corresponding to the first performance simulator 11. An object-oriented instantiation operation is performed on the general interface file 130 to obtain the first transmission interface corresponding to the first performance simulator 11. The verification process of the first performance simulator 11 will be illustrated below.

[0047] Figure 2 This illustration shows a schematic diagram of verifying a first performance simulator 11 through a first verification procedure 210, as provided in an exemplary embodiment of this application. Figure 2As shown, the first verification procedure 210 includes a statistical task 211, a result comparison queue 212, and a comparison task 213. Figure 2 The first transmission interface 230 is also shown.

[0048] like Figure 2 As shown, when verifying the first performance simulator 11, the user needs to provide user-designed code 220. User-designed code 220 contains user-designed simulated event signals 221, which are excitation signals used to verify the first performance simulator 11. The computer device sends the simulated event signals 221 to the first performance simulator 11 in the first subsystem 10. The first performance simulator 11 statistically analyzes the simulated event signals 221 to obtain actual transaction packets, which include statistical data of the simulated event signals 221. The actual transaction packets are then passed to the result comparison queue 212 in the first verification program 210.

[0049] Furthermore, during the verification of the first performance simulator 11, the simulated event signal 221 in the user design code 220 is transmitted to the statistical task 211 in the first verification program 210 via the first transmission interface 230. The statistical task 211 statistically analyzes the simulated event signal 221 to obtain a predicted transaction packet, which includes statistical data of the simulated event signal 221. The predicted transaction packet is then passed to the result comparison queue 212 in the first verification program 210.

[0050] The comparison task 213 in the first verification program 210 obtains the actual transaction packet and the predicted transaction packet from the result comparison queue 212, performs the transaction packet comparison, and obtains the comparison result of the transaction packet; optionally, the comparison task 213 outputs the comparison result of the transaction packet as the verification result of the first performance simulator 11.

[0051] In summary, the first verification program instantiated using the general verification program provided in this application instantiates statistically simulated event signals to obtain predicted transaction packets, and then compares the predicted transaction packets with the actual transaction packets to obtain the verification result of the first performance simulator. The method of comparing transaction packets after statistically simulating event signals provided in this application conforms to the functional utility of a performance simulator and can correctly and effectively verify the performance simulator.

[0052] Figure 3 A flowchart of a verification method for a performance simulator provided in an exemplary embodiment of this application is shown, illustrated by way of example that the method is performed by a computer device, and the method includes the following steps.

[0053] Step 320: Call the general verification program. The general verification program, as a class file, supports the execution of object-oriented instantiation operations and supports specifying parameters through configuration files. It is used to obtain the verification program of the performance simulator of each subsystem in the on-chip system.

[0054] The generic verification program, provided in this application embodiment, is a class file that encapsulates the generic code required by various performance simulators for verification programs. The generic verification program supports object-oriented instantiation operations and allows specifying parameters through configuration files to obtain verification programs for the performance simulators of various subsystems within the on-chip system. When performing verification on the first performance simulator in the first subsystem, the generic verification program will undergo object-oriented instantiation operations, and the parameters of the first performance simulator will be specified through the configuration file to obtain the first verification program corresponding to the first performance simulator. The first verification program is used to execute the verification process for the first performance simulator.

[0055] In this embodiment, as an illustration, the user can automatically verify the first performance simulator by calling a general verification program and passing in the corresponding parameters of the first performance simulator. When the user needs to verify the performance simulators of all subsystems on the entire SoC, the user only needs to call the general verification program and pass in the corresponding parameters of each performance simulator to automatically verify all performance simulators.

[0056] It is understood that the general verification program provided in this application embodiment has high portability and code uniformity. When used to verify the performance simulator of multiple subsystems, it can satisfy the one-click call of all subsystems. Each subsystem can continuously and automatically verify the performance simulator by calling the general verification program with one click and passing in very little corresponding code.

[0057] Step 340: When performing object-oriented instantiation on the general verification program, the parameters of the first performance simulator are injected through the configuration file to obtain the first verification program corresponding to the first performance simulator. The first performance simulator is the performance simulator of any subsystem in the system on chip.

[0058] The first performance simulator is the performance simulator in the first subsystem. It monitors the operating status of the execution devices within the subsystem. Specifically, it counts the number of events executed by the execution devices in the subsystem during a statistical period. A subsystem refers to a functional system on the SoC, and the first subsystem refers to any functional system on the SoC. Optionally, the first subsystem can be a D2D (Device to Device) system, where the execution device in the first subsystem is any one of two devices communicating with each other; alternatively, the first subsystem can be a DDR (Double Data Rate) system, where the execution device in the first subsystem is DDR memory; alternatively, the first subsystem can be an IIC (Inter-Integrated Circuit) system, where the execution device in the first subsystem is a device communicating using IIC.

[0059] In one embodiment, the generation process of the first verification program corresponding to the first performance simulator includes two steps: one step is to perform an object-oriented instantiation operation on the general verification program, and the other step is to inject parameters of the first performance simulator through a configuration file. For the first step, optionally, the object-oriented instantiation operation is performed on the general verification program according to the type of the first performance simulator input by the user. For example, the general verification program includes classes of functional components such as statistical tasks (used to statistically simulate event signals to obtain predicted transaction packets), result comparison queues (used to hold predicted transaction packets and actual transaction packets), and comparison tasks (used to compare predicted transaction packets and actual transaction packets). Instantiated objects of these functional component classes are created according to the type of the first performance simulator.

[0060] Understandably, this application will adopt the concept of object-oriented programming to encapsulate (abstract) the verification functions shared by the performance simulators of various subsystems into a reusable class (functional component class), and then allow different subsystems to call these verification functions by instantiating this class and creating new objects.

[0061] Optionally, based on the event signal type corresponding to the first performance simulator input by the user, an object-oriented instantiation operation is performed on the general verification program. The instantiated first verification program can verify the response result of the first performance simulator to a specific event signal type, where the event signal type is the type of event signal transmitted in the first subsystem.

[0062] Optionally, based on the clock parameters that the first performance simulator needs to verify, an object-oriented instantiation operation is performed on the general verification program to obtain the first verification program corresponding to the first performance simulator. The instantiated first verification program can verify the response results of the first performance simulator to specific clock parameters. Optionally, the clock parameters are the parameters of the clock used in the first subsystem.

[0063] The second step involves injecting parameters from the first performance simulator via a configuration file. Optionally, the configuration file can be a completely user-generated verification configuration containing the parameters of the first performance simulator. In this case, the user will have prior knowledge of the data structure required by the general verification program and can generate the complete verification configuration independently. Alternatively, the configuration file can be a generic configuration file. The user inputs the parameters of the first performance simulator into the generic configuration file to generate the first verification configuration corresponding to the first performance simulator. This first verification configuration is then injected into the general verification program. In this case, the configuration file acts as a class file, encapsulating the generic code for the configuration information required by various performance simulators.

[0064] Step 360: Perform a verification process for the first performance simulator using the first verification procedure.

[0065] The first verification procedure executes a verification process for the first performance simulator. In one embodiment, the first verification procedure compares the predicted transaction packets with the actual transaction packets; the comparison result between the predicted and actual transaction packets is used as the verification result of the first performance simulator.

[0066] In another embodiment, a first verification procedure compares the predicted duration with the actual duration, and uses the comparison result as the verification result of the first performance simulator. The predicted duration refers to the time between the time the simulated event signal is emitted and the time when the first verification procedure finishes counting the simulated event signal. The actual duration refers to the time between the time the simulated event signal is emitted and the time when the first performance simulator finishes counting the simulated event signal.

[0067] In summary, this application provides a general verification program that supports object-oriented instantiation operations as a class file. This general verification program can be instantiated to obtain verification programs for performance simulators of any subsystem within the on-chip system. Therefore, this application proposes a portable and reusable general verification program. When verifying the performance simulators of various subsystems in a large-scale integrated circuit design project, only the general verification program needs to be used to instantiate the verification programs required for the specific performance simulator. This achieves efficient verification of the performance simulator on the SoC, saving the verification time cost of each subsystem and improving the overall R&D efficiency of the SoC.

[0068] based on Figure 3 The optional embodiments shown, Figure 3 The configuration file in the document is a generic configuration file. Step 340 includes... Figure 4 Steps 410 to 430 are shown. Figure 4 A flowchart of a verification method for a performance simulator provided in an exemplary embodiment of this application is shown, illustrated by way of example that the method is performed by a computer device, and the method includes the following steps.

[0069] Step 410: Call the general configuration file. The general configuration file, as a class file, supports the execution of object-oriented instantiation operations to obtain the verification configuration of the performance simulator of each subsystem in the on-chip system.

[0070] The general configuration file, as provided in this application embodiment, is a class file that encapsulates general code containing configuration information required by various performance simulators. The general configuration file can be instantiated according to the verification requirements of performance simulators in at least two subsystems, obtaining verification configurations corresponding to the performance simulators of each subsystem. When performing verification on the first performance simulator in the first subsystem, the general configuration file will be instantiated as the first verification configuration corresponding to the first performance simulator. The first verification configuration includes the configuration information required by the first verification program to verify the first performance simulator.

[0071] In this embodiment, as an illustration, the user can generate the first verification configuration by calling a general configuration file and performing an instantiation operation. When the user needs to generate verification configurations for the performance simulators of all subsystems on the entire SoC, the user only needs to call the general configuration file and pass in the parameters of each performance simulator to automatically generate all verification configurations.

[0072] Step 420: Based on the parameters of the first performance simulator input by the user, perform an object-oriented instantiation operation on the general configuration file to obtain the first verification configuration corresponding to the first performance simulator;

[0073] In one embodiment, based on the parameters of the first performance simulator input by the user, an object-oriented instantiation operation is performed on the general configuration file to obtain the first verification configuration corresponding to the first performance simulator. In this embodiment, the concept of object-oriented programming is adopted to encapsulate (abstract) the verification configuration shared by the performance simulators of various subsystems into a reusable class (configuration class), and then allow different subsystems to call these verification configurations by instantiating this class and creating new objects.

[0074] For example, the general configuration file contains the group number class of the signal interface, the allowable error window class used for verification and comparison, etc. The verification configuration of the performance simulator is obtained by creating instantiated objects of these classes.

[0075] Optionally, based on the group number of the signal interface used by the first performance simulator input by the user, an object-oriented instantiation operation is performed on the general configuration file to obtain the first verification configuration corresponding to the first performance simulator. The first verification configuration includes the group number of the signal interface used by the first performance simulator.

[0076] For illustrative purposes, the first performance simulator has at least two sets of signal interfaces. For example, there are set 1, set 2, set 3, set 4, set 5, etc. During verification, it is necessary to package the statistical data corresponding to the simulated event signals of each set of signal interfaces separately. The signal interface refers to the interface used by the first performance simulator to input event signals.

[0077] Optionally, based on the allowable error window used by the first performance simulator as input by the user, an object-oriented instantiation operation is performed on the general configuration file to obtain the first verification configuration corresponding to the first performance simulator. The first verification configuration includes the allowable error window used by the first performance simulator.

[0078] As an illustration, when validating the first performance simulator, it is necessary to compare the predicted transaction packets and the actual transaction packets. If the error in the statistical data contained in both falls within the allowable error window, the comparison is considered successful, and thus the first performance simulator can be considered valid. Optionally, the first validation configuration includes allowable error windows for each event used during the first performance simulator validation comparison. In this case, the general configuration file allows users to configure allowable error windows at the event level, enabling the first validation program to achieve more accurate comparisons.

[0079] Step 430: When performing object-oriented instantiation on the general verification program, the first verification configuration is injected to obtain the first verification program corresponding to the first performance simulator.

[0080] In one embodiment, when performing object-oriented instantiation on the general verification program, a first verification configuration is also injected to obtain the first verification program corresponding to the first performance simulator. In another embodiment, based on the type of the first performance simulator input by the user, an object-oriented instantiation operation is performed on the general verification program, and the first verification configuration is injected into the general verification program to obtain the first verification program.

[0081] In summary, the above embodiments provide a general configuration file. As a class file, the general configuration file supports object-oriented instantiation operations to obtain the verification configuration of the performance simulators of various subsystems in the on-chip system. In this way, the general verification program can pass in the verification configurations corresponding to various performance simulators. For example, the general verification program can pass in the first verification configuration corresponding to the first performance simulator; the general verification program can pass in the second verification configuration corresponding to the second performance simulator.

[0082] based on Figure 3 In the optional embodiment shown, step 360 includes Figure 5 Steps 520 to 560 are shown. Figure 5 This is a flowchart illustrating a method for verifying a first performance simulator through a first verification procedure, provided in an exemplary embodiment of this application. The method is illustrated by example, with the method being executed by a computer device. The method includes:

[0083] Step 520: Through the first verification procedure, the predicted transaction packet is obtained by statistically analyzing the simulated event signals. The simulated event signals are the event signals input by the first performance simulator during verification.

[0084] Simulated event signals are used to verify the excitation signals of the first performance simulator. Optionally, different performance simulators in different subsystems may have different simulated event signals. Optionally, the same performance simulator may have multiple simulated event signals. The simulated event signals are simulation signals of the event signals monitored by the performance simulator.

[0085] In one embodiment, simulated event signals from user-designed code are transmitted to a first verification program via a first transmission interface. The user-designed code is user-designed code that includes simulated event signals for verifying a first performance simulator. Optionally, the simulated event signals from the user-designed code are transmitted to a statistical task within the first verification program via the first transmission interface.

[0086] This is illustrated by calling a generic interface file. This generic interface file, acting as a class file, supports object-oriented instantiation to obtain the transmission interfaces corresponding to the performance simulators of each subsystem in the on-chip system. Performing object-oriented instantiation on the generic interface file yields the first transmission interface corresponding to the first performance simulator. For example, based on the type of simulated event signal in the user-designed code, the generic interface file is instantiated as the first transmission interface. This first transmission interface is used to transmit the corresponding type of simulated event signal. In other words, based on the type of event signal required as input by the first performance simulator, performing object-oriented instantiation on the generic interface file yields the first transmission interface corresponding to the first performance simulator.

[0087] In one embodiment, a predicted transaction packet is obtained by statistically analyzing simulated event signals through a statistical task in the first verification procedure. Optionally, the predicted transaction packet is obtained by receiving simulated event signals through the statistical task and counting the number of times the simulated event signals are triggered. Illustratively, the statistical task includes a statistical counter, which increments the count value of the corresponding simulated event signal by one each time it receives a simulated event signal.

[0088] In some embodiments, the first performance simulator has at least two sets of signal interfaces. The signal interface is the interface used by the first performance simulator to receive event signals (simulated event signals). During verification, it is also necessary to further distinguish the statistical data corresponding to the simulated event signals received by each set of signal interfaces.

[0089] Optionally, the first verification configuration includes the group number of each of the at least two groups of signal interfaces. Through the statistical task in the first verification program, simulated event signals are statistically analyzed to obtain intermediate transaction packets. Based on the group numbers of the at least two groups of signal interfaces, the statistical data corresponding to the simulated event signals for each group number in the intermediate transaction packet are packaged to obtain a predicted transaction packet.

[0090] For example, a statistical task simulates event signals and finds that event A was triggered 5 times, event B was triggered 3 times, event C was triggered 6 times, and event D was triggered 4 times. Among them, events A, B, and D are events corresponding to the first group of signal interfaces, and event C is an event corresponding to the second group of signal interfaces. Therefore, the statistical data corresponding to events A, B, and D are packaged into one sub-package, and the statistical data corresponding to event C is packaged into another sub-package. The two sub-packages constitute a complete prediction transaction package.

[0091] Step 540: Receive the actual transaction packet output by the first performance simulator through the first verification procedure;

[0092] In one embodiment, a predicted transaction packet and an actual transaction packet output by a first performance simulator are received through a result comparison queue in the first verification procedure. The result comparison queue carries both the predicted and actual transaction packets. The predicted and actual transaction packets in the result comparison queue are in a state awaiting comparison. Optionally, the result comparison queue includes predicted and actual transaction packets for multiple statistical periods, with the predicted and actual transaction packets for each statistical period queued sequentially in the result comparison queue, waiting to be compared.

[0093] In one embodiment, a user can mount a protocol checking tool to receive actual transaction packets output from the first performance simulator. In another embodiment, the actual transaction packet output by the protocol checking tool is received via a result comparison queue in the first verification procedure, provided the protocol checking tool passes the check. The protocol checking tool is used to check the protocol of the actual transaction packets output by the first performance simulator, and this tool is mounted by the user. Optionally, the actual transaction packet is an AXI (Advanced eXtensible Interface) transaction packet, and the protocol checking tool is used to check the AXI protocol of the actual transaction packet.

[0094] For example, a user can create an interface for a standard protocol checking tool, connect it to the output interface of a first performance simulator, and receive the actual transaction packets output by the first performance simulator. The first verification program then transmits the actual transaction packets output by the protocol checking tool to the result comparison queue via the port.

[0095] like Figure 6 As shown, the user mounts a protocol checking tool 60 outside the general verification platform 100. The protocol checking tool 60 is used to receive the actual transaction packets output by the first performance simulator 11 and check whether the protocol is correct. If the check passes, the actual transaction packets are sent to the result comparison queue 212.

[0096] In this embodiment of the application, the actual transaction packets output by the first performance simulator will undergo protocol checks to ensure that the protocol checks pass before the actual transaction packets are sent to the result comparison queue. This avoids invalid or erroneous actual transaction packets from entering the result comparison queue, which would otherwise cause the result comparison queue to be blocked and reduce verification efficiency.

[0097] In one embodiment, the first verification program has an embedded transaction packet queue, which carries the received actual transaction packets. Optionally, the transaction packet queue includes a response feedback code. When the first verification program receives an actual transaction packet, it returns a response signal to the first performance simulator, causing the first performance simulator to continuously send out actual transaction packets. The response signal is used to feedback to the first performance simulator that the actual transaction packet has been received.

[0098] like Figure 6As shown, the first verification program 210 internally embeds a transaction packet queue 214. The transaction packet queue 214 receives actual transaction packets output by the protocol checking tool 60 and sends these actual transaction packets to the result comparison queue 212. Optionally, the transaction packet queue 214 contains a response feedback code. When an actual transaction packet is received, a response signal (not shown) is returned to the first performance simulator 11 through the response feedback code, enabling the first performance simulator 11 to continuously send actual transaction packets. The transaction packet queue 214 can continuously receive actual transaction packets, providing a strong guarantee for the continuous transmission of actual transaction packets.

[0099] Furthermore, by returning a response signal to the first performance simulator through the response feedback code, the correct reception of the actual transaction packets can be guaranteed, avoiding the use of incorrect actual transaction packets for comparison in the event of loss or errors in the actual transaction packets, thus ensuring the accuracy of the verification results of the first performance simulator.

[0100] Step 560: Through the first verification procedure, based on the comparison results of the predicted transaction packets and the actual transaction packets, the verification results of the first performance simulator are obtained.

[0101] In one embodiment, the comparison task in the first verification procedure compares the predicted transaction package and the actual transaction package to obtain a comparison result, which is then used as the verification result of the first performance simulator. Optionally, the comparison task compares each event in the predicted and actual transaction packages, comparing the statistical data for each event, and using the comparison result for each event as the verification result of the first performance simulator. Optionally, the comparison task compares the statistical data for the same event in the predicted and actual transaction packages to obtain comparison results for multiple events; the verification result of the first performance simulator is obtained by combining the comparison results of multiple events.

[0102] In summary, the first verification program instantiated using the general verification program provided in this application instantiates statistically simulated event signals to obtain predicted transaction packets, and then compares the predicted transaction packets with the actual transaction packets to obtain the verification result of the first performance simulator. The method of comparing transaction packets after statistically simulating event signals provided in this application conforms to the functional utility of a performance simulator and can correctly and effectively verify the performance simulator.

[0103] In related technologies, simulated event signals are continuously emitted, and a statistical counter continuously counts to generate predicted transaction packets. There may be differences between the simulated event signals counted by the statistical counter and those counted by the first performance simulator. In one scenario, a time difference exists between the received simulated event signals by the statistical counter and those received by the first performance simulator. This time difference causes the statistical counter to accumulate simulated event signals outside the statistical period, resulting in excessively large statistical data in the predicted transaction packets. In another scenario, the statistical counter accumulates simulated event signals outside the statistical period after the first performance simulator outputs the actual transaction packets, leading to excessively large statistical data in the predicted transaction packets.

[0104] Therefore, the relevant technologies are not accurate enough in generating predictive transaction packets, resulting in a large error in the comparison results.

[0105] In one embodiment, this application provides a precise data latching mechanism.

[0106] In this embodiment, the general first transmission interface not only transmits the simulated event signals in the user-designed code to the first verification program, but also transmits the start and end trigger signals corresponding to each simulated event signal to the first verification program. That is, optionally, the first transmission interface transmits the simulated event signals in the user-designed code, along with the start and end trigger signals corresponding to each simulated event signal, to the statistical task in the first verification program. Optionally, when verifying the first performance simulator, the user can instantiate a general interface file (the general interface file, as a class file, supports object-oriented instantiation operations to obtain the transmission interfaces corresponding to the performance simulators of each subsystem in the on-chip system) to obtain the first transmission interface. The first transmission interface is used to transmit the simulated event signals corresponding to the first performance simulator, along with the start and end trigger signals of the simulated event signals, to the first verification program.

[0107] based on Figure 5 In the optional embodiment shown, step 520 includes Figure 7 Steps 720 and 740 are shown. Figure 7 A flowchart of a statistical method for simulating event signals provided in an exemplary embodiment of this application is shown, illustrated by way of example that the method is performed by a computer device, and the method includes the following steps.

[0108] Step 720: Through the statistical task in the first verification procedure, statistical analysis of simulated event signals is performed, and the end trigger signal corresponding to each simulated event signal is monitored.

[0109] The statistical task will receive the start and end trigger signals for each simulated event signal and monitor the end trigger signal. The start trigger signal represents the start of the simulated event signal, and the end trigger signal represents the end of the simulated event signal. Optionally, the start trigger signal is the rising edge of the clock corresponding to the simulated event signal, and the end trigger signal is the falling edge of the clock corresponding to the simulated event signal.

[0110] Step 740: In response to the end trigger signal corresponding to the last simulated event signal in the monitoring statistical period, latch the statistical data collected at the current moment to obtain the predicted transaction packet.

[0111] The statistical task will continuously collect simulated event signals. When the end trigger signal corresponding to the last simulated event signal in the statistical period is detected, the statistical data collected at the current moment will be latched into another set of statistical data. The statistical counter in the statistical task will continue to count. That is, the precise data latching mechanism provided by this application does not affect the continuous counting of the statistical counter.

[0112] Understandably, the precise data latching mechanism provided in this application enables effective monitoring of simulated event signals, allowing statistical tasks to accurately count the number of times simulated event signals are triggered. Furthermore, the above embodiments employ a register method to count and latch simulated event signals, completing the acquisition and packaging of statistical data without interrupting existing counting. This accurately captures the statistical time corresponding to the statistical data, not only avoiding interruption of statistical data but also improving the reliability of subsequent comparisons between predicted and actual transaction packages.

[0113] based on Figure 5 In the optional embodiment shown, step 560 includes Figure 8 Steps 820 and 840 are shown. Figure 8 A flowchart of a method for comparing predicted transaction packets and actual transaction packets provided in an exemplary embodiment of this application is shown, illustrated by way of example that the method is performed by a computer device, and the method includes the following steps.

[0114] Step 820: Through the comparison task in the first verification procedure, the predicted transaction package and the actual transaction package are decomposed at the event granularity to obtain the first occurrence count of each event in the predicted transaction package and the second occurrence count of each event in the actual transaction package;

[0115] For example, the predicted transaction package includes data such as event A being triggered 3 times, event B being triggered 6 times, and event C being triggered 5 times. The actual transaction package includes data such as event A being triggered 2 times, event B being triggered 9 times, and event C being triggered 4 times.

[0116] Then, through the comparison task in the first verification procedure, the predicted transaction package and the actual transaction package are decomposed at the event granularity, and it is found that event A appeared 3 times in the predicted transaction package and 2 times in the actual transaction package.

[0117] Event B appeared 6 times in the predicted transaction packet and 9 times in the actual transaction packet;

[0118] Event C occurred 5 times in the predicted transaction packet and 4 times in the actual transaction packet.

[0119] Step 840: By comparing the first occurrence count and the second occurrence count of each event, the verification result of the first performance simulator is obtained.

[0120] Optionally, the verification result of the first performance simulator can be obtained by comparing the difference between the first occurrence count and the second occurrence count of each event. Alternatively, the verification result of the first performance simulator can be obtained by comparing the ratio of the difference between the first occurrence count and the second occurrence count of each event. The ratio is the ratio of the difference between the first occurrence count and the second occurrence count to the first occurrence count.

[0121] In related technologies, the same allowable error window is used when comparing predicted transaction packets and actual transaction packets. Specifically, the same allowable error window is used for different performance simulators, and the same allowable error window is also used for multiple simulated events corresponding to the same performance simulator. However, different performance simulators and different event signals have different synchronization difficulties. Some event signals are more difficult to synchronize, while others are easier to synchronize. In this case, if all events and all performance simulators use the same allowable error window, the verification results of the performance simulator will not be accurate enough.

[0122] In one embodiment, different events are configured with different allowable error windows. A universal configuration file allows users to set different allowable error windows for different events. Users can design the allowable error window for each event for the first performance simulator and pass it to the first verification program through the first verification configuration instantiated from the universal configuration file.

[0123] Optionally, according to the allowable error window for each event, the first occurrence count and the second occurrence count of each event are compared, and the verification result of the first performance simulator is obtained based on the comparison result of each event.

[0124] In one embodiment, events that are difficult to synchronize statistically in the first verification program and the first performance simulator are configured with a larger allowable error window; events that are easier to synchronize statistically in the first verification program and the performance simulator are configured with a smaller allowable error window.

[0125] In one embodiment, the comparison result of each event is used as a partial verification result of the first performance simulator.

[0126] For example, the difference between the number of occurrences of event A in the predicted transaction packet and the actual transaction packet is 1 / 3. The allowable error window for event A is configured as (0, 1 / 4), that is, event A is allowed to have an error ratio of 25%. Therefore, the first performance simulator verification fails for event A.

[0127] For example, the difference between the number of occurrences of event B in the predicted transaction packet and the actual transaction packet is 1 / 2, and the allowable error window for event A is configured as (0, 1 / 3), that is, event A is allowed to have an error ratio of 1 / 3. Therefore, for event B, the first performance simulator verification fails.

[0128] For example, the difference between the number of occurrences of event C in the predicted transaction packet and the actual transaction packet is 1 / 5, and the allowable error window for event A is configured as (0, 1 / 2), that is, event A is allowed to have an error ratio of 1 / 2. Therefore, for event C, the first performance simulator verification is passed.

[0129] In another embodiment, the comparison result for each event is obtained; by combining the comparison results of multiple events, the verification result of the first performance simulator is obtained. For example, the predicted transaction package and the actual transaction package cover a total of 10 events. Among the 10 events, 3 events fail the comparison, and 7 events pass the comparison, i.e., the pass rate is 0.7. The pass rate of 0.7 falls into the third level of the configured four-level verification result. The four levels of verification results are: Verification Pass: Pass rate (0.9~1); Good: Pass rate (0.8~0.9); Pass: Pass rate (0.6~0.8); Verification Fail: Pass rate (0~0.6). Through the first verification program, "Pass" is output as the verification result of the first performance simulator.

[0130] In summary, the above embodiments distinguish different simulated event signals when comparing predicted transaction packets and actual transaction packets. Different simulated event signals can be configured with different allowable error windows. The above embodiments take into account the problem that some simulated event signals are difficult to synchronize, and allow larger errors for simulated event signals that are more difficult to synchronize, thus meeting the comparison requirements of different simulated event signals.

[0131] Figure 9 An exemplary embodiment of this application provides a verification apparatus for a performance simulator, the apparatus comprising the following modules.

[0132] Module 901 is called to invoke the general verification program. The general verification program, as a class file, supports object-oriented instantiation operations and supports specifying parameters through configuration files to obtain the verification program of the performance simulator of each subsystem in the on-chip system.

[0133] The processing module 902 is used to inject the parameters of the first performance simulator through the configuration file when performing object-oriented instantiation operation on the general verification program, so as to obtain the first verification program corresponding to the first performance simulator. The first performance simulator is the performance simulator of any subsystem in the system on chip.

[0134] Verification module 903 is used to perform a verification process against the first performance simulator through the first verification program.

[0135] In an optional embodiment, the verification module 903 is further configured to obtain a predicted transaction packet by statistically analyzing simulated event signals through a first verification procedure, wherein the simulated event signals are event signals input by the first performance simulator during verification; and to receive the actual transaction packet output by the first performance simulator through the first verification procedure.

[0136] The first verification procedure obtains the verification results of the first performance simulator based on the comparison results between the predicted transaction packets and the actual transaction packets.

[0137] In an optional embodiment, the device further includes a receiving module 904. The receiving module 904 is further configured to receive the predicted transaction packet through a result comparison queue in the first verification procedure after obtaining the predicted transaction packet by statistically analyzing the simulated event signal through the first verification procedure.

[0138] After passing the result comparison queue in the first verification procedure, the actual transaction packet output by the protocol checking tool is received if the actual transaction packet passes the check by the protocol checking tool.

[0139] The protocol checking tool is used to check the protocol of the actual transaction packets output by the first performance simulator. The protocol checking tool is a tool that is mounted by the user.

[0140] In an optional embodiment, the first verification procedure includes a response feedback code, and the apparatus further includes a sending module 905. The sending module 905 is configured to return a response signal to the first performance simulator via the response feedback code when the first verification procedure receives an actual transaction packet. The response signal is used to indicate to the first performance simulator that the actual transaction packet has been received.

[0141] In an optional embodiment, the calling module 901 is also used to call a general interface file, which, as a class file, supports the execution of object-oriented instantiation operations to obtain the signal interfaces corresponding to the performance simulators of each subsystem in the on-chip system.

[0142] The processing module 902 is also used to perform an object-oriented instantiation operation on the general interface file according to the type of event signal required by the first performance simulator, so as to obtain the first transmission interface corresponding to the first performance simulator.

[0143] The sending module 905 is used to transmit the simulated event signals in the user design code, the start trigger signal and the end trigger signal corresponding to each simulated event signal to the first verification program through the first transmission interface.

[0144] In an optional embodiment, the verification module 903 is further configured to perform statistical analysis of simulated event signals and monitor the end trigger signal corresponding to each simulated event signal through a statistical task in the first verification procedure.

[0145] In response to the end trigger signal corresponding to the last simulated event signal in the monitoring statistical period, the statistical data collected at the current moment is latched to obtain the predicted transaction packet.

[0146] In an optional embodiment, the first performance simulator has at least two sets of signal interfaces; the verification module 903 is also used to latch the statistical data collected at the current moment in response to the end trigger signal corresponding to the last simulated event signal in the statistical period, and obtain the intermediate transaction packet.

[0147] Based on the group sequence numbers of at least two groups of signal interfaces, the statistical data corresponding to the simulated event signals of each group sequence number in the intermediate transaction packet are packaged to obtain the predicted transaction packet.

[0148] In an optional embodiment, the first verification procedure includes a comparison task; the verification module 903 is further configured to decompose the predicted transaction package and the actual transaction package at the event granularity by executing the comparison task, and obtain the first occurrence count of each event in the predicted transaction package and the second occurrence count in the actual transaction package.

[0149] The verification results of the first performance simulator are obtained by comparing the first and second occurrence counts of each event.

[0150] In an optional embodiment, the verification module 903 is further configured to compare the first occurrence count and the second occurrence count of each event according to the allowable error window for each event, wherein different events are configured with different allowable error windows;

[0151] Based on the comparison results of each event, the verification results of the first performance simulator are obtained.

[0152] In an optional embodiment, events that are difficult to synchronize statistically in the first verification procedure and the first performance simulator are configured with a larger allowable error window.

[0153] Events that are easier to synchronize statistically in the first verification procedure and performance simulator are configured with a small allowable error window.

[0154] In an optional embodiment, the verification module 903 is further configured to obtain the comparison result for each event;

[0155] By combining the comparison results of multiple events, the verification results of the first performance simulator are obtained.

[0156] In an optional embodiment, the configuration file is a general configuration file. Module 901 is also used to invoke the general configuration file, which, as a class file, supports object-oriented instantiation operations to obtain the verification configuration of the performance simulator for each subsystem in the on-chip system.

[0157] The processing module 902 is also used to perform an object-oriented instantiation operation on the general configuration file according to the parameters of the first performance simulator input by the user, so as to obtain the first verification configuration corresponding to the first performance simulator;

[0158] The processing module 902 is also used to inject the first verification configuration when performing object-oriented instantiation operation on the general verification program, so as to obtain the first verification program corresponding to the first performance simulator.

[0159] In an optional embodiment, the processing module 902 is further configured to perform an object-oriented instantiation operation on the general verification program according to the type of the first performance simulator input by the user, so as to obtain the first verification program corresponding to the first performance simulator.

[0160] In summary, the embodiments of this application provide a general verification program. The general verification program, as a class file, supports the execution of object-oriented instantiation operations to obtain the verification program of the performance simulator of each subsystem in the on-chip system. For the first performance simulator in the first subsystem, the instantiated first verification program will be used to verify the first performance simulator.

[0161] This application provides a general verification scheme for performance simulators. The general verification program provided in this application unifies the verification environment of various performance simulators and can meet the verification call requirements of various performance simulators. This application provides a highly reusable and easily portable general verification program. The unified general verification program improves code reusability and reduces the amount of code development required for verification programs of various performance simulators.

[0162] The general verification program provided in this application can verify the performance simulators of at least two subsystems. Users only need to pass the corresponding parameters to the general verification program to continuously and automatically verify the performance simulators. The general verification program provided in this application can efficiently meet the verification requirements of all subsystems for the performance simulator, shorten the verification cycle, reduce code redundancy, and improve the reusability of the general verification program.

[0163] Figure 10 This illustration shows a structural block diagram of a computer device 1000 provided in an exemplary embodiment of this application. The computer device 1000 may be a portable mobile terminal, such as a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. The computer device 1000 may also be referred to as a user device, portable terminal, laptop terminal, desktop terminal, or other names.

[0164] Typically, computer device 1000 includes a processor 1001 and a memory 1002.

[0165] Processor 1001 may include one or more processing cores, such as a quad-core processor, a hexa-core processor, etc. Processor 1001 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1001 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1001 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1001 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0166] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1002 are used to store at least one instruction, which is executed by the processor 1001 to implement the performance simulator verification method provided in the method embodiments of this application.

[0167] The computer device 1000 may optionally include a peripheral device interface 1003 and at least one peripheral device. The processor 1001, memory 1002, and peripheral device interface 1003 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1003 via a bus, signal line, or circuit board. The peripheral device interface 1003 can be used to connect at least one I / O (Input / Output) related peripheral device to the processor 1001 and memory 1002. In some embodiments, the processor 1001, memory 1002, and peripheral device interface 1003 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1001, memory 1002, and peripheral device interface 1003 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0168] Those skilled in the art will understand that Figure 10 The structure shown does not constitute a limitation on the computer device 1000, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0169] This application also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the performance simulator verification method provided in the above method embodiments.

[0170] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the performance simulator verification method provided in the above-described method embodiments.

[0171] The sequence numbers of the embodiments in this application are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. The above descriptions are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A verification method for a performance simulator, characterized in that, The method includes: The general verification program is invoked. This general verification program, as a class file, supports the execution of object-oriented instantiation operations and supports the specification of parameters through a configuration file. It is used to obtain the verification program of the performance simulator of each subsystem in the on-chip system. When performing object-oriented instantiation on the general verification program, the parameters of the first performance simulator are injected through the configuration file to obtain the first verification program corresponding to the first performance simulator. The first performance simulator is a performance simulator in any subsystem of the system-on-a-chip. The first verification procedure is used to statistically analyze simulated event signals to obtain predicted transaction packets, wherein the simulated event signals are the event signals input by the first performance simulator during verification; and the first verification procedure is used to receive actual transaction packets output by the first performance simulator. The first verification procedure includes a comparison task; by executing the comparison task, the predicted transaction package and the actual transaction package are decomposed at the event granularity to obtain a first occurrence count of each event in the predicted transaction package and a second occurrence count of each event in the actual transaction package; by comparing the first occurrence count and the second occurrence count of each event, the verification result of the first performance simulator is obtained.

2. The method according to claim 1, characterized in that, The method further includes: When the predicted transaction packet is obtained by statistically analyzing the simulated event signal through the first verification procedure, the predicted transaction packet is received through the result comparison queue in the first verification procedure. The step of receiving the actual transaction packet output by the first performance simulator through the first verification procedure includes: If the actual transaction packet passes the verification by the protocol checking tool, the actual transaction packet output by the protocol checking tool is received through the result comparison queue in the first verification procedure. The protocol checking tool is used to check the protocol of the actual transaction packets output by the first performance simulator. The protocol checking tool is a tool mounted by the user.

3. The method according to claim 1, characterized in that, The first verification procedure includes response feedback code, and the method further includes: When the first verification program receives an actual transaction packet, it returns a response signal to the first performance simulator via the response feedback code. The response signal is used to inform the first performance simulator that the actual transaction packet has been received.

4. The method according to claim 1, characterized in that, The method further includes: Call the general interface file, which serves as a class file to support object-oriented instantiation operations, to obtain the transmission interface corresponding to the performance simulator of each subsystem in the on-chip system; Based on the type of event signal required by the first performance simulator, an object-oriented instantiation operation is performed on the general interface file to obtain the first transmission interface corresponding to the first performance simulator. The simulated event signals, the start trigger signal and the end trigger signal corresponding to each simulated event signal in the user design code are transmitted to the first verification program through the first transmission interface.

5. The method according to claim 4, characterized in that, The step of obtaining the predicted transaction packet by statistically simulating event signals through the first verification procedure includes: The first verification procedure uses statistical tasks to collect statistics on the simulated event signals and monitor the end trigger signal corresponding to each simulated event signal. In response to the end trigger signal corresponding to the last simulated event signal in the statistical period, the statistical data collected at the current moment is latched to obtain the predicted transaction packet.

6. The method according to claim 5, characterized in that, The first performance simulator has at least two sets of signal interfaces; In response to the end trigger signal corresponding to the last simulated event signal in the monitoring statistical period, the statistical data collected at the current moment is latched to obtain the predicted transaction package, including: In response to the end trigger signal corresponding to the last simulated event signal in the statistical period, the statistical data collected at the current moment is latched to obtain an intermediate transaction packet; According to the group number of the at least two groups of signal interfaces, the statistical data corresponding to the simulated event signal of each group number in the intermediate transaction packet are packaged to obtain the prediction transaction packet.

7. The method according to claim 1, characterized in that, The step of obtaining the verification result of the first performance simulator by comparing the first occurrence count and the second occurrence count of each event includes: According to the allowable error window for each event, the first occurrence count and the second occurrence count of each event are compared, wherein different events are configured with different allowable error windows; Based on the comparison results of each event, the verification results of the first performance simulator are obtained.

8. The method according to claim 7, characterized in that, Events that are difficult to be synchronously statistically analyzed in the first verification program and the first performance simulator are configured with a larger allowable error window. Events that are relatively easy to synchronize and statistically analyze in the first verification program and the performance simulator are configured with a small allowable error window.

9. The method according to claim 7, characterized in that, The verification result of the first performance simulator is obtained based on the comparison result of each event, including: Obtain the comparison result for each event; The verification results of the first performance simulator are obtained by combining the comparison results of multiple events.

10. The method according to any one of claims 1 to 9, characterized in that, The configuration file is a general configuration file; when performing object-oriented instantiation on the general verification program, the parameters of the first performance simulator are injected through the configuration file to obtain the first verification program corresponding to the first performance simulator, including: The general configuration file is invoked, and the general configuration file, as a class file, supports the execution of object-oriented instantiation operations to obtain the verification configuration of the performance simulator of each subsystem in the on-chip system; Based on the parameters of the first performance simulator input by the user, an object-oriented instantiation operation is performed on the general configuration file to obtain the first verification configuration corresponding to the first performance simulator; When performing object-oriented instantiation on the general verification program, the first verification configuration is injected to obtain the first verification program corresponding to the first performance simulator.

11. The method according to any one of claims 1 to 9, characterized in that, The method further includes: Based on the type of the first performance simulator input by the user, perform an object-oriented instantiation operation on the general verification program.

12. A verification device for a performance simulator, characterized in that, The device includes: The calling module is used to call the general verification program. The general verification program, as a class file, supports the execution of object-oriented instantiation operations and supports the specification of parameters through configuration files. It is used to obtain the verification program of the performance simulator of each subsystem in the on-chip system. The processing module is used to inject parameters of the first performance simulator through the configuration file when performing object-oriented instantiation operation on the general verification program, so as to obtain the first verification program corresponding to the first performance simulator. The first performance simulator is the performance simulator of any subsystem of the system on chip. The verification module is configured to obtain a predicted transaction packet by statistically analyzing simulated event signals through the first verification program, wherein the simulated event signals are event signals input by the first performance simulator during verification; and to receive the actual transaction packet output by the first performance simulator through the first verification program; the first verification program includes a comparison task; by executing the comparison task, the predicted transaction packet and the actual transaction packet are decomposed at the event granularity to obtain a first occurrence count of each event in the predicted transaction packet and a second occurrence count of each event in the actual transaction packet; by comparing the first occurrence count and the second occurrence count of each event, the verification result of the first performance simulator is obtained.

13. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the verification method of the performance simulator as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is loaded and executed by a processor to implement the verification method of the performance simulator as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, The computer program product stores a computer program that is loaded and executed by a processor to implement the verification method of the performance simulator as described in any one of claims 1 to 11.

Images