Test scene recovery method and related device

Abstract

The embodiment of the invention provides a test scene recovery method and a related device. The test scene recovery method comprises the following steps: acquiring a basic test case and a log file of a to-be-recovered scene; modifying the basic test case based on the log file to obtain a heavy load case; obtaining a test service of the verification platform based on the log file and the heavy load use case; the heavy-load case comprises a heavy-load main operation stage, and the service operated in the heavy-load main operation stage is the test service; acquiring configuration parameters used for running the basic test case on a verification platform, and reproducing a scene to be restored by using the configuration parameters and the heavy load case; wherein the process of reproducing the scene to be restored comprises a main operation stage of operating the business of the basic test case; the main operation phase is overloaded as the overloaded main operation phase. According to the technical scheme, the operation of the heavy load case can be completely simulated, so that the accuracy of the obtained scene to be restored is ensured, the problem of the scene to be restored is conveniently and directly positioned, and the test efficiency of a chip is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a test scenario recovery method and related devices. Background Art

[0002] During the post-silicon testing of chip samples, for problems that occur during the chip post-silicon testing, only chip data analysis can be performed based on the post-silicon testing results, but the internal state of the chip cannot be analyzed, and thus, the problems in the chip cannot be analyzed and located. Therefore, how to efficiently locate problems in chip testing has become an urgent problem to be solved by those skilled in the art. Summary of the invention

[0003] In view of this, an embodiment of the present application provides a test scenario recovery method and related devices to efficiently locate problems in chip testing.

[0004] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0005] In a first aspect, an embodiment of the present application provides a test scenario recovery method, comprising:

[0006] Obtain the log files of the basic test cases and the scenarios to be restored;

[0007] Modify the basic test case based on the log file to obtain an overloaded test case;

[0008] Acquire the test business of the verification platform based on the log file and the overloaded use case; the overloaded use case includes an overloaded main operation phase, and the business running in the overloaded main operation phase is the test business;

[0009] Obtain the configuration parameters used to run the basic test case on the verification platform, and use the configuration parameters and the overloaded test case to reproduce the scenario to be restored; wherein the process of reproducing the scenario to be restored includes the main operation phase of the business running the basic test case; the main operation phase is overloaded as the overloaded main operation phase. In a second aspect, an embodiment of the present application provides a test scenario recovery device, comprising:

[0010] A use case acquisition module is used to acquire a basic test case and a log file of a scene to be restored, and to modify the basic test case based on the log file to obtain an overloaded test case;

[0011] A configuration data proxy module is used to obtain configuration parameters used to run the basic test case on the verification platform;

[0012] A business data proxy module, used for acquiring the test business of the verification platform based on the log file and the overloaded use case;

[0013] A scene recovery module is used to reproduce the scene to be restored using the configuration parameters; wherein the process of reproducing the scene to be restored includes a main operation phase of running the business, the business run in the main operation phase is the test business; the main operation phase is executed by the business data proxy module.

[0014] In a third aspect, an embodiment of the present application further provides a computing device, including a processor and a memory, wherein the memory stores computer instructions, and the processor executes the computer instructions to implement the test scenario recovery method as described above.

[0015] In a fourth aspect, an embodiment of the present application further provides a computer program product, comprising computer instructions, which, when executed, implement the test scenario recovery method as described above.

[0016] In a fifth aspect, an embodiment of the present application further provides a storage medium, wherein the storage medium stores a design program of a chip, and when the design program is executed, the test scenario recovery method as described above is implemented.

[0017] The test scenario recovery method provided in the embodiment of the present application includes: obtaining a basic test case and a log file of the scenario to be restored; modifying the basic test case based on the log file to obtain an overloaded case; obtaining a test business of a verification platform based on the log file and the overloaded case; the overloaded case includes a function of an overloaded main operation phase, and the business run in the overloaded main operation phase is the test business; obtaining configuration parameters used to run the basic test case on the verification platform, and using the configuration parameters to reproduce the scenario to be restored; wherein, the process of reproducing the scenario to be restored includes a function of the main operation phase of the business running the basic test case; the function of the main operation phase and the function of the overloaded main operation phase are functions with the same name; and loading the overloaded case in the process of reproducing the scenario to be restored to replace the function of the main operation phase with the function of the overloaded main operation phase.

[0018] It can be seen that by obtaining the log file of the scene to be restored, and obtaining the test business of the verification platform according to the log file and the overloaded use case. Then, in the process of reproducing the scene to be restored, the main operation phase of the business running the basic test case is replaced by the overloaded main operation phase running the test business. Therefore, in the process of reproducing the scene to be restored, the data directly related to the scene to be restored can be used for restoration, thereby ensuring the high correlation between the reproduced scene to be restored and the scene to be restored. At the same time, based on the basic test case configuration parameters and the process of reproducing the scene to be restored of the overloaded use case, the accuracy of the obtained scene to be restored can be ensured by making the business running in the reproduction process the test business, which is convenient for directly locating the problems of the scene to be restored and improving the testing efficiency of the chip. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0020] Figure 1 A flowchart of a test scenario recovery method provided in an embodiment of the present application;

[0021] Figure 2 It is a schematic diagram of the structure of a SOC chip;

[0022] Figure 3 A schematic diagram of the process of verifying the chip using basic test cases;

[0023] Figure 4 A schematic diagram of a process for verifying a chip based on an overloaded use case in a test scenario recovery method provided in an embodiment of the present application;

[0024] Figure 5 Another schematic diagram of the test scenario recovery method provided in an embodiment of the present application;

[0025] Figure 6 A complete flow chart of reproducing a test scenario based on the test scenario recovery method provided in an embodiment of the present application;

[0026] Figure 7 A schematic diagram of the structure of a test scenario recovery device provided in an embodiment of the present application;

[0027] Figure 8 A schematic diagram of the structure of the configuration data proxy module provided in the embodiment of the present application;

[0028] Fig. 9 A schematic diagram of the structure of the business data proxy module provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0030] During the post-silicon testing of chip samples, it is often necessary to analyze trace logs to confirm various performance or functional failure phenomena that occur during the testing process. The trace log usually refers to a log tool used to record and analyze events during the operation of software or systems. It is a detailed record of program execution information, used for debugging and analyzing program behavior, and records function calls, variable values, execution paths and other information to make it easier to find and solve problems.

[0031] A simple trace log can only display problems that arise in the interaction between the SOC chip and the device, but cannot reflect the internal status of the SOC chip, such as the scheduling and allocation of processes within the SOC chip, the QoS (Quality of Service) of the SOC chip, the Ordering (business or operation sorting mechanism) of the SOC chip, the current congestion status in the SOC chip, and the RAS (Reliability, Availability, Serviceability) status of the SOC chip. These cannot be directly reflected through the trace log, making it difficult to help locate and analyze problems more intuitively.

[0032] A chip positioning method obtains the behavior and phenomenon of test cases during the post-silicon testing of chip samples, and then simulates and reproduces the test scenarios of the post-silicon testing in a simulation environment based on use cases similar to the test cases, thereby analyzing and locating problems in the reproduced post-test process.

[0033] However, test cases can only reflect a large test scenario, such as the problems caused by the current packet flow and packet type (packet size, type), and the location of more problems requires more details to assist in positioning. It is difficult to reproduce the same details as the trace log using existing simulation cases. This is because the simulation environment in the test usually contains many random factors, which will interfere with the accurate reproduction of the problem. During the interaction of test cases, there may be many errors that need to be repeatedly proofread, which is relatively inefficient. In addition, when simply analyzing trace log information, due to the implicit information interaction details within the RTL (Register-Transfer Level), the lack of these implicit details also poses many obstacles to the location of the problem.

[0034] To solve the above problems, the embodiment of the present application provides a test scenario recovery method, which directly generates corresponding stimulus data by parsing the trace log generated by the logic analyzer to restore the fault scene, thereby facilitating direct location of the problem in the scene to be restored and improving the test efficiency of the chip. As an optional implementation, Figure 1 A flow chart of a test scenario recovery method provided in an embodiment of the present application is shown.

[0035] like Figure 1 As shown, the test scenario recovery method provided in the embodiment of the present application includes the following steps:

[0036] Step S10: Obtain the basic test cases and log files of the scenarios to be restored.

[0037] It should be noted that, in an optional implementation, when the high-speed I / O interface of the chip is PCIE, the log file is a trace log. The high-speed I / O interface of the chip is, for example, CXL (Compute Express Link), USB (Universal Serial Bus), SATA (Serial Advanced Technology Attachment).

[0038] Step S20: Modify the basic test case based on the log file to obtain an overloaded test case.

