Test method and device of tested equipment, equipment and storage medium

Abstract

The invention relates to a test method and device of tested equipment, equipment and a storage medium, and relates to the technical field of automobiles. The method comprises the steps that a fault definition file of a target fault is acquired, the fault definition file comprises the position of the target fault in tested equipment, the fault state and / or the fault type of the target fault, the position of a detection point in the tested equipment and a fault simulation excitation file, and the position of the target fault in the tested equipment comprises the interior of a core particle; and interfaces between different core particles; and sending the fault definition file to the tested equipment to enable the tested equipment to perform fault simulation based on the fault definition file, and generating a fault simulation result of the target fault. Therefore, when the position of the fault is located at the interface between different core particles, fault simulation can be carried out to verify the function safety of the chip, and the technical problem that only the function safety in the core particles can be tested, so that the accuracy of function safety testing on the chip is low is solved.

Description

Technical Field

[0001] The present invention relates to the field of automobile technology, and in particular to a testing method, device, equipment and storage medium for a tested device. Background Art

[0002] With the growing demand for modern smart cars such as autonomous driving and smart cockpits, the electronic systems of cars are becoming more and more complex, and the requirements for chip functional safety in the field of automotive electronics are also getting higher and higher. Therefore, reducing the risk of systematic and random hardware failures is crucial for modern smart cars. Any failure in the software and hardware related to the functional safety of the car may have serious consequences for personnel, equipment and the environment, and cause huge economic losses to car companies. At present, car manufacturers can use automatic diagnosis and redundant design in the design stage of chips (i.e. core particles) to simulate and verify the effectiveness of the safety mechanism of automotive chips, so as to achieve the purpose of reducing random failures of the system.

[0003] However, in the above method, when the effectiveness of the automotive chip safety mechanism is simulated and verified by automatic diagnosis and redundant design, only the functional safety within a single chip can be verified, and the functional safety of the die to die (D2D) interface between multiple different chips cannot be verified, resulting in incomplete verification of the automotive chip safety mechanism, and thus resulting in low accuracy in testing the effectiveness of the automotive chip safety mechanism. Summary of the invention

[0004] The purpose of the present invention is to provide a test method, device, equipment and storage medium for a device under test, so as to solve the technical problem that when the effectiveness of the automotive chip safety mechanism is simulated and verified by automatic diagnosis and redundant design, only the functional safety of a single chip can be verified, and the functional safety of the D2D interface between multiple different chips cannot be verified, resulting in incomplete testing and low accuracy. The technical solution of this application is as follows:

[0005] According to a first aspect of the present application, there is provided a testing method for a device under test, wherein the device under test is composed of a plurality of different core particles, and the method comprises: obtaining a fault definition file of a target fault, the fault definition file comprising a location of the target fault in the device under test, a fault state and / or a fault type of the target fault, a location of a detection point in the device under test, and a fault simulation stimulus file, wherein the location of the target fault in the device under test comprises an interior of the core particle and an interface between different core particles; sending the fault definition file to the device under test so that the device under test performs a fault simulation based on the fault definition file and generates a fault simulation result of the target fault.

[0006] According to the above-mentioned technical means, the present application can obtain the fault definition file of the target fault when the location of the target fault is located inside the core particle and at the interface between different core particles, perform fault simulation based on the fault definition file of the target fault, and generate a fault simulation result of the target fault, which solves the problem in the prior art that the functional safety inside the chip can only be verified when the location of the fault is inside the core particle, but the functional safety of the interface between different chips cannot be verified when the location of the fault is at the interface between different core particles, thereby improving the accuracy of testing the functional safety of the chip.

[0007] In a possible implementation, the method also includes: obtaining a design to be tested for the function executed by the device under test; respectively generating execution files, logic simulation files, and logic stimulus files corresponding to the design to be tested; performing logic simulation on the design to be tested according to the execution files, logic simulation files, and logic stimulus files; obtaining a fault definition file for a target fault, including: generating a fault definition file for a target fault when the logic simulation results of the design to be tested are correct.

[0008] According to the above-mentioned technical means, the present application can perform logic simulation on the design under test based on the execution file, logic simulation file and logic stimulus file corresponding to the design under test of the function executed by the device under test, so as to generate a fault definition file of the target fault when the logic simulation result of the design under test is correct, thereby avoiding the problem of inaccurate fault simulation results of the device under test when the code of the function executed by the device under test is incorrect.

[0009] In a possible implementation, the method also includes: performing a syntax check on the design to be tested based on a preset syntax checking tool; and respectively generating an execution file, a logic simulation file, and a logic stimulus file corresponding to the design to be tested, including: when the syntax check of the design to be tested is correct, respectively generating an execution file, a logic simulation file, and a logic stimulus file.

[0010] According to the above-mentioned technical means, the present application can perform syntax checking on the design to be tested based on a preset syntax checking tool, and generate an execution file, a logic simulation file and a logic stimulus file respectively when the syntax check of the design to be tested is correct, thereby avoiding the problem of inaccurate fault simulation results of the device under test when the syntax of the design to be tested is incorrect.

[0011] In a possible implementation, the detection points in the device under test include a first detection point and a second detection point; the first detection point is located inside the device under test, and the first detection point is used to detect whether there is a target fault; the second detection point is located at the external exit of the device under test, and the second detection point is used to detect whether there is a target fault and the fault state of the target fault.

[0012] According to the above-mentioned technical means, the present application can detect whether there is a target fault inside the device under test through a first detection point located inside the device under test, and detect whether there is a target fault outside the device under test and the fault state of the target fault through a second detection point located at the external exit of the device under test, thereby avoiding the problem of being unable to detect whether there is a target fault and the fault state of the target fault when the fault is located outside the device under test.

[0013] In a possible implementation, the target fault is any one of a plurality of faults, and the fault simulation result of the target fault includes whether the target fault exists and whether the target fault is eliminated by the device under test. The method further includes: obtaining a plurality of fault simulation results corresponding one-to-one to the plurality of faults; and generating a target fault coverage of the device under test based on the plurality of fault simulation results, wherein the target fault coverage is used to indicate the probability of eliminating the fault of the device under test.

[0014] According to the above-mentioned technical means, the present application can generate a target fault coverage of the device under test based on multiple fault simulation results corresponding to multiple faults one by one, that is, the more faults eliminated in the multiple fault simulation results, the greater the probability that the device under test eliminates the faults, which means that the function of the device under test is safer, thereby completing the functional safety test of the device under test.

[0015] In a possible implementation manner, the locations of the multiple faults in the device under test are different, and / or the order in which the multiple fault definition files corresponding to the multiple faults are input into the device under test is different.

[0016] According to the above-mentioned technical means, the present application can disperse each fault to each channel of the fault simulation when the order in which multiple fault definition files corresponding to multiple faults are input into the device under test is different, thereby avoiding the problem that when the simulation results generated by multiple faults are concentrated in a single channel, the simulation results of certain faults vary too much, resulting in inaccurate fault coverage of the device under test.

[0017] In a possible implementation, the correlation between the function performed by the device under test and the vehicle driving safety is higher than a preset level, and the preset level is positively correlated with a preset fault coverage rate; the method also includes: when the target fault coverage rate is greater than the preset fault coverage rate, determining that the test of the device under test is normal; when the target fault coverage rate is less than the preset fault coverage rate, determining that the test of the device under test is abnormal.

[0018] According to the above technical means, the present application can perform safety tests on the functions performed by the tested equipment that are highly relevant to the vehicle driving safety, thereby ensuring the safety of vehicle driving and avoiding danger.

[0019] According to the second aspect provided by the present application, a testing device for a device under test is provided, wherein the device under test is composed of a plurality of different core particles, and the testing device for the device under test comprises a transmission module and a processing module; the transmission module is used to obtain a fault definition file of a target fault, the fault definition file comprises a location of the target fault in the device under test, a fault state and / or fault type of the target fault, a location of a detection point in the device under test, and a fault simulation stimulus file, wherein the location of the target fault in the device under test comprises the interior of the core particle and an interface between different core particles; the transmission module is further used to send the fault definition file to the device under test, so that the device under test performs a fault simulation based on the fault definition file; the processing module is used to generate a fault simulation result of the target fault.

[0020] In a possible implementation, the transmission module is also used to obtain the design to be tested of the function executed by the device under test; the processing module is also used to respectively generate the execution file, logic simulation file and logic stimulus file corresponding to the design to be tested; the processing module is also used to perform logic simulation on the design to be tested according to the execution file, logic simulation file and logic stimulus file; the processing module is also used to generate a fault definition file of the target fault when the logic simulation result of the design to be tested is correct.

[0021] In a possible implementation, the processing module is also used to perform a syntax check on the design to be tested based on a preset syntax check tool; the processing module is also used to generate an execution file, a logic simulation file, and a logic stimulus file respectively when the syntax check of the design to be tested is correct.

[0022] In a possible implementation, the detection points in the device under test include a first detection point and a second detection point; the first detection point is located inside the device under test, and the first detection point is used to detect whether there is a target fault; the second detection point is located at the external exit of the device under test, and the second detection point is used to detect whether there is a target fault and the fault state of the target fault.

