Software testing method and device, equipment, storage medium and program product

Abstract

The invention discloses a software testing method and device, equipment, a storage medium and a program product, and relates to the technical field of chips. The method comprises the steps that first chip parameters and second chip parameters are obtained, the first chip parameters are parameters of a developed first chip, the second chip parameters are parameters of a to-be-developed second chip, and the chip parameters are used for indicating hardware resources provided when the chips run driving software; based on a deployment position of a second chip parameter in a first hardware layer of the first driving software, the first chip parameter is deployed to the first hardware layer to obtain a second hardware layer, the first hardware layer is used for controlling a second chip to realize the first driving software, and the second hardware layer is used for controlling the first chip to realize the first driving software; and running and testing the first driving software in the first chip based on the second hardware layer to obtain a test result used for indicating the running condition of the first driving software in the first chip, and providing a reference for running of the first driving software in the second chip.

Description

Technical Field

[0001] The present application relates to the field of chip technology, and in particular to a software testing method, apparatus, device, storage medium, and program product. Background Art

[0002] For a chip, shortening the entire project cycle is crucial to its success. After hardware description language development is complete, rapid verification is required. However, after software development is complete, during the hardware and software integration verification phase, many software design and logic issues are often discovered, resulting in unmanageable verification timelines.

[0003] In the related art, in order to reduce the test adjustment process for the driver software during the software and hardware joint debugging and verification, the stub unit testing method is usually adopted. According to the test case, a stub function or stub module is written for the function or module to be tested to simulate the actual operating environment of the function or module to be tested, ensuring that the function or module to be tested can be called normally during the test process. When a function or module has not been fully implemented, a stub function or stub module can be used as a placeholder to ensure that the testing of other completed parts is not affected. The software can be tested during the parallel development of software and hardware, reducing the testing and repair costs in the software and hardware joint debugging and verification stage.

[0004] However, since some system functions and interfaces are difficult to stub, stub testing cannot fully simulate and cover actual scenarios, and the overall test coverage is low, resulting in low software testing efficiency. Summary of the Invention

[0005] The embodiments of the present application provide a software testing method, apparatus, device, storage medium, and program product that can improve software testing efficiency. The technical solution is as follows.

[0006] In one aspect, a software testing method is provided, the method comprising:

[0007] Obtaining first chip parameters and second chip parameters, where the first chip parameters are parameters of the first chip that has been developed, and the second chip parameters are parameters of a second chip to be developed, the second chip being used to implement a driving function of the first driver software after development is completed, the first chip parameters being used to indicate first hardware resources provided when the first chip runs the driver software, and the second chip parameters being used to indicate second hardware resources provided when the second chip runs the driver software;

[0008] Deploying the first chip parameters to the first hardware layer based on the deployment location of the second chip parameters in the first hardware layer of the first driver software to obtain a second hardware layer, wherein the first hardware layer is used to control the second chip to implement the first driver software based on the second chip parameters, and the second hardware layer is used to control the first chip to implement the first driver software based on the first chip parameters;

[0009] Based on the second hardware layer, the first driver software is run and tested in the first chip to obtain a test result, which is used to indicate the running status of the first driver software in the first chip, and the running status is used to provide a reference for the running of the first driver software in the second chip.

[0010] In another aspect, a software testing device is provided, comprising:

[0011] an acquisition module, configured to acquire first chip parameters and second chip parameters, wherein the first chip parameters are parameters of a first chip that has been developed, and the second chip parameters are parameters of a second chip to be developed, wherein the second chip is configured to implement a driving function of the first driver software after development is completed, the first chip parameters are configured to indicate first hardware resources provided when the first chip runs the driver software, and the second chip parameters are configured to indicate second hardware resources provided when the second chip runs the driver software;

[0012] a processing module configured to deploy the first chip parameters into the first hardware layer based on the deployment location of the second chip parameters in the first hardware layer of the first driver software, thereby obtaining a second hardware layer, wherein the first hardware layer is configured to control the second chip to implement the first driver software based on the second chip parameters, and the second hardware layer is configured to control the first chip to implement the first driver software based on the first chip parameters;

[0013] A testing module is used to run and test the first driver software in the first chip based on the second hardware layer to obtain a test result, wherein the test result is used to indicate the running status of the first driver software in the first chip, and the running status is used to provide a reference for the running of the first driver software in the second chip.

[0014] On the other hand, a computer device is provided, which includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the software testing method as described in any of the above-mentioned embodiments of the present application.

[0015] On the other hand, a computer-readable storage medium is provided, in which at least one instruction, at least one program, a code set or an instruction set is stored. 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 a software testing method as described in any of the above embodiments of the present application.

[0016] In another aspect, a computer program product or computer program is provided, the computer program product or computer program including 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 software testing method described in any of the above embodiments.

[0017] The beneficial effects of the technical solutions provided in the embodiments of the present application include at least:

[0018] By deploying the first chip parameters to the first hardware layer based on the deployment location of the second chip parameters in the first hardware layer of the first driver software, the first driver software is adjusted from controlling the second chip to implement the first driver software based on the first hardware layer according to the second chip parameters to controlling the developed first chip to implement the first driver software based on the second hardware layer according to the first chip parameters. This allows the first driver software to be run and tested in the first chip based on the second hardware layer during the development of the second chip, so that the operating conditions indicated by the obtained test results provide a reference for the operation of the first driver software in the second chip. That is, the first chip can be used instead of the second chip. By adjusting the chip deployment of the hardware layer in the driver software, the operating conditions of the first driver software on the first chip are used to simulate the operating conditions of the first driver software on the second chip. This allows the first chip to be used to test the first driver software during the development of the second chip and the development of the first driver software simultaneously. This reduces design issues of the first driver software in the hardware and software joint debugging and verification after the development of the second chip and the first driver software is completed. At the same time, the simulation coverage of actual operating scenarios during the software testing process is improved, thereby improving the testing efficiency of the first driver software. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 This is a schematic diagram of the software and hardware development and testing process provided by an exemplary embodiment of the present application;

[0021] Figure 2 This is a schematic diagram of an implementation environment provided by an exemplary embodiment of the present application;

[0022] Figure 3 is a flowchart of a software testing method provided by an exemplary embodiment of the present application;

[0023] Figure 4 This is a schematic diagram of a driver software framework provided by an exemplary embodiment of the present application;

[0024] Figure 5 is a flowchart of a hardware layer adaptation and adjustment method provided by an exemplary embodiment of the present application;

[0025] Figure 6 This is a schematic diagram of driver loading provided by an exemplary embodiment of the present application;

[0026] Figure 7 is a flowchart of a hardware layer adaptation and adjustment method based on register parameters provided by an exemplary embodiment of the present application;

[0027] Figure 8 This is a flowchart of a hardware layer adaptation adjustment method based on memory parameters provided by an exemplary embodiment of the present application;

[0028] Figure 9 is a flowchart of a hardware layer adaptation and adjustment method based on interrupt parameters provided by an exemplary embodiment of the present application;

[0029] Figure 10 This is a schematic diagram of interrupt registration adaptation provided by an exemplary embodiment of the present application;

[0030] Figure 11 This is a schematic diagram of a ring buffer structure provided by an exemplary embodiment of the present application;

[0031] Figure 12 is a flow chart of a test result display method provided by an exemplary embodiment of the present application;

[0032] Figure 13 This is a schematic diagram of presenting an automated test report provided by an exemplary embodiment of the present application;

[0033] Figure 14 is a structural block diagram of a software testing device provided by an exemplary embodiment of the present application;

[0034] Figure 15 is a structural block diagram of a software testing device module provided by an exemplary embodiment of the present application;

[0035] Figure 16 It is a structural block diagram of a terminal provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0036] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0037] It should be understood that although the terms first, second, etc. may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, a first parameter may also be referred to as a second parameter, and similarly, a second parameter may also be referred to as a first parameter without departing from the scope of this disclosure. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0038] For a chip, how to shorten the cycle of the entire project is crucial to the success of the project. After the hardware description language is developed, it needs to be verified quickly. However, often after the software development is completed, during the stage of software and hardware joint debugging and verification, many software design and logical problems will be found, resulting in uncontrollable time for the entire verification stage. In related technologies, in order to reduce the test adjustment process for the driver software during the software and hardware joint debugging and verification, the stub unit testing method is usually adopted. According to the test case, a stub function or stub module is written for the function or module to be tested to simulate the actual operating environment of the function or module to be tested, ensuring that the function or module to be tested can be called normally during the test process. When a function or module has not been fully implemented, a stub function or stub module can be used as a placeholder to ensure that the test of other completed parts is not affected. The software can be tested during the parallel development of software and hardware, reducing the testing and repair costs of the software and hardware joint debugging and verification stage. For illustration, please refer to Figure 1 , Figure 1 This is a schematic diagram of the software and hardware development test process provided by an exemplary embodiment of the present application. Figure 1As shown, hardware and software development proceed in parallel. During hardware development, the following steps are performed sequentially: 111: requirements analysis; 112: architecture design; 113: register-transfer level (RTL) development; 114: 85% netlist delivery; 115: 95% netlist delivery; 116: 100% netlist delivery; and 117: silicon rollout. During software development, the following steps are performed sequentially: 121: software requirements analysis; 122: architecture design; 123: software development; 124: stub unit testing; and 125: hardware and software joint debugging and verification. However, because some system functions and interfaces are difficult to stub, stub testing struggles to fully simulate and cover real-world scenarios, resulting in low overall test coverage and inefficient software testing. Furthermore, test code must be inserted into software modules, invasively modifying the driver software, making the code less readable. Furthermore, stub testing is labor-intensive, complex, and unsystematic, consuming significant resources.

[0039] The software testing method provided in the embodiments of the present application deploys the first chip parameters to the first hardware layer based on the deployment location of the second chip parameters in the first hardware layer of the first driver software, so that the first driver software is adjusted from controlling the second chip to implement the first driver software based on the first hardware layer according to the second chip parameters to controlling the developed first chip to implement the first driver software based on the second hardware layer according to the first chip parameters. This allows the first driver software to be run and tested in the first chip based on the second hardware layer during the development of the second chip, so that the operating conditions indicated by the obtained test results provide a reference for the operation of the first driver software in the second chip. That is, the first chip can be used instead of the second chip. By adjusting the chip deployment of the hardware layer in the driver software, the operating conditions of the first driver software on the first chip are simulated to the operating conditions of the first driver software on the second chip. This allows the first chip to be used to test the first driver software during the development of the second chip and the development of the first driver software simultaneously. This reduces design issues of the first driver software in the hardware and software joint debugging and verification after the development of the second chip and the first driver software are completed. At the same time, the simulation coverage of actual operating scenarios during the software testing process is improved, thereby improving the testing efficiency of the first driver software.