[0039] It should be noted that the overloaded case is obtained by inheriting the log file from the basic test case. The "inheritance" is to derive a subclass from the basic test case. The derivation process uses the properties and methods of the basic class of the basic test case and expands or modifies the basic test case according to the inherited file or data to obtain a new test case. When obtaining the overloaded case, the log file needs to be used to modify the subclass derived from the basic test case.

[0040] Step S30: Obtain configuration parameters of the verification platform of the basic test case.

[0041] It should be noted that the obtaining of the configuration parameters is to obtain the configuration parameters used to run the basic test case on the verification platform. The configuration parameters are the configuration parameters used when the basic test case drives the verification platform to run.

[0042] Step S40: Acquire the test business of the verification platform based on the log file and the overload case; the overload case includes an overload main operation phase, and the business running in the overload main operation phase is the test business.

[0043] Step S50: Obtain the configuration parameters used to run the basic test case on the verification platform, and use the configuration parameters to reproduce the scene to be restored; wherein the process of reproducing the scene to be restored includes running the function of the main operation phase of the business of the basic test case. The function of the main operation phase and the function of the reloaded main operation phase have the same name.

[0044] Step S60: loading the overloaded use case in the process of reproducing the scene to be restored, so as to replace the function of the main running phase with the function of the overloaded main running phase.

[0045] In this way, the log file of the scene to be restored is obtained, and the test business of the verification platform is obtained according to the log file and the overloaded use case. Then, in the process of reproducing the scene to be restored, the main operation phase of the business running the basic test case is replaced by the overloaded main operation phase running the test business. Therefore, in the process of reproducing the scene to be restored, the data directly related to the scene to be restored can be used for restoration, thereby ensuring the high correlation between the reproduced scene to be restored and the scene to be restored. At the same time, based on the basic test case configuration parameters and the process of reproducing the scene to be restored of the overloaded use case, the accuracy of the obtained scene to be restored can be ensured by making the business running in the reproduction process the test business, which is convenient for directly locating the problems of the scene to be restored and improving the testing efficiency of the chip.

[0046] A schematic diagram of the structure of a SOC chip is shown in Figure 2 As shown in the figure, the SoC chip includes the CPU, control bus and RC (Root Complex, the main controller in the PCIe architecture) of the high-speed I / O interface; the PCIE device and the target register are located outside the SoC system. When the SoC chip is tested, the CPU sends the configuration data required for the target register to the control bus, and the PCIE device sends the service data to the SoC system through the RC.

[0047] Among them, the data that affects the behavior of the chip includes two types, namely configuration data and test business data. Among them, the configuration data includes a variety of data or parameter information used to control the operating mode, resource allocation, policy rules, etc. of the system or application, for example, data set for system parameters, data configured for the protocol stack, data set for access rights, tuning parameters for runtime, etc. These configuration data are usually modified during system initialization, reconfiguration or version upgrade. When restoring the test scenario, the configuration data needs to be configured through the CPU executing the driver software or the BIOS (Basic Input Output System) through the control bus.

[0048] The business is a specific business, such as read operation, write operation, atomic operation, message and other types of business, and the test business data is the data or signal of the above business in the test process. The test business data of the same data bus in each clock cycle will change according to the different business running in the current clock cycle, and in the real design of the chip, no new physical bus will be added for the data change of each cycle. Therefore, it is necessary to reuse the VIP (Verification IP) data bus of the pre-simulation verification environment to drive, so as to realize the modeling and abstraction of the real hardware bus. In order to maintain the behavior consistent with the real hardware, the same VIP data bus must be reused in each clock cycle to transmit different test business data. Wherein, the pre-simulation verification is the process of verifying the function and performance of the chip by simulation and modeling methods before the chip is taped out.

[0049] Furthermore, in order to realize the configuration of the scenario to be restored and the reproduction of the test stimulus in the scenario to be restored, the test scenario recovery method provided in the embodiment of the present application needs to change the test business data based on the data of the log file so that the content of the test business data conforms to the scenario to be restored.

[0050] Furthermore, during the chip testing process, all test cases are obtained based on basic test cases. The basic test cases are basic test cases for verifying the chip. Based on the basic test cases, basic functions such as clock and reset initialization, Fuse loading, and PCIE (Peripheral Component Interconnect Express) link training can be completed to establish a high-speed and stable connection. The basic test cases provide a set of standardized methods and properties for reuse and extension of inherited test cases.