[0023] In a possible implementation, the target fault is any one of a plurality of faults, and the fault simulation result of the target fault includes whether the target fault exists and whether the target fault is eliminated by the device under test. The transmission module is further used to obtain a plurality of fault simulation results corresponding to the plurality of faults one by one; the processing module is further used to generate a target fault coverage of the device under test based on the plurality of fault simulation results, and the target fault coverage is used to indicate the probability of eliminating the fault of the device under test.

[0024] In a possible implementation manner, the locations of the multiple faults in the device under test are different, and / or the order in which the multiple fault definition files corresponding to the multiple faults are input into the device under test is different.

[0025] In a possible implementation, the processing module is further used to determine that the test of the device under test is normal when the target fault coverage is greater than the preset fault coverage; the processing module is further used to determine that the test of the device under test is abnormal when the target fault coverage is less than the preset fault coverage.

[0026] According to the third aspect provided by the present application, an electronic device is provided, comprising: a processor; a memory for storing processor executable instructions; wherein the processor is configured to execute instructions to implement the method of the above-mentioned first aspect and any possible implementation manner thereof.

[0027] According to the fourth aspect provided by the present application, a computer-readable storage medium is provided. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method in the above-mentioned first aspect and any possible implementation method thereof.

[0028] According to the fifth aspect provided by the present application, a computer program product is provided, the computer program product comprising computer instructions, and when the computer instructions are executed on an electronic device, the electronic device executes the method of the above-mentioned first aspect and any possible implementation manner thereof.

[0029] Therefore, the above technical features of the present application have the following beneficial effects:

[0030] (1) When the target fault is located inside a chip or at an interface between different chiplets, a fault definition file of the target fault can be obtained, fault simulation can be performed based on the fault definition file of the target fault, and a fault simulation result of the target fault can be generated. This solves the problem in the prior art that the functional safety of the chip can only be verified when the fault is located inside a chip, but the functional safety of the interface between different chips cannot be verified when the fault is located at an interface between different chiplets, thereby improving the accuracy of testing the functional safety of the chip.

[0031] (2) Logic simulation can be performed on the design under test based on the execution file, logic simulation file and logic stimulus file corresponding to the design under test of the function executed by the device under test, so as to generate a fault definition file of the target fault when the logic simulation result of the design under test is correct, thereby avoiding the problem of inaccurate fault simulation results of the device under test when the code of the function executed by the device under test is incorrect.

[0032] (3) Based on a preset syntax checking tool, the syntax check of the design under test can be performed, and when the syntax check of the design under test is correct, an execution file, a logic simulation file and a logic stimulus file are generated respectively, thereby avoiding the problem of inaccurate fault simulation results of the device under test when the syntax of the design under test is incorrect.

[0033] (4) It is possible to detect whether a target fault exists inside the device under test through a first detection point located inside the device under test, and to detect whether a target fault exists outside the device under test and the fault state of the target fault through a second detection point located at an external exit of the device under test, thereby avoiding the problem of being unable to detect whether a target fault exists and the fault state of the target fault when the fault is located outside the device under test.

[0034] (5) Whether a target fault exists inside the device under test can be detected through a first detection point located inside the device under test, and whether a target fault exists outside the device under test and the fault state of the target fault can be detected through a second detection point located at an external exit of the device under test, thereby avoiding the problem of being unable to detect whether a target fault exists and the fault state of the target fault when the fault is located outside the device under test.

[0035] (6) The target fault coverage of the device under test can be generated based on multiple fault simulation results corresponding to multiple faults. That is, the more faults are eliminated in the multiple fault simulation results, the greater the probability that the device under test eliminates the faults, indicating that the function of the device under test is safer, thereby completing the functional safety test of the device under test.

[0036] (7) When the order in which multiple fault definition files corresponding to multiple faults are input into the device under test is different, each fault can be dispersed into each channel of the fault simulation, thereby avoiding the problem that when the simulation results generated by multiple faults are concentrated in a single channel, the simulation results of some faults vary too much, resulting in inaccurate fault coverage of the device under test.

[0037] (8) Safety tests can be performed on the functions performed by the equipment under test that are highly relevant to vehicle driving safety, thereby ensuring the safety of vehicle driving and avoiding danger.

[0038] It should be noted that the technical effects brought about by any implementation method in the second to fifth aspects can refer to the technical effects brought about by the corresponding implementation method in the first aspect, and will not be repeated here.

[0039] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application, and do not constitute an improper limitation on the present application.

[0041] Figure 1 is a structural schematic diagram of a testing system for a device under test according to an exemplary embodiment;

[0042] Figure 2 is a flow chart of a method for testing a device under test according to an exemplary embodiment;

[0043] Figure 3 is a schematic diagram of an architecture of a vehicle-mounted chiplet heterogeneous integrated computing chip according to an exemplary embodiment;