[0040] First, let's introduce the implementation environment of this application. Figure 2 , which shows a schematic diagram of an implementation environment provided by an exemplary embodiment of the present application, and the implementation environment includes: a terminal 210.

[0041] Terminal 210 is a test terminal used to perform software testing on the first driver software. Terminal 210 contains the first driver software and a first chip. The first chip is a developed chip used to test the first driver software. The first driver software corresponds to the second chip to be developed. The second chip is used to implement the driver function of the first driver software after development.

[0042] The first driver software includes a software layer logic and a hardware layer. The software layer logic is used to implement the first driver software's driving functions, and the hardware layer is used to control the chip to implement the first driver software. Based on the requirement analysis that the second chip must implement the driving functions of the first driver software after development, the first driver software is designed with a first hardware layer. This first hardware layer is used to control the second chip based on the second chip parameters to implement the first driver software.

[0043] In some embodiments, the terminal 210 stores first chip parameters and second chip parameters, wherein the first chip parameters are chip parameters of the first chip that has been developed, and the second chip parameters are chip parameters of the second chip to be developed, and the chip parameters are used to indicate the hardware resources provided when the chip runs the driver software. The terminal 210 obtains the first chip parameters and the second chip parameters, and based on the deployment location of the second chip parameters in the first hardware layer of the first driver software, deploys the first chip parameters to the first hardware layer to obtain the second hardware layer, the first hardware layer is used to control the second chip to implement the first driver software based on the second chip parameters, the second hardware layer is used to control the first chip to implement the first driver software based on the first chip parameters, and the first driver software is run and tested in the first chip based on the second hardware layer to obtain a test result, which is used to indicate the running status of the first driver software in the first chip, and the running status is used to provide a reference for the running of the first driver software in the second chip.

[0044] The above-mentioned terminal is optional. The terminal can be a desktop computer, a laptop computer, a mobile phone, a tablet computer, an e-book reader, a Moving Picture Experts Group Audio Layer III (MP3) player, a Moving Picture Experts Group Audio Layer IV (MP4) player, a smart TV, a smart car, and other terminal devices in various forms. The embodiments of the present application are not limited to this.

[0045] It is worth noting that the above-mentioned servers can be independent physical servers, or they can be server clusters or distributed systems composed of multiple physical servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud security, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), as well as big data and artificial intelligence platforms.

[0046] Among them, cloud technology refers to a hosting technology that unifies hardware, software, network and other resources within a wide area network or local area network to achieve data calculation, storage, processing and sharing.

[0047] In some embodiments, the above-mentioned server can also be implemented as a node in a blockchain system.

[0048] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, storage, display, etc.), and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant region. For example, the chip parameters involved in this application were obtained with full authorization.

[0049] To further explain, this application can display a prompt interface, pop-up window or output voice prompt information before collecting relevant user data (for example, chip parameters involved in this application, etc.) and during the process of collecting relevant user data. The prompt interface, pop-up window or voice prompt information is used to remind the user that its relevant data is currently being collected, so that this application only starts to execute the relevant steps of obtaining user-related data after obtaining the user's confirmation operation on the prompt interface or pop-up window. Otherwise (that is, when the user's confirmation operation on the prompt interface or pop-up window is not obtained), the relevant steps of obtaining user-related data are terminated, that is, the user's relevant data is not obtained. In other words, all user data collected by this application are collected with the user's consent and authorization, and the collection, use and processing of relevant user data need to comply with the relevant laws, regulations and standards of the relevant region.

[0050] For illustration, please refer to Figure 3 , which shows a flowchart of a software testing method provided by an exemplary embodiment of the present application. The method can be executed by a terminal, or by a server, or by both a terminal and a server. The embodiment of the present application takes the method executed by a terminal as an example for explanation. Figure 3 As shown, the method includes the following steps:

[0051] Step 310: Obtain first chip parameters and second chip parameters.

[0052] Among them, the first chip parameters are the parameters of the first chip that has been developed, and the second chip parameters are the parameters of the second chip to be developed. The second chip is used to implement the driving function of the first driver software after development is completed. The first chip parameters are used to indicate the first hardware resources provided when the first chip runs the driver software, and the second chip parameters are used to indicate the second hardware resources provided when the second chip runs the driver software.

[0053] Optionally, the first chip and the second chip can be any type of chip, such as an artificial intelligence (AI) chip, a codec chip, a processor chip, a memory chip, a communication chip, an input / output chip, an analog / digital conversion chip, a display chip, a sensor chip, etc., wherein the first chip and the second chip can be chips of the same type or different types, and this application does not limit this. The embodiment of the present application is described by taking the chip implemented as Peripheral Component Interconnect Express (PCIe) hardware as an example.

[0054] The chip parameters of the aforementioned chip are used to indicate the hardware resources provided by the chip when running the driver software. The chip is the core component of the computer system, primarily responsible for computing and storage tasks. The chip may include components such as a processor and memory, and is used by the driver software to control the program of the hardware device. Optionally, the hardware resources provided by the chip to the driver software include at least one of the following: interrupts, register access, and device memory. Correspondingly, the aforementioned chip parameters include at least one of interrupt parameters, register parameters, and memory parameters. Among them, the interrupt parameters are used to indicate the interrupt mechanism provided by the chip to the driver software, the register parameters are used to indicate the register storage address used in the chip, and the memory parameters are used to indicate the device memory allocation provided by the chip to the driver software.

[0055] The first chip parameters include at least one of a first interrupt parameter, a first register parameter, and a first memory parameter corresponding to the first chip, and the second chip parameters include at least one of a second interrupt parameter, a second register parameter, and a second memory parameter corresponding to the second chip.

[0056] The above-mentioned first chip and second chip are different chips, and the parameters of the first chip are different from those of the second chip. The first chip is an existing chip that has been developed and can be put into use directly; the second chip is a target chip to be developed, which is used to realize the driving function of the first driver software after the development is completed. That is, the first driver software and the second chip are developed in conjunction with each other and have not yet been completed. The first chip is an existing chip developed in conjunction with other driver software. In order to improve the testing efficiency of the first driver software and the second chip after development in the software and hardware joint debugging and verification, it is necessary to perform software testing on the first driver software in combination with the chip during the development process of the first driver software. Since the second chip has not yet been completed, it is usually necessary to use a simulation environment to simulate the second chip in combination with the first driver software for software testing. However, since using a simulation environment to simulate the second chip consumes a lot of computing resources, the testing efficiency is low. Therefore, the existing first chip is introduced to replace the second chip in combination with the first driver software for software testing. Since the first chip and the second chip are different chips, the first chip cannot be directly combined with the first driver software for software testing. Therefore, it is necessary to adapt and adjust the first chip and the first driver software based on the parameters of the first chip.

[0057] In some embodiments, in order to enable the first driver software to adapt to different hardware (chips) through simple adjustments, the software architecture of the first driver software is divided into layers. The first driver software includes a user mode driver (UMD) and a kernel mode driver (KMD). The UMD is a driver running in the user space of the operating system, which is used to process requests from the operating system and applications and does not directly communicate with hardware devices. The KMD is a driver running in the kernel space of the operating system and is used to directly access and manage hardware resources. Chip parameter deployment and adjustment can be performed for the KMD, which can reduce invasive modifications to the first driver software and enable the first driver software to adapt to different hardware. In order to further reduce the impact of invasive modifications on the driving function of the first driver software, the KMD part is further divided into a logic layer and a hardware layer. The logic layer is a hardware-independent layer that does not actually control the hardware and controls the hardware by calling the hardware layer application programming interface (API). Therefore, it is only necessary to adjust the chip parameters for the logic layer to adapt to different chips.

[0058] For illustration, please refer to Figure 4 , Figure 4 This is a schematic diagram of a driver software framework provided by an exemplary embodiment of the present application. Figure 4As shown, the first driver software 410 includes a user mode driver 411 and a kernel mode driver 412. The kernel mode driver 412 includes a logic layer 401 and a hardware layer 402. The first driver software 410 is adapted to the first chip 421 and / or the second chip 422 by adjusting the hardware layer 402. Taking the example of changing the first driver software 410 from adapting to the second chip 422 to adapting to the first chip 421 by adjusting the hardware layer 402, the first driver software 410 can be tested based on the first chip 421 to obtain test results. The test results may include the running status of the first driver software 410 on the first chip 421, such as the running time.

[0059] Based on the completed first chip, the first chip parameters can be obtained from the first chip's corresponding data sheet, reference manual, application note, design guide, technical specification, user manual, and technical support documents that record the chip parameters. Since the second chip has not yet been completed, the second chip parameters can be obtained from the second chip's corresponding firmware support document. The FS document of the second chip is a document designed based on the development requirements of the second chip. The FS document is a document that details the interface specifications between the second chip and the firmware, including key information such as the second chip's register map, instruction set, interrupts, bus interface, device memory, etc.

[0060] Step 320: Based on the deployment location of the second chip parameters in the first hardware layer of the first driver software, deploy the first chip parameters into the first hardware layer to obtain a second hardware layer.

[0061] The first hardware layer is used to control the second chip to implement the first driver software based on the second chip parameters, and the second hardware layer is used to control the first chip to implement the first driver software based on the first chip parameters.

[0062] In some embodiments, the first driver software is a driver software developed based on the second chip. The first driver software includes a UMD part and a KMD part. The KMD part includes a logic layer and a first hardware layer. The first hardware layer is designed based on the development requirements of the second chip. The second chip parameters are deployed in the first hardware layer. The first hardware layer is used to control the developed second chip based on the second chip parameters to implement the first driver software.

[0063] By deploying the first chip parameters into the first hardware layer, the first hardware layer is adjusted to the second hardware layer, so that the first driver software can control the first chip based on the first chip parameters through the second hardware layer to implement the first driver software.

[0064] Optionally, the second chip parameters can be adjusted to the first chip parameters based on the deployment position of the second chip parameters in the first hardware layer of the first driver software, or the first chip parameters can be additionally added based on the deployment position of the second chip parameters in the first hardware layer of the first driver software. That is, the second hardware layer can include only the first chip parameters, or can include both the first chip parameters and the second chip parameters.

[0065] If the second hardware layer only includes the first chip parameters, then during the development of the second chip, the first chip is controlled by the second hardware layer to test the first driver software. After the development of the second chip is completed, the second hardware layer is restored to the first hardware layer, and the first hardware layer controls the second chip to implement the first driver software. If the second hardware layer includes both the first chip parameters and the second chip parameters, then during the development of the second chip, the first chip is controlled by the second hardware layer based on the first chip parameters to test the first driver software. After the development of the second chip is completed, the second chip is controlled by the second hardware layer based on the second chip parameters to implement the first driver software.

[0066] Taking the chip as PCIe hardware as an example, the hardware resources provided by the chip to the driver software generally include an interrupt mechanism, register access and device memory. Optionally, the chip parameters include at least one of interrupt parameters, register parameters and memory parameters, wherein the interrupt parameters are used to indicate the interrupt mechanism provided by the chip to the driver software, the register parameters are used to indicate the register storage address used in the chip, and the memory parameters are used to indicate the device memory allocation provided by the chip to the driver software.

[0067] An interrupt is a communication mechanism between computer hardware and software. When the chip (hardware) detects a specific event (such as a change in an input signal or a timer expiration), the chip sends an interrupt request to the driver software. Upon receiving the terminal request, the driver software pauses the current task and processes the interrupt event. After processing the interrupt event, the driver software resumes processing the previously paused task. The interrupt parameters in the chip parameters are used to indicate the interrupt mechanism provided by the chip to the driver software, such as the threshold for the number of interrupts that the chip can request, the interrupt type, the interrupt processing channel, and the interrupt processing function. This embodiment of the application uses the Multiple Interrupt Exceptions (MSIX) interrupt as an example to illustrate the interrupt parameters used to indicate the MSIX interrupt provided by the chip to the driver software.

[0068] A register is a high-speed storage device used to store and manipulate data in a computer. The register is directly connected to the processor and other hardware components. The chip provides register access for the driver software so that the driver software can interact with the hardware device. By accessing the register, the driver software can control the hardware device and exchange data. The register parameters in the chip parameters are used to indicate the register storage address. The first driver software can access the register based on the register parameters in the hardware layer.

[0069] Device memory is an area on the chip specifically used to store data required by the driver software. When the driver software is running, it needs to read and write data from the chip's memory. The memory parameters in the chip parameters are used to indicate the device memory allocation provided by the chip to the driver software, such as the memory block number threshold and storage space threshold for reading data, and the memory block number threshold and storage space threshold for writing data.

[0070] The first chip parameters include at least one of a first interrupt parameter, a first register parameter, and a first memory parameter corresponding to the first chip, and the second chip parameters include at least one of a second interrupt parameter, a second register parameter, and a second memory parameter corresponding to the second chip.

[0071] The above step 320 includes at least one of the following three situations:

[0072] The first method is to deploy the first interrupt parameter to the first hardware layer based on the deployment position of the second interrupt parameter in the first hardware layer of the first driver software to obtain the second hardware layer.

[0073] The second hardware layer is used to control the first chip to provide an interrupt mechanism for the first driver software according to the first interrupt parameter.

[0074] The second method is to deploy the first register parameter to the first hardware layer based on the deployment position of the second register parameter in the first hardware layer of the first driver software to obtain the second hardware layer.

[0075] The second hardware layer is used to control the first chip to provide register access for the first driver software according to the first register parameter.

[0076] The third method is to deploy the first device memory parameter to the first hardware layer based on the deployment position of the second device memory parameter in the first hardware layer of the first driver software to obtain the second hardware layer.

[0077] The second hardware layer is used to control the first chip to provide device memory allocation for the first driver software according to the first memory parameter.

[0078] In some embodiments, a first chip parameter different from a second chip parameter is determined, and the first chip parameter is deployed in the first hardware layer according to a deployment position of the corresponding second chip parameter in the first hardware layer to obtain a second hardware layer.

[0079] In some embodiments, before deploying at least one of the first interrupt parameter, the first register parameter, and the first memory parameter to the first hardware layer, a first chip identifier is additionally defined in the first hardware layer, where the first chip identifier is used to indicate the first chip.

[0080] Schematically, a chip category identifier is defined in the first hardware layer, and the chip category identifier is used to indicate the chip category to which the first driver software is connected. Before the first hardware layer is adjusted, the chip category identifier includes a second chip identifier, which is used to indicate that the first driver software is connected to the second chip. Based on the deployment position of the second chip identifier corresponding to the second chip in the first hardware layer, the first chip identifier corresponding to the first chip is added to the chip identifier category defined in the first hardware layer. When the first driver software is connected to the first chip, the chip category identifier is determined to be the first chip identifier. When the first driver software is connected to the second chip, the chip category identifier is determined to be the second chip identifier.

[0081] In some embodiments, during the operation of the first driver software, when the first driver software detects that the chip category identifier is a first chip identifier, the first chip is controlled based on the first chip parameters through the hardware layer of the first driver software to implement the first driver software; when the first driver software detects that the chip category identifier is a second chip identifier, the second chip is controlled based on the second chip parameters through the hardware layer of the first driver software to implement the first driver software.

[0082] Step 330: Run and test the first driver software in the first chip based on the second hardware layer to obtain a test result.

[0083] The test result is used to indicate the running status of the first driver software in the first chip, and the running status is used to provide a reference for the running of the first driver software in the second chip.

[0084] Optionally, at any time during the development of the first driver software, the above step 230 is executed to implement software testing of the first driver software based on the first chip during the development of the second chip.

[0085] Optionally, the test results include at least one operating condition, such as the running time of the first driver software in the first chip, the running time of multiple functions in the first driver software in the first chip, and the running results of the first driver software executing the test case in the first chip.

[0086] In some embodiments, a test-driven development (TDD) program, such as the test_tipudrv program, is used to test the operation of the first driver software in the first chip. The test-driven development program includes test cases, test drivers, test execution and result analysis, wherein the test case is used to describe the data and conditions required for the test, the test driver is a defined test driver function used to execute the test case and record the results, the test execution refers to executing the test according to the test driver and reporting the test results, and the result analysis is used to analyze the test results and determine whether the test results meet expectations.

[0087] Illustratively, the test_tipudrv program is used to complete the test of the first driver software executing the preset driver test case on the first chip, and automatically summarize the test results and present a test report through a specified programming language, such as Python.

[0088] In summary, the method provided in the embodiment of the present application deploys the first chip parameters to the first hardware layer based on the deployment position of the second chip parameters in the first hardware layer of the first driver software, so that the first driver software is adjusted from controlling the second chip to implement the first driver software based on the first hardware layer according to the second chip parameters to controlling the developed first chip to implement the first driver software based on the second hardware layer according to the first chip parameters. In this way, during the development process of the second chip, the first driver software can be run and tested in the first chip based on the second hardware layer, so that the operation status indicated by the obtained test results provides a reference for the operation of the first driver software in the second chip. That is, the first chip can be used instead of the second chip. By adjusting the chip deployment of the hardware layer in the driver software, the operation status of the first driver software on the first chip is simulated by the operation status of the first driver software on the second chip. In this way, during the development process of the second chip, the first driver software can be tested using the first chip synchronously with the development process of the first driver software, thereby reducing the design problems of the first driver software in the hardware and software joint debugging and verification after the development of the second chip and the first driver software is completed. At the same time, the simulation coverage of the actual operation scenario during the software testing process is improved, and the testing efficiency of the first driver software is improved.

[0089] Please refer to Figure 5 , which shows a flowchart of a hardware layer adaptation and adjustment method provided by an exemplary embodiment of the present application. The method can be executed by a terminal, or by a server, or by both the terminal and the server. The embodiment of the present application takes the method executed by a terminal as an example for explanation. Figure 5 As shown, the above step 320 includes the following steps:

[0090] Step 321: Based on the deployment location of the second chip identifier corresponding to the second chip in the first hardware layer, add the first chip identifier corresponding to the first chip to the chip category identifier defined in the first hardware layer.

[0091] The chip type identifier is used to indicate the chip type to which the first driver software is connected.

[0092] In some embodiments, before deploying at least one of the first interrupt parameter, the first register parameter, and the first memory parameter to the first hardware layer, a first chip identifier is additionally defined in the first hardware layer, where the first chip identifier is used to indicate the first chip.

[0093] A chip category identifier is defined in the first hardware layer, and the chip category identifier is used to indicate the chip category to which the first driver software is connected. Before adjusting the first hardware layer, since the first driver software was developed in conjunction with a supporting system, the chip category identifier of the first hardware layer includes a second chip identifier, which is used to indicate that the first driver software is connected to the second chip. Based on the deployment location of the second chip identifier corresponding to the second chip in the first hardware layer, the first chip identifier corresponding to the first chip is added to the chip identifier category defined in the first hardware layer. When the first driver software is connected to the first chip, the chip category identifier is determined to be the first chip identifier. When the first driver software is connected to the second chip, the chip category identifier is determined to be the second chip identifier. When the first driver software detects that the chip category identifier is the first chip identifier, the first driver software controls the first chip based on the first chip parameters to implement the first driver software through the hardware layer of the first driver software; when the first driver software detects that the chip category identifier is the second chip identifier, the first driver software controls the second chip based on the second chip parameters to implement the first driver software through the hardware layer of the first driver software.

[0094] Schematically, the chip category identifier is indicated by the product category (product_type) field in the first hardware layer, and the first driver software can automatically identify the currently connected chip category by detecting the product_type field. In response to detecting that the product_type field indicates the first chip identifier, it is determined that the first hardware layer is currently connected to the first chip. In response to detecting that the product_type field indicates the second chip identifier, it is determined that the first hardware layer is currently connected to the second chip.

[0095] When adjusting the first hardware layer to make the first driver software adapt to different chips, it is necessary to identify the currently connected chip through the chip category identifier to instruct the first driver software on the adjustment direction of the first hardware layer when performing differentiated processing. For example, in response to detecting that the chip category identifier is the first chip identifier, the first chip parameters are deployed to the first hardware layer to obtain the second hardware layer, so that the first driver software adapts to the first chip; in response to detecting that the chip category identifier is other chip identifiers, the chip parameters of the chip corresponding to the chip identifier are deployed to the first hardware layer to obtain the second hardware layer, so that the first driver software adapts to the chip.

[0096] After adding the definition of the first chip identifier in the first hardware layer, the first driver software corresponding to the second chip can be loaded onto the first chip. You can check the loading status of the first driver software on the first chip through the command line window. For an example, please refer to Figure 6 , Figure 6 This is a schematic diagram of driver loading provided by an exemplary embodiment of the present application. Figure 6 As shown, after adding and defining the first chip identifier in the first hardware layer, the driver software loading command is executed through the command line window to load the first driver software into the first chip, and the loading result 610 is displayed. The loading result 610 includes the first chip identifier, and the loading result 610 is used to indicate that the first driver software is successfully loaded into the first chip.

[0097] Step 322: Based on the first chip identifier and according to the deployment location of the second chip parameters in the first hardware layer, the first chip parameters are deployed into the first hardware layer to obtain a second hardware layer.

[0098] The second hardware layer is used to control the first chip to provide the first hardware resource for the first driver software according to the first chip parameter based on the first chip identifier.

[0099] Taking the chip as PCIe hardware as an example, the hardware resources provided by the chip to the driver software generally include an interrupt mechanism, register access and device memory. Optionally, the chip parameters include at least one of interrupt parameters, register parameters and memory parameters, wherein the interrupt parameters are used to indicate the interrupt mechanism provided by the chip to the driver software, the register parameters are used to indicate the register storage address used in the chip, and the memory parameters are used to indicate the device memory allocation provided by the chip to the driver software.

[0100] The first chip parameters include at least one of a first interrupt parameter, a first register parameter, and a first memory parameter corresponding to the first chip, and the second chip parameters include at least one of a second interrupt parameter, a second register parameter, and a second memory parameter corresponding to the second chip.

[0101] The above step 320 includes at least one of the following three situations:

[0102] The first Based on the deployment position of the second interrupt parameter in the first hardware layer of the first driver software, the first interrupt parameter is deployed to the first hardware layer to obtain the second hardware layer.

[0103] An interrupt is a communication mechanism between computer hardware and software. When the chip (hardware) detects a specific event (such as a change in an input signal or a timer expiration), the chip sends an interrupt request to the driver software. After receiving the terminal request, the driver software pauses the current task and processes the interrupt event. After processing the interrupt event, the driver software resumes processing the previously paused task. The interrupt parameters in the chip parameters are used to indicate the interrupt mechanism provided by the chip to the driver software, such as the threshold for the number of interrupts that the chip can apply for, the interrupt type, the interrupt processing channel, the interrupt processing function, etc. The embodiments of this application use MSIX interrupts as an example to illustrate. The interrupt parameters are used to indicate the MSIX interrupts provided by the chip to the driver software.

[0104] In some embodiments, based on the first chip identifier and the number of interrupts indicated by the first interrupt parameter corresponding to the first chip, the interrupt number threshold in the first hardware layer is adjusted; based on the interrupt number threshold, an interrupt mapping relationship is constructed between the first interrupt parameter and the second interrupt parameter corresponding to the second chip, and the interrupt mapping relationship is used to indicate that the interrupt channel indicated by the second interrupt parameter is mapped to the interrupt channel indicated by the first interrupt parameter; based on the interrupt mapping relationship, the first interrupt parameter is deployed to the first hardware layer to obtain the second hardware layer, and the second hardware layer is used to apply for interrupt access according to the interrupt number threshold based on the first chip identifier, and process the interrupt access according to the interrupt channel indicated by the first interrupt parameter.

[0105] The second Based on the deployment position of the second register parameter in the first hardware layer of the first driver software, the first register parameter is deployed to the first hardware layer to obtain the second hardware layer.

[0106] A register is a high-speed storage device used to store and manipulate data in a computer. The register is directly connected to the processor and other hardware components. The chip provides register access for the driver software so that the driver software can interact with the hardware device. By accessing the register, the driver software can control the hardware device and exchange data. The register parameters in the chip parameters are used to indicate the register storage address. The first driver software can access the register based on the register parameters in the hardware layer.

[0107] In some embodiments, a register mapping relationship is constructed between a first register parameter corresponding to the first chip and a second register parameter corresponding to the second chip, and the register mapping relationship is used to indicate that the register storage address indicated by the second register parameter is mapped to the register storage address indicated by the first register parameter; based on the register mapping relationship, the first register parameter is deployed to the first hardware layer to obtain the second hardware layer, and the second hardware layer is used to control the first chip based on the first chip identifier to provide register storage resources for the first driver software according to the first register parameter.

[0108] The third Based on the deployment position of the second device memory parameter in the first hardware layer of the first driver software, the first device memory parameter is deployed into the first hardware layer to obtain the second hardware layer.

[0109] Device memory is an area on the chip specifically used to store data required by the driver software. When the driver software is running, it needs to read and write data from the chip's memory. The memory parameters in the chip parameters are used to indicate the device memory allocation provided by the chip to the driver software, such as the memory block number threshold and storage space threshold for reading data, and the memory block number threshold and storage space threshold for writing data.

[0110] In some embodiments, a memory mapping relationship is constructed between a first memory parameter corresponding to the first chip and a second memory parameter corresponding to the second chip, and the memory mapping relationship is used to indicate that the device memory allocation indicated by the second memory parameter is mapped to the device memory allocation indicated by the first memory parameter; based on the memory mapping relationship, the first memory parameter is deployed to the first hardware layer to obtain the second hardware layer, and the second hardware layer is used to control the first chip to provide memory allocation resources for the first driver software according to the first memory parameter based on the first chip identifier.

[0111] In some embodiments, the second hardware layer includes first chip parameters and second chip parameters, then the first driver software can adapt to both the first chip and the second chip based on the second hardware layer. When the first driver software is running, in response to detecting that the chip category identifier is the first chip identifier, the first chip is controlled to provide the first hardware resources for the first driver software based on the first chip parameters; or, when the first driver software is running, in response to detecting that the chip category identifier is the second chip identifier, the second chip is controlled to provide the second hardware resources for the first driver software based on the second chip parameters.

[0112] Schematically, taking the example of the first driver software adapting the register reading and writing of the first chip based on the second hardware layer, the second hardware layer includes a first register parameter and a second register parameter. When the first driver software is running, in response to detecting that the chip category identifier is the first chip identifier, the first chip is controlled to provide register access resources for the first driver software based on the first register parameter; or, when the first driver software is running, in response to detecting that the chip category identifier is the second chip identifier, the second chip is controlled to provide register access resources for the first driver software based on the second register parameter. Taking the example of the first driver software adapting the device memory allocation of the first chip based on the second hardware layer, the second hardware layer includes a first memory parameter and a second memory parameter. When the first driver software is running, in response to detecting that the chip category identifier is the first chip identifier, the first chip is controlled to provide device memory allocation resources for the first driver software based on the first memory parameter; or, when the first driver software is running, in response to detecting that the chip category identifier is the second chip identifier, the second chip is controlled to provide device memory allocation resources for the first driver software based on the second memory parameter. Taking the example of the first driver software adapting the interrupt mechanism of the first chip based on the second hardware layer, the second hardware layer includes a first interrupt parameter and a second interrupt parameter. When the first driver software is running, in response to detecting that the chip category identifier is the first chip identifier, the first chip is controlled to provide an interrupt mechanism for the first driver software based on the first interrupt parameter; or, when the first driver software is running, in response to detecting that the chip category identifier is the second chip identifier, the second chip is controlled to provide an interrupt mechanism for the first driver software based on the second interrupt parameter.

[0113] To sum up, the method provided in the embodiment of the present application adds the first chip identifier corresponding to the first chip to the chip category identifier defined in the first hardware layer, and based on the first chip identifier, deploys the first chip parameters to the first hardware layer according to the deployment position of the second chip parameters in the first hardware layer to obtain the second hardware layer, so that the second hardware layer can control the first chip based on the first chip identifier to provide the first hardware resources to the first driver software according to the first chip parameters, thereby realizing the adaptation and adjustment of the first driver software and the first chip, so that the first driver software can be tested in the existing first chip, providing a reference for the operation status of the first driver software in the second chip, and by using the existing chip to replace the chip to be developed for software testing, there is no need to use a simulation environment to simulate the hardware structure, which can fully cover the actual operation scenarios and improve software testing efficiency.

[0114] The method provided in the embodiment of the present application can, when the second hardware layer includes the first chip parameters and the second chip parameters, control the first chip to provide hardware resources for the first driver software according to the first chip parameters based on the second hardware layer based on the first chip identifier during software testing, and can also control the second chip to provide hardware resources for the first driver software according to the second chip parameters based on the second hardware layer based on the second chip identifier during actual application after the second chip is developed. That is, after obtaining the second hardware layer, no matter for software testing or actual application, there is no need to make relevant adjustments to the chip parameters of the hardware layer of the first driver software again, and only needs to make adjustments based on the test results of software and hardware, thereby reducing the impact of the adjustment of the hardware layer in the first driver software during software testing on actual application, and improving software testing efficiency.

[0115] In some embodiments, the hardware layer of the driver software is adapted and adjusted based on the register parameters of the chip, so that the second hardware layer can control the first chip through the first chip identifier to provide register access to the first driver software based on the first register parameters. Figure 7 , which shows a flowchart of a hardware layer adaptation adjustment method based on register parameters provided by an exemplary embodiment of the present application. The method can be executed by a terminal, or by a server, or by both the terminal and the server. The embodiment of the present application takes the method executed by the terminal as an example for explanation. Figure 7 As shown, the above step 322 includes the following steps:

[0116] Step 710: Construct a register mapping relationship between a first register parameter corresponding to the first chip and a second register parameter corresponding to the second chip.

[0117] The register mapping relationship is used to indicate mapping the register storage address indicated by the second register parameter to the register storage address indicated by the first register parameter.

[0118] Schematically, the embodiment of the present application is illustrated by taking the first chip as a pre-acquired codec chip and the second chip as an AI chip to be developed as an example. The second register parameter corresponding to the second chip indicates that the register adopted by the second chip accesses the register through the base address register (Base Address Register, BAR). The first chip uses double data rate (Double Data Rate, DDR) memory space to access the register. Taking the second chip needing to present 32MB of space to the outside through BAR as an example, a mapping relationship between the 32MB register access space and the DDR space of the first chip is constructed, that is, the virtual address of the register in the second chip is mapped to the physical address of the DDR space of the first chip. Specifically, different starting base addresses are configured for different registers in the first chip according to the above mapping relationship.

[0119] Step 720: deploy the first register parameter to the first hardware layer based on the register mapping relationship to obtain a second hardware layer.

[0120] The second hardware layer is used to control the first chip to provide register access resources for the first driver software according to the first register parameter based on the first chip identifier.

[0121] In some embodiments, a first register parameter indicates the starting base addresses corresponding to different registers in the first chip, and a register mapping code based on the chip category identifier is written in the first hardware layer according to the deployment position of the second register parameter in the first hardware layer to implement adaptation and adjustment based on register access resources. In the second hardware layer, except for the register starting base address, the access logic for the registers is consistent with that of the first hardware layer. The register mapping code determines the register access resources by detecting the chip category identifier. In response to detecting that the chip category identifier is the first chip identifier, the register access resources are provided to the first driver software according to the register storage address indicated by the first register parameter. In response to detecting that the chip category identifier is the second chip identifier, the register access resources are provided to the first driver software according to the register storage address indicated by the second register parameter.

[0122] Based on the adjusted second hardware layer, when the first chip is used to run the first driver software, the first driver software requests access to the 32MB space of the second chip register through the BAR during runtime based on the matching design requirements with the second chip. What is actually accessed is the register resources provided by the DDR memory of the first chip. That is, the current first driver software can adapt to the register resources provided by the first chip. Based on this second hardware layer, the running status of the first driver software on the first chip can provide a reference for the running status of the first driver software on the second chip.

[0123] To summarize, the method provided in the embodiment of the present application constructs a register mapping relationship between the first register parameter and the second register parameter, and deploys the first register parameter to the first hardware layer based on the register mapping relationship to obtain the second hardware layer, thereby realizing register adaptation between the first driver software and the first chip. That is, when the first driver software runs in the first chip, the first chip is controlled to provide register access resources for the first driver software according to the first register parameter, fully simulating the register access of the first driver software in the second chip, thereby improving software testing efficiency.

[0124] In some embodiments, the hardware layer of the driver software is adapted and adjusted based on the memory parameters of the chip, so that the second hardware layer can control the first chip through the first chip identifier to provide device memory allocation for the first driver software based on the first memory parameters. Figure 8, which shows a flowchart of a hardware layer adaptation adjustment method based on memory parameters provided by an exemplary embodiment of the present application. The method can be executed by a terminal, or by a server, or by both the terminal and the server. The embodiment of the present application takes the method executed by a terminal as an example for explanation. Figure 8 As shown, the above step 322 includes the following steps:

[0125] Step 810: Construct a memory mapping relationship between a first memory parameter corresponding to the first chip and a second memory parameter corresponding to the second chip.

[0126] The memory mapping relationship is used to indicate that the device memory allocation indicated by the second memory parameter is mapped to the device memory allocation indicated by the first memory parameter.

[0127] Schematically, the embodiment of the present application is described by taking the first chip as a pre-acquired codec chip and the second chip as an AI chip to be developed as an example. The second memory parameter corresponding to the second chip indicates that the second chip is divided into 4 Level 2 Buffering, L2 BUF (each 32MB), 4 Level 3 High Bandwidth Memory (L3 The device memory of the second chip is mapped to the device memory of the first chip by constructing a memory mapping relationship. The constructed memory mapping relationship is used to indicate that the four L2 memories in the second chip are mapped to the first space corresponding to the 0×880000000 to 0×97FFFFFFF bits in the DDR space of the first chip, and the first space size is 4GB; the HBM memory of the L3 in the second chip is mapped to the second space corresponding to the 0×98000000 to 0×9807FFFFF bits in the DDR space of the first chip, and the second space size is 128MB; based on the feature that the first chip reads and writes registers from the 32MB space of DDR through BAR, the third space corresponding to the 0×98080000 to 0×9808FFFFF bits in the DDR space of the first chip is used for register reading and writing, and the size of the third space is 32MB.

[0128] Step 820: deploy the first memory parameter to the first hardware layer based on the memory mapping relationship to obtain a second hardware layer.

[0129] The second hardware layer is used to control the first chip to provide memory allocation resources for the first driver software according to the first memory parameter based on the first chip identifier.

[0130] Schematically, taking the memory mapping relationship illustrated in step 810 above as an example, based on the memory mapping relationship, the first hardware layer defines the first memory parameters such as the device memory allocation size and address of the first chip, and deploys the first memory parameters to the first hardware layer. For example, based on the memory mapping relationship, a 4GB DDR space is defined in the first hardware layer. The DDR space is used to act as four L2 memory blocks in the second chip when running the first driver software, providing memory allocation resources for the first driver software. When the first driver software runs in the first chip, the first driver software's access to the L2 and L3 memory of the second chip is correspondingly mapped to DDR access to the first chip, achieving DDR read and write adaptation. At the same time, based on the mapping relationship, the allocation interface of the corresponding device memory is modified. For example, the starting address and size of the HBM in the operating system are modified according to the mapping relationship, so that when the chip type identifier is the first chip identifier, the second hardware layer controls the first chip to provide memory allocation resources to the first driver software according to the first memory parameters. When the chip type identifier is the second chip identifier, the second hardware layer controls the first chip to provide memory allocation resources to the first driver software according to the first memory parameters, achieving device memory allocation to access adaptation.

[0131] To sum up, the method provided in the embodiment of the present application constructs a memory mapping relationship between the first memory parameter and the second memory parameter, deploys the first memory parameter to the first hardware layer based on the memory mapping relationship, and obtains the second hardware layer, thereby realizing device memory adaptation between the first driver software and the first chip. That is, when the first driver software runs in the first chip, the first chip is controlled to provide device memory allocation for the first driver software according to the first memory parameter, and the device memory allocation of the first driver software in the second chip is simulated. When testing the first driver software in the first chip, the device memory allocation of the second chip is fully simulated, thereby improving software testing efficiency.

[0132] In some embodiments, the hardware layer of the driver software is adapted and adjusted based on the interrupt parameters of the chip, so that the second hardware layer can control the first chip through the first chip identifier to provide an interrupt mechanism for the first driver software based on the first interrupt parameters. Figure 9 , which shows a flowchart of a hardware layer adaptation adjustment method based on interrupt parameters provided by an exemplary embodiment of the present application. The method can be executed by a terminal, or by a server, or by both the terminal and the server. The embodiment of the present application takes the method executed by a terminal as an example for explanation. Figure 9 As shown, the above step 322 includes the following steps:

[0133] Step 910: Adjust an interruption number threshold in a first hardware layer based on a first chip identifier and an interruption number indicated by a first interruption parameter corresponding to the first chip.

[0134] In the process of performing interrupt adaptation on the first hardware layer of the first driver software based on the first chip parameters, it is necessary to adjust the interrupt request, interrupt registration, interrupt triggering, and interrupt handling of the first hardware layer to adapt to the first chip. An interrupt request (IRQ) is a request sent by a hardware device or driver software to the operating system. An interrupt registration is used to store the address of an interrupt handler, save data of the interrupted program, set interrupt priority, and control interrupt requests. An interrupt trigger refers to the process by which the operating system recognizes and responds to a specific event (such as a hardware device completing a task or driver software issuing an interrupt request). Interrupt handling refers to the interrupt handler executed by the operating system after responding to the interrupt request.

[0135] In some embodiments, interrupt requests are made by calling a system function, such as the pci_alloc_irq_vectors function, to request an interrupt based on an interrupt quantity threshold. Different chips can request different interrupt quantity thresholds. Therefore, it is necessary to adapt the interrupt quantity differences based on different chip parameters. In order to make the first driver software adapt to the interrupt quantity threshold of the first chip, it is necessary to adjust the interrupt quantity threshold defined in the first hardware based on the second interrupt parameter corresponding to the second chip to the interrupt quantity indicated by the first terminal parameter.

[0136] In some embodiments, step 910 includes the following three steps:

[0137] In the first step, a first interrupt quantity corresponding to the first chip is determined based on a first interrupt parameter corresponding to the first chip.

[0138] The first interrupt quantity is used to indicate a threshold value of the interrupt quantity that the first chip can support that is requested by the driver software.

[0139] Illustratively, a threshold value of the number of interrupts that the first chip can support requested by the driver software is obtained from the FS document corresponding to the first chip, and the threshold value of the number of interrupts is determined as the first number of interrupts indicated by the first interrupt parameter.

[0140] In the second step, the second interrupt quantity corresponding to the second chip is determined based on the second interrupt parameter corresponding to the second chip.

[0141] The second interrupt quantity is used to indicate a threshold value of the interrupt quantity that the second chip can support requested by the driver software.

[0142] Illustratively, a threshold value of the number of interrupts that the second chip can support requested by the driver software is obtained from the FS document corresponding to the second chip, and the threshold value of the number of interrupts is determined as the second number of interrupts indicated by the second interrupt parameter.

[0143] In the third step, in response to detecting that the chip category identifier is the first chip identifier, the interruption number threshold in the first hardware layer is adjusted to the first interruption number.

[0144] In some embodiments, an interrupt number threshold (irq_num) is defined in the first hardware layer. By writing an interrupt number threshold assignment code based on the chip category identifier in the first hardware layer, adaptive adjustment based on the interrupt number is implemented. The assignment code adjusts the assignment of the interrupt number threshold by detecting the chip category identifier. In response to detecting that the chip category identifier is the first chip identifier, the interrupt number threshold is assigned to the first interrupt number. In response to detecting that the chip category identifier is the second chip identifier, the interrupt number threshold is assigned to the second interrupt number.

[0145] Step 920 : constructing an interrupt mapping relationship between the first interrupt parameter and the second interrupt parameter corresponding to the second chip based on the interrupt quantity threshold.

[0146] The interrupt mapping relationship is used to indicate that the interrupt channel indicated by the second interrupt parameter is mapped to the interrupt channel indicated by the first interrupt parameter.

[0147] In some embodiments, the first chip is a pre-acquired codec chip, and the second chip is an AI chip to be developed. Assume that the interrupt mechanism adopted by the second chip is to send all interrupts to interrupt vector 0 through the physical layer interrupt controller module (Physical Layer Controller and Handler, PLCH), and fill the corresponding interrupt message into a ring buffer (RingBuffer), and trigger the corresponding interrupt processing. The first chip adopts the interrupt mechanism of mailbox interrupt. It is necessary to construct an interrupt mapping relationship so that the real mailbox interrupt in the first chip simulates the interrupt sending on the second chip, and then process the interrupt according to PLCH to achieve interrupt adaptation.

[0148] The above-mentioned mailbox is a mechanism for transmitting messages between processors or between processors and peripherals in an embedded system. The mailbox usually includes one or more registers for storing messages. When the message in the mailbox changes, the system will trigger a corresponding interrupt event. The embodiment of the present application takes the first chip using the mailbox start bit interrupt as an example for illustration. Schematically, the interrupt type identifier IRQ_EPIH_MAILBOX_BIT_START is used to identify the mailbox start interrupt. The mailbox start interrupt is used to indicate that the start bit in the mailbox is ready and the processor can start reading or processing the message in the mailbox.

[0149] The interrupt mechanism corresponding to the second chip includes at least one of the interrupt events such as normal interrupt, reset interrupt, fault interrupt and memory direct access interrupt. Indicatively, the above different types of interrupt events can be indicated by interrupt type identifiers such as IQR_PLCH_NORMAL, IQR_PLCH_RAS, IQR_PLCH_FATAL, IQR_PLCH_DMA(i), etc.

[0150] Normal interrupts represent general events, such as button triggers, sensor triggers, etc. Normal interrupts are usually used to handle events during the normal operation of the system; reset interrupts represent system or hardware reset events. When the system detects a reset signal, it triggers a reset interrupt and performs corresponding processing; fault interrupts indicate serious errors or faults in the system, such as memory errors, bus errors, etc. Fault interrupts usually cause the system to stop running and require troubleshooting and repair; direct memory access interrupts represent events during direct memory access (DMA) transmission and are used to handle data processing and error handling during DMA transmission.

[0151] In schematic form, by offsetting the mailbox start interrupt to different degrees, mapping them to normal interrupts, reset interrupts, fault interrupts, and memory direct access interrupts, an interrupt mapping relationship is constructed as follows: the interrupt channel of the normal interrupt corresponding to the second chip is mapped to the first interrupt channel corresponding to the first chip, the interrupt channel of the reset interrupt corresponding to the second chip is mapped to the second interrupt channel corresponding to the first chip, the interrupt channel of the fault interrupt corresponding to the second chip is mapped to the third interrupt channel corresponding to the first chip, and the interrupt channel of the memory direct access interrupt corresponding to the second chip is mapped to the fourth interrupt channel corresponding to the first chip, wherein the first interrupt channel, the second interrupt channel, the third interrupt channel, and the fourth interrupt channel are interrupt channels obtained by offsetting the interrupt channel corresponding to the mailbox start interrupt in the first chip to different degrees. Based on the above interrupt mapping relationship, when any interrupt event among normal interrupts, reset interrupts, fault interrupts, and memory direct access interrupts occurs during the operation of the first driver software, the second hardware layer can actually perform interrupt processing in the first chip in the form of mailbox start interrupt processing based on the interrupt mapping relationship, so that the first chip can simulate the interrupt mechanism provided by the second chip for the first driver software, thereby realizing interrupt adaptation.

[0152] Step 930: deploy the first interrupt parameter to the first hardware layer based on the interrupt mapping relationship to obtain a second hardware layer.

[0153] The second hardware layer is used to apply for interrupt access according to the interrupt quantity threshold based on the first chip identifier, and process the interrupt access according to the interrupt channel indicated by the first interrupt parameter.

[0154] In some embodiments, based on the above-mentioned interrupt mapping relationship, interrupt channels corresponding to normal interrupts, reset interrupts, fault interrupts and memory direct access interrupts can be added in the first hardware layer, and the first interrupt parameters can be deployed in the first hardware layer to obtain the second hardware layer, so that the first driver software can apply for interrupt access according to the interrupt quantity threshold based on the first chip identifier, and process the interrupt access according to the interrupt channel indicated by the first interrupt parameter.

[0155] For illustration, please refer to the following interrupt channel definition:

[0156] #define IQR_PLCH_NORMAL(IRQ_EPIH_MAILBOX_BIT_START+2)

[0157] #define IQR_PLCH_RAS(IRQ_EPIH_MAILBOX_BIT_START+3)

[0158] #define IQR_PLCH_FATAL(IRQ_EPIH_MAILBOX_BIT_START+4)

[0159] #define IQR_PLCH_DMA(i)(IRQ_EPIH_MAILBOX_BIT_START+(i))

[0160] Among them, IRQ_EPIH_MAILBOX_BIT_START is used to indicate the interrupt channel of the mailbox start interrupt, IRQ_EPIH_MAILBOX_BIT_START+2 is the first interrupt channel corresponding to the offset of the interrupt channel of the mailbox start interrupt, IRQ_EPIH_MAILBOX_BIT_START+3 is the second interrupt channel corresponding to the offset of the interrupt channel of the mailbox start interrupt, IRQ_EPIH_MAILBOX_BIT_START+4 is the third interrupt channel corresponding to the offset of the interrupt channel of the mailbox start interrupt, IRQ_EPIH_MAILBOX_BIT_START+(i) is the fourth interrupt channel corresponding to the offset of the interrupt channel of the mailbox start interrupt, IQR_PLCH_NORMAL is used The interrupt channel corresponding to the normal interrupt is indicated by IQR_PLCH_RAS, the interrupt channel corresponding to the reset interrupt is indicated by IQR_PLCH_FATAL, the interrupt channel corresponding to the fault interrupt is indicated by IQR_PLCH_DMA(i), and the interrupt channel corresponding to the direct access interrupt is indicated by IQR_PLCH_DMA(i). By defining the interrupt channels corresponding to the normal interrupt, the reset interrupt, the fault interrupt and the direct access interrupt as the above-mentioned first interrupt channel, second interrupt channel, third interrupt channel and fourth interrupt channel respectively, when any interrupt event among the normal interrupt, reset interrupt, fault interrupt and memory direct access interrupt occurs during the operation of the first driver software, the interrupt processing can be actually performed in the first chip in the form of mailbox-initiated interrupt processing through the second hardware layer, so that the first chip can simulate the interrupt mechanism provided by the second chip for the first driver software.

[0161] In some embodiments, the second hardware layer includes a first interrupt parameter and a second interrupt parameter. During operation, the first driver software performs interrupt registration according to the first interrupt parameter or the second interrupt parameter based on the chip category identification in the second hardware layer.

[0162] For illustration, please refer to Figure 10 , Figure 10 This is a schematic diagram of interrupt registration adaptation provided by an exemplary embodiment of the present application. Figure 10As shown, during the interrupt registration process, execute step 1010 to detect the chip category identifier (product_type); in response to the chip category identifier being the first chip identifier, execute step 1021 to call the first interrupt installation function (xinpian1_install_irqs); in response to the chip category identifier being the second chip identifier, execute step 1022 to call the second interrupt installation function (xinpian2_install_irqs); in response to calling the first interrupt installation function, execute step 1031 to fill in the interrupt vector and callback API corresponding to the first chip; in response to calling the second interrupt installation function, execute step 1032 to fill in the interrupt vector and callback API corresponding to the second chip; execute step 1040 to call the system interrupt installation function (tipu_pci_install_irqs); execute step 1050 to call the request interrupt function (request_irqs). Among them, the first interrupt installation function is used to trigger the filling of the ring buffer based on the first interrupt parameter; the second interrupt installation function is used to trigger the filling of the ring buffer based on the second interrupt parameter; the system interrupt installation function is a general interrupt program installation function, which is used to install the terminal handler to the specified interrupt vector. When an interrupt occurs, the system will automatically call the installed interrupt handler; the request interrupt function is used to request and configure hardware interrupts.

[0163] In some embodiments, a data filling function is required to enable the second hardware layer to control the first chip, based on the first chip identifier, to simulate the second chip and fill a ring buffer for interrupt registration. A ring buffer is a widely used data structure in computer science. It is a circular storage structure that can be used to store and manage data. The main feature of a ring buffer is that it is connected end to end, forming a ring structure. Therefore, it can solve the buffer full and buffer empty issues to a certain extent.

[0164] When simulating the second chip to register interrupts, data needs to be filled based on the ring buffer data structure. For an example, please refer to Figure 11 , Figure 11 This is a schematic diagram of a ring buffer structure provided by an exemplary embodiment of the present application. Figure 11As shown, in the ring buffer data structure 1110, the buffers corresponding to the first storage address 0x0 and the second storage address 0x4 respectively store 32 bits of data, from right to left, 0 to 31 bits (0 is used to identify the first bit from low to high, 1 is used to identify the second bit from low to high, and so on). Among them, bits 0-9 in the buffer corresponding to the first storage address are used to store the master device identifier (MasterID), bits 10-11 are used to store the chip identifier (DieID), bits 12-15 are used to store the context identifier (ContexID), and bits 16-31 are used to store the timestamp (TimeStamp). Bits 0-23 in the buffer corresponding to the second storage address are used to store user data (UserData), and bits 24-31 are used to store vectors (Vector). During the interrupt registration process, the first driver software is based on the second hardware layer as shown below. Figure 11 The data structure shown fills the ring buffer.

[0165] Taking the first chip as a pre-acquired codec chip and the second chip as an AI chip to be developed as an example, the PLCH interrupt and DMA interrupt in the second chip, etc., essentially fill the message to obtain a circular buffer, and then trigger the corresponding PLCH interrupt and send it to the host system (Host) side. The mailbox interrupt in the first chip can trigger the issuance of the corresponding interrupt by writing the register. Then, through the above-mentioned data filling function, the message filling behavior of the hardware can be simulated in the first driver software based on the second hardware layer to realize the interrupt registration of the simulated second chip. After the first chip issues an actual hardware interrupt, the preset interrupt processing function is called according to the interrupt processing logic of the second chip based on the interrupt mapping relationship to perform interrupt processing, thereby realizing the interrupt access of the simulated second chip.

[0166] To sum up, the method provided in the embodiment of the present application adjusts the interrupt number threshold in the first hardware layer by based on the first chip identifier and the number of interrupts indicated by the first interrupt parameter corresponding to the first chip; constructs an interrupt mapping relationship between the first interrupt parameter and the second interrupt parameter corresponding to the second chip based on the interrupt number threshold, and deploys the first interrupt parameter to the first hardware layer based on the interrupt mapping relationship to obtain the second hardware layer, thereby realizing interrupt adaptation between the first driver software and the first chip, enabling the second hardware layer to apply for interrupt access according to the interrupt number threshold based on the first chip identifier, and process interrupt access according to the interrupt channel indicated by the first interrupt parameter. When testing the first driver software in the first chip, the interrupt processing of the second chip is fully simulated, thereby improving software testing efficiency.

[0167] In some embodiments, a test driver is used to test the operation of the first driver software in the first chip. Figure 12 , Figure 12This is a flow chart of a test result display method provided by an exemplary embodiment of the present application. The method can be executed by a terminal, a server, or both. The present application embodiment takes the method executed by a terminal as an example for explanation. Figure 12 As shown, the above step 330 includes the following steps:

[0168] Step 331: Call a preset test program to test the operation of the first driver software including the second hardware layer in the first chip to obtain the test result.

[0169] In some embodiments, the preset test program is a TDD program, such as the pre-developed test_tipudrv program. The test driver includes test cases, test drivers, test execution and result analysis, wherein the test cases are used to describe the data and conditions required for the test, the test driver is a defined test driver function used to execute the test cases and record the results, test execution refers to executing the test according to the test driver and reporting the test results, and result analysis is used to analyze the test results and determine whether the test results meet expectations.

[0170] Optionally, the test results include at least one of a functional test result, a performance test result, a stability test result, a fault tolerance test result, and a compatibility test result. The functional test result is used to indicate whether the function of the first driver software is as expected, including the hardware, software, and operating system it supports, to ensure that the first driver software can work normally in various usage scenarios; the performance test structure is used to evaluate the performance of the first driver software in data transmission, processing, and calculation, mainly including indicators such as transmission speed, processing efficiency, and response time; the stability test structure is used to indicate the stability of the first driver software under various loads and pressures, including system resource consumption, memory leaks, program crashes, etc.; the fault tolerance test result is used to indicate the processing capability of the first driver software in the event of errors and abnormal situations, including error detection and reporting, recovery capability, and system stability after error handling; the compatibility test is used to indicate the compatibility of the first driver software in different hardware platforms, operating systems, and software environments, to ensure that the first driver software can work normally under various configurations without causing compatibility issues.

[0171] Step 332: Display a test report interface based on the test results.

[0172] The test report interface includes at least one report element of the number of test cases, the running time of the test cases, and the success rate of the test cases.

[0173] For illustration, please refer to Figure 13 , Figure 13 This is a schematic diagram of presenting an automated test report provided by an exemplary embodiment of the present application. Figure 13 As shown, in response to the first driver software running in the first chip and completing the execution of the preset test cases, a test report interface 1310 is displayed. The test report interface 1310 includes reporting elements such as the number of test cases, the test case running time, and the test case success ratio. Among them, the number of test cases is used to indicate that the first driver software runs in the first chip and completes the execution of 40 test cases, the test case running time 1301 is used to indicate that the time consumed by the first driver software to execute test case A is 0.421 seconds, and the test success ratio 1302 is used to indicate that the first driver software has a 100% success ratio in executing the above-mentioned preset test cases.

[0174] To sum up, the method provided in the embodiment of the present application tests the operation of the first driver software including the second hardware layer in the first chip by calling a preset test program, obtains the test results, and displays the test report interface based on the test results, thereby improving the degree of automation of the test report and improving software testing efficiency.

[0175] Figure 14 This is a structural block diagram of a software testing device provided by an exemplary embodiment of the present application. Figure 14 As shown, the device includes the following parts:

[0176] An acquisition module 1410 is configured to acquire first chip parameters and second chip parameters, wherein the first chip parameters are parameters of a first chip that has been developed, and the second chip parameters are parameters of a second chip to be developed. The second chip is configured to implement the driver function of the first driver software after development is completed. The first chip parameters are configured to indicate first hardware resources provided when the first chip runs the driver software, and the second chip parameters are configured to indicate second hardware resources provided when the second chip runs the driver software.

[0177] Processing module 1420 is configured to deploy the first chip parameters into the first hardware layer based on the deployment location of the second chip parameters in the first hardware layer of the first driver software, thereby obtaining a second hardware layer, wherein the first hardware layer is configured to control the second chip to implement the first driver software based on the second chip parameters, and the second hardware layer is configured to control the first chip to implement the first driver software based on the first chip parameters.

[0178] The testing module 1430 is used to run and test the first driver software in the first chip based on the second hardware layer to obtain a test result. The test result is used to indicate the running status of the first driver software in the first chip, and the running status is used to provide a reference for the running of the first driver software in the second chip.

[0179] Please refer to Figure 15, Figure 15 This is a structural block diagram of a software testing device module provided by an exemplary embodiment of the present application. Figure 15 As shown, in some embodiments, the processing module 1420 includes:

[0180] A first processing unit 1421 is configured to add a first chip identifier corresponding to the first chip to chip category identifiers defined in the first hardware layer based on a deployment location of a second chip identifier corresponding to the second chip in the first hardware layer, where the chip category identifier is used to indicate a chip category to which the first driver software is connected;

[0181] The second processing unit 1422 is used to deploy the first chip parameters to the first hardware layer based on the first chip identifier and according to the deployment location of the second chip parameters in the first hardware layer to obtain the second hardware layer, and the second hardware layer is used to control the first chip based on the first chip identifier to provide the first hardware resources to the first driver software according to the first chip parameters.

[0182] In some embodiments, the chip parameters include at least one of an interrupt parameter, a register parameter, and a memory parameter. The interrupt parameter is used to indicate the interrupt mechanism provided by the chip for the driver software, the register parameter is used to indicate the register storage address used in the chip, and the memory parameter is used to indicate the device memory allocation provided by the chip for the driver software.

[0183] In some embodiments, the second processing unit 1422 is configured to:

[0184] Establishing a register mapping relationship between a first register parameter corresponding to the first chip and a second register parameter corresponding to the second chip, wherein the register mapping relationship is used to indicate mapping a register storage address indicated by the second register parameter to a register storage address indicated by the first register parameter;

[0185] The first register parameter is deployed to the first hardware layer based on the register mapping relationship to obtain the second hardware layer, which is used to control the first chip based on the first chip identifier to provide register access resources for the first driver software according to the first register parameter.

[0186] In some embodiments, the second processing unit 1422 is configured to:

[0187] Establishing a memory mapping relationship between a first memory parameter corresponding to the first chip and a second memory parameter corresponding to the second chip, wherein the memory mapping relationship is used to indicate mapping the device memory allocation indicated by the second memory parameter to the device memory allocation indicated by the first memory parameter;

[0188] The first memory parameter is deployed to the first hardware layer based on the memory mapping relationship to obtain the second hardware layer, which is used to control the first chip based on the first chip identifier to provide memory allocation resources for the first driver software according to the first memory parameter.

[0189] In some embodiments, the second processing unit 1422 includes:

[0190] A first interrupt adaptation subunit 1401 is configured to adjust an interrupt quantity threshold in the first hardware layer based on the first chip identifier and the interrupt quantity indicated by the first interrupt parameter corresponding to the first chip;

[0191] The second interrupt adapter subunit 1402 is configured to establish, based on the interrupt quantity threshold, an interrupt mapping relationship between the first interrupt parameter and a second interrupt parameter corresponding to the second chip, wherein the interrupt mapping relationship indicates that the interrupt channel indicated by the second interrupt parameter is mapped to the interrupt channel indicated by the first interrupt parameter;

[0192] The third interrupt adapter unit 1403 is used to deploy the first interrupt parameter to the first hardware layer based on the interrupt mapping relationship to obtain the second hardware layer. The second hardware layer is used to apply for interrupt access according to the interrupt quantity threshold based on the first chip identifier, and process the interrupt access according to the interrupt channel indicated by the first interrupt parameter.

[0193] In some embodiments, the first interrupt adapter subunit 1401 is configured to:

[0194] determining a first interrupt quantity corresponding to the first chip based on the first interrupt parameter corresponding to the first chip, where the first interrupt quantity is used to indicate a threshold value of the number of interrupts that the first chip can support that is requested by the driver software;

[0195] determining a second interrupt quantity corresponding to the second chip based on the second interrupt parameter corresponding to the second chip, where the second interrupt quantity is used to indicate a threshold value of the number of interrupts that the second chip can support that is requested by the driver software;

[0196] In response to detecting that the chip category identifier is the first chip identifier, the interruption number threshold in the first hardware layer is adjusted to the first interruption number.

[0197] In some embodiments, the first interrupt parameter is used to indicate that the interrupt mechanism corresponding to the first chip adopts a mailbox interrupt, and the second interrupt parameter is used to indicate that the interrupt mechanism corresponding to the second chip includes at least one of a normal interrupt, a reset interrupt, a fault interrupt, and a direct memory access interrupt.

[0198] In some embodiments, the second hardware layer includes the first chip parameters and the second chip parameters; the apparatus further includes an operating module 1440 configured to:

[0199] When the first driver software is running, in response to detecting that the chip category identifier is the first chip identifier, controlling the first chip to provide the first hardware resource to the first driver software based on the first chip parameter; or

[0200] When the first driver software is running, in response to detecting that the chip category identifier is the second chip identifier, the second chip is controlled to provide the second hardware resource to the first driver software based on the second chip parameters.

[0201] In some embodiments, the testing module 1430 is configured to:

[0202] calling a preset test program to test the operation of the first driver software including the second hardware layer in the first chip, and obtaining the test result, wherein the test result includes at least one of a function test result, a performance test result, a stability test result, a fault tolerance test result, and a compatibility test result;

[0203] A test report interface is displayed based on the test results, wherein the test report interface includes at least one report element of the number of test cases, the running time of the test cases, and the success rate of the test cases.

[0204] In summary, the device provided in the embodiment of the present application deploys the first chip parameters to the first hardware layer based on the deployment position of the second chip parameters in the first hardware layer of the first driver software, so that the first driver software is adjusted from controlling the second chip to implement the first driver software based on the first hardware layer according to the second chip parameters to controlling the developed first chip to implement the first driver software based on the second hardware layer according to the first chip parameters. In this way, during the development process of the second chip, the first driver software can be run and tested in the first chip based on the second hardware layer, so that the operation status indicated by the obtained test results provides a reference for the operation of the first driver software in the second chip. That is, the first chip can be used instead of the second chip. By adjusting the chip deployment of the hardware layer in the driver software, the operation status of the first driver software on the first chip is simulated by the operation status of the first driver software on the second chip. In this way, during the development process of the second chip, the first driver software can be tested using the first chip synchronously with the development process of the first driver software, thereby reducing the design problems of the first driver software in the hardware and software joint debugging and verification after the development of the second chip and the first driver software is completed. At the same time, the simulation coverage of the actual operation scenario during the software testing process is improved, and the testing efficiency of the first driver software is improved.

[0205] It should be noted that the software testing device provided in the above embodiment is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0206] Figure 16 The following is a block diagram of a terminal 1600 according to an exemplary embodiment of the present application. Terminal 1600 may be a smartphone, tablet computer, MP3 player, MP4 player, laptop computer, or desktop computer. Terminal 1600 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other similar names.

[0207] Typically, the terminal 1600 includes a processor 1601 and a memory 1602 .

[0208] The processor 1601 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1601 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 1601 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 1601 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1601 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0209] Memory 1602 may include one or more computer-readable storage media, which may be non-transitory. Memory 1602 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in memory 1602 is used to store at least one instruction, which is executed by processor 1601 to implement the software testing method provided in the method embodiment of the present application.

[0210] In some embodiments, the terminal 1600 further includes other components, which can be understood by those skilled in the art. Figure 16 The structure shown in the figure does not constitute a limitation on the terminal 1600, and the terminal 1600 may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0211] The embodiment of the present application further provides a computer device, which can be implemented as follows: Figure 1 The terminal or server shown. The computer device includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, code set, or instruction set, and the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the software testing methods provided by the above-mentioned method embodiments.

[0212] An embodiment of the present application also provides a computer-readable storage medium, which stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement the software testing methods provided by the above-mentioned method embodiments.

[0213] Embodiments of the present application also provide a computer program product or computer program, which 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 software testing methods provided in the above-mentioned method embodiments.

[0214] Optionally, the computer-readable storage medium may include: Read Only Memory (ROM), Random Access Memory (RAM), Solid State Drives (SSD), or an optical disk. Among them, the random access memory may include resistance random access memory (ReRAM) and dynamic random access memory (DRAM). The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0215] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0216] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A software testing method, characterized in that: The method comprises: Obtaining first chip parameters and second chip parameters, where the first chip parameters are parameters of the first chip that has been developed, and the second chip parameters are parameters of a second chip to be developed, the second chip being used to implement a driving function of the first driver software after development is completed, the first chip parameters being used to indicate first hardware resources provided when the first chip runs the driver software, and the second chip parameters being used to indicate second hardware resources provided when the second chip runs the driver software; Deploying the first chip parameters to the first hardware layer based on the deployment location of the second chip parameters in the first hardware layer of the first driver software to obtain a second hardware layer, wherein the first hardware layer is used to control the second chip to implement the first driver software based on the second chip parameters, and the second hardware layer is used to control the first chip to implement the first driver software based on the first chip parameters; Based on the second hardware layer, the first driver software is run and tested in the first chip to obtain a test result, which is used to indicate the running status of the first driver software in the first chip, and the running status is used to provide a reference for the running of the first driver software in the second chip.

2. The method according to claim 1, characterized in that The method of deploying the first chip parameters to the first hardware layer based on the deployment location of the second chip parameters in the first hardware layer of the first driver software to obtain the second hardware layer includes: Based on the deployment location of the second chip identifier corresponding to the second chip in the first hardware layer, adding the first chip identifier corresponding to the first chip to the chip category identifier defined in the first hardware layer, the chip category identifier being used to indicate the chip category to which the first driver software is connected; Based on the first chip identifier, the first chip parameters are deployed into the first hardware layer according to the deployment location of the second chip parameters in the first hardware layer to obtain the second hardware layer. The second hardware layer is used to control the first chip based on the first chip identifier to provide the first hardware resources to the first driver software according to the first chip parameters.

3. The method according to claim 2, characterized in that The chip parameters include at least one of an interrupt parameter, a register parameter, and a memory parameter. The interrupt parameter is used to indicate the interrupt mechanism provided by the chip for the driver software. The register parameter is used to indicate the register storage address used in the chip. The memory parameter is used to indicate the device memory allocation provided by the chip for the driver software.

4. The method according to claim 3, characterized in that The step of deploying the first chip parameters to the first hardware layer based on the first chip identifier and according to the deployment location of the second chip parameters in the first hardware layer to obtain the second hardware layer includes: Establishing a register mapping relationship between a first register parameter corresponding to the first chip and a second register parameter corresponding to the second chip, wherein the register mapping relationship is used to indicate mapping a register storage address indicated by the second register parameter to a register storage address indicated by the first register parameter; The first register parameter is deployed to the first hardware layer based on the register mapping relationship to obtain the second hardware layer, which is used to control the first chip based on the first chip identifier to provide register access resources for the first driver software according to the first register parameter.

5. The method according to claim 3, characterized in that The step of deploying the first chip parameters to the first hardware layer based on the first chip identifier and according to the deployment location of the second chip parameters in the first hardware layer to obtain the second hardware layer includes: Establishing a memory mapping relationship between a first memory parameter corresponding to the first chip and a second memory parameter corresponding to the second chip, wherein the memory mapping relationship is used to indicate mapping the device memory allocation indicated by the second memory parameter to the device memory allocation indicated by the first memory parameter; The first memory parameter is deployed to the first hardware layer based on the memory mapping relationship to obtain the second hardware layer, which is used to control the first chip based on the first chip identifier to provide memory allocation resources for the first driver software according to the first memory parameter.

6. The method according to claim 3, characterized in that The step of deploying the first chip parameters to the first hardware layer based on the first chip identifier and according to the deployment location of the second chip parameters in the first hardware layer to obtain the second hardware layer includes: Adjusting an interrupt quantity threshold in the first hardware layer based on the first chip identifier and the interrupt quantity indicated by a first interrupt parameter corresponding to the first chip; Establishing an interrupt mapping relationship between the first interrupt parameter and a second interrupt parameter corresponding to the second chip based on the interrupt quantity threshold, wherein the interrupt mapping relationship is used to indicate that the interrupt channel indicated by the second interrupt parameter is mapped to the interrupt channel indicated by the first interrupt parameter; Based on the interrupt mapping relationship, the first interrupt parameter is deployed to the first hardware layer to obtain the second hardware layer, and the second hardware layer is used to apply for interrupt access according to the interrupt quantity threshold based on the first chip identifier, and process the interrupt access according to the interrupt channel indicated by the first interrupt parameter.

7. The method according to claim 6, characterized in that The adjusting the interruption number threshold in the first hardware layer based on the first chip identifier and the interruption number indicated by the first interruption parameter corresponding to the first chip includes: determining a first interrupt quantity corresponding to the first chip based on the first interrupt parameter corresponding to the first chip, where the first interrupt quantity is used to indicate a threshold value of the number of interrupts that the first chip can support that is requested by the driver software; determining a second interrupt quantity corresponding to the second chip based on the second interrupt parameter corresponding to the second chip, where the second interrupt quantity is used to indicate a threshold value of the number of interrupts that the second chip can support that is requested by the driver software; In response to detecting that the chip category identifier is the first chip identifier, the interruption number threshold in the first hardware layer is adjusted to the first interruption number.

8. The method according to claim 6, characterized in that The first interrupt parameter is used to indicate that the interrupt mechanism corresponding to the first chip adopts mailbox interrupt, and the second interrupt parameter is used to indicate that the interrupt mechanism corresponding to the second chip includes at least one of normal interrupt, reset interrupt, fault interrupt and direct memory access interrupt.

9. The method according to claim 2, characterized in that The second hardware layer includes the first chip parameters and the second chip parameters; The method further comprises: When the first driver software is running, in response to detecting that the chip category identifier is the first chip identifier, controlling the first chip to provide the first hardware resource to the first driver software based on the first chip parameter; or When the first driver software is running, in response to detecting that the chip category identifier is the second chip identifier, the second chip is controlled to provide the second hardware resource to the first driver software based on the second chip parameters.

10. The method according to any one of claims 1 to 9, characterized in that: The step of running and testing the first driver software in the first chip based on the second hardware layer to obtain a test result includes: calling a preset test program to test the operation of the first driver software including the second hardware layer in the first chip, and obtaining the test result, wherein the test result includes at least one of a function test result, a performance test result, a stability test result, a fault tolerance test result, and a compatibility test result; A test report interface is displayed based on the test results, wherein the test report interface includes at least one report element of the number of test cases, the running time of the test cases, and the success rate of the test cases.

11. A software testing device, characterized in that: The device comprises: an acquisition module, configured to acquire first chip parameters and second chip parameters, wherein the first chip parameters are parameters of a first chip that has been developed, and the second chip parameters are parameters of a second chip to be developed, wherein the second chip is configured to implement a driving function of the first driver software after development is completed, the first chip parameters are configured to indicate first hardware resources provided when the first chip runs the driver software, and the second chip parameters are configured to indicate second hardware resources provided when the second chip runs the driver software; a processing module configured to deploy the first chip parameters into the first hardware layer based on the deployment location of the second chip parameters in the first hardware layer of the first driver software, thereby obtaining a second hardware layer, wherein the first hardware layer is configured to control the second chip to implement the first driver software based on the second chip parameters, and the second hardware layer is configured to control the first chip to implement the first driver software based on the first chip parameters; A testing module is used to run and test the first driver software in the first chip based on the second hardware layer to obtain a test result, wherein the test result is used to indicate the running status of the first driver software in the first chip, and the running status is used to provide a reference for the running of the first driver software in the second chip.

12. A computer device, characterized in that: The computer device includes a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the software testing method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that The storage medium stores at least one computer program, and the at least one computer program is loaded and executed by a processor to implement the software testing method according to any one of claims 1 to 10.

14. A computer program product, characterized in that The invention comprises a computer program, which implements the software testing method according to any one of claims 1 to 10 when executed by a processor.

Images