[0051] Therefore, based on the information in the log file, the basic test case is modified to obtain an overloaded test case, and when the overloaded test case is used to restore the scene to be restored, it is ensured that the scene to be restored completely restores the scene where the failure occurs.

[0052] The process of verifying the chip using the above basic test cases is as follows Figure 3As shown, when the basic test case driven verification platform is running, there are multiple stages, specifically including: build_phase construction phase, used to create and initialize UVM (Universal Verification Methodology) components; connect_phase connection phase, used to connect the interface between UVM components; elaboration_phase refinement phase, used to complete the detailed configuration of the verification environment; start_of_simulate_phase simulation start phase, used to perform preparatory tasks before simulation; reset_phase reset phase, used to reset DUT (Design Under Test) and environment at the beginning of simulation; configure_phase configuration phase, used to configure DUT and environment; main_phase main simulation phase, used to perform test incentives and transactions; shutdown_phase shutdown phase, used to perform cleaning and finishing work before the end of simulation; extract_phase extraction phase, used to collect statistical information and data during simulation; report_phase reporting phase, used to generate simulation report; final_phase end phase, used to perform the final operation after the simulation is completely finished.

[0053] The configuration data is used as configuration parameters to configure the verification platform in the original configure_phase; in the original configure_phase, the verification component of the verification platform can obtain configuration parameters from the upper-level component or test. The test service data is used to give test stimuli in the original main_phase, and in the original main_phase, the verification platform runs the test service based on the test stimuli.

[0054] Furthermore, in order to enable the restored scene to restore the fault scene, the business in the main operation phase needs to be replaced with the test business, so that the test business participates in the recovery process of the scene to be restored. At this time, the main operation phase becomes main_phase based on the test business.

[0055] In addition, the resource overhead of repeatedly using the CPU to execute the driver software or the BIOS to configure through the control bus in the chip system is relatively large. Since the configuration parameters are recorded in the registers of the ASIC (Application Specific Integrated Circuit) chip, the parameters do not change all the time, so the configuration parameters can be regarded as static parameters, and then the use of an additional configuration data agent module to perform the acquisition and configuration process of the configuration parameters can greatly reduce resource overhead. That is, the step S30 and the configuration phase are both implemented by the configuration data agent module. For ease of understanding, the process of configuration using the configuration data agent module can be called configure_phase based on overloaded parameters.

[0056] At this time, the flowchart of obtaining the overloaded use case and verifying the chip based on the overloaded use case is as follows: Figure 4 As shown, after obtaining the basic test case, it is necessary to modify the basic test case based on the log file to obtain the overloaded case, and then obtain the test business of the overloaded case, at which time the main_phase based on the test business can be obtained, and the test business based on the test business has the test business data based on the overloaded case. Afterwards, during the operation of the verification platform, the original main_phase is overloaded to the main_phase based on the test business.

[0057] It should be noted that overloading is a mechanism in object-oriented programming (OOP) to improve code flexibility and readability. Through overloading, multiple functions or methods with the same name but different parameter lists (such as the number, type or order of parameters) can be defined in the same class. These functions with the same name are distinguished by their parameter signatures (the number, type and order of method parameters). When the program calls this function, the compiler will automatically select the appropriate function version to execute based on the matching degree of the passed in parameters.

[0058] That is, the original configure_phase has the same name as the configure_phase based on the overloaded parameters, and the original main_phase has the same name as the main_phase based on the test service. When the overloaded use case is used to verify the chip, the chip will choose to execute the configure_phase based on the overloaded parameters and the main_phase based on the test service.

[0059] Further, such as Figure 5As shown, in an optional implementation, the step of obtaining the configuration parameters of the verification platform of the basic test case (i.e., the step S30) includes step S31: obtaining the configuration parameters of the verification platform from the BIOS. It should be noted that the number of configuration parameters that need to be configured in a chip is very large. In order to simulate the sample test site to the greatest extent, all configuration parameters of the configuration site need to be scanned out from the BIOS.

[0060] like Figure 5 As shown, the step S30 further includes step S32: parsing the configuration parameters into a preset parameter format. It should be noted that, in order to facilitate configuration of a large number of parameters, a script is required to parse the configuration parameters into a fixed format so as to uniformly process the configuration parameters.

[0061] Furthermore, in an optional implementation, the configuration parameters include configuration data and configuration addresses; the preset parameter format includes: a corresponding format of configuration data and configuration addresses. That is, the basic unit of the preset parameter format is a pair of [address, data], and each address corresponds to a configuration data.

[0062] Furthermore, in an optional implementation, the step S40 includes a step S41: analyzing and filtering the test services included in the log file, and converting the test service data of the test services into a preset service data format.

[0063] It should be noted that the test log usually needs to be acquired by a logic analyzer of a high-speed I / O interface (such as PCIE), so the test log contains a service log issued by a high-speed I / O interface, such as a service packet of a PCIE protocol. Due to the complex content of the service log, the service log may contain data (such as link layer data) that does not require a verification environment to process, so script filtering and analysis are required so that only test service data in a service data format that can be recognized by a verification environment is retained in the test log. The service data format includes standard communication protocols, storage and memory protocols, multimedia data, security and encryption protocols, application layer protocols, and customized proprietary protocols.

[0064] like Figure 5As shown, the step S40 also includes a step S42: parsing the test service data to obtain the service information of each test service during the test process. It should be noted that the "parsing" is stimulus parsing, that is, analyzing, decoding and processing the input stimulus signal or data to convert complex or low-level stimulus data into a high-level transaction or service data format. Specifically, the main content of the parsing is basic service information, including: TLP (Transaction Layer Packet, transaction layer data packet) type, data length, data address, and PCIE protocol layer data.

[0065] At this time, in an optional implementation, parsing the test service data to obtain the service information of each test service during the test process includes: performing stimulus parsing on the test service data to obtain the service type, service data address, service data length, and protocol layer data of the service data.

[0066] Furthermore, it is also necessary to analyze the interval delay information between two service data to provide the chip with the option of whether to drive the bus at the same time interval. In an optional implementation, step S42 further includes analyzing the interval delay information between different test services.

[0067] like Figure 5 As shown, the step S40 further includes a step S43: encapsulating the service information of each test service into a service package in a preset format and storing the package in a service queue.

[0068] It should be noted that, in order to facilitate the control bus to process the business information, each independent business needs to be mapped into a package format that can be recognized by the control bus to instantiate the business information. In an optional implementation, the package format includes a memory transaction (Memory Transactions) package, an I / O transaction (I / O Transactions) package, a configuration transaction (Configuration Transactions) package, a message transaction (Message Transactions) package, and an atomic operation transaction (Atomic Operations) package. After obtaining the business package, it is necessary to store the instantiated business package in a first-in-first-out queue according to the order in the Trace log to wait for the subsequent use of the business package.

[0069] Furthermore, in order to accurately restore the scene to be restored, the configure_phase based on the overloaded parameters and the main_phase based on the test business are the same as the original main_phase and the original configure_phase in terms of running process, and only differ in the data used.

[0070] Specifically, Figure 5 As shown, in an optional implementation, the process in the configure_phase based on the overloaded parameters includes step S33: the configuration parameters in the preset parameter format are configured and sent through the control bus, and sent to the target register of the scene to be restored. It should be noted that the control bus is a control bus VIP (Verification IP), which is a software and hardware module specially developed for verifying the control bus function in a chip or system, and is mainly used to simulate the behavior and characteristics of the control bus protocol in a simulation environment. It usually includes the sending, receiving, monitoring and checking functions of the interface protocol, and follows the corresponding communication rules and data formats. The parameters for all target registers can be directly configured through the control bus VIP.

[0071] Furthermore, in an optional implementation, the step S33 may include: the configuration parameters are sent from the front door through the control bus or the configuration parameters are sent from the back door through the control bus. The front door sends to access the target register through the designed formal interface (such as bus protocol), such as AXI (Advanced eXtensible Interface), APB (Advanced Peripheral Bus), I2C (Inter-Integrated Circuit), etc., and configures parameters for the target register. The back door sends to directly access the target register, bypassing the bus interface, and directly configures parameters for the target register through the function of the simulation device.

[0072] Specifically, in an optional implementation, the backdoor delivery includes delivering the backdoor configuration through the register model of RAL (Register Abstraction Layer). At this time, it is necessary to use RAL to create a model corresponding to the target register, and the created content includes the address, width, access type and other information of the target register. Afterwards, in the target register model, a signal path is specified for each target register, and the signal path is usually a hierarchical hardware description language (HDL) path. During the backdoor delivery, when performing a backdoor write operation, it is necessary to use RAL's API (Application Programming Interface) to directly write the value to the register inside the design through the backdoor path. When performing a backdoor read operation, the current value of the target register is directly read from the inside of the target register and updated to the target register model.