[0044] Figure 4 is a schematic diagram showing a detection point position according to an exemplary embodiment;

[0045] Figure 5 is a flow chart of another method for testing a device under test according to an exemplary embodiment;

[0046] Figure 6 is a flow chart of another method for testing a device under test according to an exemplary embodiment;

[0047] Figure 7 is a flow chart of another method for testing a device under test according to an exemplary embodiment;

[0048] Figure 8 is a flow chart of another method for testing a device under test according to an exemplary embodiment;

[0049] Fig. 9 is a block diagram of a testing device for a device under test according to an exemplary embodiment;

[0050] Fig.10 It is a block diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0051] The following will describe the embodiments of the present invention with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention, not for limiting the scope of protection of the present invention.

[0052] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0053] The biggest problem currently facing car manufacturers is how to avoid the potential failure risk of on-board chips during the product design stage. Therefore, functional safety verification is particularly important during the design and verification stage of automotive chips. As the level of autonomous driving of vehicles develops from L2 to L5, more functions related to sensing and resolution need to be installed on the vehicle. The computing power of existing automotive-grade system-on-chip (SOC) chips (i.e., on-board chips) is difficult to meet the massive data processing requirements brought about by higher levels of autonomous driving, and SOC chips with high computing power are difficult to adapt to the harsh in-vehicle environment. In order to effectively solve the current demand for higher computing power on-board chips in the field of autonomous driving and improve the adaptability of on-board chips in the in-vehicle environment, functional safety verification of on-board chips is required.

[0054] Functional safety verification refers to testing the effectiveness of a product's safety mechanism. Currently, research on functional safety verification of products is based on the International Organization for Standardization (ISO) 26262 standard. The ISO 26262 standard clearly stipulates that the automotive chip standards for the Automotive Safety Integrity Level (ASIL) are from A to D (A represents the lowest level of automotive hazard, and D represents the highest level of automotive hazard). From A to D, the functional safety of the car is getting higher and higher.

[0055] For ease of understanding, the testing method for the device under test provided by the present application is specifically introduced below with reference to the accompanying drawings.

[0056] A testing method for a device under test provided in an embodiment of the present application may be applicable to a testing system for the device under test. Figure 1 FIG. 1 is a schematic diagram showing a structure of a test system for a device under test according to an exemplary embodiment. Figure 1 As shown, the test system 10 of the device under test includes: a fault observation module 11 , a fault stimulation module 12 , a fault injection module 13 , a fault simulation module 14 and a device under test 15 .

[0057] Among them, the fault observation module 11 is used to set the position of the detection point in the device under test 15; the fault stimulus module 12 is used to generate a logic stimulus file according to the design under test of the function performed by the device under test 15; the fault injection module 13 is used to set the position of the target fault in the device under test 15, the fault state and / or the fault type of the target fault; the fault simulation module 14 is used to perform fault simulation based on the position of the detection point, the logic stimulus file, the position of the target fault in the device under test 15, the fault state and / or the fault type of the target fault, and generate a fault simulation result of the target fault, so as to test the device under test 15 based on the fault observation module 11, the fault stimulus module 12, the fault injection module 13 and the fault simulation module 14.

[0058] It should be noted that the test system 10 of the device under test can be a functional safety verification platform based on the device under test (DUT) (i.e., the device under test), and the functional safety verification platform based on the DUT is designed based on the fault injection simulator Z01X tool.

[0059] Figure 2 is a flow chart of a method for testing a device under test according to an exemplary embodiment. Figure 2 As shown, the device under test is composed of a plurality of different core particles, and the testing method of the device under test includes the following steps:

[0060] S201: Obtain a fault definition file of a target fault.

[0061] Among them, the fault definition file includes the location of the target fault in the device under test, the fault state and / or fault type of the target fault, the location of the detection point in the device under test, and the fault simulation stimulus file. The location of the target fault in the device under test includes the inside of the core particle and the interface between different core particles.

[0062] The detection points in the device under test include a first detection point and a second detection point; the first detection point is located inside the device under test, and the first detection point is used to detect whether a target fault exists; the second detection point is located at the external exit of the device under test, and the second detection point is used to detect whether a target fault exists and the fault state of the target fault.

[0063] Optionally, the device under test may be a vehicle-mounted chiplet heterogeneous integrated computing chip, and the multiple different chiplets may include an underlying main chip and multiple slave chips.

[0064] Exemplarily, the plurality of side chips may be four side chips (side dies). Figure 3 FIG. 1 is a schematic diagram of an architecture of a vehicle-mounted chiplet heterogeneous integrated computing chip according to an exemplary embodiment. Figure 3As shown, the packaging substrate of the vehicle-mounted chiplet heterogeneous integrated computing chip includes an underlying main chip, a side chip 1, a side chip 2, a side chip 3, and a side chip 4, which can perform functional safety verification on the D2D interface between the underlying main chip and the side chip, the underlying main chip, the side chip, and the entire system (i.e., the vehicle-mounted chiplet heterogeneous integrated computing chip).

[0065] Optionally, the $fs_strobe() system function provided by the Z01X tool can be used to set all output ports of the top level of the design to be tested {$fs_strobe(design_top)} as the second detection point, and set some signals of the top level of the design to be tested {$fs_strobe(design_top.a, design_top.b, design_top.c, design_top.d, design_top.e)} representing errors inside the processor as the first detection point.

[0066] For example, Figure 4 is a schematic diagram showing a detection point position according to an exemplary embodiment, such as Figure 4 As shown, at the detection point set in the device under test (DUT), the multi-system task combination of the Z01X tool can be used to determine whether the target fault propagates to the first detection point set by the functional safety verification platform, and then determine whether the target fault exists, and determine whether the target fault propagates to the position of the second detection point set by the functional safety verification platform, and then determine whether the target fault exists and the fault state of the target fault. The position of the first detection point is set inside the design level to be tested, and the position of the second detection point is set at the top level of the design to be tested.

[0067] Optionally, the Status Definitions block in the fault injection module allows the definition of the fault state of the target fault, the creation of new fault states, the redefinition of the fault state of existing faults, and the customization of new state groups. The default fault state of the target fault and the user-defined state of the Z01X tool are interactively operated to collect the fault state of a certain injection fault location. The fault generation constraints block in the fault injection module can be used to set the location of the target fault in the device under test according to the fault type of the target fault.

[0068] Exemplarily, the wrong injection position may be main_core (ie, the underlying main chip) or side_core (ie, the secondary chip).

[0069] It should be noted that the automotive chiplet heterogeneous integrated computing chip includes parity support, error checking and correction (ECC) support, watchdog timer (watchdog), memory protection unit (MPU) and safety monitor (safety monitor), dual-core Lockstep processing mechanism and other safety hardware structures, which can simplify the development of key functional safety applications and accelerate the ISO26262 certification of automotive chiplet heterogeneous integrated computing chips. Different process technologies, different architectures (including RISC format and ARM format), and different high-speed interconnection buses are packaged together between the various chiplets in the automotive chiplet heterogeneous integrated computing chip. When there are n different chiplets, the functional safety verification scheme for the entire system will have at least kind.

[0070] S202: Send a fault definition file to the device under test, so that the device under test performs fault simulation based on the fault definition file and generates a fault simulation result of a target fault.

[0071] Optionally, the fault simulation module can be used to set relevant variables in the fault simulation process based on the fault definition file, including adding stimuli (i.e., fault simulation stimulus files), fault manager settings, fault generator settings, and generating fault probability reports. Specifically, the environment variable TEST can be used in the paper.fmsh script file to set the name of the stimulus, and addtst(test=[$TEST], stimtype=[tb]) can be used to add the stimulus. The fault manager can be used to select the target fault from the list of untried faults (NA), undetected faults (ND), potentially detected faults (PT), and detected faults (DT), and the fault generator can be used to generate the fault simulation results of the target fault.

[0072] Figure 5 is a flow chart of another method for testing a device under test according to an exemplary embodiment. Figure 5 As shown, the method further includes S301-S303, and the method in the above step S201 specifically includes S304:

[0073] S301, obtaining a design to be tested of a function executed by a device under test.

[0074] Optionally, the design under test may be codes of functions executed by the device under test.

[0075] Exemplarily, the functions performed by the device under test may include chassis control, engine control, driving speed, and other functions related to personal safety.

[0076] S302 , respectively generating execution files, logic simulation files, and logic stimulus files corresponding to the design to be tested.

[0077] Optionally, in the functional safety verification platform, when the architecture between the various core particles in the vehicle-mounted chiplet heterogeneous integrated computing chip is in risc format, the Verilog$dumpports system task can be used to obtain the value of the port signal (input / output / inout) to create a logic stimulus file in evcd format, or, when the architecture between the various core particles in the vehicle-mounted chiplet heterogeneous integrated computing chip is in arm format, the $dumpvar system task can be used to obtain the value of the port signal (input / output / inout) to create a logic stimulus file in vcd format.

[0078] It should be noted that the Z01X tool supports vcd and evcd formats for logic simulation and fault simulation. The format of the logic stimulus file is related to the architecture of each chip in the device under test. The risc format corresponds to the evcd format logic stimulus file, and the arm format corresponds to the vcd format logic stimulus file.

[0079] S303: Perform logic simulation on the design to be tested according to the execution file, the logic simulation file and the logic stimulus file.

[0080] Optionally, the binary executable file z01x.sim (i.e., the execution file), the simulation database file sim.zdb (i.e., the logic simulation file) and the logic stimulus file created by the compilation process may be added to the design to be tested without any annotation errors to perform logic simulation.

[0081] It should be noted that the main purpose of performing logic simulation on the design under test is to check whether there are logical errors in the functions corresponding to the design under test.

[0082] S304: When the logic simulation result of the design to be tested is correct, generate a fault definition file of the target fault.

[0083] It should be noted that the fault definition file of the target fault can be generated only when the logic simulation of the design to be tested with and without the protection of the safety mechanism is correct.

[0084] Figure 6 is a flow chart of another method for testing a device under test according to an exemplary embodiment. Figure 6 As shown, the method further includes S401, and the above step S302 specifically includes S402:

[0085] S401. Perform a syntax check on the design to be tested based on a preset syntax check tool.

[0086] Optionally, first design a functional safety verification platform for the in-vehicle chiplet heterogeneous integrated computing chip, and then compile the design to be tested in the Z01X tool. The compilation stage includes three steps: analysis, refinement, and simulation. In the analysis stage, the syntax errors in the design to be tested can be checked based on the preset syntax check tool, and the intermediate file can be generated and saved to the design library pointed to by the default logic library.

[0087] S402: When the syntax check of the design to be tested is correct, generate an execution file, a logic simulation file and a logic stimulus file respectively.

[0088] Optionally, when there are no syntax errors in the design under test, the intermediate file generated by the analysis step can be used in the refinement stage to build an instance hierarchy of the design under test through a Z01X script to split the design under test into a binary executable file and a z01x.sim simulation database file sim.zdb, and generate a logic stimulus file.

[0089] Figure 7 is a flow chart of another method for testing a device under test according to an exemplary embodiment. Figure 7 As shown, the target fault is any one of the multiple faults, and the fault simulation result of the target fault includes whether the target fault exists and whether the target fault is eliminated by the device under test. The method also includes the following steps:

[0090] S501. Obtain multiple fault simulation results corresponding to multiple faults one by one.

[0091] The locations of the multiple faults in the device under test are different, and / or the order in which the multiple fault definition files corresponding to the multiple faults are input into the device under test is different.

[0092] Optionally, when creating multiple fault definition files corresponding to multiple faults, the order of the multiple faults can be randomly disrupted (i.e., the order in which the multiple fault definition files corresponding to the multiple faults are input into the device under test is different). All static fault types (including permanent types and transient types, etc.) can be generated for all input, output and multi-channel driven circuits by the fault generator, and multiple faults can be generated on the signal of the PORT type of the design under test by set(var=[fdef],method=[fgen],model.stuck=[port]).

[0093] In one possible implementation, randomly disrupting the order of multiple faults can disperse these faults to various channels of fault simulation, avoiding the simulation results generated by various faults from being concentrated in a single channel, and preventing the simulation results of some faults from changing too much when multiple faults are concentrated in a single channel, resulting in inaccurate fault coverage of the device under test.

[0094] S502: Generate a target fault coverage of the device under test according to multiple fault simulation results.

[0095] Among them, the target fault coverage is used to indicate the probability of eliminating faults in the device under test.

[0096] Optionally, the analysis and setting of environmental parameters related to fault simulation (i.e., multiple fault simulation results) can be integrated into the paper.fmsh file, and then a suitable coverage formula can be formulated according to one's own test verification requirements, and the coverage formula can be added to the paper.fmsh file. Furthermore, based on the paper.fmsh file, a fault coverage report (i.e., the fault coverage of the device under test) can be generated through the coverage command in the fault manager.

[0097] Exemplarily, if the target faults corresponding to 8 fault simulation results among 10 fault simulation results corresponding to 10 target faults have been eliminated, the probability of eliminating the faults of the device under test is 80%.

[0098] It should be noted that the fault coverage report provides fault coverage statistics for the specified functional blocks (including the underlying main chip, slave chip, and D2D interface) or the entire chiplet system (i.e., the on-board chiplet heterogeneous integrated computing chip), as well as individual fault details for all test faults.

[0099] Figure 8 is a flow chart of another method for testing a device under test according to an exemplary embodiment. Figure 8 As shown, the correlation between the function performed by the tested device and the vehicle driving safety is higher than the preset level, and the preset level is positively correlated with the preset fault coverage rate. The method also includes the following steps:

[0100] S601: When the target fault coverage is greater than the preset fault coverage, determine that the device under test is tested normally.

[0101] S602: When the target fault coverage is less than the preset fault coverage, determine that the test of the device under test is abnormal.

[0102] It should be noted that for fault coverage of software unit testing, ASIL A can implement 100% C0 coverage (instruction coverage), while ASIL D requires 100% implementation of C1 coverage (branch coverage) and MC / DC (modified condition / decision coverage). For software integration testing, ASIL D requires 100% implementation of functional coverage and call coverage.

[0103] ASIL has four levels, namely A, B, C, and D, with A being the lowest level and D being the highest. The higher the level, the higher the functional safety required for the design, including fault coverage, traceability of the design process, and trustworthiness of the design software. For example, ASIL A requires more than 90% coverage of system single-point faults, while ASIL D requires more than 99% coverage of system single-point faults. There are many certification requirements for ASIL levels, and single-point faults are just one of them.

[0104] The embodiment of the present application provides a testing method for a device under test. Specifically, the present application provides a functional safety verification method for an on-board chiplet heterogeneous integrated computing chip. The present application can respectively perform functional safety verification on an underlying main chip, a side chip, and a D2D interface included in the on-board chiplet heterogeneous integrated computing chip, and regards the on-board chiplet heterogeneous integrated computing chip including the underlying main chip and multiple side chips as a complete system, and performs functional safety verification on it, which effectively solves the current demand for higher computing power on-board chips in the field of autonomous driving and improves the adaptability of on-board chips in the on-board environment.

[0105] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, the test device or electronic device of the device under test includes a hardware structure and / or software module corresponding to the execution of each function. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0106] The embodiment of the present application can divide the functional modules of the test device or electronic device of the device under test according to the above method. For example, the test device or electronic device of the device under test can include various functional modules corresponding to the various functional divisions, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0107] Fig. 9 FIG. 1 is a block diagram of a testing device for a device under test according to an exemplary embodiment. Fig. 9 , the testing device 70 of the device under test includes: a transmission module 701 and a processing module 702;

[0108] The transmission module 701 is used to obtain a fault definition file of a target fault, wherein the fault definition file includes a location of the target fault in the device under test, a fault state and / or a fault type of the target fault, a location of a detection point in the device under test, and a fault simulation stimulus file. The location of the target fault in the device under test includes the interior of a core particle and an interface between different core particles.

[0109] The transmission module 701 is further used to send a fault definition file to the device under test, so that the device under test performs fault simulation based on the fault definition file;

[0110] The processing module 702 is used to generate a fault simulation result of a target fault.

[0111] In a possible implementation, the transmission module 701 is also used to obtain the design under test of the function executed by the device under test; the processing module 702 is also used to respectively generate the execution file, logic simulation file and logic stimulus file corresponding to the design under test; the processing module 702 is also used to perform logic simulation on the design under test according to the execution file, logic simulation file and logic stimulus file; the processing module 702 is also used to generate a fault definition file of the target fault when the logic simulation result of the design under test is correct.

[0112] In a possible implementation, the processing module 702 is also used to perform a syntax check on the design to be tested based on a preset syntax check tool; the processing module 702 is also used to generate an execution file, a logic simulation file, and a logic stimulus file respectively when the syntax check of the design to be tested is correct.

[0113] In a possible implementation, the transmission module 701 is further used to obtain multiple fault simulation results corresponding to multiple faults; the processing module 702 is further used to generate a target fault coverage of the device under test based on the multiple fault simulation results, and the target fault coverage is used to indicate the probability of eliminating the fault of the device under test.

[0114] In a possible implementation, the processing module 702 is further used to determine that the test of the device under test is normal when the target fault coverage is greater than the preset fault coverage; the processing module 702 is further used to determine that the test of the device under test is abnormal when the target fault coverage is less than the preset fault coverage.

[0115] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0116] Fig.10 FIG. 1 is a block diagram of an electronic device according to an exemplary embodiment. Fig.10 As shown, the electronic device 80 includes but is not limited to: a processor 801 and a memory 802 .

[0117] The memory 802 is used to store executable instructions of the processor 801. It can be understood that the processor 801 is configured to execute instructions to implement the test method of the device under test in the above embodiment.

[0118] It should be noted that those skilled in the art can understand that Fig.10 The electronic device structure shown in the figure does not constitute a limitation on the electronic device, and the electronic device may include Fig.10 More or fewer components may be shown, or certain components may be combined, or the components may be arranged differently.

[0119] The processor 801 is the control center of the electronic device. It uses various interfaces and lines to connect various parts of the entire electronic device. By running or executing software programs and / or modules stored in the memory 802, and calling data stored in the memory 802, it performs various functions of the electronic device and processes data, thereby monitoring the electronic device as a whole. The processor 801 may include one or more processing modules. Optionally, the processor 801 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 801.

