Test methods and test platforms

Abstract

The present application relates to the field of simulation test technology, and provides a test method and a test platform. The test platform includes a software driver module, a software and hardware interface module, a hardware module to be tested, and a storage model. The software driver module is connected to the hardware module to be tested and the storage model respectively through the software and hardware interface module. The software driver module writes the target test parameters into the hardware module to be tested through the software and hardware interface module, and the software driver module loads the data to be tested into the storage model through the software and hardware interface module; the hardware module to be tested reads the data to be tested from the storage model, and tests the data to be tested based on the target test parameters, so that the software driver module obtains the hardware test output through the software and hardware interface module. The use of the above-mentioned test platform and test method eliminates the intermediate step of the incentive file, simplifies the operation process, and simplifies the development and maintenance workload of the test environment.

Description

Technical Field

[0001] The present application relates to the field of simulation testing technology, and in particular to a testing method and a testing platform. Background Art

[0002] An algorithmic hardware module refers to a module that implements specific algorithmic functions in hardware. It implements specific computing tasks or data processing functions through hardware circuits and is usually used to improve processing speed and efficiency, such as video encoding hardware modules, video decoding hardware modules, and image processing hardware modules.

[0003] In order to ensure the functionality and performance of algorithmic hardware modules, simulation testing is an essential step. During simulation testing, a test stimulus file is currently generated through the algorithm's software model. The simulation environment reads the test requirement data from the generated test stimulus file, sends it to the hardware module to be tested, and collects the test results. However, the above method is cumbersome and requires generating a test stimulus file before simulation can be performed. In addition, both generating and reading test requirement data require additional code development. Summary of the invention

[0004] Based on this, it is necessary to provide a testing method and testing platform that can simplify the operating steps and testing environment to address the above technical problems.

[0005] In a first aspect, the present application provides a testing method, which is applied to a testing platform, the testing platform comprising a software driver module, a software and hardware interface module, a hardware module to be tested and a storage model, the software driver module is respectively connected to the hardware module to be tested and the storage model through the software and hardware interface module, and the hardware module to be tested is connected to the storage model; the method comprises:

[0006] The software driver module writes the target test parameters into the hardware module to be tested through the software and hardware interface module;

[0007] The software driver module loads the data to be tested into the storage model through the software and hardware interface module;

[0008] The hardware module to be tested reads the data to be tested from the storage model and tests the data to be tested based on the target test parameters, so that the software driver module obtains hardware test output through the software and hardware interface module; the hardware test output is used to compare with the reference output to generate a test result.

[0009] In one embodiment, the method further comprises:

[0010] The software driver module obtains the initial test parameters and the data to be tested from the configuration file corresponding to the target test case, and divides the data to be tested according to a preset division method to obtain a plurality of sub-data to be tested;

[0011] The software driver module determines the target test sub-parameter corresponding to the sub-data to be tested based on the initial test parameter, loads the sub-data to be tested into the storage model, and writes the target test sub-parameter into the hardware module to be tested;

[0012] The hardware module to be tested reads the sub-data to be tested from the storage model, and tests the sub-data to be tested based on the target test sub-parameter, so that the software driver module obtains the hardware test sub-output through the software and hardware interface module;

[0013] For the plurality of sub-data to be tested, the software driver module repeats the above process of obtaining the hardware test sub-output to obtain the hardware test output.

[0014] In one embodiment, before loading the sub-data to be tested into the storage model and writing the target test sub-parameters into the hardware module to be tested, the method includes:

[0015] The software driving module allocates a first address in the storage model, where the first address is used to store the sub-data to be tested;

[0016] The software driving module loads the sub-data to be tested to the first address in the storage model.

[0017] In one embodiment, the hardware module to be tested tests the sub-data to be tested based on the target test sub-parameters, so that the software driver module obtains the hardware test sub-output through the software and hardware interface module, including:

[0018] The hardware module to be tested tests the sub-data to be tested based on the target test sub-parameters, obtains the hardware test sub-output, and stores the hardware test sub-output at a second address in the storage model; the second address is pre-allocated to the storage model by the software driver module;

[0019] The software driver module obtains the hardware test sub-output from the second address through the software and hardware interface module.

[0020] In one embodiment, the software driver module obtains the hardware test sub-output from the second address through the software and hardware interface module, including:

[0021] The software driver module obtains the test status of the status register in the hardware module to be tested through the software and hardware interface module;

[0022] When the test status indicates that the test of the current sub-data to be tested is completed, the software driver module obtains the hardware test sub-output from the second address through the software-hardware interface module.

[0023] In one embodiment, the test platform further includes a monitoring module, which is connected to the hardware module to be tested and the storage model respectively; the method further includes:

[0024] The monitoring module obtains the state change information of the interface or internal key nodes of the hardware module to be tested;

[0025] The monitoring module obtains data change information in the storage model;

[0026] The state change information and the data change information are used to assist in debugging the test platform, and the assist in debugging includes performance statistics, storing and loading error point data, and accelerating simulation verification.

[0027] In a second aspect, the present application also provides a testing method. The method comprises:

[0028] Obtaining hardware test output of a target test case by using a test platform using the test method provided in the first aspect of the present application;

[0029] Obtaining a reference output of the target test case through the reference software corresponding to the hardware module to be tested;

[0030] A test result is generated based on a comparison result of the hardware test output and the reference output.

[0031] In a third aspect, the present application further provides a test platform, which includes a software driver module, a software and hardware interface module, a hardware module to be tested, and a storage model, wherein the software driver module is connected to the hardware module to be tested and the storage model respectively through the software and hardware interface module, and the hardware module to be tested is connected to the storage model;

[0032] The software driver module is used to write the target test parameters into the hardware module to be tested through the software and hardware interface module; and to load the data to be tested into the storage model through the software and hardware interface module;

[0033] The hardware module to be tested is used to read the data to be tested from the storage model and test the data to be tested based on the target test parameters, so that the software driver module obtains the hardware test output through the software and hardware interface module; the hardware test output is used to compare with the reference output to generate a test result.

[0034] In a fourth aspect, the present application further provides a computer device. The computer device includes a memory and a processor, and the processor is used to execute instructions stored in the memory so that the computer device performs the steps of the test method provided in the first aspect of the present application, or the steps of the test method provided in the second aspect of the present application.

[0035] In a fifth aspect, the present application further provides a computer-readable storage medium, on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the steps of the test method provided in the first aspect of the present application or the steps of the test method provided in the second aspect of the present application are implemented.

[0036] The above-mentioned test method and test platform, the test platform includes a software driver module, a software and hardware interface module, a hardware module to be tested and a storage model, the software driver module is respectively connected to the hardware module to be tested and the storage model through the software and hardware interface module, the software driver module writes the target test parameters into the hardware module to be tested through the software and hardware interface module, and the software driver module loads the data to be tested into the storage model through the software and hardware interface module; the hardware module to be tested reads the data to be tested from the storage model, and tests the data to be tested based on the target test parameters, so that the software driver module obtains the hardware test output through the software and hardware interface module. In this application, through the software and hardware interface module, the software driver module can directly control the hardware module to be tested, such as configuring parameters, issuing commands, observing status, loading / obtaining data to be tested, eliminating the intermediate steps of the incentive file, simplifying the operation process, and simplifying the development and maintenance workload of the test environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 An application environment diagram of a test method in an embodiment;

[0038] Figure 2 A schematic diagram of a test method in one embodiment;

[0039] Figure 3 A schematic flow chart of a testing method in another embodiment;

[0040] Figure 4 A schematic flow chart of a testing method in another embodiment;

[0041] Figure 5 A schematic flow chart of a testing method in another embodiment;

[0042] Figure 6 A structural block diagram of a test platform in an embodiment;

[0043] Figure 7 A schematic flow chart of a testing method in another embodiment;

[0044] Figure 8 A schematic diagram of a test method in one embodiment;

[0045] Fig. 9 A schematic diagram of batch concurrent testing in one embodiment;

[0046] Fig.10FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] Algorithmic hardware modules usually adopt a software-hardware collaborative design approach. The software part is usually implemented in C language to be responsible for the main control logic and high-level functional control, and the hardware part is implemented in hardware description languages ​​such as Verilog / VHDL to be responsible for implementing the core algorithm part with large computational workload. The algorithm model can be implemented in C or C++ language as a standard reference model to verify the correctness of the hardware design. The simulation environment can be implemented in Verilog / System Verilog language to simulate and verify the hardware design.

[0049] Code needs to be added to the algorithm model to implement the export of test stimuli, including hardware control commands, data, and expected results, etc., which are written into files in a certain format. The simulation environment reads the stimulus file, parses the commands and data in the agreed format, drives the hardware module to be tested to start simulation, detects the status and output of the hardware module to be tested, and exports the hardware test output to write files for comparison with the reference output of the algorithm model. The generation and reading of stimulus files require additional code to implement, and the development and operation steps are cumbersome. If the design is changed, the content and format of the stimulus file also need to be adjusted accordingly, which is troublesome to maintain.

[0050] The test method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown. Among them, the test platform is deployed with a software driver module, a software and hardware interface module, a hardware module to be tested and a storage model. The software driver module is connected to the hardware module to be tested and the storage model respectively through the software and hardware interface module, and the hardware module to be tested is connected to the storage model. The software and hardware interface module is used to realize direct access between the software driver module and the hardware module to be tested. For example, the software driver module can read / write the registers of the hardware module to be tested, configure hardware parameters, issue control commands and detect its hardware status through the software and hardware interface module. The software driver module can also read / write the storage model through the software and hardware interface module to load the data to be tested, export the hardware test output, etc.

[0051] Among them, the software driver module can be implemented in C language or C++ language, the software and hardware interface module can be implemented in System Verilog language, the hardware module to be tested can be implemented in Verilog language, and the storage model can be implemented in System Verilog language.

[0052] In one embodiment, Figure 2 As shown, a test method is provided, which is applied to Figure 1 The test platform in is used as an example to illustrate, including the following steps:

[0053] Step 202: The software driver module writes the target test parameters into the hardware module to be tested through the software and hardware interface module.

[0054] The target test parameters refer to the test parameters required for testing the hardware module under test.

[0055] The software and hardware interface module of the embodiment of the present application is used to bridge the software driver and the hardware design, so that the software driver module can directly interact with the hardware to be tested and the storage model, thereby achieving more efficient testing and debugging. For example, the software and hardware interface module can use DPI (Direct Programming Interface), which is an interface that directly connects SystemVerilog with an external language. In this way, the software driver module and the hardware to be tested, and the software driver module and the storage model can directly transmit data through the DPI interface.

[0056] Among them, DPI consists of two layers: SystemVerilog layer and external language layer. The two layers are isolated from each other. The actual programming language used as the external language layer has nothing to do with the SystemVerilog end. In the embodiment of the present application, the external language layer of DPI can use C language or C++ language for implementing the software driver module.

[0057] Exemplarily, the target test parameters include target configuration parameters and target control parameters, and the software driver module writes the target configuration parameters and target control parameters into the control register of the hardware module to be tested through DPI. The target control parameters are used to control the working state and behavior of the hardware module to be tested, such as starting or controlling specific operations of the test process, resetting, pausing, interrupting or continuing the test process. The target configuration parameters are used to configure the test mode of the data to be tested, the data type of the data to be tested and other related information, specify the storage address of the input / output data, etc.

[0058] Step 204: The software driver module loads the data to be tested into the storage model through the software and hardware interface module.

[0059] Among them, the storage model can adopt the DDR (Double Data Rate) model. The DDR model is a model for simulating and modeling the behavior of DDR memory in hardware design and verification. DDR memory is a memory technology that can transmit data on both the rising and falling edges of the clock signal. Compared with the traditional single data rate (SDR) memory, it has a higher transmission rate. The DDR model has a commonly used bus interface, such as AXI, which can be directly connected to the bus interface of the hardware module to be tested.

[0060] Exemplarily, the software driver module loads the data to be tested into the DDR model through DPI.

[0061] Step 206 , the data to be tested is read from the storage model of the hardware module to be tested, and the data to be tested is tested based on the target test parameters, so that the software driver module obtains the hardware test output through the software and hardware interface module.

[0062] The hardware test output is used to compare the reference output to generate the test result.

[0063] Exemplarily, the software driver module may write the control command for starting the test in the target control parameter into the control register of the hardware module under test through the DPI interface. When the hardware module under test monitors the control command for starting the test in the control register, it starts to execute the test operation.

[0064] Specifically, the hardware module to be tested obtains the data to be tested from the specified address of the DDR model based on the storage address of the input / output data specified in the target configuration parameters, and tests the data to be tested based on the target configuration parameters and the target control parameters to generate hardware test output. The hardware module to be tested writes the hardware test output to the corresponding specified address of the DDR model based on the storage address of the input / output data specified in the target configuration parameters. The software driver module obtains the hardware test output from the DDR model through DPI.

[0065] In the above test method, the test platform includes a software driver module, a software and hardware interface module, a hardware module to be tested and a storage model. The software driver module is connected to the hardware module to be tested and the storage model respectively through the software and hardware interface module. The software driver module writes the target test parameters into the hardware module to be tested through the software and hardware interface module, and the software driver module loads the data to be tested into the storage model through the software and hardware interface module; the hardware module to be tested reads the data to be tested from the storage model, and tests the data to be tested based on the target test parameters, so that the software driver module obtains the hardware test output through the software and hardware interface module. In the embodiment of the present application, through the software and hardware interface module, the software driver module can directly control the hardware module to be tested, such as configuring parameters, issuing commands, observing status, loading / obtaining data to be tested, eliminating the intermediate step of the incentive file, simplifying the operation process, and simplifying the development and maintenance workload of the test environment.

[0066] The following uses the hardware module to be tested for video encoding or video decoding as an example to specifically describe the testing method of the embodiment of the present application.

[0067] In one embodiment, Figure 3 As shown, the test method includes:

[0068] Step 302: the software driver module obtains initial test parameters and data to be tested from a configuration file corresponding to the target test case, and divides the data to be tested according to a preset division method to obtain a plurality of sub-data to be tested.

[0069] Exemplarily, for the coding test, the software driver module obtains the initial test parameters and the data to be tested from the configuration file corresponding to the target test case, the data to be tested includes multiple frames of yuv data in the yuv image sequence file to be encoded, and the initial test parameters include image resolution (width, height), key frame (I frame) interval, number of frames, key frame (I frame), prediction frame (P frame) quantization coefficients, etc. The software driver module reads the yuv image sequence file, and divides the multiple frames of yuv data into multiple frames of data to be encoded, and obtains multiple sub-data to be tested.

[0070] Step 304 , the software driver module determines the target test sub-parameters corresponding to the sub-data to be tested based on the initial test parameters, loads the sub-data to be tested into the storage model, and writes the target test sub-parameters into the hardware module to be tested.

[0071] Exemplarily, the software driver module determines the current frame data to be encoded from multiple frame data to be encoded as the current sub-data to be tested, and loads the current frame data to be encoded into the DDR model through DPI. The software driver module determines the target test sub-parameters corresponding to the sub-data to be tested based on the initial test parameters, for example, the type (I or P) of the current frame data to be encoded is calculated based on the initial test parameters, and the quantization coefficients of the current frame data to be encoded are converted and mapped based on the initial test parameters, etc. The target test sub-parameters include the type of the current frame data to be encoded, the quantization coefficients after conversion and mapping, the resolution and encoding mode of the current frame to be encoded, etc. The above target test sub-parameters are written into the register of the hardware module to be tested through DPI.

[0072] Step 306 , the hardware module to be tested reads the sub-data to be tested from the storage model, and tests the sub-data to be tested based on the target test sub-parameters, so that the software driver module obtains the hardware test sub-output through the software and hardware interface module.

[0073] Exemplarily, the software driver module writes the start encoding control command of the current frame data to be encoded into the control register of the hardware module to be tested through DPI. After the hardware module to be tested detects the start encoding control command, it reads the current frame data to be encoded from the DDR model based on the target test sub-parameters, starts a frame encoding, and generates a code stream corresponding to the current frame data to be encoded as the hardware test sub-output.

[0074] In addition, the software driver module can also generate frame header data corresponding to the current frame data to be encoded according to the target test sub-parameters. After the software driver module reads the code stream corresponding to the current frame data to be encoded through DPI, the code stream corresponding to the current frame data to be encoded and the frame header data corresponding to the current frame data to be encoded are combined into a complete frame data.

[0075] Step 308: for multiple sub-data to be tested, the software driver module repeats the above process of obtaining the hardware test sub-output to obtain the hardware test output.

[0076] Exemplarily, the software driver module repeats the process of writing the target sub-data to be tested of each frame of multiple frame data to be encoded into the hardware module to be tested, and loading each frame of frame data to be encoded into the DDR model. The hardware module to be tested repeats the encoding process of each frame of frame data to be encoded until the specified number of frames are encoded. The software driver module repeats the above process of obtaining the hardware test sub-output, and obtains the hardware test output by repeatedly combining into a complete multi-frame data.

[0077] In one embodiment, Figure 4 As shown, before loading the sub-data to be tested into the storage model and writing the target test sub-parameters into the hardware module to be tested, the process includes:

[0078] Step 402: The software driver module allocates a first address in the storage model, where the first address is used to store the sub-data to be tested.

[0079] Step 404: the software driver module loads the sub-data to be tested to the first address in the storage model.

[0080] Exemplarily, the software driver module allocates the first address of the current frame data to be encoded in the DDR model, and writes the current frame data to be encoded to the first address in the DDR model through DPI. The software driver module can also use the first address in the DDR model as the target test sub-parameter corresponding to the current frame data to be encoded, and write it into the register of the hardware module to be tested through DPI, so that the hardware module to be tested can read the current frame data to be encoded from the first address in the DDR model when receiving the control command to start encoding.

[0081] In one embodiment, Figure 5 As shown, the hardware module to be tested tests the sub-data to be tested based on the target test sub-parameters, so that the software driver module obtains the hardware test sub-output through the software and hardware interface module, including:

[0082] Step 502, the hardware module to be tested tests the sub-data to be tested based on the target test sub-parameters, obtains the hardware test sub-output, and stores the hardware test sub-output at the second address in the storage model; the second address is pre-allocated to the storage model by the software driver module.

[0083] Step 504: the software driver module obtains the hardware test sub-output from the second address through the software and hardware interface module.

[0084] In the embodiment of the present application, before loading the sub-data to be tested into the storage model and writing the target test sub-parameter into the hardware module to be tested, the software driver module allocates a second address in the storage model, and the second address is used to store the hardware test sub-output. The hardware module to be tested tests the sub-data to be tested based on the target test sub-parameter, obtains the hardware test sub-output, and stores the hardware test sub-output at the second address in the storage model. The software driver module obtains the hardware test sub-output from the second address through the software and hardware interface module.

[0085] Exemplarily, the software driver module allocates the second address of the encoded code stream corresponding to the current frame data to be encoded in the DDR model, and the software driver module writes the second address as the target test sub-parameter into the register of the hardware module to be tested through DPI. After the hardware module to be tested completes encoding the current frame data to be encoded and obtains the code stream corresponding to the current frame data to be encoded, the code stream corresponding to the current frame data to be encoded is stored in the second address in the DDR model, and the software driver module reads the code stream corresponding to the current frame data to be encoded from the second address in the DDR model through DPI.

[0086] In an optional implementation, the software driver module obtains the test status of the status register in the hardware module to be tested through the software and hardware interface module; when the test status indicates that the test of the current sub-data to be tested is completed, the software driver module obtains the hardware test sub-output from the second address through the software and hardware interface module.

[0087] Exemplarily, when the encoding of the hardware module to be tested is completed, the hardware module to be tested updates the status register to indicate that the current encoding has been completed. The software driver module monitors the status register of the hardware module to be tested through DPI to determine the progress and completion of the encoding process. For example, the software driver module continuously queries the status register of the hardware module to be tested through DPI, and when it is found that the encoding of the current frame is completed, the encoded code stream is read from the second address in the DDR model through DPI, and combined with the frame header data formed previously into a complete frame of data.

[0088] In one embodiment, Figure 6 As shown, the test platform also includes a monitoring module, which is connected to the hardware module to be tested and the storage model respectively; the test method also includes the following steps: Figure 7 Steps shown:

[0089] Step 702: The monitoring module obtains status change information of the interface or internal key nodes of the hardware module to be tested.

[0090] Step 704: The monitoring module obtains data change information in the storage model.

[0091] The state change information and the data change information are used to assist in debugging the test platform.

[0092] In an embodiment of the present application, the test platform may further include a monitoring module, which serves as an observation point for observing the interface and internal key node information of the hardware module to be tested, as well as the data in the DDR model, to assist debugging.

[0093] In one embodiment, the monitoring module can directly observe the interface and internal signals of the hardware module to be tested, including the interface signals of the internal sub-modules, key node control signals and data signals, and check the correctness of the above signals.

[0094] Among them, the interface signal of the internal submodule is used to indicate the communication channel between different submodules inside the hardware module to be tested. The interface signal of the internal submodule may include an input signal, i.e., a signal received by the submodule from other submodules, an output signal, i.e., a signal that the submodule sends the processing result to other submodules, and a handshake signal, i.e., a signal for coordinating the operation between submodules. The key point control signal is used to indicate the signal for controlling the execution of a specific function inside the hardware module to be tested. The key point control signal may include a clock signal, i.e., a signal for driving the timing of the submodule, a reset signal, i.e., a signal for initializing the module state, an enable signal, i.e., a signal for controlling whether a specific function is activated, etc. The data signal is used to indicate the signal that carries the actual data content, for example, it may include a data bus signal, i.e., a signal that transmits a numerical value or data inside the hardware module to be tested, a status signal, i.e., a signal that reflects the current data processing status information (such as a signal including an error flag or a completion flag), etc.

[0095] In an optional embodiment, the monitoring module can determine whether the timing of the key point control signal complies with predetermined rules, whether the value of the data signal is within a predetermined range, etc. If incorrect, a prompt message is printed and the error data is written to a file to assist in error troubleshooting and positioning.

[0096] For example, inside the hardware module to be tested, a set of control signal timing rules are preset, including the rising edge, falling edge and time interval between signals. The monitoring module can capture the timing waveform of the key point control signal and compare it with the preset timing rules. Through time measurement and logic analysis, it is determined whether the timing of the key point control signal meets the preset timing rules. For example, if the rising edge delay of a control signal exceeds the set delay tolerance, it is considered that the timing is incorrect. If a situation that does not comply with the timing rules is detected, the system will generate a prompt message, record the actual timing data of the control signal, and write it into the error log file for subsequent analysis and troubleshooting.

[0097] For another example, for the data signal in the hardware module to be tested, a preset valid range is set, including the minimum and maximum values ​​of the signal. The monitoring module can monitor the value of the data signal in real time and compare it with the preset valid range. If the value of the data signal exceeds the preset valid range, the system will trigger the error handling mechanism, generate a prompt message, record the data signal value that exceeds the range, and write it to the error log file to assist developers in locating the problem.

[0098] For another example, the monitoring module can write all detected error information into a log file in a standard format, including detailed information such as timestamp, signal name, actual value, and predetermined rules. In addition, the system can classify errors according to set conditions to quickly locate and fix problems during subsequent analysis.

[0099] In an optional implementation, when the problem is found and the design is modified and re-simulated and verified, it may take a long time to reach the error point due to the slow simulation. To solve this problem, the monitoring module can also write the data before the error (including the data inside the hardware module to be tested and the DDR model) into a file. After modifying the design, the data can be directly loaded into the hardware module to be tested and the DDR model when re-running the simulation, and the simulation can be started directly from the vicinity of the error point to speed up the verification iteration. When the initial verification is correct, run the complete simulation from the beginning.

[0100] For example, when the monitoring module detects inconsistent or erroneous data in the hardware module to be tested or the DDR model, the error capture mechanism will be activated immediately. Before the error point, the monitoring module can record the internal signals of the hardware module to be tested, the interface signals, and the data content in the DDR model, including but not limited to the current register state, data bus content, control signal value, etc. The monitoring module saves all captured status information or data to a file in a predetermined format to ensure that the state before the error can be accurately restored in subsequent operations. Before re-simulation, the system provides a loading mechanism that can directly import previously captured data into the corresponding positions of the hardware module to be tested and the DDR model. By loading these data, the hardware module to be tested and the DDR model will be restored to a state near the error point, thereby avoiding the time required to simulate from the beginning.

[0101] In an optional implementation, the monitoring module can also collect statistics on the performance of the hardware module under test, record the number of cycles of specific operations of the hardware module and sub-modules under test, etc., so that the bottleneck of computing performance can be analyzed based on the data, and the design can be further improved to enhance performance.

[0102] For example, in the design of the hardware module to be tested, the monitoring module is configured to monitor the number of execution cycles and related performance indicators of a specific operation. The monitoring module can identify and capture event signals related to the specific operation of the hardware module to be tested, such as operation start signal, operation end signal and intermediate state signal. When the hardware module to be tested performs a specific operation, the monitoring module records the start and end time of each operation in real time, calculates the corresponding number of cycles, and counts the actual execution time, number of cycles, and related control signal status of each operation, all of which are saved in a performance log in a standard format. The monitoring module can summarize data regularly as needed and identify bottlenecks in the operation process, such as whether operations with high cycle numbers are related to specific sub-module designs, whether the utilization rate of processor resources has reached a bottleneck point, and whether data transmission delays affect the overall operation efficiency.

[0103] In an optional implementation, the monitoring module can directly observe the data in the DDR model and check the correctness of the data.

[0104] For example, the monitoring module is configured to access the data content of all key address locations in the DDR model, which may include a first address and a second address, and monitor the data transmission process in real time. During the simulation initialization phase, the monitoring module will set the specific address range, data type and expected data format to be monitored to ensure that it covers all possible valid data areas. For each data read, the monitoring module reads the data information of the specified address in the DDR model in real time, and verifies it with the preset standards to ensure that the data is within the specified range and conforms to the expected format, such as the numerical range, bit width, data type, etc. When the monitoring module finds that the data does not meet the predetermined standards, it can immediately trigger the error handling mechanism to record relevant error information, including timestamp, actual read data value, expected data value and accessed address.

[0105] In one embodiment, taking decoding test as an example, the data to be tested includes a code stream file to be decoded, and the initial test parameters include the number of frames to be tested, etc. The software driver module reads in the data to be tested and the initial test parameters, and after dividing the code stream to be decoded, the first address of the code stream of the current frame in the DDR model and the second address of the decoded yuv in the DDR model are allocated. The software driver module reads in the code stream file and loads the current frame code stream to the first address allocated by DDR through DPI. The software driver module parses the header data of the current frame code stream, parses out information such as resolution, frame type (I or P), quantization coefficient, etc., and writes this information and the allocated code stream address, i.e., the first address, and the yuv address, i.e., the second address, into the register of the hardware module to be tested through DPI. The control register is written by DPI to start a frame decoding. Then, the status register of the module to be tested is continuously queried through DPI. When the decoding is completed, the decoded yuv data is read out from the allocated second address in the DDR model through DPI and written into the file. Repeat the above decoding process for each frame until the specified number of frames are decoded.

[0106] Based on the same inventive concept, the embodiment of the present application further provides a test method. The implementation scheme for solving the problem provided by the test method is similar to the implementation scheme recorded in the test method provided in the first aspect of the embodiment of the present application, so the specific limitations in one or more test method embodiments provided below can refer to the limitations on the test method above, and will not be repeated here.

[0107] In one embodiment, Figure 8 As shown, the test method includes: obtaining the hardware test output of the target test case through the test platform using the test method provided in the first aspect of the embodiment of the present application; obtaining the reference output of the target test case through the reference software corresponding to the hardware module to be tested; and generating the test result based on the comparison result between the hardware test output and the reference output.

[0108] The test method of the embodiment of the present application can be applied to a computer device, which can call the test platform to perform a test operation, or call the reference software to perform a reference output operation. The computer device of the embodiment of the present application can adopt an automatic comparison mechanism, which is generally implemented with a script, such as bash, python, etc. For each test case, the computer device calls the reference software through a script to generate a reference output; at the same time, the above-mentioned test platform is called for testing to obtain the hardware test output, and the hardware test output and the reference output are compared. If they are consistent, the information of the test passing is given, and if they are inconsistent, the information of the test failing is given.

[0109] In this embodiment, an automatic comparison mechanism is used to automatically compare the reference results and the hardware results, and provide information on whether the test is passed or failed, thereby improving the test efficiency.

[0110] In one embodiment, Fig. 9 As shown, the computer device of the embodiment of the present application can also adopt batch concurrent testing, which is generally implemented by scripts. The parameters of all items to be tested and the data to be tested are summarized in a parameter file. The computer device obtains the parameter file and calls the script to parse the parameter file to generate the running directory and configuration file for each test item. Figure 8 The method shown in the figure starts a test instance for each test item and compares the results. All test instances are run in parallel. After completion, the results of all test items are summarized.

[0111] The parameter file can be in the form of a table, where each row corresponds to a test item or a test item group, and each column corresponds to a parameter. If one of the parameters represents a range, the row represents a test item group, and the range is expanded into all possible parameter values ​​during parsing to form corresponding multiple test items.

[0112] In this embodiment, batch concurrent testing is adopted, and by parsing parameter files, automatic generation and parallel testing of all test items and statistical aggregation of results are achieved to improve test efficiency.

[0113] In one embodiment, the computer device of the embodiment of the present application can also use a scrambling test. On the basis of the common test items, a scrambling test is added to randomly scramble the input data to be tested, for example, replace the data of random length with random numbers at random positions of the data to be tested, observe whether the hardware module to be tested can detect errors, and whether the operation is abnormal, so as to test the robustness of the hardware module to be tested, and make corresponding improvements to the test results.

[0114] In this embodiment, a random scrambling test is adopted to test the robustness of the hardware module to be tested.

[0115] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0116] Based on the same inventive concept, the embodiment of the present application also provides a test platform for implementing the test method involved above. The implementation scheme for solving the problem provided by the test platform is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more test platform embodiments provided below can refer to the limitations on the test method above, and will not be repeated here.

[0117] In one embodiment, a test platform is provided. Please refer to Figure 1 The test platform includes a software driver module, a software and hardware interface module, a hardware module to be tested and a storage model. The software driver module is connected to the hardware module to be tested and the storage model respectively through the software and hardware interface module, and the hardware module to be tested is connected to the storage model.

[0118] The software driver module is used to write the target test parameters into the hardware module to be tested through the software and hardware interface module; and to load the data to be tested into the storage model through the software and hardware interface module.

[0119] The hardware module to be tested is used to read the data to be tested from the storage model and test the data to be tested based on the target test parameters, so that the software driver module obtains the hardware test output through the software and hardware interface module; the hardware test output is used to compare with the reference output to generate a test result.

[0120] Each module in the above test platform can be implemented in whole or in part by software, hardware and their combination. Each module can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each module above.

[0121] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.10As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a test method is implemented.

[0122] Those skilled in the art will understand that Fig.10 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0123] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0124] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0125] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0126] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0127] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0128] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A testing method, characterized in that: The method is applied to a test platform, the test platform includes a software driver module, a software and hardware interface module, a hardware module to be tested and a storage model, the software driver module is connected to the hardware module to be tested and the storage model respectively through the software and hardware interface module, and the hardware module to be tested is connected to the storage model; the method includes: The software driver module writes the target test parameters into the hardware module to be tested through the software and hardware interface module; The software driver module loads the data to be tested into the storage model through the software and hardware interface module; The hardware module to be tested reads the data to be tested from the storage model, and tests the data to be tested based on the target test parameters, so that the software driver module obtains hardware test output through the software and hardware interface module; the hardware test output is used to compare with the reference output to generate a test result; The method further comprises: The software driving module obtains the initial test parameters and the data to be tested from the configuration file corresponding to the target test case, and divides the data to be tested according to a preset division method to obtain a plurality of sub-data to be tested; The software driver module determines the target test sub-parameter corresponding to the sub-data to be tested based on the initial test parameter, loads the sub-data to be tested into the storage model, and writes the target test sub-parameter into the hardware module to be tested; The hardware module to be tested reads the sub-data to be tested from the storage model, and tests the sub-data to be tested based on the target test sub-parameter, so that the software driver module obtains the hardware test sub-output through the software and hardware interface module; For the plurality of sub-data to be tested, the software driver module repeats the above process of obtaining the hardware test sub-output to obtain the hardware test output; The hardware module to be tested tests the sub-data to be tested based on the target test sub-parameters so that the software driver module obtains the hardware test sub-output through the software and hardware interface module, including: The hardware module to be tested tests the sub-data to be tested based on the target test sub-parameter, obtains a hardware test sub-output, and stores the hardware test sub-output at a second address in the storage model; the second address is pre-allocated by the software driver module to the storage model; The software driver module obtains the hardware test sub-output from the second address through the software and hardware interface module; The storage model adopts a DDR model; the test platform also includes a monitoring module, and the monitoring module is connected to the storage model; the method also includes: The monitoring module accesses the data content of the key address position in the DDR model and monitors the data transmission process in real time, wherein the key address position includes the second address; For each data read, the monitoring module reads the data information of the specified address in the DDR model in real time, and verifies the data information with a preset standard; the preset standard includes a preset value range, a preset bit width and a preset data type; When the monitoring module finds that the data does not meet the preset standard, an error handling mechanism is triggered, and the error handling mechanism is used to indicate and record related error information, and the error information includes a timestamp, an actual read data value, an expected data value, and an accessed address.