[0073] like Figure 5As shown, in an optional implementation, the process of the main_phase based on the test service includes step S44: obtaining the service package in the service queue and running the test service corresponding to the service package. At this time, the test service is stored in the queue in the form of service packages. When the test service is needed, the service packages are taken out of the queue one by one and driven to the interface of the control bus, which can be used for the subsequent running of the test service corresponding to the service package.

[0074] Furthermore, in the process of driving to the control bus, it can be selected whether to simulate the interval delay information of the packet. In an optional implementation, after the step S44, the interval delay information between different test services is also output to the verification platform.

[0075] Combining the above recovery steps of the scene to be restored and the process of reproducing the scene to be restored based on the basic test case, the complete recovery process of the scene to be restored is as follows: Figure 6 As shown. When starting to restore the scene to be restored, first execute step S11: obtain basic test cases. After obtaining the basic test cases, based on the basic test cases, execute step S61: reset the chip clock. After successfully resetting the chip clock, the scene to be restored that needs to be reproduced needs to use the overloaded test case, that is, continue to execute the above steps S31 in sequence: obtain the configuration parameters of the verification platform from the BIOS and step S32: parse the configuration parameters into a preset parameter format. In addition, after step S31, it is also necessary to execute step S311: detect whether the configuration parameters are obtained to ensure that the configuration parameters are obtained normally. If the configuration parameters are obtained, continue to execute step S32. If the configuration parameters are not obtained, execute step S650: fail to open the file and report an error.

[0076] Afterwards, execute step S62 to check whether the front door is configured. If the front door is configured, execute step S621: call the control bus interface front door configuration. If the front door is not configured, execute step S622: call the RAL model back door configuration. After configuration, it is also necessary to execute step S63: check whether the configuration is complete. If the configuration is not completed, execute step S631: configuration fails and an error is reported. If the configuration is complete, continue to execute step S12: obtain the log file of the scene to be restored. Afterwards, in order to ensure that the log file is obtained, it is also necessary to execute step S121: detect whether the log file is obtained. If the log file is not obtained, execute step S651: file opening fails and an error is reported. If the log file is obtained, continue to execute. After reading the log file, it is necessary to obtain the service package required for overloading based on the log file. Therefore, after the step S121, it is also necessary to execute the above steps S41 to S44 in sequence to complete the operation of the test service. After the test service is run, step S64 can be executed: the simulation ends.

[0077] The embodiment of the present application also provides a test scenario recovery device, which directly generates corresponding stimulus data by parsing the tracelog generated by the logic analyzer to restore the fault scene, thereby facilitating direct location of the problem of the scene to be restored and improving the test efficiency of the chip. As an optional implementation, Figure 7 The structure diagram of the test scene recovery device provided by the embodiment of the present application is shown. Figure 7 As shown, the test scenario recovery device provided in the embodiment of the present application includes the following structure.

[0078] The use case acquisition module 100 is used to acquire the basic test case and the log file of the scene to be restored, and modify the basic test case based on the log file to obtain the overloaded test case. In an optional implementation, the use case acquisition module 100 is set in the RC of the high-speed I / O interface, or in the CPU of the chip.

[0079] The configuration data proxy module 200 is used to obtain configuration parameters used to run the basic test case on the verification platform. The configuration data proxy module 200 is connected to the control bus 110.

[0080] The business data proxy module 300 is used to obtain the test business of the verification platform based on the log file and the overloaded use case.

[0081] The scene recovery module 400 is used to reproduce the scene to be restored using the configuration parameters; wherein the process of reproducing the scene to be restored includes a main operation phase of running a business, wherein the business run in the main operation phase is the test business; and the main operation phase is executed by the business data proxy module. It should be noted that the scene recovery module 400 is set in the CPU.

[0082] The target register 500 is used to store the configuration parameters.

[0083] In this way, the log file of the scene to be restored is obtained, and the test business of the verification platform is obtained according to the log file and the overloaded use case. Then, in the process of reproducing the scene to be restored, the main operation phase of the business running the basic test case is replaced by the overloaded main operation phase running the test business. Therefore, in the process of reproducing the scene to be restored, the data directly related to the scene to be restored can be used for restoration, thereby ensuring the high correlation between the reproduced scene to be restored and the scene to be restored. At the same time, based on the basic test case configuration parameters and the process of reproducing the scene to be restored of the overloaded use case, the accuracy of the obtained scene to be restored can be ensured by making the business running in the reproduction process the test business, which is convenient for directly locating the problems of the scene to be restored and improving the testing efficiency of the chip.

[0084] Further, such as Figure 8 As shown, in an optional implementation, the configuration data proxy module 200 includes: a configuration parsing module 210, which is used to obtain the configuration parameters of the verification platform from the BIOS; and parse the configuration parameters into a preset parameter format.

[0085] Further, it can be known from the above content that in the process of reproducing the scene to be restored, the configuration phase is overloaded by the configuration proxy data module 200 to be a configure_phase based on overloaded parameters. The configuration data proxy module 200 also includes a configuration delivery module 220 for executing the configure_phase based on overloaded parameters.

[0086] Specifically, Figure 8 As shown, in an optional implementation, the configuration data proxy module 200 further includes: a configuration sending module 220, which is used to send the configuration parameters in parameter format through a control bus to a target register of the scene to be restored.

[0087] Further, such as Fig. 9 As shown, in an optional implementation, the business data proxy module 300 includes:

[0088] The service preprocessing module 310 is used to analyze and filter the test services included in the log file, and convert the test service data of the test service into a preset service data format. It should be noted that the service preprocessing module 310 is implemented based on PERL, or scripting languages ​​such as python or tcl, and mainly parses the log file to complete data preprocessing.

[0089] The service parsing module 320 is used to parse the test service data to obtain the service information of each test service during the test process.

[0090] The service conversion module 330 is used to encapsulate the service information of each test service into a service package in a preset format and store it in a service queue.

[0091] Furthermore, in an optional implementation, the service preprocessing module 310 is used to perform stimulus parsing on the test service data to obtain the service type, service data address, service data length, and protocol layer data of the test service data.

[0092] Further, it can be seen from the above content that in the process of reproducing the scene to be restored, the main operation phase is overloaded by the business data proxy module 300 as the main_phase based on the test business. The business data proxy module 300 also includes a business driver module 340 for executing the main_phase based on the test business. Fig. 9 As shown, in an optional implementation, the business data proxy module 300 further includes: a business driver module 340, which is used to obtain the business package in the business queue and run the test business corresponding to the business package.

[0093] Furthermore, in an optional implementation, the service preprocessing module 310 is further used to parse the interval delay information between different test services. The service driving module 340 is further used to output the interval delay information between different test services to the verification platform.

[0094] An embodiment of the present application also provides a computing device including a processor and a memory, wherein the memory stores computer instructions, and the processor executes the computer instructions to implement the test scenario recovery method as described above.

[0095] An embodiment of the present application also provides a computer program product, including computer instructions, which implement the test scenario recovery method as described above when executed.

[0096] An embodiment of the present application further provides a storage medium, wherein the storage medium stores a design program of a chip, and when the design program is executed, the test scenario recovery method as described above is implemented.

[0097] Although the embodiments of the present application are disclosed above, the present application is not limited thereto. Any person skilled in the art may make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be subject to the scope defined by the claims.

Claims

1. A test scenario recovery method, characterized in that: include: Obtain the log files of the basic test cases and the scenarios to be restored; Modify the basic test case based on the log file to obtain an overloaded test case; Acquire the test business of the verification platform based on the log file and the overloaded use case; the overloaded use case includes a function of the overloaded main running phase, and the business run in the overloaded main running phase is the test business; Obtain the configuration parameters used to run the basic test case on the verification platform, and use the configuration parameters to reproduce the scene to be restored; wherein the process of reproducing the scene to be restored includes running the function of the main operation phase of the business of the basic test case; the function of the main operation phase and the function of the overloaded main operation phase have the same name; The overloaded use case is loaded during the process of reproducing the scene to be restored, so as to replace the function of the main running phase with the function of the overloaded main running phase.

2. The test scenario recovery method according to claim 1, characterized in that: The step of obtaining the configuration parameters used to run the basic test case on the verification platform includes: Obtaining configuration parameters of the verification platform from the BIOS; The configuration parameters are parsed into a preset parameter format.

3. The test scenario recovery method according to claim 2, characterized in that: The process of reproducing the scene to be restored also includes a configuration stage, which includes: configuring and sending the configuration parameters through a control bus to a target register of the scene to be restored.

4. The test scenario recovery method according to claim 3, characterized in that: The configuration parameters include configuration data and configuration addresses; the preset parameter formats include: corresponding formats of configuration data and configuration addresses.

5. The test scenario recovery method according to claim 1, characterized in that: The main operation phase includes: obtaining the business of the basic test case, sending the business of the basic test case to the target register and running the business of the basic test case; The reload main operation phase includes: acquiring the test service, sending the test service to the target register and running the test service.

6. The test scenario recovery method according to claim 5, characterized in that: The step of acquiring the test business of the verification platform based on the log file and the overloaded use case includes: Analyze and filter the test services included in the log file, and convert the test service data of the test services into a preset service data format; Parsing the test service data to obtain service information of each test service during the test process; The service information of each test service is encapsulated into a service package in a preset format and stored in a service queue.

7. The test scenario recovery method according to claim 6, characterized in that: The step of parsing the test service data to obtain service information of each test service during the test process includes: The test service data is stimulated and parsed to obtain the service type, service data address, service data length, and protocol layer data of the test service data.

8. The test scenario recovery method according to claim 6, characterized in that: The main operation phase includes: acquiring a service packet in the service queue, sending the service packet to the target register, and running a test service corresponding to the service packet.

9. The test scenario recovery method according to claim 8, characterized in that: After the step of parsing the test service data to obtain service information of each test service during the test process, the method further includes: parsing the interval delay information between different test services; After the step of sequentially outputting the service packets in the service queue to the verification platform, the method further includes: The interval delay information between different test services is output to the verification platform.

10. A test scene recovery device, characterized in that: include: A use case acquisition module is used to acquire a basic test case and a log file of a scene to be restored, and to modify the basic test case based on the log file to obtain an overloaded test case; A configuration data proxy module is used to obtain configuration parameters used to run the basic test case on the verification platform; A business data proxy module, used for acquiring the test business of the verification platform based on the log file and the overloaded use case; A scene recovery module, used to reproduce the scene to be restored using the configuration parameters; wherein the process of reproducing the scene to be restored includes a main operation phase of running the service, and the service run in the main operation phase is the test service; The main operation phase is executed by the business data proxy module.

11. The test scenario recovery device according to claim 10, characterized in that: The configuration data proxy module includes: The configuration parsing module is used to obtain the configuration parameters of the verification platform from the BIOS; and parse the configuration parameters into a preset parameter format.

12. The test scenario recovery device according to claim 11, characterized in that: The configuration data proxy module also includes: A configuration sending module, used to send the configuration parameters in parameter format through a control bus to a target register of a scene to be restored; The process of reproducing the scene to be restored includes a configuration phase, and the configuration phase is executed by the configuration sending module.

13. The test scenario recovery device according to claim 10, characterized in that: The business data proxy module includes: A service preprocessing module, used for analyzing and filtering the test services included in the log file, and converting the test service data of the test services into a preset service data format; A service parsing module, used for parsing the test service data to obtain service information of each test service during the test process; The service conversion module is used to encapsulate the service information of each test service into a service package in a preset format and store it in a service queue.

14. The test scenario recovery device according to claim 13, characterized in that: The service preprocessing module is used to perform stimulus analysis on the test service data to obtain the service type, service data address, service data length, and protocol layer data of the test service data.

15. The test scenario recovery device according to claim 14, characterized in that: The business data proxy module also includes: a business driving module, which is used to output the business packages in the business queue to the verification platform in sequence and run the test business corresponding to the business package.

16. The test scenario recovery device according to claim 15, characterized in that: The service preprocessing module is further used to parse the interval delay information between different test services; The service driving module is also used to output the interval delay information between different test services to the verification platform.

17. A computing device, characterized in that It comprises a processor and a memory, the memory stores computer instructions, and the processor executes the computer instructions to implement the test scenario recovery method as described in any one of claims 1-9.

18. A computer program product, characterized in that It comprises computer instructions, which, when executed, implement the test scenario recovery method as described in any one of claims 1 to 9.

19. A storage medium, characterized in that: The storage medium stores a design program of the chip, and when the design program is executed, it implements the test scenario recovery method as described in any one of claims 1-9.

Images