[0120] The memory 802 can be used to store software programs and various data. The memory 802 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application program required by at least one functional module (such as a transmission module, a processing module, etc.), etc. In addition, the memory 802 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0121] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 802 including instructions. The above instructions can be executed by a processor 801 of an electronic device 800 to implement the testing method of the device under test in the above embodiment.

[0122] In actual implementation, Fig.10 The functions of the transmission module 701 and the processing module 702 in the embodiment can be obtained by Fig.10 The processor 801 in the embodiment calls the computer program stored in the memory 802. The specific execution process can refer to the description of the test method of the device under test in the above embodiment, which will not be repeated here.

[0123] Optionally, the computer-readable storage medium may be a non-temporary computer-readable storage medium, for example, the non-temporary computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0124] In an exemplary embodiment, the embodiment of the present application further provides a computer program product including one or more instructions, and the one or more instructions can be executed by the processor 801 of the electronic device to complete the testing method of the device under test in the above embodiment.

[0125] It should be noted that when the instructions in the above-mentioned computer-readable storage medium or one or more instructions in the computer program product are executed by the processor of the electronic device, the various processes of the test method embodiment of the above-mentioned device under test are implemented, and the same technical effect as the test method of the above-mentioned device under test can be achieved. To avoid repetition, they will not be repeated here.

[0126] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0127] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0128] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0129] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0130] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or the full classification part or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including a number of instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute the full classification part or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, disk or CD and other media that can store program code.

[0131] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A testing method for a device under test, characterized in that: The device under test is composed of a plurality of different core particles, including: Obtaining a fault definition file of a target fault, wherein the fault definition file includes a location of the target fault in the device under test, a fault state and / or a fault type of the target fault, a location of a detection point in the device under test, and a fault simulation stimulus file, wherein the location of the target fault in the device under test includes an interior of a core particle and an interface between different core particles; The fault definition file is sent to the device under test, so that the device under test performs fault simulation based on the fault definition file and generates a fault simulation result of the target fault.

2. The method according to claim 1, characterized in that The method further comprises: Obtaining a design to be tested for a function performed by the device under test; Respectively generate an execution file, a logic simulation file and a logic stimulus file corresponding to the design to be tested; Performing logic simulation on the design to be tested according to the execution file, the logic simulation file and the logic stimulus file; The step of obtaining the fault definition file of the target fault includes: When the logic simulation result of the design to be tested is correct, a fault definition file of the target fault is generated.

3. The method according to claim 2, characterized in that The method further comprises: Based on a preset grammar checking tool, performing grammar checking on the design to be tested; The step of respectively generating the execution file, the logic simulation file and the logic stimulus file corresponding to the design to be tested comprises: When the syntax check of the design to be tested is correct, the execution file, the logic simulation file and the logic stimulus file are generated respectively.

4. The method according to any one of claims 1 to 3, characterized in that The detection points in the device under test include a first detection point and a second detection point; The first detection point is located inside the device under test, and the first detection point is used to detect whether the target fault exists; The second detection point is located at an external exit of the device under test, and the second detection point is used to detect whether the target fault exists and the fault state of the target fault.

5. The method according to any one of claims 1 to 3, characterized in that: The target fault is any one of a plurality of faults, the fault simulation result of the target fault includes whether the target fault exists and whether the target fault is eliminated by the device under test, and the method further includes: Acquire multiple fault simulation results corresponding to the multiple faults one by one; A target fault coverage of the device under test is generated according to the multiple fault simulation results; the target fault coverage is used to indicate the probability of eliminating faults of the device under test.

6. The method according to claim 5, characterized in that The locations of the multiple faults in the device under test are different, and / or the orders in which the multiple fault definition files corresponding to the multiple faults are input into the device under test are different.

7. The method according to claim 5, characterized in that The correlation between the function performed by the tested device and the driving safety of the vehicle is higher than a preset level, and the preset level is positively correlated with a preset fault coverage rate; the method further includes: When the target fault coverage is greater than the preset fault coverage, determining that the test of the device under test is normal; When the target fault coverage is less than the preset fault coverage, it is determined that the test of the device under test is abnormal.

8. A testing device for a device under test, characterized in that: The device under test is composed of a plurality of different core particles, and the testing device of the device under test includes a transmission module and a processing module; The transmission module is used to obtain a fault definition file of a target fault, wherein the fault definition file includes a location of the target fault in the device under test, a fault state and / or a fault type of the target fault, a location of a detection point in the device under test, and a fault simulation stimulus file, wherein the location of the target fault in the device under test includes an interior of a core particle and an interface between different core particles; The transmission module is further used to send the fault definition file to the device under test, so that the device under test performs fault simulation based on the fault definition file; The processing module is used to generate a fault simulation result of the target fault.

9. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: When the computer-executable instructions stored in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is capable of performing the method as claimed in any one of claims 1 to 7.

Images