CN113535496B - Chip verification system and method - Google Patents
Chip verification system and method Download PDFInfo
- Publication number
- CN113535496B CN113535496B CN202110870878.0A CN202110870878A CN113535496B CN 113535496 B CN113535496 B CN 113535496B CN 202110870878 A CN202110870878 A CN 202110870878A CN 113535496 B CN113535496 B CN 113535496B
- Authority
- CN
- China
- Prior art keywords
- chip
- tested
- test
- hardware
- instruction
- 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
- 238000012795 verification Methods 0.000 title claims abstract description 119
- 238000000034 method Methods 0.000 title claims abstract description 47
- 238000012360 testing method Methods 0.000 claims abstract description 269
- 230000007274 generation of a signal involved in cell-cell signaling Effects 0.000 claims abstract description 26
- 238000013515 script Methods 0.000 claims abstract description 16
- 230000004044 response Effects 0.000 claims abstract description 10
- 230000006870 function Effects 0.000 claims description 65
- 238000012545 processing Methods 0.000 claims description 19
- 238000010586 diagram Methods 0.000 description 13
- 230000008569 process Effects 0.000 description 9
- 238000004088 simulation Methods 0.000 description 8
- 230000001960 triggered effect Effects 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 5
- 238000013461 design Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000005284 excitation Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
- G06F11/2236—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test CPU or processors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2247—Verification or detection of system hardware configuration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/26—Functional testing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/39—Circuit design at the physical level
- G06F30/398—Design verification or optimisation, e.g. using design rule check [DRC], layout versus schematics [LVS] or finite element methods [FEM]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- Tests Of Electronic Circuits (AREA)
Abstract
The application provides a chip verification system and a method, wherein the chip verification system comprises: the test event module is used for sending out a test instruction, wherein the test instruction is an instruction generated based on a script, and the test instruction is used for verifying the function of the chip to be tested; the signal generation module is used for generating a hardware signal which is suitable for the chip to be tested according to the test instruction; the module to be tested is used for placing the chip to be tested, so that the chip to be tested receives the hardware signal and generates output data in response to the hardware signal; the comparison module is used for acquiring output data, determining whether the chip to be tested passes verification according to the comparison result of the output data and preset data, wherein the preset data is the data which is output by the chip to be tested in response to the hardware signal under the condition of normal function. The signal generation module can generate a hardware signal which is suitable for the chip to be tested based on the test instruction no matter how the hardware information of the chip to be tested changes, so that the corresponding function of the chip to be tested is verified, and the chip verification efficiency is improved.
Description
Technical Field
The present disclosure relates to the field of chip technologies, and in particular, to a chip verification system and method.
Background
Chip verification means that by adopting corresponding verification language, verification tool and verification method, whether the design of the chip meets the expected function of the chip is verified before the chip is produced, and the corresponding defect is found.
Currently, front-end verification is mainly performed for chip verification based on the general verification methodology (Universal Verification Methodology, UVM). Specifically, an excitation drive is generated through a code Verification IP (VIP) technology, so that internal signals of a chip in a module to be verified are turned over, and relevant functional points are triggered to generate output. And then comparing the output with the output of the comparison module, and further determining whether the chip passes the verification according to the comparison result.
However, there is a certain difference between different chips. For example: the bit width, register address, etc. of each chip are different. When different chips are verified, the same chip verification system is adopted, and because the details to be realized are different, before the different chips are actually verified, certain functional points in the chip verification system are required to be selected and removed according to the hardware condition of the chip to be verified, so that the verification of the same function of the different chips can be met. Thus, the complexity of the chip verification work operation is increased, and the chip verification efficiency is reduced.
Disclosure of Invention
The embodiment of the application aims to provide a chip verification system and method, so that the complexity of chip verification work is reduced, and the efficiency of chip verification is improved.
In order to solve the technical problems, the embodiment of the application provides the following technical scheme:
a first aspect of the present application provides a chip authentication system, the system comprising: the test event module is used for sending out a test instruction which is an instruction generated based on a script and is used for verifying the function of the chip to be tested; the signal generation module is used for generating a hardware signal which is suitable for the chip to be tested according to the test instruction; the to-be-tested module is used for placing the to-be-tested chip, enabling the to-be-tested chip to receive the hardware signal and responding to the hardware signal to generate output data; and the comparison module is used for acquiring the output data, determining whether the chip to be tested passes verification according to the comparison result of the output data and preset data, wherein the preset data is the data which is output by the chip to be tested in response to the hardware signal under the condition of normal function.
A second aspect of the present application provides a chip verification method, which is applied to the chip verification system in the first aspect, the method including: issuing a test instruction, wherein the test instruction is an instruction generated based on a script and is used for verifying the function of a chip to be tested; generating a hardware signal which is suitable for the chip to be tested according to the test instruction; the chip to be tested is controlled to receive the hardware signal and respond to the hardware signal to generate output data, and the module to be tested is used for placing the chip to be tested; and acquiring the output data, and determining whether the chip to be tested passes verification according to a comparison result of the output data and preset data, wherein the preset data is data which is output by the chip to be tested in response to the hardware signal under the condition of normal functions.
Compared with the prior art, the chip verification system provided in the first aspect of the application is provided with the test event module and the signal generation module, after verification content is determined, the test event module can send a software test instruction to the signal generation module, and the signal generation module can generate a hardware signal corresponding to the chip to be tested based on the software test instruction, so that the chip to be tested processes the hardware signal, and the corresponding function of the chip to be tested is verified. Therefore, no matter how the hardware information of the chip to be tested changes, the signal generation module can generate a hardware signal which is suitable for the chip to be tested based on the test instruction, so that the corresponding function of the chip to be tested is verified. Therefore, the interface related to the chip to be tested in the system is not required to be modified one by a tester, the complexity of verification work is reduced, and the chip verification efficiency is improved.
The chip verification method provided in the second aspect of the application has the same or similar beneficial effects as the chip verification system provided in the first aspect.
Drawings
The above, as well as additional purposes, features, and advantages of exemplary embodiments of the present application will become readily apparent from the following detailed description when read in conjunction with the accompanying drawings. Several embodiments of the present application are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like reference numerals refer to similar or corresponding parts and in which:
FIG. 1 is a schematic diagram of a chip verification system according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a chip verification system according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a chip verification system according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of a scanning unit in an embodiment of the present application;
FIG. 5 is a schematic diagram of a chip verification system according to an embodiment of the present disclosure;
FIG. 6 is a schematic structural diagram of a test environment module according to an embodiment of the present application;
fig. 7 is a schematic flow chart of a chip verification method according to an embodiment of the present application;
fig. 8 is a second flowchart of a chip verification method according to an embodiment of the present application.
Detailed Description
Exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
It is noted that unless otherwise indicated, technical or scientific terms used herein should be given the ordinary meaning as understood by one of ordinary skill in the art to which this application belongs.
In the existing chip verification system, based on the same functional module and the same functional specification, when different chips are tested, the details of implementation are different, and the functional points may be selected and removed, so that all the functions are not necessarily realized. Thus, the complexity of chip verification work is increased, and the efficiency of chip verification is reduced.
In view of this, the embodiment of the application provides a chip verification system, which generates a test instruction by using a high-level language, and further converts the test instruction into a hardware signal by a hardware signal generating tool, thereby improving verification efficiency. In particular, the efficiency of the method can be compared with the development efficiency of languages such as assembly language, c/python and the like by using a script language, namely writing and using without compiling. Therefore, when testing different chips based on the same functional module, the hardware signal generating tool can generate the hardware signal applicable to the current chip based on the scripted test case so as to test the current chip. The information of each interface related to the chip to be tested in the chip verification system is not required to be modified one by one, and the chip verification efficiency is improved.
It should be noted that, in practical application, the functional module to be tested in the chip may be a debug module. Of course, other functional modules are also possible. The specific type of functional module to be tested in the chip is not limited here.
Next, a chip verification system provided in the embodiment of the present application is described in detail.
Fig. 1 is a schematic structural diagram of a chip verification system according to an embodiment of the present application, and referring to fig. 1, the system may include: a test event module 101, a signal generation module 102, a module to be tested 103 and a comparison module 104.
The test event module 101 is connected with the signal generating module 102, the signal generating module 102 is connected with the module to be tested 103, and the module to be tested 103 is connected with the comparison module 104.
The test event module 101 is configured to receive and store a test instruction input by a user, and send the test instruction to the signal generating module 102.
The test instruction herein is an instruction generated based on a script. That is, the test instruction is a scripted instruction. The test instruction includes an instruction to test one or more functions of the chip. That is, one or more functions of the chip can be verified by the test instruction.
For example, when the verification of the function a of the chip is required, the user inputs the edited script instruction of the test function a into the test event module 101. The test event module 101 sends the script command to the signal generating module 102, and the signal generating module 102 can generate a corresponding hardware signal based on the script command, so as to input the corresponding hardware signal to the chip to be tested, and then verify the function a of the chip to be tested. The function a here may be a function of any function module to be verified. The specific content of function a is not limited herein.
Of course, the test instructions may also be instructions that implement other functions, the single step function test instructions above being merely exemplary. The specific content of the test instruction needs to be edited according to the verification content, namely, the test content is abstract described by adopting a script language. The specific content of the test is not limited herein.
In actual practice, the test instructions may be stored in the test event module 101 in the form of a universal tool language (Tool Control Language, TCL) script. Of course, it may exist in other scripting languages or other high-level types of programming languages. The specific form of the test instruction is not limited herein.
The signal generating module 102 is configured to receive the test instruction sent by the test event module 101, and generate a hardware signal adapted to the chip to be tested according to the received test instruction.
Since the chip verification system in the embodiment of the application tests the hardware function of the chip, the signal input to the chip is also a hardware signal. The test event module 101 receives a software test instruction, so the software test instruction needs to be converted into a hardware signal to be input to the chip to be tested, and the chip to be tested is tested.
The signal generation module 102 is able to generate a hardware test signal, i.e. a hardware signal, from the software test instruction. In practical applications, the signal generating module 102 may be any tool capable of converting a software instruction into a hardware signal. For example: and a tool capable of realizing a signal conversion function, such as an open source on-chip debugger (Open On Chip Debugger, openOCD), a driver for UVM development or a C driver called by a deep packet inspection (Deep Packet Inspection, DPI) mode. The specific type of signal generation module 102 is not limited herein.
In the signal generation module 102, a hardware signal suitable for the chip under test can be generated based on the software-based test instruction. That is, the signal generating module 102 is not only capable of generating a hardware signal for testing a corresponding function based on the test instruction, but also capable of adapting to the current chip under test.
For example, assume that the bit width of the current chip under test is 32 bits. After receiving the test instruction, the signal generating module 102 generates a hardware signal matched with the chip to be tested according to the test instruction, and sends the hardware signal to the chip to be tested. The hardware signal generated at this time is a 32-bit corresponding hardware signal, not a 64-bit corresponding hardware signal.
The type of hardware signal that the signal generating module 102 generates is determined according to the hardware information of the chip under test. The specific manner in which the signal generating module 102 obtains the hardware information of the chip to be tested is not limited, and the signal generating module 102 may actively scan the chip to be tested, or may passively receive the hardware information from other modules.
The module to be tested 103 is configured to place the chip to be tested, so that the chip to be tested can receive the hardware signal sent by the signal generating module 102, and generate output data based on the hardware signal.
That is, when functional verification of the chip to be tested is required, first, the chip to be tested needs to be placed in the module to be tested 103. Since the module under test 103 is connected to the signal generating module 102, after the signal generating module 102 generates a hardware signal based on the test instruction sent by the test event 101, the module under test 103 can receive the hardware signal generated by the signal generating module 102. The module under test 103 then transmits the hardware signal to the chip under test placed therein. And finally, processing the received hardware signals by the chip to be tested to generate output, namely generating output data. And then comparing the output data of the chip to be tested with preset data, and determining whether the corresponding function of the chip to be tested passes verification according to the comparison result.
And the comparison module 104 is used for acquiring the output data and determining whether the chip to be tested passes the verification according to the comparison result of the output data and the preset data.
The preset data are data which are output by the chip to be tested in response to the hardware signals under the condition of normal functions.
For example, it is assumed that it is necessary to verify whether the indication function of the chip under test is normal. Inputting a hardware signal a into the chip to be tested, generating output data a 'by the chip to be tested based on the hardware signal a, comparing the output data a' with preset data, wherein the preset data is used for triggering a corresponding indicator lamp to be lighted, and if the comparison result is consistent, determining that the indication function of the chip to be tested passes verification; if the comparison result is inconsistent, determining that the indication function of the chip to be tested is not verified.
The preset data for comparing with the output data in the comparison module 104 may be obtained from a test case of the test event module 101, or may be directly input in the comparison file 104 by a developer or a tester based on the function to be verified. The specific source of the preset data is not limited herein.
As can be seen from the above, in the chip verification system, by setting the test event module and the signal generation module, after the verification content is determined, the test event module can send the software test instruction to the signal generation module, and the signal generation module can generate the hardware signal corresponding to the chip to be tested based on the software test instruction, so that the chip to be tested processes the hardware signal, and thus the corresponding function of the chip to be tested is verified. The signal generation module can generate a hardware signal which is suitable for the chip to be tested based on the test instruction no matter how the hardware information of the chip to be tested changes, so that the corresponding function of the chip to be tested is verified. The interface related to the chip to be tested in the system is not required to be modified one by a tester, so that the complexity of verification work is reduced, and the chip verification efficiency is improved.
Further, in order to improve the generation efficiency and accuracy of the test instruction and further improve the verification efficiency and verification accuracy of the chip verification system, as a refinement and expansion of the system shown in fig. 1, the embodiment of the application further provides a chip verification system.
Fig. 2 is a schematic diagram of a second structure of a chip verification system in an embodiment of the present application, and referring to fig. 2, the system may include: a test event module 101, a signal generation module 102, a module to be tested 103 and a comparison module 104.
The structure and function of the signal generating module 102, the module to be tested 103, and the comparing module 104 are the same as or similar to those of the signal generating module 102, the module to be tested 103, and the comparing module 104 in fig. 1, so that the description thereof will not be repeated here. The description herein is mainly directed to a specific structure in the test event module 101.
The test event module 101 may include: a first receiving unit 1011, a storage unit 1012, a calling unit 1013, and a first transmitting unit 1014.
The first receiving unit 1011 and the storage unit 1012 are connected to the calling unit 1013, respectively, and the calling unit 1013 is connected to the first transmitting unit 1014.
A first receiving unit 1011 is configured to receive a target test item identification input by a user. The target test item identification here is used to characterize different test contents.
In one chip function verification, it may be necessary to verify multiple functions of the chip, or only one function of the chip may be verified. Therefore, one target test item identifier may correspond to one test content or may correspond to a plurality of test contents.
For example, assume that verification of function a, function b, function c is required for the chip under test. Then, when the target test item corresponds to one test content, the user needs to input the identifier a corresponding to the function a, the identifier b corresponding to the function b, and the identifier c corresponding to the function c. When the target test item identifier corresponds to a plurality of test contents, the user can directly input the identifiers abc corresponding to the functions a, b and c.
The above identification is only an example, and the identification may be a number, a chinese/english name corresponding to the test content, or the like. So long as the content can be tested based on the identified content unique determination. The particular form of the identification is not limited herein.
And the storage unit 1012 is used for storing each test item identifier and the test instruction corresponding to each test item identifier.
A calling unit 1013, configured to obtain the target test item identifier from the first receiving unit 1011, and call a target test instruction corresponding to the target test item identifier from the storage unit 1012.
When the corresponding function of the chip to be tested needs to be verified based on the test instruction, the test instruction is directly written based on the test content, so that the efficiency is low and errors are easy to occur. In order to improve the generation efficiency and accuracy of the test instruction, the test instructions corresponding to the various test items may be edited in advance, and then the test instructions corresponding to the various test items and the corresponding identifiers thereof may be stored in the storage unit 1012. Thus, when verification of a function or functions is required, the calling unit 1013 may directly obtain the test instruction corresponding to the function from the storage unit 1012 through the identifier corresponding to the function.
For example, the storage unit 1012 stores a test instruction a and an identifier a corresponding to the test function a, and a test instruction b and an identifier b corresponding to the test function b. When the first receiving unit 1011 receives the target test item identifier a input by the user, the calling unit 1013 may directly find the test instruction a corresponding to the identifier a from the storage unit 1012 according to the identifier a received in the first receiving unit 1011, without writing the test instruction a again, thereby improving the efficiency and accuracy of generating the test instruction.
A first transmitting unit 1014, configured to transmit the target test instruction to the signal generating module 102.
After extracting the target test instruction required by the current test, the first transmitting unit 1014 transmits the target test instruction to the signal generating module 102, so that the signal generating module 102 generates a corresponding hardware signal based on the target test instruction and inputs the corresponding hardware signal to the chip to be tested to verify the function of the chip to be tested.
As can be seen from the above, in the chip verification system provided in the embodiment of the present application, in the test event module, each test item identifier and a test instruction corresponding to each test item identifier are stored in advance through the storage unit. Thus, when one or a plurality of functions of the chip to be tested need to be verified, the user only needs to input the target test item identification corresponding to the function to be verified in the first receiving unit. The calling unit calls the target test instruction corresponding to the target test item identifier from the storage unit according to the target test item identifier received in the first receiving unit, and then sends the target test instruction to the signal generating module through the first sending unit, so that automatic generation of the test instruction corresponding to the function to be verified is realized, the test instruction is prevented from being written manually for multiple times, the generation efficiency and accuracy of the test instruction can be improved, and the efficiency and accuracy of chip verification are further improved.
Further, in order to generate a hardware signal suitable for a chip to be tested based on the test instruction faster and more accurately, as a refinement and extension to the system shown in fig. 1, the embodiment of the application further provides a chip verification system.
Fig. 3 is a schematic diagram of a third structural diagram of a chip verification system in an embodiment of the present application, and referring to fig. 3, the system may include: a test event module 101, a signal generation module 102, a module to be tested 103 and a comparison module 104.
The test event module 101, the module under test 103, and the comparison module 104 are the same as or similar to the structures and functions of the test event module 101, the module under test 103, and the comparison module 104 in fig. 1 or 2, so that the description thereof will not be repeated here. The specific structure in the signal generation module 102 will be mainly described herein.
The signal generation module 102 may include: a scanning unit 1021 and a signal generation unit 1022.
Wherein the scanning unit 1021 is connected with the signal generating unit 1022.
The scanning unit 1021 is configured to scan hardware information of the chip under test, and send the hardware information meeting a preset condition to the signal generating unit 1022.
When the chip to be tested is placed in the module to be tested 103, since the signal generating module 102 is connected with the module to be tested 103, the signal generating module 102 can monitor that the chip to be tested is placed in the module to be tested 103, or the module to be tested 103 can actively send information to the signal generating module 102 to inform that the chip to be tested is placed in the module to be tested 103. The scan unit 1021 may be triggered to scan the chip to be tested, and obtain the hardware information of the chip to be tested. Therefore, the hardware information of the chip to be tested can be obtained more quickly, the hardware signal which is suitable for the chip to be tested can be generated more quickly, and the chip verification speed is improved.
Alternatively, when the test event module 101 acquires the test instruction, the test event module 101 may send a message to the signal generating module 102 to inform the scanning unit 1021 that the chip to be tested may start to be scanned, or the signal generating module 102 may monitor the test event module 101, and once the test event module 101 acquires the test instruction, the scanning unit 1021 may start to scan the chip to be tested until all hardware information of the chip to be tested is scanned.
Or, when the signal generating module 102 receives the test instruction, the scanning unit 1021 starts scanning the chip to be tested to obtain the hardware information of the chip to be tested.
The timing at which the scanner unit 1021 starts scanning may be any of the above timings, and is not limited thereto.
The scanning unit 1021 is used for scanning the hardware information of the chip to be tested, so that compared with the process of acquiring the hardware information of the chip to be tested from the outside of the system, the problems that data are easy to lose in the transmission process of the hardware information, the transmission speed is low when the data are transmitted from the outside of the system to the inside of the system and the like are solved, the scanning unit 1021 in the system is used for directly scanning the hardware information of the chip to be tested, the hardware information of the chip to be tested can be acquired more quickly and accurately, further, the hardware signal suitable for the chip to be tested is generated more quickly and accurately, and further, the verification speed and the verification accuracy of the chip verification system are improved.
In the scan unit 1021, in order to avoid the failure of the scan unit 1021, the wrong hardware information is scanned, so as to affect the accuracy of chip verification, the scan result of the scan unit 1021 may be detected, and when it is determined that the scan result is error-free, the scanned hardware information is sent out, so that the accuracy of chip verification can be improved.
Fig. 4 is a schematic structural diagram of a scanning unit in an embodiment of the present application, and referring to fig. 4, the scanning unit may include: a scan sub-unit 1021a, a determination sub-unit 1021b, a transmission sub-unit 1021c, and a presentation sub-unit 1021d.
Wherein, the scanning sub-unit 1021a is connected with the judging sub-unit 1021b, and the judging sub-unit 1021b is respectively connected with the transmitting sub-unit 1021c and the prompting sub-unit 1021d.
The scanning subunit 1021a is configured to scan hardware information of the chip under test.
The scan sub-unit 1021a can realize a part of the functions of the scan unit 1021, that is, the scan function, and the details of the scan sub-unit 1021a are described in the foregoing description, which is not repeated herein.
A judging subunit 1021b, configured to judge whether the hardware information scanned by the scanning subunit 1021a exists in the preset hardware information; if yes, triggering the transmitting subunit 1021c; if not, the hint subunit 1021d is triggered.
The preset hardware information is a set of hardware information of various types of chips.
For example, the preset hardware information includes various hardware information of different types of chips, such as 32-bit width, 64-bit width, register address a, register address B, and the like.
When the hardware information scanned by the scanning subunit 1021a does not exist in the preset hardware information, since the preset hardware information already includes various types of hardware information of various types of chips, it is indicated that the scanning subunit 1021a may have a scanning failure, the scanned hardware information is problematic, or the scanned chip itself is problematic. Next, the hint subunit 1021d is triggered. The hint subunit 1021d can trigger a termination instruction and generate hint information. The verification process of the chip can be terminated by a termination instruction triggered by the prompt subunit 1021d. The user can be informed that the hardware of the scanned chip has a problem or that the scanning subunit 1021a has a fault when scanning the hardware information of the chip to be tested by the prompt information generated and displayed by the prompt subunit 1021d. At this time, the chip verification is terminated, and the stability of the chip test can be improved.
When the hardware information scanned by the scanning subunit 1021a exists in the preset hardware information, it is indicated that the scanning subunit 1021a is normal, and the scanned hardware information is also without problems. Next, the transmitting subunit 1021c is triggered, and the transmitting subunit 1021c transmits the hardware information of the chip under test scanned by the scanning subunit 1021a to the signal generating unit 1022, so that the signal generating unit 1022 continues to generate a hardware signal suitable for the chip under test according to the test instruction.
The signal generating unit 1022 is configured to generate a hardware signal corresponding to the hardware information according to the test instruction.
After the scanning unit 1021 scans the hardware information of the chip to be tested, the signal generating unit 1022 can generate a hardware signal adapted to the chip to be tested according to the test instruction sent by the test event module 101 and the hardware information of the chip to be tested scanned by the scanning unit 1021, and input the hardware signal to the chip to be tested, and the chip to be tested can process the hardware signal.
For example, assume that the scan unit 1021 scans the chip under test to have a bit width of 64 bits, and the register address is address B. Then, the hardware signal generated by the signal generating unit 1022 based on the test instruction is applied to 64 bits, and the hardware signal is sent to the address B.
As can be seen from the foregoing, in the chip verification system provided in the embodiment of the present application, in the signal generating module, the hardware information of the chip to be tested is scanned by the scanning unit, compared with the hardware information of the chip to be tested obtained from the outside of the system, the data loss easily occurs in the transmission process of the hardware information, and the transmission speed is slower when the data is transmitted from the outside of the system to the inside of the system.
Further, in conventional chip verification, after the chip is verified in the chip verification system using the simulation environment, the chip is required to be mounted in a circuit board for testing, i.e. on-board testing. However, in the process of on-board testing, if a problem occurs in the detection result, the detection result cannot be positioned against the occurring problem, so that the debugging difficulty of the chip is increased.
In view of this, as a refinement and extension to the system shown in fig. 1, the embodiment of the present application further provides a chip verification system, by reproducing the on-board test environment in the system in 1 to 1, the on-board test can also be performed in the chip verification system, so as to achieve integration of front-end test and post-test of the chip. Like this, when the chip tests out the problem on the board, because can't fix a position to the problem on the board, more be inconvenient for debugging, consequently, put into the chip verification system that this application embodiment provided with the chip again, test the chip through the test environment on the reproduction board, in this in-process, can call out intermediate data, and then fix a position to the problem chip, the debugging of the chip of being convenient for.
Fig. 5 is a schematic structural diagram of a chip verification system according to an embodiment of the present application, and referring to fig. 4, the system may include: a test event module 101, a signal generation module 102, a module under test 103, a comparison module 104, a test environment module 105, and a processing module 106.
The test event module 101, the signal generating module 102, the module to be tested 103, and the comparing module 104 are similar to the test event module 101, the signal generating module 102, the module to be tested 103, and the comparing module 104 in fig. 1, 2, or 3 in structure and function, and reference is made to the related description, and the description is omitted here. The description will be made mainly with respect to the test environment module 105 and the processing module 106.
The test environment module 105 is connected with the processing module 106, and the processing module 106 is respectively connected with the module to be tested 103 and the comparison module 104.
The test environment module 105 is used for issuing program instructions.
The program instructions herein are generated based on an on-board test environment of the chip under test. That is, during testing of the chip on the board, which devices are used on the board, which versions of the devices are all simulated by the program instructions. What software is used when running on board, which version of the software, program instructions simulate the software.
However, the program instructions do not simulate all of the hardware and software on the board, but rather simulate a portion of the hardware and software on the board. This part of the hardware and part of the software content is related to the problems that occur when the chip is actually tested on board. For example: in the actual on-board test of the chip, the chip is not output according to the sequence of the step a, the step b and the step c. Then, the program instructions only simulate the hardware and software related to executing the steps a, b and c on the board, and do not need to simulate the hardware and software such as a sound card and the like which are not related to executing the steps. Thus, on-board environment verification can be performed in the system more quickly aiming at the problem of the chip on the board, and the problem can be positioned more quickly.
Fig. 6 is a schematic structural diagram of a test environment module in an embodiment of the present application, and referring to fig. 6, the test environment module may include: a second receiving unit 1051, an instruction generating unit 1052, an instruction optimizing unit 1053, and a second transmitting unit 1054.
The second receiving unit 1051 is connected to the instruction generating unit 1052, the instruction generating unit 1052 is connected to the instruction optimizing unit 1053, the instruction optimizing unit 1053 is connected to the second transmitting unit 1054, and the second transmitting unit 1054 is connected to the processing module 106.
The second receiving unit 1051 is configured to receive a hardware version and a program version input by a user.
The hardware version is the version of each hardware on the board when the chip to be tested performs the on-board test. The program version is the version of the program running on the board when the chip to be tested performs the on-board test.
For example, after the front end has been verified, the chip is later mounted on a circuit board for testing. It is assumed that the circuit board has hardware a, b, c mounted thereon in versions 1.0, 2.0, respectively. The circuit board runs software d, version 3.0. Then, the user (may be a tester) may input all hardware versions (hardware a, version 1.0; hardware b, version 1.0; hardware c, version 2.0) and software versions (software d, version 3.0) thereof to the second receiving unit 1051 according to the actual condition of the circuit board. The second receiving unit 1051 receives all hardware versions and program versions of the board on which the chip is tested later.
An instruction generation unit 1052 for generating program instructions from the hardware version and the program version.
After the hardware version and the program version are received, the program instruction of the board-level test environment can be simulated according to the hardware version and the program version, so that the board-level test environment in the later stage can be simulated in the chip verification system for the chip early-stage verification.
And performing on-board test environment simulation based on the hardware version and the program version, and establishing a board-level simulation environment, wherein the existing simulation technology can be adopted. For example: electronic design automation (Electronic Design Automation, EDA). The specific technique used is not limited herein.
The instruction optimizing unit 1053 is configured to delete an instruction that is not related to the test instruction from the program instructions, and obtain the target program instruction.
Because all the environments on the board are not required to be simulated in the chip verification system, only relevant parts of problems occurring in the actual on-board test are simulated, the environments on the board which are actually required to be simulated in the chip verification system can be determined according to the test instructions, and then the instructions which are generated in advance and can simulate all the environments on the board and are irrelevant to the test are deleted.
For example, in an actual on-board test, it is assumed that the display card on the board is found to have no output, while the sound card has an output, at which time the chip needs to be put into the chip verification system again for testing. The test instructions in the system are merely test instructions associated with the graphics card. The program instructions generated by the instruction generating unit 1052 are all instructions related to the video card and the sound card on the board. Then, the instruction optimizing unit 1053 deletes the instruction related to the sound card from all the instructions, and only retains the instruction related to the display card. In this way, in the system, only the display card environment on the board is simulated, the test of the related functions of the chip and the display card is realized, and then the positioning of the problems of the chip is realized.
The second sending unit 1054 is configured to send the target program instruction to the processing module 106.
After obtaining the target program instruction, the second sending unit 1054 sends the target program instruction to the processing module 106, so that the processing module 106 simulates an on-board environment, and realizes that the chip verification system reproduces an on-board test environment so as to grasp the tested intermediate data and locate the chip problem, thereby facilitating chip debugging.
And the processing module 106 is used for running the program instruction and sending the generated on-board instruction to a chip to be tested placed in the module to be tested, so that the chip to be tested is simulated to run in an on-board test environment.
In the process of the processing module 106 running the target program instruction, the chip verification system simulates the real test environment on the board, thereby realizing the on-board simulation test of the chip. In the test, the data generated in the middle of the chip can be grasped, and the problem of the chip can be rapidly and accurately positioned through the middle data, so that the chip is convenient to debug.
In practical applications, the processing module 106 may be a central processing unit (Central Processing Unit, CPU). The program instructions executed in the CPU may be a C program.
In addition, the chip verification system provided by the embodiment of the application can be further interconnected with a program debugging tool (GNU symbolic debugger, GDB), and the test of the on-board software function can be realized through the system.
As can be seen from the above, in the chip verification system provided in the embodiment of the present application, by adding the environment testing module and the processing module to the system, the environment testing module generates the program instruction capable of simulating the on-board testing environment, and runs the program instruction, so that the on-board environment is simulated in the system, and further the on-board testing is implemented in the simulation system. The intermediate data generated in the chip test can be called in the system, so that the problem points of the chip with problems in the on-board test can be positioned through the intermediate data, and the chip is convenient to debug.
Based on the same inventive concept, as an implementation method of the system shown in fig. 1, the embodiment of the application further provides a chip verification method. The chip verification method is realized based on the chip verification system. Fig. 7 is a schematic flow chart of a chip verification method provided in an embodiment of the present application, and referring to fig. 7, the method may include:
s701: and sending out a test instruction.
The test instruction is an instruction generated based on a script and is used for verifying the function of the chip to be tested.
S702: and generating a hardware signal which is suitable for the chip to be tested according to the test instruction.
S703: and controlling the chip to be tested to receive the hardware signal and generating output data in response to the hardware signal.
The module to be tested is used for placing the chip to be tested.
S704: and acquiring the output data, and determining whether the chip to be tested passes verification according to a comparison result of the output data and preset data.
The preset data are data which are output by the chip to be tested in response to the hardware signals under the condition of normal functions.
Further, as a refinement and extension of the method shown in fig. 7, the embodiment of the application further provides a chip verification method. Fig. 8 is a second flowchart of a chip verification method provided in an embodiment of the present application, and referring to fig. 8, the method may include:
s801: and receiving a target test item identification input by a user.
S802: and storing each test item identifier and a test instruction corresponding to each test item identifier.
Step S801 and step S802 may be performed simultaneously or sequentially. The execution sequence of step S801 and step S802 is not limited herein.
S803: and calling a target test instruction corresponding to the target test item identifier from the storage unit.
S804: and sending the target test instruction to the signal generation module.
S805: and scanning the hardware information of the chip to be tested.
In the process of scanning the hardware information of the chip to be tested, the method specifically may include: and scanning the hardware information of the chip to be tested, and judging whether the hardware information obtained by scanning exists in preset hardware information. If yes, executing S806; if not, triggering a termination instruction and generating prompt information, wherein the termination instruction is used for terminating the verification of the chip, and the prompt information is used for indicating that the hardware of the chip has a problem. The preset hardware information is a set of hardware information of various types of chips.
S806: and generating a hardware signal corresponding to the hardware information according to the test instruction.
S807: program instructions are issued.
The program instructions are generated based on an on-board test environment of the chip under test.
In the process of issuing the program instruction, the method specifically may include: and receiving a hardware version and a program version which are input by a user, wherein the hardware version is the version of each piece of hardware on the board when the chip to be tested performs the on-board test, and the program version is the version of the program running on the board when the chip to be tested performs the on-board test. Then, the program instructions are generated from the hardware version and the program version. And then deleting the instruction which is irrelevant to the test instruction in the program instructions to obtain the target program instruction. And finally, sending the target program instruction to the processing module.
S808: and running the program instruction, and sending the generated on-board instruction to the chip to be tested placed in the module to be tested, so that the chip to be tested is simulated to run in an on-board test environment.
S809: and controlling the chip to be tested to receive the hardware signal and generating output data in response to the hardware signal.
S810: and acquiring the output data, and determining whether the chip to be tested passes verification according to a comparison result of the output data and preset data.
Here, steps S801 to S806 and steps S807 to S808 are two method routes. Steps S801-S806 are to implement chip verification in a scripted form, and steps S807-S808 are to simulate the on-board test environment of the chip. The final purpose of both routes is to test the functionality of the chip more truly.
It should be noted that, the execution subject of the methods in steps S701-S704 and S801-S810 may be corresponding modules in the chip verification system, or may be a processor other than each module, which is not limited herein.
Finally, a specific example of the test hardware-tuned module is used to explain the chip verification method of the chip verification system provided in the embodiment of the application again.
The chip verification system includes a DUT (Device Under Test), a driver layer (OpenOCD), and an application layer. Thus, the chip authentication is software-implemented.
In the application layer, it includes: program C and TCL test points.
In the driving layer, it includes: extended OpenOCD.
In the system, of course, further comprises: a CPU (for simulating board level test environments, a module under test (for placing DUTs), an automatic comparison module (UVM base environment).
The specific verification steps are as follows:
1. analyzing test points, and writing a C program and a TCL script;
2. compiling a C program to generate a binary file;
3. starting a UVM simulation environment, filling a C program into a CPU, and filling a TCL script into an OpenOCD;
4. the OpenOCD further generates a control flow, drives a jtag interface between the OpenOCD and the DUT, and finally controls the DUT;
5. the testing of the test point is completed and a result file is generated through the information communication and data interaction between the CPU and the DUT;
6. judging whether the result accords with the expectation or not by analyzing the key data and the specific signals in the result file, and outputting Pass/Fail.
The basic instruction stream running on the CPU is constructed through the C program, the test excitation stream is triggered and imported through OpenOCD, and the debug module is connected with the CPU, so that the later-stage board-level test scene can be basically reproduced. The CPU and the debug module are both in a register conversion stage circuit (Register Transfer Level, RTL) simulation environment, and test excitation flows are automatically imported through TCL scripts, so that artificial knock-in commands in a later-stage board-level environment can be replaced.
It should be noted here that the description of the method embodiments above is similar to the description of the system embodiments above, with similar benefits to the system embodiments. For technical details not disclosed in the method embodiments of the present application, please refer to the description of the system embodiments of the present application for understanding.
The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (9)
1. A chip authentication system, the system comprising:
the test event module is used for sending out a test instruction which is an instruction generated based on a script and is used for verifying the function of the chip to be tested;
the signal generation module is used for generating a hardware signal which is suitable for the chip to be tested according to the test instruction;
the to-be-tested module is used for placing the to-be-tested chip, enabling the to-be-tested chip to receive the hardware signal and responding to the hardware signal to generate output data;
The comparison module is used for acquiring the output data, determining whether the chip to be tested passes verification according to a comparison result of the output data and preset data, wherein the preset data is data which is output by the chip to be tested in response to the hardware signal under the condition of normal functions;
wherein the signal generation module comprises:
the scanning unit is used for scanning the hardware information of the chip to be detected and sending the hardware information meeting preset conditions to the signal generating unit;
the signal generating unit is used for generating a hardware signal corresponding to the hardware information according to the test instruction;
wherein the scanning unit includes:
the scanning subunit is used for scanning the hardware information of the chip to be tested;
the judging subunit is used for judging whether the scanned hardware information exists in preset hardware information, wherein the preset hardware information is a set of hardware information of various types of chips; if yes, triggering a sending subunit; if not, triggering a prompt subunit;
the transmitting subunit is configured to transmit the hardware information to the signal generating unit;
the prompting subunit is used for triggering a termination instruction and generating prompting information, the termination instruction is used for terminating the verification of the chip, and the prompting information is used for indicating that the hardware of the chip has a problem.
2. The system of claim 1, wherein the test event module comprises:
the first receiving unit is used for receiving a target test item identifier input by a user;
the storage unit is used for storing each test item identifier and a test instruction corresponding to each test item identifier;
the calling unit is used for acquiring the target test item identification and calling a target test instruction corresponding to the target test item identification from the storage unit;
and the first sending unit is used for sending the target test instruction to the signal generating module.
3. The system of claim 1, wherein the signal generation module is OpenOCD.
4. A system according to any one of claims 1 to 3, further comprising:
the test environment module is used for sending out program instructions which are generated based on an on-board test environment of the chip to be tested;
and the processing module is connected with the module to be tested and used for running the program instruction and sending the generated on-board instruction to the chip to be tested placed in the module to be tested so that the chip to be tested can simulate running in an on-board test environment.
5. The system of claim 4, wherein the test environment module comprises:
the second receiving unit is used for receiving a hardware version and a program version which are input by a user, wherein the hardware version is a version of each hardware on the board when the chip to be tested performs the on-board test, and the program version is a version of a program running on the board when the chip to be tested performs the on-board test;
an instruction generating unit configured to generate the program instruction according to the hardware version and the program version;
the instruction optimizing unit is used for deleting the instructions which are irrelevant to the test instructions in the program instructions to obtain target program instructions;
and the second sending unit is used for sending the target program instruction to the processing module.
6. A chip verification method, characterized in that the method is applied to the chip verification system according to any one of claims 1 to 5, the method comprising:
issuing a test instruction, wherein the test instruction is an instruction generated based on a script and is used for verifying the function of a chip to be tested;
generating a hardware signal which is suitable for the chip to be tested according to the test instruction;
The chip to be tested is controlled to receive the hardware signal and respond to the hardware signal to generate output data, and the module to be tested is used for placing the chip to be tested;
acquiring the output data, and determining whether the chip to be tested passes verification according to a comparison result of the output data and preset data, wherein the preset data is data which is output by the chip to be tested in response to the hardware signal under the condition that the function of the chip to be tested is normal;
wherein the generating, according to the test instruction, a hardware signal adapted to the chip to be tested includes:
scanning hardware information of the chip to be tested;
generating a hardware signal corresponding to the hardware information according to the test instruction;
wherein, the scanning the hardware information of the chip to be tested includes:
scanning hardware information of the chip to be tested;
judging whether the scanned hardware information exists in preset hardware information, wherein the preset hardware information is a set of hardware information of various types of chips;
if yes, generating a hardware signal corresponding to the hardware information according to the test instruction;
if not, triggering a termination instruction and generating prompt information, wherein the termination instruction is used for terminating the verification of the chip, and the prompt information is used for indicating that the hardware of the chip has a problem.
7. The method of claim 6, wherein issuing the test instruction comprises:
receiving a target test item identifier input by a user;
storing each test item identifier and a test instruction corresponding to each test item identifier;
invoking a target test instruction corresponding to the target test item identifier from the storage unit;
and sending the target test instruction to the signal generation module.
8. The method according to any one of claims 6 to 7, further comprising:
issuing a program instruction, wherein the program instruction is generated based on an on-board test environment of the chip to be tested;
and running the program instruction, and sending the generated on-board instruction to the chip to be tested placed in the module to be tested, so that the chip to be tested is simulated to run in an on-board test environment.
9. The method of claim 8, wherein the issuing program instructions comprises:
receiving a hardware version and a program version which are input by a user, wherein the hardware version is a version of each piece of hardware on the board when the chip to be tested performs the on-board test, and the program version is a version of a program running on the board when the chip to be tested performs the on-board test;
Generating the program instructions according to the hardware version and the program version;
deleting an instruction which is irrelevant to the test instruction in the program instruction to obtain a target program instruction;
and sending the target program instruction to the processing module.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110870878.0A CN113535496B (en) | 2021-07-30 | 2021-07-30 | Chip verification system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110870878.0A CN113535496B (en) | 2021-07-30 | 2021-07-30 | Chip verification system and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113535496A CN113535496A (en) | 2021-10-22 |
| CN113535496B true CN113535496B (en) | 2024-03-29 |
Family
ID=78121568
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110870878.0A Active CN113535496B (en) | 2021-07-30 | 2021-07-30 | Chip verification system and method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113535496B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113986641B (en) * | 2021-12-28 | 2022-04-22 | 苏州浪潮智能科技有限公司 | Method, system, equipment and storage medium for verifying chip hardware function |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1725188A (en) * | 2004-07-22 | 2006-01-25 | 华为技术有限公司 | Logic verification system and method |
| CN101799506A (en) * | 2010-04-21 | 2010-08-11 | 广州市广晟微电子有限公司 | Chip test method, device and system based on script control |
| CN107038280A (en) * | 2017-03-10 | 2017-08-11 | 烽火通信科技股份有限公司 | A kind of checking system and method for software and hardware cooperating simulation |
| CN111737066A (en) * | 2020-05-29 | 2020-10-02 | 浪潮电子信息产业股份有限公司 | USB signal testing system and method |
| CN112580295A (en) * | 2020-11-24 | 2021-03-30 | 北京智芯微电子科技有限公司 | Automatic verification method, system and device for multi-core SoC chip |
-
2021
- 2021-07-30 CN CN202110870878.0A patent/CN113535496B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1725188A (en) * | 2004-07-22 | 2006-01-25 | 华为技术有限公司 | Logic verification system and method |
| CN101799506A (en) * | 2010-04-21 | 2010-08-11 | 广州市广晟微电子有限公司 | Chip test method, device and system based on script control |
| CN107038280A (en) * | 2017-03-10 | 2017-08-11 | 烽火通信科技股份有限公司 | A kind of checking system and method for software and hardware cooperating simulation |
| CN111737066A (en) * | 2020-05-29 | 2020-10-02 | 浪潮电子信息产业股份有限公司 | USB signal testing system and method |
| CN112580295A (en) * | 2020-11-24 | 2021-03-30 | 北京智芯微电子科技有限公司 | Automatic verification method, system and device for multi-core SoC chip |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113535496A (en) | 2021-10-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107463473B (en) | Chip software and hardware simulation environment based on UVM and FPGA | |
| Belinfante et al. | Formal test automation: A simple experiment | |
| CN110688313B (en) | Fault injection method for software testing under VxWorks operating system | |
| US20070061641A1 (en) | Apparatus and method for generating test driver | |
| CN114912413A (en) | Chip verification method and platform | |
| CN107329889B (en) | Method for automatically testing C compiler | |
| CN110704314B (en) | Fault injection method for embedded software test | |
| CN113535496B (en) | Chip verification system and method | |
| CN115656791B (en) | Test method and test platform for chip testability design | |
| JP4959941B2 (en) | Interactive software probing | |
| CN104699617A (en) | Automated testing method for games | |
| CN117787155B (en) | Chip testability code dynamic simulation test system and test method | |
| CN115684896A (en) | Chip testability design test method, test platform, and generation method and device thereof | |
| CN115576768A (en) | Universal verification platform architecture automatic generation method based on UVM | |
| JPWO2005036402A1 (en) | Test program debug device, semiconductor test device, test program debug method, and test method | |
| CN114564392A (en) | RTL simulation method and device, electronic equipment and computer readable storage medium | |
| CN108776723B (en) | Test system self-checking adapter connection line generation method, device, equipment and storage medium | |
| CN111736924B (en) | Method, device, equipment and medium for accessing data acquisition instrument based on Lua script | |
| CN111737933A (en) | SOC prototype verification method, system, equipment and medium | |
| CN109960238B (en) | Automatic test system and method for vehicle diagnostic instrument | |
| CN116306479A (en) | UVM-based Ethernet PHY universal verification platform and verification method | |
| CN115684895A (en) | Chip testability design test method, test platform, and generation method and device thereof | |
| US20050108596A1 (en) | Method of verifying circuitry used for testing a new logic component prior to the first release of the component | |
| Crouch et al. | P1687. 1: Accessing Embedded 1687 Instruments using Alternate Device Interfaces other than JTAG | |
| JP2004101203A (en) | Failure analysis system for logic lsi and failure analysis method |
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: Room 101, floor 1, building 3, yard 18, Kechuang 10th Street, Beijing Economic and Technological Development Zone, Daxing District, Beijing 100176 Applicant after: Beijing ESWIN Computing Technology Co.,Ltd. Address before: Room 101, floor 1, building 3, yard 18, Kechuang 10th Street, Beijing Economic and Technological Development Zone, Daxing District, Beijing 100176 Applicant before: Beijing yisiwei Computing Technology Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |