CN112540288B - Method, system, device and storage medium for chip after silicon verification - Google Patents
Method, system, device and storage medium for chip after silicon verification Download PDFInfo
- Publication number
- CN112540288B CN112540288B CN202011375141.3A CN202011375141A CN112540288B CN 112540288 B CN112540288 B CN 112540288B CN 202011375141 A CN202011375141 A CN 202011375141A CN 112540288 B CN112540288 B CN 112540288B
- Authority
- CN
- China
- Prior art keywords
- breakpoint
- instruction
- execution
- test program
- chip
- 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
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/2851—Testing of integrated circuits [IC]
Abstract
A method, system, apparatus, and storage medium for post-silicon chip verification. The method for chip verification after silicon comprises the following steps: providing a breakpoint during execution of a test program for a chip; interrupting the execution of the test program after the breakpoint is executed, and acquiring a first execution result of the test program which is cut off to the breakpoint; comparing the first execution result with a second execution result of the test program executed in the reference model; and verifying the chip according to the comparison result. The method for verifying the chip after the silicon can improve the coverage rate and the verification efficiency of the verification after the silicon.
Description
Technical Field
Embodiments of the present disclosure relate to a method, system, device, and storage medium for post-silicon chip verification.
Background
In the field of chip verification, the verification process is divided into a pre-silicon stage and a post-silicon stage, which jointly ensure that the produced chips can be correctly used in an application scene. Currently, the chip design field needs to spend nearly 70% of resources on pre-silicon verification (pre-silicon verification) and post-silicon verification (post-silicon validation). As the complexity of chip design has increased, it has become impossible to complete all of the verification components of a chip design in front of silicon. The purpose of post-silicon verification is to ensure that the chip can correctly execute real software under actual working conditions, and to find and locate design problems or defects in manufacturing that cannot be found in pre-silicon verification. Post-silicon verification is becoming more and more important in chip verification links.
Disclosure of Invention
Embodiments of the present disclosure provide a method, system, device, and storage medium for post-silicon chip verification. The method for verifying the chip after the silicon can improve the coverage rate and the verification efficiency of the verification after the silicon.
At least one embodiment of the present disclosure provides a method for post-silicon chip verification, the method comprising: providing a breakpoint during execution of a test program for the chip; interrupting the test program execution after the breakpoint is executed, and acquiring a first execution result of the test program which is cut to the breakpoint; comparing the first execution result with a second execution result of executing the test program in a reference model; and verifying the chip according to the comparison result.
For example, in the method for verifying the chip after silicon according to at least one embodiment of the present disclosure, when the comparison result is inconsistent, it is determined that a problem is found until the breakpoint.
For example, in the method for verifying the chip after silicon according to at least one embodiment of the present disclosure, in response to retirement of the breakpoint after the breakpoint is executed, the first execution result is dumped into a storage unit, and a contrast process is performed to compare the data dumped into the storage unit with the second execution result; and resetting a breakpoint when the comparison result is consistent, and reloading the data dumped into the storage unit into the chip so as to return to the state when the test program is stopped to the breakpoint.
For example, in a method for chip verification after silicon provided in at least one embodiment of the present disclosure, providing a breakpoint during execution of a test program for the chip includes: and selecting the current instruction as a breakpoint instruction in the process of executing the test program.
For example, in a method for verifying a chip after silicon provided in at least one embodiment of the present disclosure, selecting a current instruction as a breakpoint instruction in a process of executing the test program includes: setting a breakpoint instruction set value, counting the number of transmitted instructions in the process of executing the test program through an instruction counter to obtain an instruction count value corresponding to transmitting the current instruction, and marking the current instruction as the breakpoint instruction when the instruction count value is equal to the breakpoint instruction set value.
For example, in the method for verifying a chip after silicon according to at least one embodiment of the present disclosure, the breakpoint instruction set value is a random number.
For example, in a method for chip verification after silicon provided in at least one embodiment of the present disclosure, comparing the first execution result with the second execution result of executing the test program in the reference model includes: in response to retirement of the breakpoint instruction after the breakpoint instruction is executed, dumping the first execution result into the storage unit, and performing a contrast process to compare the data dumped into the storage unit with the second execution result of the corresponding test program in the reference model.
For example, in a method for verifying a chip after silicon provided by at least one embodiment of the present disclosure, in response to retirement of the breakpoint instruction after executing the breakpoint instruction, dumping the first execution result into the storage unit includes: before the breakpoint instruction is retired, executing the transmitted instruction out of order in the process of executing the test program on the chip, wherein the transmitted instruction comprises the breakpoint instruction, and rearranging the transmitted instruction which is executed out of order according to the sequence of transmitting the instruction; and dumping the first execution result of the instruction ending to the breakpoint in the rearranged instruction sequence into the storage unit.
For example, in the method for verifying the chip after silicon according to at least one embodiment of the present disclosure, the instructions following the breakpoint instruction in the rearranged instruction sequence are flushed.
For example, in the method for verifying a chip after silicon according to at least one embodiment of the present disclosure, before dumping the first execution result to a storage unit in response to retirement of the breakpoint instruction after executing the breakpoint instruction, the method further includes: establishing a data protocol for dumping the first execution result into the storage unit; and informing the comparison process of the data protocol, wherein the comparison process reads the dumped data in the storage unit according to the data protocol, and the data protocol comprises a storage format of the first execution result of the test program.
For example, in the method for verifying the chip after silicon according to at least one embodiment of the present disclosure, before retirement of the breakpoint instruction, when the issued instruction has an execution error, all instructions after the instruction having the execution error are flushed away, and the state before the execution error of the issued instruction is recovered; and recovering the counting value counted by the instruction counter into the instruction counting value corresponding to the instruction which does not emit the execution error.
For example, in the method for verifying the chip after silicon according to at least one embodiment of the present disclosure, the execution error includes an execution path prediction error of a branch instruction in the issued instruction, so that the breakpoint instruction is on an incorrect execution path.
For example, in the method for verifying the chip after silicon according to at least one embodiment of the present disclosure, when the comparison result is consistent, the breakpoint is reset, and the comparison process is exited to continue executing the test program.
For example, in the method for verifying a chip after silicon according to at least one embodiment of the present disclosure, when the comparison result is inconsistent and it is determined that a problem is found by the time the breakpoint is reached, the test program returns to the state of the last breakpoint, and it is determined that the problem exists between the breakpoint and the last breakpoint; and reducing the instruction range of the problem to meet the recurrence in the previous simulation environment so as to speed up the positioning of the problem.
For example, in a method for verifying a chip after silicon provided in at least one embodiment of the present disclosure, the reducing the instruction range of the problem to satisfy the recurrence in the pre-simulation environment includes: setting a breakpoint between the breakpoint and the previous breakpoint again, exiting the comparison process, continuing to execute the test program, determining whether the problem is found when the breakpoint is reached through the comparison process, if the problem is found, setting a breakpoint between the current breakpoint and the breakpoint which has no problem found last, if the problem is not found, setting a breakpoint between the current breakpoint and the breakpoint which has no problem found last, and repeatedly executing the step of determining whether the problem is found when the breakpoint is reached until the instruction range of the problem is narrowed to meet the requirement of being reproducible in the previous simulation environment.
At least one embodiment of the present disclosure also provides a system for post-silicon chip verification, including: the device comprises a breakpoint providing module, an execution result obtaining module, a result comparing module and a chip verification module. The breakpoint providing module is configured to provide a breakpoint during execution of a test program for the chip; the execution result acquisition module is configured to interrupt the execution of the test program after the breakpoint is executed, and acquire a first execution result of the test program ending at the breakpoint; a result comparison module configured to compare the first execution result with a second execution result of the test program executed in a reference model; the chip verification module is configured to verify the chip according to the comparison result.
At least one embodiment of the present disclosure also provides an apparatus for post-silicon chip verification, the apparatus comprising a memory and a processor, wherein the memory has stored therein executable code that, when executed by the processor, causes the processor to perform the method for post-silicon chip verification as set forth in any one of the preceding.
At least one embodiment of the present disclosure also provides a computer-readable storage medium having stored thereon executable code, which when executed by a processor, causes the processor to perform a method for post-silicon chip verification as any one of the preceding.
According to the method for verifying the chip after the silicon, the breakpoint is provided, the first execution result and the second execution result of the test program ending to the breakpoint are compared, the chip is verified according to the comparison result, and the coverage rate and the verification efficiency of the chip after the silicon verification can be improved.
Drawings
To more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings of the embodiments will be briefly introduced below, and it is apparent that the drawings in the following description relate only to some embodiments of the present disclosure and are not limiting to the present disclosure.
Fig. 1 is a schematic flow chart diagram of a method for post-silicon chip verification according to at least one embodiment of the present disclosure;
fig. 2 is a schematic flow chart of a method for post-silicon chip verification according to at least another embodiment of the present disclosure;
FIG. 3 is a process diagram of a problem of recurrent discovery provided by at least one embodiment of the present disclosure;
fig. 4 is a process diagram of a positioning problem provided by at least one embodiment of the present disclosure;
FIG. 5 is a schematic flow chart of a replication and localization problem provided by at least another embodiment of the present disclosure;
fig. 6 is a schematic flow chart of setting a breakpoint according to at least one embodiment of the present disclosure;
fig. 7 is a schematic diagram of setting a breakpoint according to at least one embodiment of the present disclosure;
FIG. 8 is a schematic diagram illustrating dumping of a first execution result according to at least one embodiment of the present disclosure;
FIG. 9 is a schematic diagram illustrating dumping of a first execution result into a storage unit according to at least one embodiment of the present disclosure;
fig. 10 is a schematic processing procedure diagram when an instruction execution error occurs according to at least one embodiment of the disclosure;
fig. 11 is a schematic diagram of a system for post-silicon chip verification according to at least one embodiment of the present disclosure;
fig. 12 is a schematic structural diagram of an apparatus for post-silicon chip verification according to at least one embodiment of the present disclosure; and
fig. 13 is a schematic diagram of a storage medium according to at least one embodiment of the present disclosure.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the technical solutions of the embodiments of the present disclosure will be described clearly and completely with reference to the drawings of the embodiments of the present disclosure. It is to be understood that the described embodiments are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the described embodiments of the disclosure without any inventive step, are within the scope of protection of the disclosure.
Unless otherwise defined, technical or scientific terms used herein shall have the ordinary meaning as understood by one of ordinary skill in the art to which this disclosure belongs. The use of "first," "second," and similar terms in this disclosure is not intended to indicate any order, quantity, or importance, but rather is used to distinguish one element from another. Also, the use of the terms "a," "an," or "the" and similar referents do not denote a limitation of quantity, but rather denote the presence of at least one. The word "comprising" or "comprises", and the like, means that the element or item listed before the word covers the element or item listed after the word and its equivalents, but does not exclude other elements or items.
Pre-silicon verification is the verification of the correctness and sufficiency of a chip on an RTL (register-transfer level) behavioral model or netlist (netlist) before the chip is put into manufacturing. And mainstream EDA (electronic design automation) vendors have developed enough tools for pre-silicon verification to help them find and locate problems. The post-silicon verification is performed on an actual chip from the time of chip production to the time of market, and the problems faced by the post-silicon verification include not only design problems (local bugs) but also manufacturing problems (electrical bugs). The significance of the post-silicon verification is mainly due to the following two reasons. First, as chip design scales gradually increase, verification space increases in geometric progression, and verification before relying on silicon alone in a limited time cannot ensure that a chip can be fully verified, some problems remain in the design and need to be found through verification after silicon. Second, the verification before silicon only verifies the correctness of the design logic, and defects in manufacturing cannot be reflected, so that the verification after silicon is required to be covered. At present, few automatic simulation tools are used for verification after silicon, and multiple chip companies independently research and develop relevant verification means and tools after silicon according to the use scenes of chips.
Silicon post verification as the scale of chip design increases, the rate in verification of the entire chip becomes higher and higher. The complexity of post-silicon verification is greatly increased over pre-silicon verification because of the difficulty in controlling, observing, and debugging on an actual post-silicon chip. Meanwhile, the silicon post-verification also needs to solve the problem of the chip in a short time to meet the time for the product to be on the market. Also, the limited controllable means of observation for post-silicon verification makes post-silicon verification very challenging. Because the internal state of a chip can only be peeped through limited chip pins in the running process of the chip, the state of the chip can be seen in real time in the face of huge chip scale and complex design compared with verification before silicon, and the state of the chip is extremely limited.
A silicon post-verification method mainly comprises the following steps. Finding a problem (detect a bug): finding that the running result of the program on the silicon rear chip is inconsistent with the expectation; localization problem (localization of the bug): reducing the problem to the suspect extent, preferably to a certain row of instructions, or to a certain functional unit; determining the root cause (identity the root cause): finding the root cause of the problem, whether it is a design error or a manufacturing error; repairing problems (Fix or bypass the bug): the problem is repaired directly on the circuit by engineering modifications or avoided by turning off some functions by some control bits. At present, a method for adding hardware assertion is commonly used to find problems and locate the problems. And realizing assertion according to error characteristics and hardware logic at a place where errors possibly occur according to chip design requirements, wherein the assertion can be checked in real time in the actual process of the chip, and once a violation is found, the execution is interrupted, and the assertion is further processed by a subsequent flow.
However, the difficulty of the method for increasing the hardware assertion is that the hardware assertion needs to occupy resources on a chip, and only limited hardware assertion can be added, otherwise, the complexity of a design to be verified is increased, and the expenses such as chip area and power consumption are correspondingly increased. Because the number of added hardware assertions is limited, the increase of the hardware assertions where and how to increase the hardware assertions is extremely challenging for the design experience of engineers, and finally all the hardware assertions need to be fully verified in pre-silicon simulation to ensure normal work, so that the verification workload can be remarkably increased.
According to the above, the hardware assertion method has certain limitations, firstly, the requirement of a designer on adding the hardware assertion is high, secondly, the hardware assertion introduces the increase of design complexity and the obvious increase of resources, and finally, because the hardware implementation cannot be modified, if the detection error of the assertion is limited, the method cannot well play a role of detecting errors.
At least one embodiment of the present disclosure provides a method for post-silicon chip verification. The method for chip verification after silicon comprises the following steps: providing a breakpoint during execution of a test program for a chip; interrupting the execution of the test program after the breakpoint is executed, and acquiring a first execution result of the test program ending to the breakpoint; comparing the first execution result with a second execution result of the test program executed in the reference model; and verifying the chip according to the comparison result.
According to the method for verifying the chip after the silicon, provided by the embodiment of the disclosure, by providing the breakpoint, comparing the first execution result and the second execution result of the test program which is cut to the breakpoint, and verifying the chip according to the comparison result, the coverage rate and verification efficiency of the verification after the silicon can be improved.
Embodiments of the present disclosure and examples thereof are described in detail below with reference to the accompanying drawings.
Fig. 1 is a schematic flow chart of a method for post-silicon chip verification according to at least one embodiment of the present disclosure. Fig. 2 is a schematic flow chart of a method for post-silicon chip verification according to at least another embodiment of the present disclosure.
The method for chip verification after silicon provided by the embodiment of the present disclosure shown in fig. 1 includes steps S110-S140. The method for verifying the chip after the silicon provided by the embodiment of the disclosure shown in fig. 2 comprises steps S201-S212.
Step S110: breakpoints are provided during execution of a test program for a chip.
For example, in some embodiments, as shown in fig. 2, step S201: the test is started. For example, a test program is executed on the finished chip to verify the chip. The test program may be a piece of code for testing or an actual piece of software, and the embodiments of the present disclosure are not limited thereto. The flow proceeds to step S202: and executing the test program. And executing the test program on the chip and obtaining an execution result in the execution process of the test program.
For example, a breakpoint is provided during program execution, for example, by setting a random number, and by counting the transmitted instructions, when the count value of the instruction is the same as the random number, the instruction is marked as a breakpoint. The exemplary setting manner of the breakpoint will be described in detail later in the embodiments of the present disclosure. The method for verifying the chip after the silicon provided by the embodiment of the disclosure can increase the controllability of the verification after the silicon and improve the coverage rate by providing the breakpoint.
For example, in other embodiments, the manner in which breakpoints are provided sets breakpoints on instruction addresses, storage data addresses, or on the storage data itself, interrupting execution of the test program and jumping to a processing function when the test program takes a value from an address, fetches/stores, or accesses data of a value.
For example, as shown in fig. 2, step S207: a second execution result in the reference model is obtained. For example, the reference model is a behavior model for executing the instruction stream, and the test program is executed using the reference model to obtain a second execution result of the test program. The second execution result is used for comparing with a first execution result obtained after the chip which carries out the silicon post-verification executes the test program, and the problem in the chip is found according to the comparison result.
Step S120: and interrupting the test program execution after the breakpoint is executed, and acquiring a first execution result of the test program ending to the breakpoint. For example, as shown in fig. 2, in the process of executing the test program on the chip, the process proceeds to step S203: the breakpoint is bumped (e.g., an instruction marked as a breakpoint) and the execution of the test program enters a self-trapping state, i.e., the test program execution is interrupted after the breakpoint is executed. After the execution of the test program enters the self-trapping state, a first execution result of the test program (including an execution result of the breakpoint and an execution result of an instruction before the breakpoint) which is cut to the breakpoint is obtained for comparison with a second execution result of the reference model.
For example, in some embodiments, the first execution result is dumped to the storage unit in response to retirement of the breakpoint after the breakpoint is executed. As shown in fig. 2, step S204: and dumping the first execution result to a storage unit. By the method for dumping the execution result into the storage unit, the difficulty of hardware implementation can be reduced, and the hardware cost is reduced to a certain extent. Then, the process proceeds to step S205: a jump is made to the processing function. I.e. jump to the comparison process of the first execution results to find problems in the chip design.
For example, in the embodiments of the present disclosure, the storage unit may be a unit selected from the inside of the chip (e.g., a cache in the chip, such as a first-level cache, a second-level cache, a third-level cache, etc.) and may be a unit external to the chip (e.g., an external memory) for storing data. In addition, the first execution result is dumped into the storage unit by designing microcode according to a certain format, and the process will be described in detail later.
Step S130: the first execution result is compared to a second execution result of executing the test program in the reference model. For example, the second execution result corresponds to the test program executing until the cutoff is at the breakpoint. For example, as shown in fig. 2, step S206: the first execution result is compared with the second execution result. At the end-to-break point, if there is no problem with the chip design, the comparison result of the first execution result and the second execution result should be consistent, i.e., no difference; if there is a problem in the chip design, the first execution result and the second execution result will be inconsistent, i.e. there will be some differences.
Step S140: and verifying the chip according to the comparison result. For example, as shown in fig. 2, step S208: and judging whether the comparison result of the first execution result and the second execution result is consistent. At this time, if the comparison result of the first execution result and the second execution result matches, no problem is found, and the process proceeds to step S210. If the comparison result of the first execution result and the second execution result is not consistent, the process proceeds to step S209: a problem is found. In some embodiments of the present disclosure, the chip is verified according to the comparison result, which may improve the efficiency of the post-silicon chip verification.
For example, in some embodiments, when the comparison results are consistent, the breakpoint is reset, and the comparison process is exited and the test program continues to be executed.
For example, in some embodiments, a transfer-to-compare process compares the data dumped into the storage unit with the second execution result; and when the comparison result is consistent, resetting the breakpoint, and reloading the data dumped into the storage unit into the chip so as to return to the state when the test program is stopped to the breakpoint.
As shown in fig. 2, when the comparison result is consistent, the process proceeds to step S210: and reloading the data dumped into the storage unit into the chip. The above steps are exactly opposite to dumping the first execution result into the storage unit, and after step S210 is completed, the internal state of the test program executed on the chip should be consistent with the state when the breakpoint occurs. The flow advances to step S211: and setting a breakpoint. At this point, a breakpoint needs to be reset (for example, by randomly setting a new count value) to continue the verification of the chip.
Step S212: the processing function is exited. After the breakpoint is reset, a processing function (i.e., a comparison process) is pushed out. Then, the process proceeds to step S202, and the test program is executed continuously to verify whether the subsequent instruction execution will find a problem.
For example, in some embodiments, when the comparison results are inconsistent, it is determined that problems are found by the time the breakpoint is reached. When a problem is found, it can be continued to locate the problem, i.e. localize the problem to a small extent. For example, in the case that the found problem can be stably reproduced, the suspected area can be further reduced by reducing the count value of the break point, so as to realize fast iteration and speed up problem positioning. The following detailed description is made with reference to the accompanying drawings.
Fig. 3 is a process diagram for reproducing a discovered problem according to at least one embodiment of the present disclosure. Fig. 4 is a process diagram of a positioning problem according to at least one embodiment of the present disclosure. Fig. 5 is a schematic flow chart of a recurring and positioning problem provided by at least another embodiment of the present disclosure. The process of reproducing the discovered problem provided by the embodiment shown in fig. 3 includes step S310. The process of positioning problem provided by the embodiment shown in fig. 4 includes step S410, step S411 and step S412. The process of reproducing and locating problems provided by the embodiment shown in fig. 5 includes steps S501 to S509.
For example, in some embodiments, when the comparison results are inconsistent, it is determined that a problem is found by the time the breakpoint is reached, the test program is returned to the state of being executed to the last breakpoint, and it is determined that a problem exists between the breakpoint and the last breakpoint. As shown in fig. 5, step S501: and determining that the problem is found by ending the breakpoint if the comparison result is inconsistent. As shown in fig. 3, step S310: the found problems are reproduced. Step S502 in fig. 5: returning to the state where the test program executed to the last breakpoint, it is determined that a problem exists between the breakpoint and the last breakpoint.
For example, as shown in FIG. 3, from the breakpoint D1 where a problem is found, the comparison process exits, and returns to the last breakpoint D2 (also referred to as the recovery point H1, the breakpoint D2 is a breakpoint where no problem is found). The problem is reproduced by re-executing the segment of the test program that found the problem between the last breakpoint D2 and the breakpoint D1 that found the problem. When the found problem can be reproduced between the last breakpoint D2 and the breakpoint D1, the area where the problem is located is determined, and the area where the problem is located needs to be further narrowed, that is, the problem is located.
For example, in some embodiments, the instruction range in which the problem is located is narrowed to meet the recurrence in the previous simulation environment to speed up the positioning of the problem. For example, the pre-emulation environment may be selected as an RTL emulation environment, and the instruction range of the problem needs to be narrowed due to the limitation of the pre-emulation environment on the program length.
For example, as shown in fig. 4, step S410: and (4) positioning. For example, the breakpoint D1 at which a problem is found is used as an end point, and the breakpoint D2 at which a problem is not found is used as a start point. Between the break point D1 and the break point D2, whenever the problem can be reproduced, by step S411: the breakpoint of the problem is found forward. And through step S412: and moving backward to avoid the break point of the problem, so as to reduce the instruction range of the problem to be suitable for reappearing in the former simulation environment.
For example, in some embodiments, narrowing the range of instructions in which the problem is located to meet the recurrence in the prior simulated environment includes: setting breakpoints between the breakpoints and the previous breakpoint again, exiting the comparison process, continuing to execute the test program, determining whether the problem is found when the breakpoint is reached through the comparison process, if the problem is found, setting the breakpoint between the current breakpoint and the breakpoint which is not found with the problem, if the problem is not found, setting the breakpoint between the current breakpoint and the breakpoint which is not found with the problem, and repeatedly executing the step of determining whether the problem is found when the current breakpoint is reached until the instruction range of the problem is narrowed to meet the requirement of reappearance in the previous simulation environment.
For example, as shown in fig. 5, step S503: the breakpoint is set again between the breakpoint D1 and the last breakpoint D2. A new breakpoint is set through step S503, and then step S504 is entered: and exiting the comparison process and continuing to execute the test program. The test program continues to execute steps S203 to S208 in fig. 2 to determine whether the problem can be reproduced by the comparison process until the breakpoint set again between the breakpoint D1 and the last breakpoint D2. Therefore, step S505 of fig. 5 is further performed: whether a problem is found by the break point is determined through a comparison process. When no problem is found, the breakpoint (current breakpoint) set between the breakpoints D1 and D2 finds no problem, and a problem exists between the current breakpoint and the breakpoint D1. At this time, the flow proceeds to step S506: a breakpoint is set between the current breakpoint and the breakpoint (breakpoint D1) at which the problem was last found, thereby further reducing the scope of the problem. When a problem is found, the breakpoint (current breakpoint) set between the breakpoint D1 and the breakpoint D2 finds the problem, and the problem exists between the current breakpoint and the breakpoint D2. At this time, the flow proceeds to step S507: a breakpoint is set between the current breakpoint and the last breakpoint (breakpoint D2) at which no problem was found, thereby further reducing the range of the problem.
The flow proceeds to step S508: and judging whether the instruction range of the problem is narrowed to meet the requirement of the former simulation environment or not. At this time, the instruction range in which the problem exists is the range between the current breakpoint in step S506 and the breakpoint (breakpoint D1) at which the problem was found last or the range between the current breakpoint in step S507 and the breakpoint (breakpoint D2) at which the problem was not found last. When the instruction range of the problem is narrowed to meet the requirement of recurrence in the previous simulation environment, the step S509 is performed to recurrence the instruction range of the determined problem in the previous simulation environment, so as to more accurately position the problem, and further correct the chip according to the positioning of the problem. When the instruction range of the problem is not narrowed to meet the requirement of recurrence in the previous simulated environment, the step S054 is executed repeatedly, and the step of determining whether the problem is found by the current breakpoint (the breakpoint set in step S506 or step S507) is executed repeatedly until the instruction range of the problem is narrowed to meet the requirement of recurrence in the previous simulated environment.
For example, in some embodiments, providing a breakpoint during execution of a test program for a chip includes: the current instruction is selected as a breakpoint instruction during execution of the test program. For example, an instruction when the test program is executed is marked as a breakpoint instruction to interrupt the test program into the comparison process when the breakpoint instruction is retired (e.g., when the breakpoint instruction finishes execution and commits execution results). The breakpoint instruction is set as a certain instruction of which the breakpoint can be accurate to a certain cycle, so that the execution effect of the cycle cannot be interrupted, and the verification effect is improved to a certain extent. The instruction for providing a breakpoint is described in detail below with reference to the drawings.
Fig. 6 is a schematic flow chart of setting a breakpoint according to at least one embodiment of the present disclosure. Fig. 7 is a schematic diagram of setting a breakpoint according to at least one embodiment of the present disclosure. The breakpoint setting flow provided in the embodiment shown in fig. 6 includes steps S610 to S630. Selecting the current instruction as the breakpoint instruction in the process of executing the test program includes steps S610 to S630. The embodiment shown in fig. 7 provides a process for setting a breakpoint, which includes steps S710 to S740.
As illustrated in fig. 6, step S610: and setting a breakpoint instruction set value. For example, in some examples, the instruction setting value is a random number, and the random number can increase the coverage of the breakpoint and increase the coverage of chip verification.
Step S620: and counting the number of the transmitted instructions in the process of executing the test program through the instruction counter to obtain an instruction count value corresponding to the current instruction.
For example, as shown in fig. 7, in the process of executing the test program, the order of transmitting the instructions, i.e., the order of transmitting the instruction stream, is from 0 to n. The number of instructions transmitted per beat in the graph is counted by an instruction counter. Step S710: the issued instructions are counted. The counter starts counting at the time of instruction issue, and since processors now all issue more, the counter is updated each time. And counting the number of the transmitted instructions in the process of executing the test program through the instruction counter to obtain an instruction count value for transmitting the current instruction. That is, the instruction count value obtained by the instruction counter corresponds to the instruction issue order.
Step S630: when the instruction count value is equal to the breakpoint instruction set value, the current instruction is marked as a breakpoint instruction.
For example, as shown in fig. 7, step S720: the instruction count value of the current instruction is equal to the breakpoint instruction set value. For example, the instruction counter determines whether the current beat instruction needs to generate a breakpoint according to the recorded breakpoint instruction set value and the instruction count value corresponding to the current beat transmission instruction. When the instruction count value is not equal to the breakpoint instruction set value, namely the count value is not equal to the expected value, the quantity of the transmitted instructions is directly accumulated. When the instruction count value is equal to the breakpoint instruction set value, namely the count value is equal to the expected value, a breakpoint label is marked on the current instruction. I.e. mark the current instruction as a breakpoint instruction. As shown in fig. 7, it is assumed that the count value and the expected value are both m, where m is less than n. The mth transmitted instruction is marked as a breakpoint instruction. In the method for setting the breakpoint, the instruction counter sees an instruction stream in a counting mode of the instruction counter, the breakpoint can be set at any instruction in the cycle of the first time, and controllability is greatly enhanced.
For example, in some embodiments, comparing the first execution result with a second execution result of executing the test program in the reference model comprises: and in response to the retirement of the breakpoint instruction after the breakpoint instruction is executed, dumping a first execution result into the storage unit, and turning into a comparison process to compare data dumped into the storage unit with a second execution result of the corresponding test program in the reference model.
For example, in some embodiments, dumping the first execution result into the storage unit in response to retirement of the breakpoint instruction after execution of the breakpoint instruction includes: before the retirement of the breakpoint instruction, carrying out-of-order execution on the transmitted instruction in the process of executing the test program on the chip, wherein the transmitted instruction comprises the breakpoint instruction, and rearranging the transmitted instruction which is executed out of order according to the sequence of the transmitted instruction; and dumping a first execution result of the instruction ending to the breakpoint in the rearranged instruction sequence into a storage unit.
For example, in some embodiments, instructions following the breakpoint instruction in the rearranged instruction sequence are flushed.
For example, as shown in FIG. 7, the instruction marked as a breakpoint (the m-th issued instruction in the figure) executes out of order normally in the pipeline as other instructions. The flow proceeds to step S730: the instructions are reordered. For example, issued instructions that are executed out of order are reordered according to the order in which the instructions are issued. After rearrangement (Reorder), when the instruction waits for retirement (submission result), whether the instruction has a breakpoint or not is judged, the first execution result of the instruction ending to the breakpoint is allowed to be submitted normally, and the instruction after the breakpoint instruction is flushed from the instruction pipeline. The flow proceeds to step S740: and executing the test program to enter the trap state, and transferring to a processing function to perform subsequent operation. And then dumping a first execution result of the instruction ending to the breakpoint in the rearranged instruction sequence into a storage unit.
For example, in some embodiments, before dumping the first execution result into the storage unit in response to retirement of the breakpoint instruction after executing the breakpoint instruction, the method further includes: establishing a data protocol for dumping the first execution result into a storage unit; and informing the comparison process of the data protocol, wherein the comparison process reads the dumped data in the storage unit according to the data protocol, and the data protocol comprises a storage format of a first execution result of the test program.
Fig. 8 is a schematic diagram of dumping a first execution result according to at least one embodiment of the disclosure. Fig. 9 is a schematic diagram of dumping a first execution result into a storage unit according to at least one embodiment of the present disclosure.
As shown in fig. 8, for example, the chip includes a processor, such as a CPU, DSP, GPU, etc. The processor, for example a CPU, comprises general purpose registers GP2, other registers GP1 and a first execution result R1 up to the current instruction. After the instruction with the breakpoint tag is trapped, the first execution result R1 (i.e., the internal state) needs to be saved. For example, data saving is performed by microcode UCD (microcode). After the current instruction is trapped by itself, the current instruction enters the section of microcode and dumps the first execution result R1 into an external storage unit RM1 according to the convention format, and after the data storage is finished, the current instruction jumps to the corresponding processing function entry. The agreed format is, for example, a data protocol for dumping the first execution result into the storage unit. For example, the data protocol includes a storage format of a first execution result of the test program.
For example, in other embodiments, the dumping of data may be accomplished as follows. And reading the data to be dumped (first execution result) by the processing function and saving by providing a corresponding instruction interface.
It should be noted that the storage unit RM1 may also be located inside the processor, and the embodiment of the disclosure is not limited thereto.
As shown in fig. 9, the memory unit RM1 includes a plurality of general purpose registers, a plurality of status registers, and the like. The storage format is a data storage mode in the storage unit RM1, data is stored in the storage unit RM1 according to what order or rule, the order or rule of data storage is notified to the comparison process, and the comparison process reads the stored data from the storage unit RM1 according to the order or rule of data storage. It should be noted that the storage format may be set as needed, and does not need to be fixed. The data is read in the data dump and comparison process, so that the increase of hardware interfaces in the chip verification process can be reduced, and the hardware complexity is reduced.
The storage unit RM1 is implemented as a Random Access Memory (RAM), for example.
For example, in some embodiments, before retirement of the breakpoint instruction, when an execution error occurs in the issued instruction, all instructions following the instruction in which the execution error occurred are flushed back to a state before the execution error occurred in the issued instruction; and recovering the counting value counted by the instruction counter into the instruction counting value corresponding to the instruction which does not transmit the execution error.
For example, in some embodiments, the execution error comprises an execution path prediction error for a branch instruction in the issued instructions, resulting in a breakpoint instruction being on the wrong execution path.
Fig. 10 is a schematic processing procedure diagram when an instruction execution error occurs according to at least one embodiment of the disclosure. The embodiment shown in fig. 10 provides a processing procedure when an instruction execution error occurs, including steps S810 to S830.
As shown in fig. 10, step S810: find instruction execution error/find branch instruction execution path prediction error. At this time, since the instruction marking the breakpoint (breakpoint D3) cannot necessarily be retired (executed and the execution result is committed), when an instruction execution error is found before the breakpoint instruction/an execution path prediction error of the branch instruction is found, at this time, the erroneously executed instruction after the position where the error is found is flushed, that is, the breakpoint instruction (breakpoint D3) is flushed. Therefore, step S820 is to be entered: the count value is restored to the count value of the instruction corresponding to the instruction for which the execution error was not issued. That is, the count value of the instruction counter is restored to the instruction count value of the instruction corresponding to the flushing pipeline. Then, the process proceeds to step S830: and resetting the breakpoint. The breakpoint D3' is reset. The test program continues to be executed and the instruction counter resumes counting until breakpoint D3' is encountered. The method can be correctly returned to the chip verification method under the condition that the execution of the test program is wrong, so that the controllability of the chip verification method after silicon provided by the embodiment of the disclosure is high.
For example, at least one embodiment of the present disclosure also provides a system for post-silicon chip verification. Fig. 11 is a schematic diagram of a system for post-silicon chip verification according to at least one embodiment of the present disclosure.
For example, in some embodiments, as shown in FIG. 11, a system 300 for post-silicon chip verification includes: a breakpoint providing module 310, an execution result obtaining module 320, a result comparing module 330, and a chip verifying module 340.
For example, the breakpoint providing module 310 is configured to provide a breakpoint during execution of a test program for a chip. For example, a breakpoint is provided during program execution, for example, by setting a random number, and by counting the number of transmitted instructions, when the count value of the instruction is the same as the random number, the instruction is marked as a breakpoint.
For example, the execution result obtaining module 320 is configured to interrupt the test program execution after the breakpoint is executed, and obtain the first execution result of the test program that is up to the breakpoint. For example, a breakpoint (e.g., an instruction marked as a breakpoint) is bumped during execution of the test program on the chip, and the execution of the test program enters a self-trapping state, i.e., the execution of the test program is interrupted after the breakpoint is executed. After the execution of the test program enters the trap state, a first execution result of the test program (including an execution result of the breakpoint and an execution result of an instruction before the breakpoint) up to the breakpoint is obtained for comparison with a second execution result of the reference model.
For example, the result comparison module 330 is configured to compare the first execution result with a second execution result of the test program executed in the reference model. For example, a reference model is a behavioral model of an executing instruction stream, and a test program is executed using the reference model to obtain all correct execution results of the test program. For example, the second execution result also corresponds to the test program executing to the point where the cutoff is at the breakpoint. For example, the first execution result is compared to the second execution result. At the point of ending to the breakpoint, if there is no problem with the chip design, the comparison result of the first execution result and the second execution result should be consistent, i.e. no difference; if there is a problem in the chip design, the first execution result and the second execution result will be inconsistent, i.e. there will be some differences.
For example, the chip verification module 340 is configured to verify the chip according to the comparison result. For example, it is determined whether the comparison result of the first execution result and the second execution result is consistent. At this time, if the comparison result of the first execution result and the second execution result is consistent, no problem is found. If the comparison result of the first execution result and the second execution result is inconsistent, it is indicated that a problem is found.
The system for verifying the chip after the silicon provided by the embodiment can improve the coverage rate and the verification efficiency of the verification after the silicon by providing the breakpoint, comparing the first execution result and the second execution result of the test program ending to the breakpoint and verifying the chip according to the comparison result.
Fig. 12 is a schematic structural diagram of an apparatus for post-silicon chip verification according to at least one embodiment of the present disclosure.
The apparatus 400 for post-silicon chip verification shown in fig. 12 is, for example, suitable for use in implementing the method for post-silicon chip verification provided by the embodiments of the present disclosure. The device 400 for verifying the chip after silicon may be a terminal device such as a personal computer, a notebook computer, a tablet computer, a mobile phone, etc., or may be a workstation, a server, a cloud service, etc. It should be noted that the apparatus 400 for post-silicon chip verification shown in fig. 12 is only an example and does not bring any limitations to the function and scope of use of the embodiments of the present disclosure.
As shown in fig. 12, the apparatus 400 for post-silicon chip verification may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 410, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 420 or a program loaded from a storage device 480 into a Random Access Memory (RAM) 430. In the RAM 430, various programs and data necessary for the operation of the apparatus 400 for the chip verification after silicon are also stored. The processing device 410, the ROM 420, and the RAM 430 are connected to each other by a bus 440. An input/output (I/O) interface 450 is also connected to bus 440.
Generally, the following devices may be connected to the I/O interface 450: input devices 460 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 470 including, for example, a Liquid Crystal Display (LCD), speakers, vibrators, or the like; storage 480 including, for example, magnetic tape, hard disk, etc.; and a communication device 490. The communication means 490 may allow the apparatus 400 for post-silicon chip verification to communicate wirelessly or by wire with other electronic devices to exchange data. While FIG. 12 illustrates an apparatus 400 for post-silicon chip verification including various means, it is to be understood that not all of the illustrated means are required to be implemented or provided, and that the apparatus 400 for post-silicon chip verification may alternatively be implemented or provided with more or fewer means.
For example, the above-described method for post-silicon chip verification may be implemented as a computer software program according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a non-transitory computer readable medium, the computer program comprising program code for performing the above-described method for post-silicon chip verification. In such embodiments, the computer program may be downloaded and installed from a network through communication device 490, or installed from storage device 480, or installed from ROM 420. When executed by the processing device 410, the computer program may perform the functions defined in the method for post-silicon chip verification provided by the embodiments of the present disclosure.
At least one embodiment of the present disclosure also provides a storage medium for storing non-transitory computer program executable code (e.g., computer executable instructions) that, when executed by a computer, may implement the method for post-silicon chip verification described in any of the embodiments of the present disclosure; alternatively, the non-transitory computer program executable code may implement the method for post-silicon chip verification described in any of the embodiments of the present disclosure when executed by a computer.
Fig. 13 is a schematic diagram of a storage medium according to at least one embodiment of the present disclosure. As shown in fig. 13, the storage medium 500 non-temporarily stores computer program executable code 501. For example, the computer program executable code 501 may perform one or more steps according to the method for post-silicon chip verification described above when executed by a computer.
For example, the storage medium 500 may be applied to the apparatus 400 for post-silicon chip verification described above. For example, the storage medium 500 may be the memory 420 in the apparatus 400 for post-silicon chip verification shown in fig. 13. For example, the related description about the storage medium 500 may refer to the corresponding description of the memory 420 in the device 400 for chip verification after silicon shown in fig. 13, and will not be repeated here.
In addition to the above description, there are the following points to be explained:
(1) The drawings of the embodiments of the disclosure only relate to the structures related to the embodiments of the disclosure, and other structures can refer to the common design.
(2) Without conflict, embodiments of the present disclosure and features of the embodiments may be combined with each other to arrive at new embodiments.
The above is only a specific embodiment of the present disclosure, but the scope of the present disclosure is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present disclosure, and shall be covered by the scope of the present disclosure. Therefore, the protection scope of the present disclosure shall be subject to the protection scope of the claims.
Claims (16)
1. A method for post-silicon chip verification, comprising:
providing a breakpoint during execution of a test program for the chip;
interrupting the test program execution after the breakpoint is executed, and acquiring a first execution result of the test program which is cut to the breakpoint;
comparing the first execution result with a second execution result of executing the test program in a reference model; and
the chip is verified according to the comparison result,
wherein providing a breakpoint during execution of a test program for the chip comprises: selecting a current instruction as a breakpoint instruction during execution of the test program,
selecting a current instruction as a breakpoint instruction in the process of executing the test program, wherein the selecting step comprises the following steps:
a breakpoint instruction set value is set,
counting the number of transmitted instructions during the execution of the test program by an instruction counter to obtain an instruction count value corresponding to transmitting the current instruction,
when the instruction count value is equal to the breakpoint instruction set value, marking the current instruction as a breakpoint instruction.
2. The method of claim 1, wherein,
and when the comparison result is inconsistent, determining that the problem is found until the breakpoint is reached.
3. The method of claim 1, wherein,
in response to retirement of the breakpoint after execution of the breakpoint, dumping the first execution result into a storage unit,
transferring to a comparison process to compare the data dumped into the storage unit with the second execution result;
when the comparison result is consistent, resetting the breakpoint,
and reloading the data dumped into the storage unit into the chip so as to return to the state when the test program is cut off to the breakpoint.
4. The method of claim 1, wherein the breakpoint instruction set value is a random number.
5. The method of claim 1, wherein comparing the first execution result with the second execution result of executing the test program in the reference model comprises:
in response to retirement of the breakpoint instruction after execution of the breakpoint instruction, dumping the first execution result into a storage unit,
and transferring to a comparison process to compare the data dumped into the storage unit with the second execution result of the corresponding test program in the reference model.
6. The method of claim 5, wherein dumping the first execution result into the memory unit in response to retirement of the breakpoint instruction after execution of the breakpoint instruction comprises:
before the breakpoint instruction is retired, executing the transmitted instruction out of order in the process of executing the test program on the chip, wherein the transmitted instruction comprises the breakpoint instruction, and rearranging the transmitted instruction which is executed out of order according to the sequence of the transmitted instruction; and
and dumping the first execution result of the instruction ending to the breakpoint in the rearranged instruction sequence into the storage unit.
7. The method of claim 6, wherein instructions in the rearranged instruction order that follow the breakpoint instruction are flushed.
8. The method of claim 5, wherein in response to retirement of the breakpoint instruction after execution of the breakpoint instruction, prior to dumping the first execution result into a storage unit, further comprising:
establishing a data protocol for dumping the first execution result into the storage unit; and
informing the comparison process of the data protocol, reading the dumped data in the storage unit according to the data protocol by the comparison process,
wherein the data protocol includes a storage format of the first execution result of the test program.
9. The method of claim 5, wherein,
before the breakpoint instruction is retired, when the transmitted instruction execution error occurs, all instructions behind the instruction with the execution error are flushed, and the state before the transmitted instruction execution error occurs is recovered; and
and recovering the counting value counted by the instruction counter into the instruction counting value corresponding to the instruction which does not emit the execution error.
10. The method of claim 9, wherein,
the execution error comprises an execution path prediction error for a branch instruction in the issued instructions, resulting in the breakpoint instruction being on the wrong execution path.
11. The method of any one of claims 3, 5 and 8,
resetting a breakpoint when the comparison results are consistent, an
And exiting the comparison process and continuing to execute the test program.
12. The method of claim 1, wherein,
when the comparison result is inconsistent, determining that a problem is found by the breakpoint, returning to the state that the test program executes to the last breakpoint, and determining that the problem exists between the breakpoint and the last breakpoint; and
and reducing the instruction range of the problem to meet the recurrence requirement in the prior simulation environment so as to accelerate the positioning of the problem.
13. The method of claim 12, wherein narrowing the range of instructions in which the problem is located to meet recurrence in the pre-simulation environment comprises:
resetting the breakpoint between the breakpoint and the last breakpoint,
the comparison process is exited, the test program is continuously executed, whether the problem is found when the breakpoint is reached is determined through the comparison process,
if the problem is found, a breakpoint is set between the current breakpoint and the last breakpoint without the problem,
if the problem is not found, a breakpoint is set between the current breakpoint and the breakpoint of the last found problem,
and repeatedly executing the step of determining whether a problem is found by the current breakpoint until the instruction range of the problem is narrowed to meet the condition that the problem can be reproduced in the previous simulation environment.
14. A system for post-silicon chip verification, comprising:
a breakpoint providing module configured to provide a breakpoint during execution of a test program for the chip;
the execution result acquisition module is configured to interrupt the execution of the test program after the breakpoint is executed, and acquire a first execution result of the test program ending to the breakpoint;
a result comparison module configured to compare the first execution result with a second execution result of the test program executed in a reference model; and
a chip verification module configured to verify the chip according to the comparison result,
wherein the breakpoint providing module is configured to select a current instruction as a breakpoint instruction during execution of the test program,
selecting a current instruction as a breakpoint instruction in the process of executing the test program, wherein the selecting step comprises the following steps:
a breakpoint instruction set value is set,
counting the number of transmitted instructions during the execution of the test program by an instruction counter to obtain an instruction count value corresponding to transmitting the current instruction,
when the instruction count value is equal to the breakpoint instruction set value, marking the current instruction as a breakpoint instruction.
15. An apparatus for post-silicon chip verification, comprising:
a processor; and
memory, wherein computer executable code is stored in the memory, which when executed by the processor performs the method for post silicon chip verification according to any one of claims 1 to 13.
16. A computer readable storage medium having stored thereon executable code which, when executed by a processor, causes the processor to perform the method for post silicon chip verification of any of claims 1-13.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011375141.3A CN112540288B (en) | 2020-11-30 | 2020-11-30 | Method, system, device and storage medium for chip after silicon verification |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011375141.3A CN112540288B (en) | 2020-11-30 | 2020-11-30 | Method, system, device and storage medium for chip after silicon verification |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112540288A CN112540288A (en) | 2021-03-23 |
| CN112540288B true CN112540288B (en) | 2023-02-21 |
Family
ID=75016543
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011375141.3A Active CN112540288B (en) | 2020-11-30 | 2020-11-30 | Method, system, device and storage medium for chip after silicon verification |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112540288B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101714114A (en) * | 2009-12-21 | 2010-05-26 | 北京龙芯中科技术服务中心有限公司 | Device and method for supporting processor silicon post debugging |
| CN103299282A (en) * | 2010-12-02 | 2013-09-11 | 超威半导体公司 | Debug state machine and processor including the same |
| CN104471545A (en) * | 2012-05-07 | 2015-03-25 | 密克罗奇普技术公司 | Device having configurable breakpoint based on interrupt status |
| CN104573228A (en) * | 2015-01-06 | 2015-04-29 | 中国人民解放军国防科学技术大学 | Microprocessor silicone-fed verification device and method for compatibility design |
| CN105589993A (en) * | 2015-12-18 | 2016-05-18 | 中国科学院微电子研究所 | Microprocessor function verifying equipment and method |
| CN105760612A (en) * | 2016-02-26 | 2016-07-13 | 中国科学院计算技术研究所 | Assertion detection device, method, system and chip for post-silicon chip verification |
| CN106324476A (en) * | 2015-06-30 | 2017-01-11 | 龙芯中科技术有限公司 | On-chip debug and diagnostic method, device and chip |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04306735A (en) * | 1991-04-04 | 1992-10-29 | Toshiba Corp | Asynchronous interruption inhiobition mechanism |
| US7225431B2 (en) * | 2002-10-24 | 2007-05-29 | International Business Machines Corporation | Method and apparatus for setting breakpoints when debugging integrated executables in a heterogeneous architecture |
| US7774647B2 (en) * | 2005-01-28 | 2010-08-10 | International Business Machines Corporation | Method for counting instructions for logging and replay of a deterministic sequence of events |
| CN102193860B (en) * | 2010-03-10 | 2015-04-22 | 上海海尔集成电路有限公司 | Microcontroller online debugging circuit and method as well as microcontroller |
| CN110515754B (en) * | 2018-05-22 | 2021-01-26 | 深圳云天励飞技术有限公司 | Debugging system and method of neural network processor |
-
2020
- 2020-11-30 CN CN202011375141.3A patent/CN112540288B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101714114A (en) * | 2009-12-21 | 2010-05-26 | 北京龙芯中科技术服务中心有限公司 | Device and method for supporting processor silicon post debugging |
| CN103299282A (en) * | 2010-12-02 | 2013-09-11 | 超威半导体公司 | Debug state machine and processor including the same |
| CN104471545A (en) * | 2012-05-07 | 2015-03-25 | 密克罗奇普技术公司 | Device having configurable breakpoint based on interrupt status |
| CN104573228A (en) * | 2015-01-06 | 2015-04-29 | 中国人民解放军国防科学技术大学 | Microprocessor silicone-fed verification device and method for compatibility design |
| CN106324476A (en) * | 2015-06-30 | 2017-01-11 | 龙芯中科技术有限公司 | On-chip debug and diagnostic method, device and chip |
| CN105589993A (en) * | 2015-12-18 | 2016-05-18 | 中国科学院微电子研究所 | Microprocessor function verifying equipment and method |
| CN105760612A (en) * | 2016-02-26 | 2016-07-13 | 中国科学院计算技术研究所 | Assertion detection device, method, system and chip for post-silicon chip verification |
Non-Patent Citations (2)
| Title |
|---|
| 一款基于SPARC V8指令集体系结构的系统芯片的功能验证;杨爽等;《南通大学学报(自然科学版)》;20161220;9-17 * |
| 基于扫描链的可编程片上调试系统;陈华军等;《高技术通讯》;20150630;584-592 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112540288A (en) | 2021-03-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10083262B2 (en) | Deadlock detection in hardware design using assertion based verification | |
| CN109032879B (en) | Multi-core processor memory access data detection and verification system and method | |
| TWI454925B (en) | Psmi using at-speed scan capture | |
| US11475193B2 (en) | Control path verification of hardware design for pipelined process | |
| US11204859B2 (en) | Partial-results post-silicon hardware exerciser | |
| US9092567B2 (en) | Systems and methods for analyzing transactions in a computer system | |
| US7124383B2 (en) | Integrated proof flow system and method | |
| CN113779912A (en) | Chip verification system, method and device, electronic equipment and storage medium | |
| US7502966B2 (en) | Testcase generation via a pool of parameter files | |
| US10482207B2 (en) | Verification support apparatus and design verification support method | |
| CN116401989B (en) | Signal checking method based on chip design source code, electronic equipment and medium | |
| CN112540288B (en) | Method, system, device and storage medium for chip after silicon verification | |
| CN117454811A (en) | Verification method and device for design to be tested | |
| CN115422865B (en) | Simulation method and device, computing equipment and computer readable storage medium | |
| JP2009289072A (en) | Circuit operation verification method and apparatus | |
| CN112698974A (en) | Fault injection test method, device and storage medium | |
| Ho et al. | Post-silicon debug using formal verification waypoints | |
| CN116048887A (en) | Chip verification method, device, system, electronic equipment and storage medium | |
| CN114239452A (en) | Design function verification method, system, verification electronic device, and storage medium | |
| US20080270762A1 (en) | Method, System and Computer Program Product for Register Management in a Simulation Enviroment | |
| US7133818B2 (en) | Method and apparatus for accelerated post-silicon testing and random number generation | |
| Cong | Post-silicon functional validation with virtual prototypes | |
| US20110218793A1 (en) | Concretization of abstracted traces | |
| US11022649B2 (en) | Stabilised failure estimate in circuits | |
| Bustamante et al. | A fault injection environment for the evaluation of a soft error detection technique based on time redundancy |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |