CN113343617B - Software and hardware co-simulation method - Google Patents
Software and hardware co-simulation method Download PDFInfo
- Publication number
- CN113343617B CN113343617B CN202110584450.XA CN202110584450A CN113343617B CN 113343617 B CN113343617 B CN 113343617B CN 202110584450 A CN202110584450 A CN 202110584450A CN 113343617 B CN113343617 B CN 113343617B
- Authority
- CN
- China
- Prior art keywords
- hardware
- software
- test
- code
- simulation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2119/00—Details relating to the type or aim of the analysis or the optimisation
- G06F2119/02—Reliability analysis or reliability optimisation; Failure analysis, e.g. worst case scenario performance, failure mode and effects analysis [FMEA]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a software and hardware collaborative simulation method, which comprises a software test code, a hardware test platform and a hardware simulation platform; loading the software test code to an FPGA or a chip, and setting a status flag bit for judging the running status of the software test code; the hardware test platform is used for running software test codes and providing a means for reading the internal storage unit; the hardware simulation platform is used for acquiring a state mark generated by the software test code during running so as to judge the running state of the software test code. The invention provides a brand-new low-cost software and hardware collaborative simulation method, hardware behaviors can be reproduced through simulation without redundant hardware interfaces, simulators and storage equipment, so that the key problems that a special interface is needed, a large amount of storage is needed, equipment is expensive and the like in the existing scheme are effectively solved, and software personnel can perform hardware testing and problem positioning very conveniently; and the reliability is high, and the efficiency is higher.
Description
Technical Field
The invention belongs to the field of chip design, and particularly relates to a software and hardware co-simulation method.
Background
With the development of semiconductor technology, nodes of integrated circuit (hereinafter referred to as IC) processes are developed step by step with moore's law, and reach the nm level so far. The rapid development of process nodes has enabled large-scale integrated circuits, even very large-scale integrated circuits; it has become common for a chip to contain hundreds of millions of transistors. However, how the bulky logic circuit works normally, and how to locate the abnormality has become a problem that engineers often face. A digital circuit engineer simulates a design through a tool and verifies whether the function is correct or not; meanwhile, a software engineer also needs to verify the design downloaded to the FPGA or verify the chip function. However, unlike the digital circuit engineer, the software engineer has no dedicated software simulation tool for simulation, and the verification is completed to ensure the correctness and stability of the software system. How to verify the accuracy and consistency of functions by a hardware engineer and a software engineer becomes a key point for the research and development of the FPGA design or the chip design. For example, when a software engineer finds that a function has a problem, but the hardware engineer cannot know whether the configuration of the software engineer is correct or not, or whether the usage scenario of the software engineer reveals a hidden problem or not, software and hardware co-simulation is particularly important.
In the field of FPGA design, in the conventional software and hardware collaborative simulation, logic sampling is carried out on a set signal by adopting internal insertion provided by an FPGA manufacturer, then sampling data is downloaded to the local through a JTAG chain, and the working behavior of a circuit is checked through waveforms, so that whether the circuit works correctly or not is judged. However, this approach is very limited: firstly, a sampling signal is set in advance, and if other sampling signals are added, recompilation is needed, so that great time cost is caused; secondly, the storage of the sampled data completely depends on the storage unit in the FPGA, and if the FPGA is designed in a huge manner and the number of the FPGA storage units used by the existing functions is large, no redundant storage unit is provided for the collaborative simulation; finally, the sampling logic is added, great difficulty is brought to time sequence in a compiling stage, along with the increasing design scale, the time sequence requirement is higher and higher, and the sampling logic has great possibility that the correctness of a sampling signal cannot be ensured due to the time sequence problem. Of course, many EDA manufacturers, such as Synopsys, provide complete debug technology to solve the storage and timing problems, but the required devices are expensive and cannot be synchronized in real time.
In the ASIC field, software engineers encounter various problems in using the chip, and often problems at the system level. However, the simulation of the system by the hardware engineer is relatively simple, and the simulation result cannot be obtained by one module or several modules for the problem posed by the software engineer. The operation of software is simplified by the conventional method, a scene is extracted from the system level, and even a certain module is simulated. The method can cause inconsistent simulation conditions, cannot position real problems, and can also generate wrong debug directions for software engineers. At present, EDA manufacturers have proposed solutions, such as Palladium from Cadence, which can solve the problem of slow simulation at the system level. Such devices are expensive and relatively inefficient in simulation.
Disclosure of Invention
The invention aims to provide a software and hardware co-simulation method which is low in cost, high in reliability and high in efficiency, and does not need additional equipment and interfaces.
The software and hardware co-simulation method provided by the invention comprises a software test code, a hardware test platform and a hardware simulation platform; loading the software test code to an FPGA or a chip, and setting a state flag bit for judging the running state of the software test code; the hardware test platform is used for running a software test code and providing a means for reading the internal storage unit; the hardware simulation platform is used for acquiring a state mark generated when the software test code runs, so as to judge the running state of the software test code.
The software test code is converted into a binary file through a compiling tool and loaded to an FPGA or a chip; and meanwhile, setting a state flag bit for judging the running state of the software test code.
The software test code does not comprise printed characters and time delay used for outputting, so that the efficiency of the collaborative simulation is improved.
The hardware simulation platform comprises an existing hardware simulation tool and a simulation model with the same peripheral function as the FPGA or the chip; the hardware simulation tool is used for simulating during functional design; the simulation model with the same peripheral functions as the FPGA or the chip is consistent with the hardware functions of the hardware test platform and is used for acquiring the state mark of the software test code in the running process.
The software and hardware collaborative simulation method comprises the following steps:
s1, compiling a test program aiming at a test item;
s2, compiling the program obtained by compiling in the step S1 to generate a binary file, and ensuring that the binary file can run on an FPGA or a chip;
s3, loading the binary file generated in the step S2 to a hardware test platform, and judging whether the corresponding verification item passes through the running status flag:
if so, returning to the step S1 and testing the next test item;
if not, performing the subsequent steps;
s4, modifying the program compiled in the step S1, ensuring that the program is adapted to a hardware simulation platform, and compiling the modified program into binary codes;
s5, loading the binary code obtained in the step S4 to a hardware simulation platform for simulation, and checking whether the program runs correctly:
if the result is correct, which is the same as the phenomenon of S3, the next step S6 is performed;
if not, the phenomenon is the same as the phenomenon of S3, the step S4 is returned, and the written program is revised again;
s6, comparing the operation results of the hardware test platform and the hardware simulation platform:
if the comparison is consistent, performing problem analysis, namely S7;
if the comparison is not consistent, returning to S1;
and S7, analyzing problems by hardware designers.
According to the software and hardware collaborative simulation method, when a software engineer writes a software test code, a state mark is written into a storage space every time a function point test is completed; if the storage space can find the identifications, the test of the functional point is completed; if no state mark exists, the functional point corresponding to the state mark fails to test; when the status identifier of a certain functional test point is not read, the software engineer needs to check whether the test flow is normal: comparing through a pointer of the CPU; the software engineer finishes checking the test flow, and confirms that the instruction execution fails due to the functional problem or the instruction execution is not finished, so that the state mark is not written into the internal storage unit; then, a software engineer modifies the software test codes, deletes the printing instruction and the time delay instruction, and simultaneously ensures that the software test codes after the printing instruction and the time delay instruction are deleted can be executed on a hardware test platform, and the program running state and the state mark writing state are the same as the software test codes before modification; at this point, the first round of software testing is completed;
after the first round of test is finished, the problems are concentrated on one test point, but the CPU can not be positioned to execute the error instruction; a second round of software testing is performed: the starting point of the second round of software testing is the position of the last correct writing state mark during the first round of software testing, more writing state mark instructions are inserted after the position, and whether the writing state failure instruction flow of the second round is correct is checked; then, the software engineer modifies the code again for the hardware simulation platform;
and repeating the steps until the set requirements are met.
According to the software and hardware collaborative simulation method, if an unwritten error occurs in a state flag, but the state flag is inconsistent with a test code on a hardware test platform, a software engineer checks whether the code is the same as the code in the test platform execution process or not, and meanwhile, the hardware engineer checks whether the error is caused by configuration or unexpected operation or not and informs the software engineer to modify the error; the software engineer confirms the correctness of the code again, modifies the code and provides the code for the hardware engineer; if the hardware function is wrong, judging that the hardware function is caused by different processes or configuration errors; at the moment, the first interaction of software and hardware is completed;
if the hardware simulation platform correctly reproduces the problems appearing on the test platform, the hardware engineer checks the logic function, and then the second interaction of software and hardware is completed;
in an FPGA platform, software test code problems are found through software and hardware interaction for a plurality of times, hardware logic function problems are found at the same time, and the software test code problems or the hardware test code problems are completed through modifying software codes or hardware codes;
finding the same error state mark on a chip test platform, and determining that the logic function of the chip has a problem if a hardware engineer confirms that the configuration or the use has no problem;
and finally, performing software and hardware interaction again to solve the problem.
The software and hardware co-simulation method provided by the invention provides a brand-new low-cost software and hardware co-simulation method, and the method can reproduce hardware behaviors through simulation without redundant hardware interfaces, simulators and storage equipment, thereby effectively solving the key problems of the existing scheme that special interfaces are needed, a large amount of storage is needed, the equipment price is high and the like, and being very beneficial to software personnel to carry out hardware test and problem positioning; and the reliability is high, and the efficiency is higher.
Drawings
FIG. 1 is a schematic diagram of the method of the present invention.
FIG. 2 is a schematic flow chart of the method of the present invention.
Detailed Description
FIG. 1 shows a schematic diagram of the method of the present invention: the software and hardware co-simulation method provided by the invention comprises a software test code, a hardware test platform and a hardware simulation platform; loading the software test code to an FPGA or a chip, and setting a status flag bit for judging the running status of the software test code; the hardware test platform is used for running software test codes and providing a means for reading the internal storage unit; the hardware simulation platform is used for acquiring a state mark generated by the software test code during running so as to judge the running state of the software test code.
In the specific implementation:
whether FPGA design or ASIC chip verification is carried out, the verification result is based on the test code generated by software, so the software test code is the basic of verification; the software test code is run on an FPGA or a chip to verify whether the function is correct or not; these codes may be either bare codes or operating system based codes; the software testing code compiles the code into a binary file form through a compiling tool, the binary file can be loaded to an FPGA or a chip to be executed, the running state of the code is judged through state flag bits set by a CPU or the code, and a software engineer can easily judge whether the running of the current program is in accordance with expectation and judge whether the current running state is correct through the state flag bits; the software test code necessarily includes printed characters for output, which the software engineer needs to conveniently remove, but which it is necessary to ensure that these operations do not interfere with the normal functioning of the device, and to select other alternative operations as necessary. The reason for this is that in hardware emulation platforms, these prints are time consuming and the elimination of hardware emulation platforms can improve.
The hardware test platform comprises an FPGA or ASIC chip with programmed functions, which can run software test codes written by a software engineer, and the hardware test platform needs to provide a means for the software engineer to read internal memory cells, wherein the memory cells are only used for storing running state identification of programs and are not used for a large amount of signal sampling data.
The hardware simulation platform is a simulation tool in the general sense that a hardware design engineer performs function design, such as a UVM-based simulation environment, an HDL-based compiling simulation tool VCS, and the like, and the simulation tools are used in a large amount when the hardware engineer performs original function design; the hardware simulation platform also comprises simulation models with the same peripheral functions as the FPGA or the chip, and the functions of the models are completely consistent with the hardware functions of the actual hardware test platform; these models are readily available to manufacturers of test hardware; through a simulation environment, a hardware engineer can obtain state marks of program operation in a simulation model of the class storage unit, and the functions of the marks are the same as the significance of state marks obtained by running software test codes on a hardware test platform; by comparing the status flags, an engineer can easily determine whether the running process of the program meets expectations and whether the running process is correct.
FIG. 2 is a schematic flow chart of the method of the present invention:
the software and hardware co-simulation method comprises the following steps:
s1, compiling a test program aiming at a test item;
s2, compiling the program obtained by compiling in the step S1 to generate a binary file, and ensuring that the binary file can run on an FPGA or a chip;
s3, loading the binary file generated in the step S2 to a hardware test platform, and judging whether the corresponding verification item passes through the running status flag:
if yes, returning to the step S1, and testing the next test item;
if not, the subsequent steps are carried out;
s4, modifying the program compiled in the step S1, ensuring that the program is adapted to a hardware simulation platform, and compiling the modified program into binary codes;
s5, loading the binary code obtained in the step S4 to a hardware simulation platform for simulation, and checking whether the program runs correctly:
if the result is correct, which is the same as the phenomenon of S3, the next step S6 is performed;
if not, the phenomenon is the same as the phenomenon of S3, the step S4 is returned, and the written program is revised again;
s6, comparing the operation results of the hardware test platform and the hardware simulation platform:
if the comparison is consistent, performing problem analysis, namely S7;
if the comparison is not consistent, returning to S1;
and S7, analyzing problems by hardware designers.
In specific implementation, the software and hardware collaborative simulation method mainly comprises problem positioning and software and hardware interaction:
problem location:
the CPU of the hardware test platform adopting the method can normally run binary executable files, and then the hardware test platform or the hardware simulation platform has a space for the CPU to read and write.
When the software engineer writes the software test code, each time a function point test is completed, the software engineer may write a status flag to the memory space, which may be a simple sequential count, such as 1, 2, 3, … …, which indicates that the function point test is completed after the flag is found in the memory space. If there are no such identifiers, it represents that this one functional point has failed the test. These internal memory locations are also easily readable by the CPU.
When the state identifier of a certain functional test point is not read, a software engineer needs to check whether the test flow is normal, comparison can be performed through a pointer of the CPU at this time, the state identifier is usually written, the instructions are assembly instructions, and the execution process of the assembly instructions is easily seen from the instruction process of the CPU. The software engineer checks the test flow to confirm that the instruction execution failed due to a functional problem or that the instruction execution was not complete, resulting in the status flag not being written to the internal storage location.
Later, a software engineer needs to modify software test codes and delete instructions for printing, because the execution time of the instructions on a hardware simulation platform is long, and the efficiency is affected; some of the larger delays also need to be removed. The software engineer needs to ensure that the binary file after the printing instruction and the delay instruction are removed can still be executed on the hardware test platform, and the program running state, including whether the status flag is correctly written, needs to be ensured to be the same as before.
At this point, the first round of software testing is complete, and the problem can be located at this point.
If the first round of test is completed, the problem is concentrated on one test point, but the CPU can not know exactly which instruction executed by the CPU is wrong, and the second round of software test can be adopted. In the second round of test, the starting point writes the state identifier for the last time in the first round of test, then more write state flag instructions are inserted, then whether the write state failure instruction flow of the second round is correct is checked, and the software engineer modifies the code again for the hardware simulation platform.
A third, or even fourth, round of software testing may then be performed.
The key point of problem location is granularity on a time slice, the granularity is smaller, the more precise the position of a program operation error is, and the larger the granularity is.
The software engineer can locate the faulty instruction but the cause is not available. After the software engineer modifies the code, the software engineer can go to the hardware simulation platform for simulation, and the hardware simulation platform can check the hardware behavior, so that whether the logic function is correct or not can be confirmed.
Software and hardware interaction:
software engineers obtain the time point of the error by positioning the error instruction, but cannot know the cause of the error, and the most effective method is to find the same time point by hardware function simulation and check the state of the hardware signal at the moment. The key point of the software and hardware interaction mechanism is that the same program of the software is operated, and an error identifier can also be obtained to indicate the state of the software program which is simulated and reproduced in the FPGA or the chip to operate. By downloading the software program into the storage model.
The hardware simulation platform must contain all the simulation models required by the hardware test platform for testing, and these models must be consistent with the real device behaviors.
The hardware emulation platform must contain memory models from which the CPU can read instructions and execute.
The test code or binary executable provided by the software engineer to the hardware engineer does not contain print instructions or delay instructions because these instructions are executed for long periods of time on the hardware simulation platform and do not have to be replicated. On the simulation platform, a hardware engineer can check the instruction process executed by the CPU and check whether the operation flow is correct. In this process, it is possible to simply check from the simulation model whether the status flag is correct.
If some status flags have unwritten errors but are inconsistent with the test code on the hardware test platform, the software engineer is required to check whether the code executing process on the test platform is the same as the code executing process on the simulation platform, and the hardware engineer is also required to check whether the errors are caused by configuration or unexpected operation, so as to inform the software engineer to modify the errors. The software engineer confirms the correctness of the code again, modifies the code and provides the code for the hardware engineer; if the hardware function is wrong, the basic judgment is that the flow is different or the configuration is wrong. And at the moment, the first interaction of software and hardware is completed.
If the hardware simulation platform correctly reproduces the problems appearing on the test platform, namely the same state flag is not written into the storage model, a hardware engineer can check the logic function, and then the second interaction of software and hardware is completed.
In an FPGA platform, software test code problems can be found through several times of software and hardware interaction, hardware logic function problems can also be found, and software codes or hardware codes can be modified; if the chip test platform is adopted, the same error state mark is found, and a hardware engineer confirms that no problem exists in configuration or use, the problem of the chip logic function can be basically determined.
At this time, software and hardware interaction is carried out again, and the solution is discussed.
Claims (5)
1. A software and hardware co-simulation method is characterized by comprising a software test code, a hardware test platform and a hardware simulation platform; loading the software test code to an FPGA or a chip, and setting a status flag bit for judging the running status of the software test code; the hardware test platform is used for running a software test code and providing a means for reading the internal storage unit; the hardware simulation platform is used for acquiring a state mark generated when the software test code runs so as to judge the running state of the software test code;
the hardware simulation platform comprises an existing hardware simulation tool and a simulation model with the same peripheral function as the FPGA or the chip; the hardware simulation tool is used for simulating during functional design; the simulation model with the same peripheral functions as the FPGA or the chip is consistent with the hardware functions of the hardware test platform and is used for acquiring the state mark of the software test code in the running process;
the software and hardware co-simulation method comprises the following steps:
s1, compiling a test program aiming at the test items;
s2, compiling the program compiled in the step S1 to generate a binary file, and ensuring that the binary file can run on an FPGA or a chip;
s3, loading the binary file generated in the step S2 to a hardware test platform, and judging whether the corresponding verification item passes through the running status flag:
if yes, returning to the step S1, and testing the next test item;
if not, performing the subsequent steps;
s4, modifying the program written in the step S1, ensuring that the program is adapted to a hardware simulation platform, and compiling the modified program into binary codes;
s5, loading the binary code obtained in the step S4 to a hardware simulation platform, carrying out simulation, and checking whether the program runs correctly:
if so, go to the next step S6;
if not, returning to the step S4 to modify the written program again;
s6, comparing the operation results of the hardware test platform and the hardware simulation platform:
if the comparison is consistent, go to step S7;
if the comparison is not consistent, returning to the step S1;
and S7, analyzing the problem by a hardware designer.
2. The software and hardware co-simulation method according to claim 1, wherein the software test code is converted into a binary file by a compiling tool and loaded onto an FPGA or a chip; and meanwhile, setting a state flag bit for judging the running state of the software test code.
3. A software and hardware co-simulation method according to claim 1, wherein the software test code does not include printed characters and time delay for output, thereby improving the efficiency of co-simulation.
4. A software and hardware co-simulation method according to claim 3, wherein in the software and hardware co-simulation method, when a software engineer writes software test codes, a status flag is written into the storage space each time a function point test is completed; if the storage space can find the identifiers, the test of the functional point is completed; if no state mark exists, the functional point corresponding to the state mark fails to test; when the status identifier of a certain functional test point is not read, the software engineer needs to check whether the test flow is normal: comparing through a pointer of the CPU; the software engineer finishes checking the test flow, and confirms that the instruction execution fails due to the functional problem or the instruction execution is not finished, so that the state mark is not written into the internal storage unit; then, a software engineer modifies the software test code, deletes the printing instruction and the delay instruction, and simultaneously ensures that the software test code after deleting the printing instruction and the delay instruction can be executed on a hardware test platform, and the program running state and the state mark writing state are the same as the software test code before modification; at this point, the first round of software testing is completed;
after the first round of test is finished, the problems are concentrated on one test point, but the CPU can not be positioned to execute the error instruction; a second round of software testing is performed: the starting point of the second round of software testing is the position of the last correct writing state mark during the first round of software testing, more writing state mark instructions are inserted after the position, and whether the writing state failure instruction flow of the second round is correct is checked; then, the software engineer modifies the code again for the hardware simulation platform;
and repeating the steps until the set requirements are met.
5. The software and hardware co-simulation method according to claim 4, wherein if the status flag shows an unwritten error but is not consistent with the test code on the hardware test platform, the software engineer checks whether the code is the same as the code in the test platform execution process, and meanwhile the hardware engineer checks whether the error is caused by configuration or unexpected operation and notifies the software engineer to modify the error; the software engineer confirms the correctness of the code again, modifies the code and provides the code for the hardware engineer; if the hardware function is wrong, judging that the hardware function is caused by different processes or configuration errors; at the moment, the first interaction of software and hardware is completed;
if the hardware simulation platform correctly reproduces the problems appearing on the test platform, a hardware engineer checks the logic function, and then the second interaction of software and hardware is completed;
in an FPGA platform, software testing code problems are discovered through software and hardware interaction for a plurality of times, hardware logic function problems are discovered at the same time, and the software testing code problems or the hardware testing code problems are completed by modifying software codes or hardware codes;
and in the chip test platform, the same error state mark is found, and a hardware engineer confirms that no problem exists in configuration or use, so that the problem of the logic function of the chip is determined.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110584450.XA CN113343617B (en) | 2021-05-27 | 2021-05-27 | Software and hardware co-simulation method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110584450.XA CN113343617B (en) | 2021-05-27 | 2021-05-27 | Software and hardware co-simulation method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113343617A CN113343617A (en) | 2021-09-03 |
| CN113343617B true CN113343617B (en) | 2022-07-22 |
Family
ID=77471736
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110584450.XA Active CN113343617B (en) | 2021-05-27 | 2021-05-27 | Software and hardware co-simulation method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113343617B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114330178B (en) * | 2021-12-28 | 2023-03-14 | 杭州朗迅科技有限公司 | Drive system for debugging and verifying embedded hardware circuit |
| CN115630537B (en) * | 2022-12-21 | 2023-03-28 | 长沙北斗产业安全技术研究院股份有限公司 | Navigation signal simulation method and system based on-chip simulation |
| CN117194276B (en) * | 2023-11-06 | 2024-01-23 | 沐曦集成电路(上海)有限公司 | Chip software and hardware joint simulation debugging system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102521444A (en) * | 2011-12-08 | 2012-06-27 | 青岛海信信芯科技有限公司 | Cooperative simulation/verification method and device for software and hardware |
| CN103150441A (en) * | 2013-03-14 | 2013-06-12 | 中山大学 | Software and hardware synergic simulation verification platform and construction method thereof |
| CN106599343A (en) * | 2016-11-01 | 2017-04-26 | 深圳国微技术有限公司 | SOC system verification method and apparatus for improving simulation efficiency |
| CN109669363A (en) * | 2018-10-25 | 2019-04-23 | 中国工程物理研究院计算机应用研究所 | A kind of automation simulation test optimization method based on state behavior tree |
-
2021
- 2021-05-27 CN CN202110584450.XA patent/CN113343617B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102521444A (en) * | 2011-12-08 | 2012-06-27 | 青岛海信信芯科技有限公司 | Cooperative simulation/verification method and device for software and hardware |
| CN103150441A (en) * | 2013-03-14 | 2013-06-12 | 中山大学 | Software and hardware synergic simulation verification platform and construction method thereof |
| CN106599343A (en) * | 2016-11-01 | 2017-04-26 | 深圳国微技术有限公司 | SOC system verification method and apparatus for improving simulation efficiency |
| CN109669363A (en) * | 2018-10-25 | 2019-04-23 | 中国工程物理研究院计算机应用研究所 | A kind of automation simulation test optimization method based on state behavior tree |
Non-Patent Citations (1)
| Title |
|---|
| SoC芯片关键测试技术综述;龙伊雯 等;《电子产品可靠性与环境试验》;20201031;第38卷(第5期);第11-15页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113343617A (en) | 2021-09-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113343617B (en) | Software and hardware co-simulation method | |
| Civera et al. | An FPGA-based approach for speeding-up fault injection campaigns on safety-critical circuits | |
| Ziade et al. | A survey on fault injection techniques | |
| Civera et al. | Exploiting circuit emulation for fast hardness evaluation | |
| US7178115B2 (en) | Manufacturing method and apparatus to avoid prototype-hold in ASIC/SOC manufacturing | |
| TW544523B (en) | Event based test system for testing memory devices | |
| CN112084113B (en) | Configurable automatic test method and system based on embedded simulation verification software | |
| CN109189479B (en) | Parallel automatic verification method for processor instruction set | |
| JPH11328251A (en) | Method for automatically generating operation environment for model inspection | |
| CN117094269B (en) | Verification method, verification device, electronic equipment and readable storage medium | |
| CN115562982A (en) | Reference model debugging method and device, electronic equipment and storage medium | |
| US20100241414A1 (en) | Debugging simulation with partial design replay | |
| US10528689B1 (en) | Verification process for IJTAG based test pattern migration | |
| CN112731117A (en) | Automatic verification method and system for chip, and storage medium | |
| US7065724B2 (en) | Method and apparatus for generating and verifying libraries for ATPG tool | |
| US6760904B1 (en) | Apparatus and methods for translating test vectors | |
| Eklow et al. | Simulation based system level fault insertion using co-verification tools | |
| CN113204939A (en) | Full-chip simulation verification method | |
| KR100939642B1 (en) | Test device generating stimulus based on software, method for testing using the same and computer-readable storage medium storged program for generating the stimulus | |
| Patel et al. | Method and Apparatus for Bug Free Rapid Silicon Bringup | |
| US10060976B1 (en) | Method and apparatus for automatic diagnosis of mis-compares | |
| CN117313650B (en) | Chip test verification method and application device thereof | |
| CN111427731B (en) | Automatic split code stream and verification code stream testing method and system | |
| Hashempour et al. | An integrated environment for design verification of ATE systems | |
| US10572624B2 (en) | Modified design debugging using differential trace back |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: 410000 Room 601, 6 / F, building 14, phase II, Xincheng Science Park, No. 662 Qingshan Road, Changsha high tech Development Zone, Changsha, Hunan Province Applicant after: Changsha Jinwei Information Technology Co.,Ltd. Address before: 6 / F, building 14, phase II, Xincheng science and Technology Park, high tech Zone, Changsha, Hunan 410000 Applicant before: CHANGSHA HAIGE BEIDOU INFORMATION TECHNOLOGY Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |