A test environment development method, system, device and medium

Abstract

The present invention discloses a test environment development method, comprising the following steps: generating an initial software simulation platform including a reference model and a comparator; collecting input and output data generated by the initial software simulation platform during the simulation of the unit to be tested according to preset collection parameters; building a lightweight software simulation platform using the reference model and the comparator; inputting the input data into the lightweight software simulation platform and debugging the reference model and the comparator according to the output data; replacing the undebugged reference model and comparator in the initial software simulation platform with the debugged reference model and comparator to obtain the final software simulation platform. The present invention also discloses a system, a computer device, and a readable storage medium. The solution proposed by the present invention can greatly reduce the time for developing reference models and comparators.

Description

Technical Field

[0001] The present invention relates to the field of testing, and in particular to a testing environment development method, system, equipment and storage medium. Background Art

[0002] The continuous advancement of chip manufacturing processes has made chip design increasingly complex. To ensure the correctness of chip design, comprehensive simulation verification is required before tape-out. This is done by generating stimuli as chip input signals through a simulation platform and comparing the chip's output signals with the expected output signals to verify the chip design.

[0003] When the verification personnel get the unit under test provided by the designer, they need to build a software environment (TB, test platform) for the unit under test that can run simulation verification, such as Figure 1 As shown in Figure 1, the test platform consists of a unit under test (UUT) and a verification component. The verification component primarily includes configuration information, agents, reference models, and comparators. Depending on the location of the UUT, classic chip verification platforms can be categorized as software emulation platforms or hardware emulation platforms.

[0004] like Figure 1 As shown, a software simulation platform uses simulation compilation software to compile verification components and units under test into computer-executable binary files. This executable file is then placed on a dedicated server and run using simulation runtime software. This combination of simulation software and a dedicated server is called a software simulation platform.

[0005] like Figure 2 As shown in the figure, the hardware simulation platform mainly consists of two parts: hardware platform and host. The hardware platform is mainly responsible for running the unit under test, and the host is responsible for running the verification component. Figure 2 As shown in the figure, this type of simulation software and dedicated hardware platform is called a hardware emulation platform. The hardware emulation software first uses synthesis and routing software to compile an executable binary bitstream from the unit under test. Simulation compilation tools then compile the verification component into a computer-runnable binary file, which is then executed by the host computer. The emulation platform and host computer are connected via a specific high-speed communication interface. Through this physical interface, the host computer can obtain the required partial operational data, which serves as input for the host-side reference model and comparator.

[0006] Software simulation platform and hardware simulation each have their own advantages and disadvantages, such as Figure 3As shown, software simulation platforms compile binary files that can be executed by computers, significantly increasing compilation speed compared to hardware platforms. For example, compiling a small-scale communication interface software program takes only minutes, but up to several hours using a hardware platform. However, hardware simulation speeds are much faster than software simulation platforms, especially for highly complex algorithms or system-on-chips. For example, a typical system-on-chip can execute at speeds of 1 to 10 Hz on a hardware platform, while a software simulation platform only performs at speeds of one-hundredth to one-thousandth of that. Both software and hardware simulation platforms can effectively verify the functionality of the unit under test (UUT). Software simulation platforms, aided by debugging tools, can observe all signals in the verification component and the UUT, while hardware simulation platforms can only observe a subset of the UUT signals, and for a limited observation time. Hardware simulation platforms, because they require the purchase of additional hardware, are significantly more expensive than software simulation platforms.

[0007] In order to combine the respective advantages of software simulation and hardware simulation, the current mainstream chip verification process is to first use the software simulation platform to test the basic functions of the chip, and then use the hardware simulation platform to verify the complex functions and timing logic of the chip.

[0008] like Figure 4 As shown, verification engineers first use automated tools to generate basic verification components and connect the corresponding signals to the inputs and outputs of the UUT. Input data is typically generated by test cases, converted by a driver, and then sent to the UUT. Output signals are typically connected to a comparator. Next, a corresponding reference model and comparator are developed based on the UUT. The comparator compares the expected value of the reference model with the actual value of the UUT.