2. The method according to claim 1, characterized in that Before the sub-data to be tested is loaded into the storage model and the target test sub-parameter is written into the hardware module to be tested, the method includes: The software driver module allocates a first address in the storage model, where the first address is used to store the sub-data to be tested; The software driving module loads the sub-data to be tested to the first address in the storage model.

3. The method according to claim 1, characterized in that The software driver module obtains the hardware test sub-output from the second address through the software and hardware interface module, including: The software driver module obtains the test status of the status register in the hardware module to be tested through the software and hardware interface module; When the test status indicates that the test of the current sub-data to be tested is completed, the software driver module obtains the hardware test sub-output from the second address through the software and hardware interface module.

4. The method according to any one of claims 1 to 3, characterized in that The monitoring module is connected to the hardware module to be tested; the method further comprises: The monitoring module obtains the status change information of the interface or internal key nodes of the hardware module to be tested; The monitoring module obtains data change information in the storage model; The state change information and the data change information are used to assist in debugging the test platform, and the assist in debugging includes performance statistics, storing and loading error point data, and accelerating simulation verification.

5. A testing method, characterized in that: The method comprises: Obtaining hardware test output of a target test case by using a test platform according to a method as described in any one of claims 1 to 4; Obtaining a reference output of the target test case through reference software corresponding to the hardware module to be tested; A test result is generated based on a comparison result of the hardware test output and the reference output.

6. A test platform, characterized in that: The test platform includes a software driver module, a software and hardware interface module, a hardware module to be tested and a storage model, wherein the software driver module is connected to the hardware module to be tested and the storage model respectively through the software and hardware interface module, and the hardware module to be tested is connected to the storage model; The software driver module is used to write the target test parameters into the hardware module to be tested through the software and hardware interface module; and load the data to be tested into the storage model through the software and hardware interface module; The hardware module to be tested is used to read the data to be tested from the storage model and test the data to be tested based on the target test parameters, so that the software driver module obtains hardware test output through the software and hardware interface module; the hardware test output is used to compare with the reference output to generate a test result; The software driver module is further used to obtain initial test parameters and the data to be tested from a configuration file corresponding to a target test case, and divide the data to be tested according to a preset division method to obtain a plurality of sub-data to be tested; The software driver module is further used to determine the target test sub-parameters corresponding to the sub-data to be tested based on the initial test parameters, load the sub-data to be tested into the storage model, and write the target test sub-parameters into the hardware module to be tested; The hardware module to be tested is further used to read the sub-data to be tested from the storage model, and test the sub-data to be tested based on the target test sub-parameters, so that the software driver module obtains the hardware test sub-output through the software and hardware interface module; For the plurality of sub-data to be tested, the software driver module is further used to repeat the above process of obtaining the hardware test sub-output to obtain the hardware test output; The hardware module to be tested is further used to test the sub-data to be tested based on the target test sub-parameter, obtain the hardware test sub-output, and store the hardware test sub-output at a second address in the storage model; the second address is pre-allocated by the software driver module to the storage model; The software driver module is further used to obtain the hardware test sub-output from the second address through the software and hardware interface module; The storage model adopts a DDR model; the test platform also includes a monitoring module, and the monitoring module is connected to the storage model; The monitoring module is further used to access the data content of the key address position in the DDR model and monitor the data transmission process in real time, the key address position includes the second address; For each data read, the monitoring module is further used to read the data information of the specified address in the DDR model in real time, and verify the data information with a preset standard; the preset standard includes a preset value range, a preset bit width and a preset data type; The monitoring module is also used to trigger an error handling mechanism when it is found that the data does not meet the preset standard. The error handling mechanism is used to indicate the record-related error information, and the error information includes a timestamp, an actual read data value, an expected data value and an accessed address.

7. A computer device comprising a memory and a processor, characterized in that: The processor is configured to execute instructions stored in the memory, so that the computer device executes the method according to any one of claims 1 to 4, or executes the method according to claim 5.

8. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 4 is implemented, or the method according to claim 5 is performed.

Images