[0009] In the early stages of software simulation platform development, the difficulties encountered were mainly the following:

[0010] 1. Time-consuming test platform development

[0011] Testbench development primarily involves reference models, comparators, and test cases. In the initial stages of verification, due to the immaturity of the reference models and comparators, data for a typical scenario may require multiple compilation and debugging cycles, each requiring the entire testbench to be restarted, a time-consuming process.

[0012] 2. Diversity of test scenarios

[0013] For example, for a typical scenario, verification engineers developed a reference model and comparator on a software simulation platform. After executing the model on the simulation platform, they discovered an error in the reference model. After several attempts and modifications, the reference model and comparator outputs were finally identical in the current scenario. Similarly, similar operations are required for other typical scenarios. Each debug session requires recompiling the test platform, and running it after compilation also consumes a significant amount of time. In even more extreme cases, the test platform may have run for a long time before an error occurs at a specific time or event. In this case, after modifying the reference model and rerunning the simulation platform, it takes a significant amount of time to reach the time point where the previous error occurred.

[0014] 3. Repeatability of special scenarios

[0015] During the testing process, it is sometimes necessary to test the response of the component under test to incorrect input, and establishing this special incorrect input requires building complex test cases.

[0016] After entering the hardware simulation stage, the probability of the problems encountered in the above software simulation will be greatly reduced, but new difficulties will also arise:

[0017] 4. Difficulties in debugging

[0018] like Figure 3 As shown, since the hardware simulation platform executes the hardware bitstream after compilation and integrated wiring, the entire unit under test is a black box to the verification component. The verification component can only draw conclusions by comparing the output of the unit under test with the output of the reference model. If a difference is found, the problem can only be located by adding debug signals to the hardware bitstream, recompiling and integrating wiring, and then observing the specified signals using dedicated tools. As shown above, the compilation and integrated wiring of the hardware simulation platform is very time-consuming. In addition, due to the limited size of the built-in memory, the number of debug signals and the acquisition time cannot be arbitrarily increased according to needs, which greatly restricts the use of the hardware simulation platform. Summary of the Invention

[0019] In view of this, in order to overcome at least one aspect of the above problems, an embodiment of the present invention provides a test environment development method, comprising the following steps:

[0020] Generate an initial software simulation platform including reference models and comparators;

[0021] Collecting input and output data generated by the initial software simulation platform during the simulation of the unit to be tested according to preset collection parameters;

[0022] Building a lightweight software simulation platform using the reference model and the comparator;

[0023] Inputting the input data into the lightweight software simulation platform and debugging the reference model and the comparator according to the output data;

[0024] The debugged reference model and comparator are used to replace the undebugged reference model and comparator in the initial software simulation platform to obtain a final software simulation platform.

[0025] In some embodiments, further comprising:

[0026] Build a hardware simulation platform;

[0027] Debugging the unit under test using the final software simulation platform;

[0028] Utilizing the hardware simulation platform to simulate the debugged unit under test;

[0029] Collecting input data when an error occurs on the debugged unit under test during simulation of the debugged unit under test by the hardware simulation platform or input data under a preset scenario;

[0030] The collected data is sent as input data to the final software simulation platform to debug the debugged unit under test again.

[0031] In some embodiments, collecting input and output data generated by the initial software simulation platform during the simulation of the unit under test according to preset collection parameters further includes:

[0032] An acquisition mode is determined according to the acquisition parameters, wherein the acquisition mode includes a continuous mode, an interval mode, and an event mode.

[0033] In some embodiments, further comprising:

[0034] In response to the acquisition mode being the continuous mode, setting a data buffer;

[0035] Store the collected data into the data buffer;

[0036] The data in the data buffer area is converted into a preset data format and time-stamped before being saved in a file.

[0037] In some embodiments, further comprising:

[0038] In response to the acquisition mode being the interval mode, starting a first timer and a second timer;

[0039] generating a collection trigger signal every first preset time period using the first timer;

[0040] Using the second timer to record the time when no data is input, and generating an acquisition stop signal after the time reaches a preset value;

[0041] The collected data is converted into a preset data format, saved in a file and timestamped.

[0042] In some embodiments, further comprising:

[0043] In response to the acquisition mode being the event mode, data acquisition is performed according to the set time trigger condition, address trigger condition, and data trigger condition;

[0044] The collected data is converted into a preset data format, saved in a file and timestamped.

[0045] In some embodiments, further comprising:

[0046] Extract the data and timestamp from the file and put them into the first queue and the second queue respectively;

[0047] The corresponding data in the first queue is sent to the corresponding simulation platform according to the time of the timestamp in the second queue.

[0048] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a test environment development system, including:

[0049] A generation module configured to generate an initial software simulation platform including a reference model and a comparator;

[0050] an acquisition module configured to acquire input and output data generated by the initial software simulation platform during the simulation of the unit under test according to preset acquisition parameters;

[0051] A building module configured to build a lightweight software simulation platform using the reference model and the comparator;

[0052] a debugging module configured to input the input data into the lightweight software simulation platform and debug the reference model and the comparator according to the output data;

[0053] The replacement module is configured to replace the undebugged reference model and comparator in the initial software simulation platform with the debugged reference model and comparator to obtain the final software simulation platform.

[0054] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a computer device, including:

[0055] at least one processor; and

[0056] A memory storing a computer program executable on the processor, wherein the processor executes the steps of any one of the test environment development methods described above when executing the program.

[0057] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any one of the test environment development methods described above are performed.

[0058] The present invention has the following beneficial technical effects: The solution proposed in the present invention can significantly reduce the time required to develop reference models and comparators. Once the reference models and comparators are developed and stabilized in a lightweight verification environment, they can be directly placed back into a traditional verification environment for large-scale regression testing. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0060] Figure 1 This is a schematic diagram of the existing software simulation verification platform;

[0061] Figure 2 This is a schematic diagram of an existing hardware simulation platform;

[0062] Figure 3 This is a schematic diagram comparing software simulation platform and hardware simulation platform;

[0063] Figure 4 Verify the flow chart for traditional chips;

[0064] Figure 5 A flow chart of a test environment development method provided by an embodiment of the present invention;

[0065] Figure 6 A schematic diagram of an initial software simulation platform provided by an embodiment of the present invention;

[0066] Figure 7 A schematic diagram of a lightweight software simulation platform provided by an embodiment of the present invention;

[0067] Figure 8 A flowchart of data collection provided by an embodiment of the present invention;

[0068] Figure 9 Schematic diagram of storing collected data in a file provided by an embodiment of the present invention;

[0069] Figure 10 A schematic diagram of the structure of a test environment development system provided by an embodiment of the present invention;

[0070] Figure 11 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention;

[0071] Figure 12 A schematic structural diagram of a computer-readable storage medium provided for an embodiment of the present invention. DETAILED DESCRIPTION

[0072] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the embodiments of the present invention are further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

[0073] It should be noted that all expressions using "first" and "second" in the embodiments of the present invention are for distinguishing two non-identical entities with the same name or non-identical parameters. It can be seen that "first" and "second" are only for the convenience of expression and should not be understood as limitations on the embodiments of the present invention. Subsequent embodiments will not explain this one by one.

[0074] According to one aspect of the present invention, an embodiment of the present invention provides a test environment development method, such as Figure 5 As shown, it may include the steps of:

[0075] S1, generating an initial software simulation platform including a reference model and a comparator;

[0076] S2, collecting input and output data generated by the initial software simulation platform during the simulation of the unit under test according to preset collection parameters;

[0077] S3, building a lightweight software simulation platform using the reference model and the comparator;

[0078] S4, inputting the input data into the lightweight software simulation platform and debugging the reference model and the comparator according to the output data;

[0079] S5, replacing the undebugged reference model and comparator in the initial software simulation platform with the debugged reference model and comparator to obtain a final software simulation platform.

[0080] The solution proposed in the present invention can greatly reduce the time for reference model and comparator development. After the reference model and comparator are developed and stabilized in a lightweight verification environment, they can be directly put back into the traditional verification environment for large-scale regression testing.

[0081] In some embodiments, steps S1-S5, specifically, Figure 6 The initial software simulation platform shown includes a reference model and a comparator. In the software simulation platform, the UUT runs on a host computer, along with the test component. In the hardware simulation platform, the UUT runs on the hardware platform, while the test component runs on the host computer. The test component primarily consists of a reference model and a comparator. Test data is transmitted through a driver to the UUT and the reference model. The outputs of both serve as inputs to the comparator, which compares the UUT's actual value with the expected value of the reference model and draws a conclusion.

[0082] like Figure 7 The lightweight software simulation platform shown in the figure is collected by Figure 6 The input and output data generated by the initial software simulation platform are then input into the reference model, and the output data of the reference model is compared with the collected output data, thereby realizing the development of the reference model and the comparator.

[0083] In some embodiments, further comprising:

[0084] Build a hardware simulation platform;

[0085] Debugging the unit under test using the final software simulation platform;

[0086] Utilizing the hardware simulation platform to simulate the debugged unit under test;

[0087] Collecting input data when an error occurs on the debugged unit under test during simulation of the debugged unit under test by the hardware simulation platform or input data under a preset scenario;

[0088] The collected data is sent as input data to the final software simulation platform to debug the debugged unit under test again.

[0089] Specifically, special data is collected from the hardware simulation platform, including extreme scenario data or error data from the unit under test. This error data is then analyzed and reinjected into the final software simulation platform, where debugging is finally carried out.

[0090] In some embodiments, collecting input and output data generated by the initial software simulation platform during the simulation of the unit under test according to preset collection parameters further includes:

[0091] An acquisition mode is determined according to the acquisition parameters, wherein the acquisition mode includes a continuous mode, an interval mode, and an event mode.

[0092] Specifically, when collecting data, the specific input and output bus protocol on the unit under test can be converted into a specific data format and saved in a file, with a time stamp added to each data packet. The data in the file can then be converted into specific data packets using a data parsing unit, which serves as the input for the reference model and comparator. Data collection can have three modes. The first is continuous mode. In this mode, all input and output data are recorded in a file by the data conversion unit. This mode maximizes the preservation of possible data sets, but its disadvantage is the large amount of data, which places a high demand on the storage medium. The second is intermittent mode. In this mode, data is saved at a certain interval. This storage method saves a smaller amount of data, but may lose useful data. The third is time-triggered mode. In this mode, by setting trigger conditions and a save time, the input and output under specific scenarios can be saved. This not only allows for quick identification of extreme conditions, but also significantly reduces the amount of data saved.

[0093] In some embodiments, further comprising:

[0094] In response to the acquisition mode being the continuous mode, setting a data buffer;

[0095] Store the collected data into the data buffer;

[0096] The data in the data buffer area is converted into a preset data format and time-stamped before being saved in a file.

[0097] Specifically, such as Figure 8 As shown, after entering continuous mode, data packets are continuously written to the file through the interface conversion module. To ensure optimal file writing performance, a data buffer needs to be opened. If the data writing speed in continuous mode is slower than the speed at which the data conversion module writes the file, all data will be securely stored in the file. If the data writing speed is faster than the speed at which the data conversion module writes the file, the buffer will be full after a period of time. There are two ways to deal with this. One is to discard the latest written data, and the other is to discard the earliest written data. Both methods will result in data loss. As for whether to discard the latest written data or the earliest written data, it is up to the user to decide according to their needs. There is no obvious advantage or disadvantage between the two methods. If the data acquisition time or length is not specified, sampling stops when the file is full.

[0098] In some embodiments, further comprising:

[0099] In response to the acquisition mode being the interval mode, starting a first timer and a second timer;

[0100] generating a collection trigger signal every first preset time period using the first timer;

[0101] Using the second timer to record the time when no data is input, and generating an acquisition stop signal after the time reaches a preset value;

[0102] The collected data is converted into a preset data format, saved in a file and timestamped.

[0103] Specifically, such as Figure 8 As shown in the figure, after entering interval mode, the data conversion module starts a timer, which sends a trigger signal at regular intervals to alert the data acquisition module. After receiving the trigger signal from the timer, the acquisition module waits for data on the bus. If there is data, it enters the sampling state; otherwise, it remains in the waiting state, awaiting data acquisition. To prevent the module from entering an infinite waiting state, another timer is required after entering the sampling state. If no data arrives within the timer's specified time, the acquisition module exits the acquisition state.

[0104] In some embodiments, further comprising:

[0105] In response to the acquisition mode being the event mode, data acquisition is performed according to the set time trigger condition, address trigger condition, and data trigger condition;

[0106] The collected data is converted into a preset data format, saved in a file and timestamped.

[0107] Specifically, such as Figure 8 As shown, after entering the event trigger mode, the data conversion module will trigger sampling according to the trigger conditions. The trigger conditions are mainly divided into time trigger, address trigger and data trigger.

[0108] Time triggering means that when the simulation time advances to a certain moment T, the signal sampling module starts working, and the sampling module stops after sampling a certain time or a certain amount of data.

[0109] Address triggering means that when the bus sends / receives data to a specific address, the signal sampling module starts working and stops after sampling a certain time or a certain amount of data.

[0110] Data triggering means that when an event of writing / reading specific data occurs on the bus, the signal sampling module starts working and stops after sampling a certain time or a certain amount of data.

[0111] In some embodiments, further comprising:

[0112] Extract the data and timestamp from the file and put them into the first queue and the second queue respectively;

[0113] The corresponding data in the first queue is sent to the corresponding simulation platform according to the time of the timestamp in the second queue.

[0114] Specifically, data is collected according to the selected trigger mode, and the data on the bus is packaged into several data packets after clock sampling, and then written to the host's disk or the hardware platform's memory through the system's file read and write interface. Figure 9 As shown, the data packets are stored continuously in the storage medium. The content of each data packet consists of two parts: a timestamp and data. The timestamp records the start time of the current data packet sampling, and the data packet records the input / output data sampled by the module. A typical data packet content includes data address information and data information, where the data information mainly includes the data bit width and length. Then, when the data packet needs to be input into the corresponding simulation platform, it can be done through the data parsing module. This module completes the extraction of data and timestamps from the file. The extracted timestamp is placed in a separate queue, and the data packet is placed in another separate queue. The two queues have a one-to-one relationship. After the data packet and timestamp are placed in the corresponding queue, the sending module starts the timer and sends the data packet to the output interface according to the time of the timestamp.

[0115] The solution proposed by the present invention first separates the reference model and comparator in the traditional verification platform, and then uses the data acquisition module proposed by the present invention to save specific test data from the bus into a file in a certain format. The test data in the file is then passed to the reference model and comparator as data using the data parsing module proposed by the present invention. Since the reference model and comparator are developed based on an independent lightweight verification platform, this can avoid compiling the entire test component and the unit to be tested each time. At the same time, since the sampling method proposed by the present invention can be used to sample specific data, the time for developing the reference model and comparator can be greatly reduced. After the reference model and comparator are developed and stabilized in the lightweight verification environment, the reference model and comparator can be directly placed back into the traditional verification environment for large-scale regression testing.

[0116] Traditional reference model and comparator development is typically based on a series of common data. This makes it very easy to encounter errors when encountering certain specific data. Each time such an error occurs, the reference model needs to be recompiled to correct it, which is very time-consuming. Furthermore, in some cases, after a simulation has run for a considerable period of time, an error in the reference model or comparator occurs. Because the data that caused the error is not saved, even after correcting the reference model or comparator, a long simulation run is required to verify the correctness of the corrected reference model or comparator.

[0117] The present invention also uses sampled data to solve the difficulty of debugging the unit under test in hardware simulation. That is, special data or problem data collected from the hardware is injected into the final software simulation platform. With the help of verification tools, all signals of the unit under test can be observed, thus quickly completing the debugging of the unit under test.

[0118] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a test environment development system 400, such as Figure 10 Shown, including:

[0119] A generating module 401 is configured to generate an initial software simulation platform including a reference model and a comparator;

[0120] The acquisition module 402 is configured to acquire input and output data generated by the initial software simulation platform during the simulation of the unit under test according to preset acquisition parameters;

[0121] A building module 403 is configured to build a lightweight software simulation platform using the reference model and the comparator;

[0122] a debugging module 404 configured to input the input data into the lightweight software simulation platform and debug the reference model and the comparator according to the output data;

[0123] The replacement module 405 is configured to replace the undebugged reference model and comparator in the initial software simulation platform with the debugged reference model and comparator to obtain a final software simulation platform.

[0124] Based on the same inventive concept, according to another aspect of the present invention, Figure 11 As shown, an embodiment of the present invention further provides a computer device 501, including:

[0125] at least one processor 520; and

[0126] The memory 510 stores a computer program 511 that can be run on a processor. When the processor 520 executes the program, the processor 520 performs the steps of any of the above test environment development methods.

[0127] Based on the same inventive concept, according to another aspect of the present invention, Figure 12 As shown, an embodiment of the present invention further provides a computer-readable storage medium 601 , which stores computer program instructions 610 . When the computer program instructions 610 are executed by a processor, the steps of any of the above test environment development methods are performed.

[0128] Finally, it should be noted that a person skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods.

[0129] Furthermore, it should be appreciated that the computer-readable storage media (eg, memory) herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory.

[0130] It will also be appreciated by those skilled in the art that the various exemplary logic blocks, modules, circuits and algorithmic steps described in conjunction with the disclosure herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, a general description has been given of the functions of various schematic components, blocks, modules, circuits and steps. Whether this function is implemented as software or hardware depends on specific applications and the design constraints imposed on the entire system. Those skilled in the art can implement the function in various ways for each specific application, but this implementation decision should not be interpreted as causing a departure from the disclosed scope of the embodiments of the present invention.

[0131] The above are exemplary embodiments disclosed in the present invention, but it should be noted that various changes and modifications may be made without departing from the scope of the embodiments disclosed in the claims. The functions, steps and / or actions of the method claims according to the disclosed embodiments described herein do not need to be performed in any particular order. In addition, although the elements disclosed in the embodiments of the present invention may be described or required in individual form, they may also be understood as multiple unless expressly limited to the singular.

[0132] It should be understood that, as used herein, the singular forms "a" and "an" are intended to include the plural forms as well, unless the context clearly supports an exception. It should also be understood that, as used herein, "and / or" is intended to include any and all possible combinations of one or more of the associated listed items.

[0133] The serial numbers of the embodiments disclosed in the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0134] 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 may be accomplished by a program instructing the relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk, or an optical disk, etc.

[0135] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the disclosure of the embodiments of the present invention (including the claims) is limited to these examples. Within the spirit of the embodiments of the present invention, the technical features of the above embodiments or different embodiments may be combined, and there are many other variations of different aspects of the above embodiments of the present invention, which are not provided in detail for the sake of simplicity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present invention should be included in the scope of protection of the embodiments of the present invention.

Claims

1. A test environment development method, characterized in that: The following steps are involved: Generate an initial software simulation platform including reference models and comparators; Collecting input and output data generated by the initial software simulation platform during the simulation of the unit to be tested according to preset collection parameters; Building a lightweight software simulation platform using the reference model and the comparator; Inputting the input data into the lightweight software simulation platform and debugging the reference model and the comparator according to the output data, wherein the input data is input into the reference model of the lightweight software simulation platform, and the comparator in the lightweight software simulation platform compares the output data of the reference model with the collected output data, thereby realizing the development of the reference model and the comparator; Replacing the undebugged reference model and comparator in the initial software simulation platform with the debugged reference model and comparator to obtain a final software simulation platform; The method further includes: Build a hardware simulation platform; Debugging the unit under test using the final software simulation platform; Utilizing the hardware simulation platform to simulate the debugged unit under test; Collecting input data when an error occurs on the debugged unit under test during simulation of the debugged unit under test by the hardware simulation platform or input data under a preset scenario; The collected data is sent as input data to the final software simulation platform to debug the debugged unit under test again.

2. The method according to claim 1, wherein Collecting input and output data generated by the initial software simulation platform during the simulation of the unit to be tested according to preset collection parameters further includes: An acquisition mode is determined according to the acquisition parameters, wherein the acquisition mode includes a continuous mode, an interval mode, and an event mode.

3. The method according to claim 2, wherein Also includes: In response to the acquisition mode being the continuous mode, setting a data buffer; Store the collected data into the data buffer; The data in the data buffer area is converted into a preset data format and time-stamped before being saved in a file.

4. The method according to claim 2, wherein Also includes: In response to the acquisition mode being the interval mode, starting a first timer and a second timer; generating a collection trigger signal every first preset time period using the first timer; Using the second timer to record the time when no data is input, and generating an acquisition stop signal after the time reaches a preset value; The collected data is converted into a preset data format, saved in a file and timestamped.

5. The method according to claim 2, wherein Also includes: In response to the acquisition mode being the event mode, data acquisition is performed according to the set time trigger condition, address trigger condition, and data trigger condition; The collected data is converted into a preset data format, saved in a file and timestamped.

6. The method according to any one of claims 3 to 5, wherein: Also includes: Extract the data and timestamp from the file and put them into the first queue and the second queue respectively; The corresponding data in the first queue is sent to the corresponding simulation platform according to the time of the timestamp in the second queue.

7. A test environment development system, characterized in that: include: A generation module configured to generate an initial software simulation platform including a reference model and a comparator; an acquisition module configured to acquire input and output data generated by the initial software simulation platform during the simulation of the unit under test according to preset acquisition parameters; A building module configured to build a lightweight software simulation platform using the reference model and the comparator; a debugging module configured to input the input data into the lightweight software simulation platform and debug the reference model and the comparator according to the output data, wherein the input data is input into the reference model of the lightweight software simulation platform, and the comparator in the lightweight software simulation platform compares the output data of the reference model with the collected output data, thereby realizing the development of the reference model and the comparator; a replacement module configured to replace the undebugged reference model and comparator in the initial software simulation platform with the debugged reference model and comparator to obtain a final software simulation platform; The debug module is also configured to: Build a hardware simulation platform; Debugging the unit under test using the final software simulation platform; Utilizing the hardware simulation platform to simulate the debugged unit under test; Collecting input data when an error occurs on the debugged unit under test during simulation of the debugged unit under test by the hardware simulation platform or input data under a preset scenario; The collected data is sent as input data to the final software simulation platform to debug the debugged unit under test again.

8. A computer device comprising: at least one processor; as well as A memory storing a computer program executable on the processor, wherein the processor executes the steps of the method according to any one of claims 1 to 6 when executing the program.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are performed.

Images