US20050262410A1 - Tool for generating a re-generative functional test - Google Patents
Tool for generating a re-generative functional test Download PDFInfo
- Publication number
- US20050262410A1 US20050262410A1 US11/189,621 US18962105A US2005262410A1 US 20050262410 A1 US20050262410 A1 US 20050262410A1 US 18962105 A US18962105 A US 18962105A US 2005262410 A1 US2005262410 A1 US 2005262410A1
- Authority
- US
- United States
- Prior art keywords
- test
- self
- device under
- software built
- rit
- 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.)
- Abandoned
Links
Images
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/26—Functional testing
- G06F11/263—Generation of test inputs, e.g. test vectors, patterns or sequences ; with adaptation of the tested hardware for testability with external testers
Definitions
- the present invention relates to the manufacture and functional testing of complex devices such as microprocessors, and more particularly, relates to a tool for generating a re-generative functional test in the form of a kernel for enabling on-chip generation and application of functional tests.
- ASIC Application specific integrated circuit
- Current ASIC chips may include functional blocks, such as microprocessors, interfaces, memory arrays, and DSPs (digital signal processors) all of which need to be validated for design correctness and/or tested for manufacturing defects.
- DSPs digital signal processors
- Microprocessor testing is typically considered one of the most complex problems in ASIC testing, whether the microprocessor happens to be an ASIC core or a stand-alone device. This is because modern microprocessors are highly complex and typically enhanced with additional operating modes and features. For example, newer ⁇ 86 microprocessors such as Pentium® processors as marketed by Intel® Corporation are designed to maintain software compatibility with previous 80 ⁇ 86 microprocessor generations (e.g., 8086/8, 80286, 80386, and 80486). These newer ⁇ 86 microprocessors include multiple operating modes and are equipped with cache memory systems and added hardware support features for operation in multi-processor environments. Errors in the designs of microprocessors and defects introduced during manufacturing may cause the microprocessors to produce incorrect results during operation.
- ATE automatic test equipment
- DFT design-for-test
- BIST built-in self-test
- scan partial scan
- logic BIST logic BIST
- scan-based BIST scan-based BIST
- FIG. 1 illustrates an example test system for testing a complex device such as a microprocessor for manufacturing defect(s);
- FIG. 2 illustrates an example flow diagram of an example test procedure
- FIG. 3 illustrates an example RIT tool installed in a host computer under an operating system (OS) for generating a test program (functional test);
- OS operating system
- FIG. 4 illustrates an example test system for testing a complex device such as a microprocessor for manufacturing defects, via an example functional random instruction test (FRIT) kernel according to an embodiment of the present invention
- FIG. 5 illustrates an example functional random instruction test (FRIT) kernel according to an embodiment of the present invention
- FIG. 6 illustrates an example concept of an example software built-in, self-test (BIST) engine (SBE) generation tool installed in a host computer under an operating system (OS) for generating a SBE of the FRIT kernel according to an embodiment of the present invention
- BIST software built-in, self-test
- OS operating system
- FIG. 7 illustrates an example SBE generation tool implementation according to an embodiment of the present invention
- FIG. 8 illustrates an example instruction generation algorithm embedded in the SBE for generating an individual instruction during test application according to an embodiment of the present invention
- FIG. 9 illustrates a flow diagram of an example functional random instruction test (FRIT) application according to an embodiment of the present invention.
- FIG. 10 illustrates a flow diagram of an example flow diagram of a functional random instruction test (FRIT) execution sequence according to an embodiment of the present invention
- FIG. 11 illustrates a block diagram of an example functional random instruction test (FRIT) sequence execution according to an embodiment of the present invention
- FIG. 12 illustrates an example memory image of a complex device such as a microprocessor under test (DUT) at the beginning of test according to an embodiment of the present invention.
- DUT microprocessor under test
- FIG. 13 illustrates an example memory image of a complex device such as a microprocessor under test (DUT) at the end of test according to an embodiment of the present invention.
- DUT microprocessor under test
- the present invention is applicable to the testing of microprocessors, complex digital systems, and chipsets and new chipsets having memory and logic components incorporated therein which may become available as computer technology develops in the future. In addition, testing can be conducted on automated test equipment such as low cost testers, functional testers or even computer systems.
- the present invention is also applicable to the testing of one or more complex devices such as microprocessors integrated on one or more chipsets on board. However, for the sake of simplicity, discussions will concentrate mainly on random instruction testing of a single complex device such as a microprocessor, although the scope of the present invention is not limited thereto.
- an example test system 100 may include an automated test equipment (ATE) such as a tester 110 utilized for testing a complex device such as a microprocessor under test (DUT) 130 , via test programs 120 , for manufacturing defect(s).
- ATE automated test equipment
- Each test program 120 may include a test stimulus 120 A and an expected test result (expected response) 120 B.
- the test stimulus 120 may correspond to a software program, typically written manually or generated by traditional RIT tools for executing a functional test of a complex device such as a microprocessor under test (DUT) 130 .
- the expected test result 120 B is an expected response of a complex device under test (DUT) 130 computed based on a computer model of the same complex device under test (DUT) 130 .
- a simulation software (simulator) and a simulation model are utilized by a computer system (not shown) for computing the expected response of a complex device under test (DUT) 130 .
- the simulation model may indicate a software representation of a complex device under test (DUT) 130 , and may be written using hardware description languages such as Verilog or VHDL, and may be provided on a computer tangible medium, such as memory devices; magnetic disks (fixed, floppy, and removable); other magnetic media such as magnetic tapes; optical media such as CD-ROM disks, or via Internet downloads, which may be available for plug-in or download into an existing operating system (OS) for computing the expected response of a complex device under test (DUT) 130 .
- OS operating system
- the tester 110 may include, but not limited to, a controller 112 and a memory 114 .
- the controller 112 may be arranged to receive one or more test programs 120 in tester format and store test patterns into the tester memory 114 .
- the controller 112 may then execute the test program 120 by applying the test patterns to the complex device under test (DUT) 130 , via an interface 132 , to check for manufacturing defects.
- DUT complex device under test
- FIG. 2 illustrates an example test procedure of the test system 100 shown in FIG. 1 .
- a test program 120 is generated and converted into a tester format (i.e., tester patterns).
- the test program 120 includes a test stimulus 120 A configured for executing a functional test which tests the functionality of a complex device under test (DUT) 130 or structural test which tests the structure of a complex device under test (DUT) 130 , and a test expected result (expected response) 120 B computed from the computer modeling of a complex device under test (DUT) 130 .
- the controller 112 of the tester 110 may then store the test patterns in the tester memory 114 .
- the controller 112 of the tester 110 may execute the test program 120 by applying the test patterns stored in the tester memory 114 to the complex device under test (DUT) 130 , via the interface 132 , at block 214 .
- the controller 112 of the tester 110 may then check the test result from the complex device under test (DUT) 130 with the expected test result (expected response) from the tester memory 114 in order to check for manufacturing defects at block 216 .
- Test programs 120 configured for functional tests have been commonly used to ensure that complex devices such as microprocessors produce correct results in all possible operating environments and indicate improper microprocessor operation due to design errors or manufacturing defects.
- functional tests are very costly in terms of the (human) resources needed.
- Traditional RIT tools may be used to generate functional tests, but are not very efficient in terms of high fault coverage and, often, require higher test data volume on a host computer under an operating system (OS).
- OS operating system
- FIG. 3 illustrates a typical RIT tool provided to generate a test program (functional test) 120 .
- the RIT tool 300 may be installed in a host computer under an operating system (OS) to receive user directives (user instructions) 302 and ISA (Instruction Set Architecture) information 304 and generate a test program (functional test) 120 .
- the RIT tool 300 may include a test generator 310 arranged to generate a test program (functional test) 120 under device constraints and other architecture constraints, and a simulator 320 arranged to back-off from illegal instructions such as undefined memory accesses and undefined flags.
- the simulator 320 may also be utilized to compute the expected response of a complex device under test (DUT) 130 .
- DUT complex device under test
- Operating system (OS) function calls 330 are provided from an operating system (OS) to format data, generate random numbers and provide other such services for the test generator 310 and the simulator 320 to generate a test program (functional test) 120 .
- OS operating system
- RIT tool generated functional tests require high cost tester 110 where the cost is driven by the need for high speed electronics and high pin count.
- a large number of such RIT tool generated functional tests are needed which in turn drives up the memory required on the tester 110 .
- test programs 120 configured for structural tests have been recently used to indicate improper microprocessor operation due to manufacturing defects.
- Structural tests may be generated by scan automatic test pattern generation (ATPG) tools and executed in the same manner described with reference to FIG. 2 .
- ATG scan automatic test pattern generation
- each flip-flop circuit in the microprocessor is preceded by a selector (multiplexer) to selectively provide the flip-flop either a scan-in signal or a normal signal.
- a selector multiplexer
- DFT design-for-test
- BIST built-in self-test
- FIG. 4 an example test system 400 for testing a complex device such as a microprocessor for manufacturing defects, via an example functional random instruction test (FRIT) kernel 420 according to an embodiment of the present invention is illustrated.
- the new functional random instruction test (FRIT) method advantageously enables automated test generation in real time that is functional test based at speed and inexpensive to implement in silicon, and can be applied on low cost structural testers in order to achieve high collateral coverage while avoiding delay defect screening issues.
- the functional random instruction test (FRIT) method is intended to address the following concerns: (1) the test generation cost issue associated with manual functional test development; (2) the test data volume issue related to RIT tool generated functional tests; (3) the test cost issue by enabling functional tests to be run on low cost structural tests; (4) the test data volume issues on structural testers associated with scan testing; (5) the delay defect screening issues associated with scan testing. Further, since functional patterns are generated and applied at system clock speed, the collateral coverage is very high and, as a result, the defect screening ability of the functional random instruction test (FRIT) method is much superior compared to the structural test methods in use to date. At-speed functional tests can be executed on low cost automated test equipments (ATE) such as low cost testers and delay defects can be identified.
- ATE automated test equipments
- the example test system 400 may include a low cost tester 410 utilized for testing a complex device such as a microprocessor under test (DUT) 430 , via an especially programmed functional random instruction test (FRIT) kernel 420 , for manufacturing defect(s).
- a FRIT kernel 420 is a software programmed to provide a special re-generative capability.
- the FRIT kernel 420 is a special functional test (sequence of instructions)—a test which generates one or more tests in real time when loaded on-board a complex device such as a microprocessor under test (DUT) 430 .
- the FRIT kernel 420 will activate the complex device under test (DUT) 430 to generate and execute its own functional test sequences in real time.
- the FRIT kernel 420 may include a software built-in, self-test (BIST) engine (SBE) 420 A configured to repeatedly generate and execute functional tests of a complex device under test (DUT) 430 , and an expected test result (expected response) 420 B computed based on a computer model of the same complex device under test (DUT) 430 .
- the expected test result (expected response) 420 B may be incorporated into the software built-in, self-test (BIST) engine (SBE) 420 A.
- the SBE 420 A of the FRIT kernel 420 may operate independently from any operating system (OS) and may, therefore, provide an environment to store and run the re-generative functional test.
- OS operating system
- the SBE 420 A of the FRIT kernel 420 may be written in any computer language such as C or C++ code language, and may be provided on a computer tangible medium, such as memory devices; magnetic disks (fixed, floppy, and removable); other magnetic media such as magnetic tapes; optical media such as CD-ROM disks, or via Internet downloads, which may be available for plug-in or download into the controller 412 of the tester 410 for executing random functional instructions (machine code).
- the expected test result (expected response) 420 B may be obtained by alternative techniques. For example, one technique to generate the expected response is to run the re-generative functional test on a good device first and then use the test results of a known good device to construct the expected response.
- the low-cost tester 410 may include, but not limited to, a controller 412 and a memory 414 .
- the complex device under test (DUT) 430 may contain an interface 432 that requires only a few pins, and an on-board memory (e.g., cache) 434 that is used to store the FRIT kernel 420 .
- the controller 412 of the tester 410 may be arranged to receive and store at least a FRIT kernel 420 , including the SBE 420 A and the test expected result (expected response) 420 B into the tester memory 414 .
- the controller 412 may then load the kernel test patterns (SBE) into on-board memory 434 of the complex device under test (DUT) 430 , via an interface 432 .
- SBE kernel test patterns
- the kernel test patterns (SBE) are activated and applied to the complex device under test (DUT) 430 .
- the test result (device response) may be unloaded from the on-board memory 434 of the complex device under test (DUT) 430 and delivered back to the controller 412 of the low-cost tester 410 , via an interface 432 .
- the controller 412 of the low-cost tester 410 may then compare the test result from the on-board memory 434 of the complex device under test (DUT) 430 with the test expected result 420 B stored in the tester memory 414 in order to check for manufacturing defects.
- test result from the complex device under test (DUT) 430 may be sent directly to the tester 410 , via the interface 432 , without first being stored in the on-board memory 434 .
- the test result may be compared directly with the test expected result (expected response) 420 B for manufacturing defects.
- the software BIST engine (SBE) 420 A of the FRIT kernel 420 contains three (3) components: a compact RIT generator 510 , a test program execution module 520 , and a test result compaction module 530 .
- the RIT generator 510 is a software configured with compact RIT machine code that can reside in the on-board memory 434 of the complex device under test (DUT) 430 for generating functional test sequences.
- the test program execution module 520 is a software that contains test execution directives for providing an environment to store and run the re-generated functional test (sequence of instructions). The test execution environment ensures that no memory access outside the complex device under test (DUT) may take place.
- the test execution environment may also employ an exception handler for handling illegal/dangerous conditions such as undesirable memory accesses, deadlock, shut-down, infinite loops etc.
- the test execution environment ensures that the complex device under test (DUT) 430 does not generate any bus cycles during test in order to eliminate the need for a high pin count interface to the tester 410 .
- the test result compaction module 530 is a software that compresses test results for storage in the on-board memory 434 of the complex device under test (DUT) 430 .
- the test result compaction module 530 may correspond to a hardware integrated on-board as part of the complex device under test (DUT) 430 for test result compression.
- FIG. 6 illustrates an example concept of an example SBE generation tool installed in a host computer under an operating system (OS) for generating a SBE 420 A of the FRIT kernel 420 according to an embodiment of the present invention.
- OS operating system
- the SBE generation tool 600 is advantageously configured to generate a software BIST engine (SBE) 420 A of a FRIT kernel 420 that is used for on-chip generation and application of functional tests.
- SBE software BIST engine
- the SBE 420 A of the FRIT kernel 420 is not a typical RIT tool 300 shown in FIG. 3 which requires operating system (OS) facilities for execution.
- the SBE 420 A of the FRIT kernel 420 is a stand-alone software program used to generate and execute one or more tests (the DUT's own functional test sequences) in real time, when loaded on-board a complex device under test (DUT) 430 .
- the SBE 420 A of the FRIT kernel 420 includes a compact RIT generator 510 loaded on-board a complex device under test (DUT) 430 such that a target complex device under test (DUT) 430 can be made to generate its own test in real time.
- the SBE 420 A of the FRIT kernel 420 does not require OS support for test generation since the operating system (OS) is non-existent on the target complex device under test (DUT) 430 .
- a run time (test execution) environment 622 may be provided for the equivalent OS functionality in order to store and execute its own functional test sequences. This way a large number of tests can be executed without corresponding increase in test vector and other test generation restrictions. Likewise, the entire testing can be made possible on low pin count testers because real time generation and application of tests are enabled by the SBE 420 A of the FRIT kernel 420 while on-board a target complex device under test (DUT) 430 .
- DUT target complex device under test
- the SBE generation tool 600 may include a RIT-generator (RIT-G) composer 610 , a test execution directive composer 620 , a test result compaction module composer 630 , and a code merger 640 .
- the RIT-G composer 610 may be arranged to receive user directives 602 and ISA information 604 and generate a compact RIT-generator (RIT-G) code 612 .
- the test execution directive composer 620 may be arranged to receive the user directives 602 and DUT constraints 606 and provide a run time environment 622 .
- the run time environment 622 may include an environment for the generated tests, called “test execution environment” 622 A to provide memory protection and an exception handler to handle occurrence of illegal conditions on-chip such as undesirable memory accesses, deadlock, shut-down, an infinite loops etc., and an environment 622 B for the compact RIT-G code 612 .
- the test result compaction module composer 630 may be arranged to generate a test result compaction module code 632 used to compress test results for subsequent storage on-board a complex device under test (DUT) 430 .
- the code merger 640 may merge coding from the RIT-G composer 610 , the test execution directive composer 620 and the test result compaction module composer 630 to produce the SBE 420 A of the FRIT kernel 420 as shown in FIG. 4 .
- Individual module of the SBE generation tool 600 shown in FIG. 6 may be written in any computer language such as C or C++ code language.
- the SBE generation tool 600 may be provided on a computer tangible medium, such as memory devices; magnetic disks (fixed, floppy, and removable); other magnetic media such as magnetic tapes; optical media such as CD-ROM disks, or via Internet downloads, which may be available for plug-in or download into the host computer for generating a SBE 420 A of a FRIT kernel 420 .
- the SBE generation tool 600 shown in FIG. 6 may be implemented, via hardware of a host computer, to generate a SBE 420 A of a FRIT kernel 420 .
- FIG. 7 illustrates an example SBE generation tool implementation according to an embodiment of the present invention.
- the test execution directive composer 620 may be a component of the SBE generation tool 600 that is responsible for generating run time environments (env.asm), i.e., the test execution environment 622 A and the RIT environment 622 B, which are needed to ensure a regenerative functional test SBE 420 A of a FRIT kernel 420 to repeatedly generate functional tests and execute the generated tests in real time on a target complex device under test (DUT) 430 .
- the test execution environment 622 may be dependent on the memory available in the complex device under test (DUT) 430 , and such information may be provided to the SBE generation tool 600 as DUT constraints 606 .
- the SBE 420 A of the FRIT kernel 420 enables generation and execution of multiple functional tests.
- Each functional test may include a sequence of random instructions.
- the number of instructions in each functional test and the number of functional tests that need to be generated may be user controlled and are part of the user directives 602 .
- a test execution environment 622 A may be produced by the test execution directive composer 620 which ensures appropriate testing is accomplished.
- the test execution environment 622 A may also include an exception handler to handle illegal conditions, such as illegal memory accesses, infinite loops etc., that occur during test execution.
- the RIT environment 622 B has the basic environment that accomplishes operating system (OS) functions needed by the RIT generator 612 .
- OS operating system
- the test result compaction module composer 630 generates the test result compaction module code (trcomp.asm) 632 that is used by the target complex device under test (DUT) 430 in order to compress the test results obtained by application of the several functional tests that get generated and executed during testing.
- the RIT-G composer 610 may be a complex piece of software that is responsible for producing compact RIT-G programs based on user directives 602 .
- the target RIT generator 612 has several constraints that must be followed.
- the ISA (instruction set architecture) information 604 defines the entire suite of possible instructions that a RIT generator 612 can potentially use. However based on the user directives 602 , specific instruction sequences may only be produced by any particular RIT generator 612 .
- Examples of such user directives 602 include, but are not limited to the following cases: Specifying a class of instructions like floating point, integer, branch, etc., specifying sequences of instruction classes like memory operations followed by integer/floating point instructions, specifying a ratio of the desired mix of the instruction classes etc.
- the RIT-G composer 610 may be capable of taking such user directives and crafting specific RIT-G programs that when executed by the complex device under test (DUT) 430 in real time during test application, produce functional tests in accordance with the user directives 602 provided.
- the RIT-G code (RIT-G.c) 612 is a program (sequence of target DUT instructions) that meets the following constraints: it is compact in memory utilization, efficient in terms of instruction generation cost, is able to work around the lack of an operating system (OS) by using the provided run time environment 622 , and when executed on the target DUT 430 during test, generates sequences of DUT instructions.
- the RIT-G code 612 includes an instruction generation module. The algorithm of the instruction generation module is shown in FIG. 8 .
- the RIT generator (RIT-G) 612 produced is a C-language program which is compiled by a C-compiler 710 to produce the assembly language version of the RIT generator (RIT-G.asm) 712 .
- the code merger 640 is used to generate a single assembly language program. This is processed by the assembler 720 to produce the final re-generative functional test SBE 420 A in the object code (machine language) of the target complex device under test (DUT) 430 .
- FIG. 8 illustrates an example instruction generation algorithm that is part of the RIT generator 612 according to an embodiment of the present invention.
- the algorithm shows how an individual instruction gets generated by the RIT generator 612 when it is executed as part of the SBE 420 A by the complex device under test (DUT) 430 .
- a random index may be first generated.
- the random index may then be used to select an instruction to be generated from the instruction data structure table 814 .
- Each instruction may include several fields. For the selected instruction, the valid field values may be generated at block 816 . Certain instructions may not be self-contained and may need additional instructions to be executed before or after the generated instruction.
- the FRIT kernel 420 is generated and converted into a test format (i.e., kernel test patterns).
- the FRIT kernel 420 contains a SBE 420 A configured for executing the functional test sequences which test the functionality of a complex device under test (DUT) 430 , and a test expected result (expected response) 420 B computed from the computer modeling of the same complex device under test (DUT) 430 or from a known good device.
- the controller 412 of the low-cost tester 410 may then receive and store the kernel test patterns in the tester memory 414 at block 912 .
- the controller 412 of the low cost tester 410 may then load the kernel test patterns (SBE “420A”) into on-board memory 434 of the complex device under test (DUT) 430 , via an interface 432 at block 914 .
- the controller 412 of the low cost tester 410 may enable execution of the kernel test patterns (SBE “420A”), that is, the kernel test patterns (SBE “420A”) may be automatically activated and repeatedly applied to the complex device under test (DUT) 430 at block 916 .
- the test results may store in the on-board memory 434 of the complex device under test (DUT) 430 .
- the controller 412 of the tester 410 may then unload the test results (device response) from the on-board memory 434 of the complex device under test (DUT) 430 , via the interface 432 , and compare the test results from the on-board memory 434 of the complex device under test (DUT) 430 with the test expected result 420 B stored in the tester memory 414 in order to check for manufacturing defects at block 918 .
- FIG. 10 illustrates a flow diagram of an example functional random instruction test (FRIT) execution sequence according to an embodiment of the present invention.
- the kernel test patterns SBE “420A”
- DUT microprocessor under test
- the microprocessor 430 may begin basic set-up at block 1010 .
- the kernel test patterns SBE “420A”
- SBE “320A” Associated data for the test sequence may also be generated by the kernel test patterns (SBE “320A”) at block 1014 .
- the microprocessor 430 may now run (execute) the test sequence at block 1016 .
- the test results may be obtained and compressed by way of the test result compaction module 530 of the kernel test patterns (SBE “420A”) as shown in FIG. 5 , for subsequently storage in the on-board memory 434 at block 1018 .
- each FRIT kernel 420 may be programmed to generate one or more (“N”) loops of test sequences, where N represents an integer no less than “1” and is a user-specified number used in generating the FRIT kernel 420 by an especially designed SBE generation tool 600 shown in FIG. 6 .
- N represents an integer no less than “1” and is a user-specified number used in generating the FRIT kernel 420 by an especially designed SBE generation tool 600 shown in FIG. 6 .
- Each of these N test sequences may in turn employ one or more (M) different data sets. Therefore, if N is ten (10) and M is five (5) for example, then there may be ten (10) distinct instruction sequences executed, each being executed five (5) times on five (5) distinct data sets, and the test results of respective loops may be obtained, compressed and written back to the on-board memory 434 .
- a signature may be generated to provide a unique identification of the test result of each test sequence and to indicate whether the test result of a particular test sequence is “good” or “bad”.
- the resulting “signature” may then be stored in the on-board memory 434 .
- the signatures of all (N times M) loops may make up the expected test result (expected response) of the complex device under test (DUT) 430 .
- the microprocessor 430 may determine if all data sets (M) associated with a test sequence of a particular loop are completed or done at block 1020 . If all data sets associated with a test sequence of a particular loop are not completed or done, the microprocessor 430 may return to generate associated data at block 1014 and continue to run the test sequence at block 1016 until the test result is obtained and compressed at block 1018 . However, if the data sets associated with a test sequence are completed or done, the microprocessor 430 may determine if all (“N”) instruction sequences are completed or done at block 1022 .
- the microprocessor 430 may return to generate a new test sequence at block 1012 , associated data of the new test sequence at block 1014 and continue to run the test sequence at block 1016 until the test result of the new test sequence is obtained and compressed at block 1018 .
- the microprocessor 430 may dump the test results of the FRIT kernel 420 from the on-board memory 434 of the microprocessor 430 back to the low cost tester 410 , via low pin interface 432 .
- FIG. 11 illustrates a block diagram of an example functional random instruction test (FRIT) execution sequence shown in FIG. 10 .
- FRIT functional random instruction test
- FIG. 11 shows the case when M is one “1”.
- the FRIT kernel 420 is loaded into the on-board memory 434 of a complex device such as microprocessor under test (DUT) 430 .
- the FRIT kernel 420 may be executed by the microprocessor 430 to produce test sequence # 1 and associated data for test sequence # 1 .
- the test sequence # 1 may be executed by the microprocessor 430 to produce a test result # 1 , after the test sequence # 1 and associated data for test sequence # 1 are produced.
- the test result # 1 may be compressed for compaction and may then be written into the on-board memory 434 .
- the FRIT kernel 420 may be continued executed by the microprocessor 430 to produce a next test sequence, test sequence # 2 for example, and associated data for test sequence # 2 for test execution and subsequent test result compression until all test sequences are completed.
- the test results may then be dumped out after several data loops of test generation/execution by the microprocessor 430 and transferred back to the tester memory 314 for comparison with the expected test result (expected response) 420 B stored therein to check for manufacturing defects.
- FIGS. 12-13 illustrate an example memory image of a complex device such as a microprocessor under test (DUT) 430 at the beginning and at the end of a test according to an embodiment of the present invention.
- the FRIT kernel test patterns 420 may be loaded into the on-board memory 434 using, for example, a test access port (TAP) controller (not shown).
- TAP test access port
- the FRIT kernel 420 may also contain an exception handler 422 configured to handle illegal conditions during test (i.e., execution of the FRIT kernel 420 ).
- all the test results of the complex device under test (DUT) 430 stored in the on-board memory 334 may be dumped out from the on-board memory 434 to the controller 412 of the tester 410 where the test results are compared with the expected test result (expected response) 420 B stored in the tester memory 414 in order to check for manufacturing defects.
- DUT complex device under test
- the SBE generation tool advantageously generates a testing component, SBE 420 A of the FRIT kernel 420 for on-chip generation and application of functional tests.
- the FRIT kernel 420 then enables automated test generation in real time that is functional test based at speed and inexpensive to implement in silicon, and can be applied on low cost structural testers in order to achieve high collateral coverage while avoiding delay defect screening issues.
- the FRIT kernel 420 also allows a large number of tests to be applied without corresponding increase in test vector, that is, the increase in test data volume that exist with traditional RIT tools.
- the FRIT method offers tremendous benefits in containing the cost and ensuring quality of the microprocessors that are produced with practically no design changes and no silicon overhead.
- the FRIT kernel can be used at any test phase (SORT, Burn-In, Class) to reduce test data volume on the tester.
- FIGS. 1 and 4 may be configured differently or employ some or different components than those illustrated without changing the basic function of the invention.
- the SBE generation tool and the SBE generation tool implementation may be configured differently without changing the basic function of generating a SBE.
- the flow diagrams shown in FIGS. 9-13 may also be described differently without changing the basic function of the invention. Many modifications may be made to adapt the teachings of the present invention to a particular situation without departing from the scope thereof. Therefore, it is intended that the present invention not be limited to the various exemplary embodiments disclosed, but that the present invention includes all embodiments falling within the scope of the appended claims.
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Tests Of Electronic Circuits (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
A host system for generating a software built-in self-test engine (SBE) is provided for enabling on-chip generation and application of a re-generative functional test on a complex device such as a microprocessor under test. The host system comprises user directives provided to indicate user desired actions; instruction information provided to define a suite of instructions; and a SBE generation tool arranged to generate a software built-in self-test engine (SBE) based on the user directives, the instruction information and device constraints, for subsequent storage on-board of a complex device such as a microprocessor under test and activation of a re-generative functional test on the complex device under test (DUT).
Description
- This application is a continuation of U.S. application Ser. No. 09/922,639 filed on Aug. 7, 2001 which is incorporated herein by reference.
- This application relates to prior application for Functional Random Instruction Testing (FRIT) Method For Complex Devices Such As Microprocessors filed on Jul. 31, 2001, there duly assigned Ser. No. 09/917,661.
- The present invention relates to the manufacture and functional testing of complex devices such as microprocessors, and more particularly, relates to a tool for generating a re-generative functional test in the form of a kernel for enabling on-chip generation and application of functional tests.
- Application specific integrated circuit (ASIC) technology has undergone rapid changes in recent years. Current ASIC chips may include functional blocks, such as microprocessors, interfaces, memory arrays, and DSPs (digital signal processors) all of which need to be validated for design correctness and/or tested for manufacturing defects.
- Microprocessor testing is typically considered one of the most complex problems in ASIC testing, whether the microprocessor happens to be an ASIC core or a stand-alone device. This is because modern microprocessors are highly complex and typically enhanced with additional operating modes and features. For example, newer ×86 microprocessors such as Pentium® processors as marketed by Intel® Corporation are designed to maintain software compatibility with previous 80×86 microprocessor generations (e.g., 8086/8, 80286, 80386, and 80486). These newer ×86 microprocessors include multiple operating modes and are equipped with cache memory systems and added hardware support features for operation in multi-processor environments. Errors in the designs of microprocessors and defects introduced during manufacturing may cause the microprocessors to produce incorrect results during operation.
- Traditionally functional tests have been used to ensure that complex devices such as microprocessors under test produce correct results in all possible operating environments. Functional tests may be manually written by designers/programmers but are typically generated by random instruction test (RIT) tools, via a host computer under an operating system (OS) as described, for example, in the “Native Mode Functional Test Generation For Processors With Applications To Self Test and Design Validation” by Jian Shen and Jacob A. Abraham of the Computer Engineering Research Center, University of Texas, IEEE International Test Conference, pp. 990-999, August 1998. In general, these functional tests include software instructions which cause a microprocessor under test to perform a desired activity and to produce a test result. The test result is compared with an expected test result derived from a functional specification of the microprocessor under test. Any difference between the test result produced by the microprocessor under test and the expected test result represents a failure of the functional test. Such a functional test failure may indicate improper microprocessor operation due to a design error or a manufacturing defect.
- However, manual development of functional tests is very costly in terms of the (human) resources needed. Likewise, RIT tools are not very efficient in terms of high fault coverage and, often, require a large number of tests and a large tester memory to produce high coverage. In addition, large scale, high pin count and expensive automatic test equipments (ATE) such as IC testers with several hundreds test pins (test channels), each of which includes a pattern generator, a timing generator and a frame processor, are required.
- Other types of testing, such as design-for-test (DFT) techniques and built-in self-test (BIST) schemes such as scan, partial scan, logic BIST, and scan-based BIST, have been utilized to structurally test various logic blocks within a microprocessor. However, structural test tools require a large amount of test data and additional hardware area (extra logic circuits) to implement the test logic. In addition, there are inherent problems relating to high performance penalty and low collateral coverage.
- Therefore there is need to develop a new tool programmed to generate a re-generative functional test in the form of a kernel that can be loaded on-board of a complex device such as a microprocessor to generate and execute its own functional tests in real time so as to avoid test data volume issues and achieve high collateral coverage with at-speed test application.
- A more complete appreciation of exemplary embodiments of the present invention, and many of the attendant advantages of the present invention, will become readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein:
-
FIG. 1 illustrates an example test system for testing a complex device such as a microprocessor for manufacturing defect(s); -
FIG. 2 illustrates an example flow diagram of an example test procedure; -
FIG. 3 illustrates an example RIT tool installed in a host computer under an operating system (OS) for generating a test program (functional test); -
FIG. 4 illustrates an example test system for testing a complex device such as a microprocessor for manufacturing defects, via an example functional random instruction test (FRIT) kernel according to an embodiment of the present invention; -
FIG. 5 illustrates an example functional random instruction test (FRIT) kernel according to an embodiment of the present invention; -
FIG. 6 illustrates an example concept of an example software built-in, self-test (BIST) engine (SBE) generation tool installed in a host computer under an operating system (OS) for generating a SBE of the FRIT kernel according to an embodiment of the present invention; -
FIG. 7 illustrates an example SBE generation tool implementation according to an embodiment of the present invention; -
FIG. 8 illustrates an example instruction generation algorithm embedded in the SBE for generating an individual instruction during test application according to an embodiment of the present invention; -
FIG. 9 illustrates a flow diagram of an example functional random instruction test (FRIT) application according to an embodiment of the present invention; -
FIG. 10 illustrates a flow diagram of an example flow diagram of a functional random instruction test (FRIT) execution sequence according to an embodiment of the present invention; -
FIG. 11 illustrates a block diagram of an example functional random instruction test (FRIT) sequence execution according to an embodiment of the present invention; -
FIG. 12 illustrates an example memory image of a complex device such as a microprocessor under test (DUT) at the beginning of test according to an embodiment of the present invention; and -
FIG. 13 illustrates an example memory image of a complex device such as a microprocessor under test (DUT) at the end of test according to an embodiment of the present invention. - The present invention is applicable to the testing of microprocessors, complex digital systems, and chipsets and new chipsets having memory and logic components incorporated therein which may become available as computer technology develops in the future. In addition, testing can be conducted on automated test equipment such as low cost testers, functional testers or even computer systems. The present invention is also applicable to the testing of one or more complex devices such as microprocessors integrated on one or more chipsets on board. However, for the sake of simplicity, discussions will concentrate mainly on random instruction testing of a single complex device such as a microprocessor, although the scope of the present invention is not limited thereto.
- Attention now is directed to the drawings and particularly to
FIG. 1 , anexample test system 100 may include an automated test equipment (ATE) such as atester 110 utilized for testing a complex device such as a microprocessor under test (DUT) 130, viatest programs 120, for manufacturing defect(s). Eachtest program 120 may include a test stimulus 120A and an expected test result (expected response) 120B. Thetest stimulus 120 may correspond to a software program, typically written manually or generated by traditional RIT tools for executing a functional test of a complex device such as a microprocessor under test (DUT) 130. The expectedtest result 120B is an expected response of a complex device under test (DUT) 130 computed based on a computer model of the same complex device under test (DUT) 130. - Generally, a simulation software (simulator) and a simulation model are utilized by a computer system (not shown) for computing the expected response of a complex device under test (DUT) 130. The simulation model may indicate a software representation of a complex device under test (DUT) 130, and may be written using hardware description languages such as Verilog or VHDL, and may be provided on a computer tangible medium, such as memory devices; magnetic disks (fixed, floppy, and removable); other magnetic media such as magnetic tapes; optical media such as CD-ROM disks, or via Internet downloads, which may be available for plug-in or download into an existing operating system (OS) for computing the expected response of a complex device under test (DUT) 130.
- As shown in
FIG. 1 , thetester 110 may include, but not limited to, acontroller 112 and amemory 114. Thecontroller 112 may be arranged to receive one ormore test programs 120 in tester format and store test patterns into thetester memory 114. Thecontroller 112 may then execute thetest program 120 by applying the test patterns to the complex device under test (DUT) 130, via aninterface 132, to check for manufacturing defects. -
FIG. 2 illustrates an example test procedure of thetest system 100 shown inFIG. 1 . Atblock 210, atest program 120 is generated and converted into a tester format (i.e., tester patterns). As described with reference toFIG. 1 , thetest program 120 includes a test stimulus 120A configured for executing a functional test which tests the functionality of a complex device under test (DUT) 130 or structural test which tests the structure of a complex device under test (DUT) 130, and a test expected result (expected response) 120B computed from the computer modeling of a complex device under test (DUT) 130. Thecontroller 112 of thetester 110 may then store the test patterns in thetester memory 114. Next, thecontroller 112 of thetester 110 may execute thetest program 120 by applying the test patterns stored in thetester memory 114 to the complex device under test (DUT) 130, via theinterface 132, atblock 214. Thecontroller 112 of thetester 110 may then check the test result from the complex device under test (DUT) 130 with the expected test result (expected response) from thetester memory 114 in order to check for manufacturing defects atblock 216. -
Test programs 120 configured for functional tests have been commonly used to ensure that complex devices such as microprocessors produce correct results in all possible operating environments and indicate improper microprocessor operation due to design errors or manufacturing defects. However, functional tests are very costly in terms of the (human) resources needed. Traditional RIT tools may be used to generate functional tests, but are not very efficient in terms of high fault coverage and, often, require higher test data volume on a host computer under an operating system (OS). - For example,
FIG. 3 illustrates a typical RIT tool provided to generate a test program (functional test) 120. As shown inFIG. 3 , theRIT tool 300 may be installed in a host computer under an operating system (OS) to receive user directives (user instructions) 302 and ISA (Instruction Set Architecture)information 304 and generate a test program (functional test) 120. TheRIT tool 300 may include atest generator 310 arranged to generate a test program (functional test) 120 under device constraints and other architecture constraints, and asimulator 320 arranged to back-off from illegal instructions such as undefined memory accesses and undefined flags. Thesimulator 320 may also be utilized to compute the expected response of a complex device under test (DUT) 130. Operating system (OS) function calls 330 are provided from an operating system (OS) to format data, generate random numbers and provide other such services for thetest generator 310 and thesimulator 320 to generate a test program (functional test) 120. However, RIT tool generated functional tests requirehigh cost tester 110 where the cost is driven by the need for high speed electronics and high pin count. In addition, for high test coverage a large number of such RIT tool generated functional tests are needed which in turn drives up the memory required on thetester 110. - Due to high equipment costs and test generation costs inherent to functional tests, various design-for-test (DFT) techniques and built-in self-test (BIST) schemes such as scan, partial scan, logic BIST, scan-based BIST may be utilized to structurally test various logic blocks within a microprocessor, via
low cost tester 110 without the need for high pin count and high speed test. As a result,test programs 120 configured for structural tests have been recently used to indicate improper microprocessor operation due to manufacturing defects. Structural tests may be generated by scan automatic test pattern generation (ATPG) tools and executed in the same manner described with reference toFIG. 2 . - The main problem in these structural test approaches is the requirement of large amount of test data and additional hardware area (extra logic circuits) to implement the test logic. This is because test patterns are serially shifted into the microprocessor at slow speeds which can be very costly in terms of test time. In addition, these test schemes also cause a 5-10% performance penalty, typically, in a signal propagation delay. For example, in the scan implementation, each flip-flop circuit in the microprocessor is preceded by a selector (multiplexer) to selectively provide the flip-flop either a scan-in signal or a normal signal. Such an additional selector causes a delay time in the overall performance of the flip-flop circuit. Thus, the design-for-test (DFT) and built-in self-test (BIST) schemes may adversely affect the microprocessor's performance, such as an operating speed because of the signal propagation delays. Moreover, the collateral coverage from application of structural tests may be more limited compared to that achieved through the application of functional patterns.
- Turning now to
FIG. 4 , anexample test system 400 for testing a complex device such as a microprocessor for manufacturing defects, via an example functional random instruction test (FRIT)kernel 420 according to an embodiment of the present invention is illustrated. The new functional random instruction test (FRIT) method advantageously enables automated test generation in real time that is functional test based at speed and inexpensive to implement in silicon, and can be applied on low cost structural testers in order to achieve high collateral coverage while avoiding delay defect screening issues. The functional random instruction test (FRIT) method is intended to address the following concerns: (1) the test generation cost issue associated with manual functional test development; (2) the test data volume issue related to RIT tool generated functional tests; (3) the test cost issue by enabling functional tests to be run on low cost structural tests; (4) the test data volume issues on structural testers associated with scan testing; (5) the delay defect screening issues associated with scan testing. Further, since functional patterns are generated and applied at system clock speed, the collateral coverage is very high and, as a result, the defect screening ability of the functional random instruction test (FRIT) method is much superior compared to the structural test methods in use to date. At-speed functional tests can be executed on low cost automated test equipments (ATE) such as low cost testers and delay defects can be identified. - As shown in
FIG. 4 , theexample test system 400 may include alow cost tester 410 utilized for testing a complex device such as a microprocessor under test (DUT) 430, via an especially programmed functional random instruction test (FRIT)kernel 420, for manufacturing defect(s). AFRIT kernel 420 is a software programmed to provide a special re-generative capability. Essentially, theFRIT kernel 420 is a special functional test (sequence of instructions)—a test which generates one or more tests in real time when loaded on-board a complex device such as a microprocessor under test (DUT) 430. When loaded on-board a complex device such as a microprocessor under test (DUT) 430, theFRIT kernel 420 will activate the complex device under test (DUT) 430 to generate and execute its own functional test sequences in real time. - The
FRIT kernel 420 may include a software built-in, self-test (BIST) engine (SBE) 420A configured to repeatedly generate and execute functional tests of a complex device under test (DUT) 430, and an expected test result (expected response) 420B computed based on a computer model of the same complex device under test (DUT) 430. Alternatively, the expected test result (expected response) 420B may be incorporated into the software built-in, self-test (BIST) engine (SBE) 420A. In either situation, theSBE 420A of theFRIT kernel 420 may operate independently from any operating system (OS) and may, therefore, provide an environment to store and run the re-generative functional test. TheSBE 420A of theFRIT kernel 420 may be written in any computer language such as C or C++ code language, and may be provided on a computer tangible medium, such as memory devices; magnetic disks (fixed, floppy, and removable); other magnetic media such as magnetic tapes; optical media such as CD-ROM disks, or via Internet downloads, which may be available for plug-in or download into thecontroller 412 of thetester 410 for executing random functional instructions (machine code). In addition, the expected test result (expected response) 420B may be obtained by alternative techniques. For example, one technique to generate the expected response is to run the re-generative functional test on a good device first and then use the test results of a known good device to construct the expected response. - As shown in
FIG. 4 , the low-cost tester 410 may include, but not limited to, acontroller 412 and a memory 414. The complex device under test (DUT) 430 may contain aninterface 432 that requires only a few pins, and an on-board memory (e.g., cache) 434 that is used to store theFRIT kernel 420. Thecontroller 412 of thetester 410 may be arranged to receive and store at least aFRIT kernel 420, including theSBE 420A and the test expected result (expected response) 420B into the tester memory 414. Thecontroller 412 may then load the kernel test patterns (SBE) into on-board memory 434 of the complex device under test (DUT) 430, via aninterface 432. Once loaded on-board memory 434 of the complex device under test (DUT) 430, the kernel test patterns (SBE) are activated and applied to the complex device under test (DUT) 430. The test result (device response) may be unloaded from the on-board memory 434 of the complex device under test (DUT) 430 and delivered back to thecontroller 412 of the low-cost tester 410, via aninterface 432. Thecontroller 412 of the low-cost tester 410 may then compare the test result from the on-board memory 434 of the complex device under test (DUT) 430 with the test expectedresult 420B stored in the tester memory 414 in order to check for manufacturing defects. In another embodiment of the present invention, the test result from the complex device under test (DUT) 430 may be sent directly to thetester 410, via theinterface 432, without first being stored in the on-board memory 434. At thetester 410, the test result may be compared directly with the test expected result (expected response) 420B for manufacturing defects. - As shown in
FIG. 5 , the software BIST engine (SBE) 420A of theFRIT kernel 420 contains three (3) components: acompact RIT generator 510, a testprogram execution module 520, and a testresult compaction module 530. TheRIT generator 510 is a software configured with compact RIT machine code that can reside in the on-board memory 434 of the complex device under test (DUT) 430 for generating functional test sequences. The testprogram execution module 520 is a software that contains test execution directives for providing an environment to store and run the re-generated functional test (sequence of instructions). The test execution environment ensures that no memory access outside the complex device under test (DUT) may take place. The test execution environment may also employ an exception handler for handling illegal/dangerous conditions such as undesirable memory accesses, deadlock, shut-down, infinite loops etc. Thus the test execution environment ensures that the complex device under test (DUT) 430 does not generate any bus cycles during test in order to eliminate the need for a high pin count interface to thetester 410. The testresult compaction module 530 is a software that compresses test results for storage in the on-board memory 434 of the complex device under test (DUT) 430. Alternatively, the testresult compaction module 530 may correspond to a hardware integrated on-board as part of the complex device under test (DUT) 430 for test result compression. -
FIG. 6 illustrates an example concept of an example SBE generation tool installed in a host computer under an operating system (OS) for generating aSBE 420A of theFRIT kernel 420 according to an embodiment of the present invention. Unlike thetypical RIT tool 300 used to generate a test program (functional test) 120 as described with reference toFIG. 3 , theSBE generation tool 600 according to an embodiment of the present invention is advantageously configured to generate a software BIST engine (SBE) 420A of aFRIT kernel 420 that is used for on-chip generation and application of functional tests. In other words, theSBE 420A of theFRIT kernel 420 is not atypical RIT tool 300 shown inFIG. 3 which requires operating system (OS) facilities for execution. Rather, theSBE 420A of theFRIT kernel 420 is a stand-alone software program used to generate and execute one or more tests (the DUT's own functional test sequences) in real time, when loaded on-board a complex device under test (DUT) 430. This is because theSBE 420A of theFRIT kernel 420 includes acompact RIT generator 510 loaded on-board a complex device under test (DUT) 430 such that a target complex device under test (DUT) 430 can be made to generate its own test in real time. In addition, theSBE 420A of theFRIT kernel 420 does not require OS support for test generation since the operating system (OS) is non-existent on the target complex device under test (DUT) 430. Instead, a run time (test execution)environment 622 may be provided for the equivalent OS functionality in order to store and execute its own functional test sequences. This way a large number of tests can be executed without corresponding increase in test vector and other test generation restrictions. Likewise, the entire testing can be made possible on low pin count testers because real time generation and application of tests are enabled by theSBE 420A of theFRIT kernel 420 while on-board a target complex device under test (DUT) 430. - As shown in
FIG. 6 , theSBE generation tool 600 may include a RIT-generator (RIT-G)composer 610, a testexecution directive composer 620, a test resultcompaction module composer 630, and acode merger 640. The RIT-G composer 610 may be arranged to receiveuser directives 602 andISA information 604 and generate a compact RIT-generator (RIT-G)code 612. The testexecution directive composer 620 may be arranged to receive theuser directives 602 andDUT constraints 606 and provide arun time environment 622. Therun time environment 622 may include an environment for the generated tests, called “test execution environment” 622A to provide memory protection and an exception handler to handle occurrence of illegal conditions on-chip such as undesirable memory accesses, deadlock, shut-down, an infinite loops etc., and anenvironment 622B for the compact RIT-G code 612. The test resultcompaction module composer 630 may be arranged to generate a test resultcompaction module code 632 used to compress test results for subsequent storage on-board a complex device under test (DUT) 430. Thecode merger 640 may merge coding from the RIT-G composer 610, the testexecution directive composer 620 and the test resultcompaction module composer 630 to produce theSBE 420A of theFRIT kernel 420 as shown inFIG. 4 . - Individual module of the
SBE generation tool 600 shown inFIG. 6 , such as the RIT-G composer 610, the testexecution directive composer 620, the test resultcompaction module composer 630, may be written in any computer language such as C or C++ code language. TheSBE generation tool 600 may be provided on a computer tangible medium, such as memory devices; magnetic disks (fixed, floppy, and removable); other magnetic media such as magnetic tapes; optical media such as CD-ROM disks, or via Internet downloads, which may be available for plug-in or download into the host computer for generating aSBE 420A of aFRIT kernel 420. Alternatively, theSBE generation tool 600 shown inFIG. 6 may be implemented, via hardware of a host computer, to generate aSBE 420A of aFRIT kernel 420. -
FIG. 7 illustrates an example SBE generation tool implementation according to an embodiment of the present invention. As shown inFIG. 7 , the testexecution directive composer 620 may be a component of theSBE generation tool 600 that is responsible for generating run time environments (env.asm), i.e., thetest execution environment 622A and theRIT environment 622B, which are needed to ensure a regenerativefunctional test SBE 420A of aFRIT kernel 420 to repeatedly generate functional tests and execute the generated tests in real time on a target complex device under test (DUT) 430. Thetest execution environment 622 may be dependent on the memory available in the complex device under test (DUT) 430, and such information may be provided to theSBE generation tool 600 asDUT constraints 606. - During test application, the
SBE 420A of theFRIT kernel 420 enables generation and execution of multiple functional tests. Each functional test may include a sequence of random instructions. The number of instructions in each functional test and the number of functional tests that need to be generated may be user controlled and are part of theuser directives 602. Based on theseuser directives 602, atest execution environment 622A may be produced by the testexecution directive composer 620 which ensures appropriate testing is accomplished. In addition, thetest execution environment 622A may also include an exception handler to handle illegal conditions, such as illegal memory accesses, infinite loops etc., that occur during test execution. TheRIT environment 622B has the basic environment that accomplishes operating system (OS) functions needed by theRIT generator 612. - The test result
compaction module composer 630 generates the test result compaction module code (trcomp.asm) 632 that is used by the target complex device under test (DUT) 430 in order to compress the test results obtained by application of the several functional tests that get generated and executed during testing. - The RIT-
G composer 610 may be a complex piece of software that is responsible for producing compact RIT-G programs based onuser directives 602. Thetarget RIT generator 612 has several constraints that must be followed. For a target complex device under test (DUT) 430, the ISA (instruction set architecture)information 604 defines the entire suite of possible instructions that aRIT generator 612 can potentially use. However based on theuser directives 602, specific instruction sequences may only be produced by anyparticular RIT generator 612. Examples ofsuch user directives 602 include, but are not limited to the following cases: Specifying a class of instructions like floating point, integer, branch, etc., specifying sequences of instruction classes like memory operations followed by integer/floating point instructions, specifying a ratio of the desired mix of the instruction classes etc. - The RIT-
G composer 610 may be capable of taking such user directives and crafting specific RIT-G programs that when executed by the complex device under test (DUT) 430 in real time during test application, produce functional tests in accordance with theuser directives 602 provided. The RIT-G code (RIT-G.c) 612 is a program (sequence of target DUT instructions) that meets the following constraints: it is compact in memory utilization, efficient in terms of instruction generation cost, is able to work around the lack of an operating system (OS) by using the providedrun time environment 622, and when executed on thetarget DUT 430 during test, generates sequences of DUT instructions. The RIT-G code 612 includes an instruction generation module. The algorithm of the instruction generation module is shown inFIG. 8 . - In the example SBE tool implementation shown in
FIG. 7 , the RIT generator (RIT-G) 612 produced is a C-language program which is compiled by a C-compiler 710 to produce the assembly language version of the RIT generator (RIT-G.asm) 712. Once the run timetest execution environment 622, the testresult compaction module 632 and the assembly language version of the RIT generator (RIT-G.asm) 712 are generated, thecode merger 640 is used to generate a single assembly language program. This is processed by theassembler 720 to produce the final re-generativefunctional test SBE 420A in the object code (machine language) of the target complex device under test (DUT) 430. -
FIG. 8 illustrates an example instruction generation algorithm that is part of theRIT generator 612 according to an embodiment of the present invention. The algorithm shows how an individual instruction gets generated by theRIT generator 612 when it is executed as part of theSBE 420A by the complex device under test (DUT) 430. Atblock 810, a random index may be first generated. Atblock 812, the random index may then be used to select an instruction to be generated from the instruction data structure table 814. Each instruction may include several fields. For the selected instruction, the valid field values may be generated atblock 816. Certain instructions may not be self-contained and may need additional instructions to be executed before or after the generated instruction. - At
block 818, all such instructions may be handled, and appropriate pre and post instructions may be generated. Atblock 820, the generated instruction may then be stored in the on-board memory of the target complex device under test (DUT) 430 at the location assigned by thetest execution environment 622. - Referring now to
FIG. 9 , an example test procedure of thetest system 400 according to an embodiment of the present invention is illustrated. Atblock 910, theFRIT kernel 420 is generated and converted into a test format (i.e., kernel test patterns). As described with reference toFIG. 4 , theFRIT kernel 420 contains aSBE 420A configured for executing the functional test sequences which test the functionality of a complex device under test (DUT) 430, and a test expected result (expected response) 420B computed from the computer modeling of the same complex device under test (DUT) 430 or from a known good device. - The
controller 412 of the low-cost tester 410 may then receive and store the kernel test patterns in the tester memory 414 atblock 912. Next, thecontroller 412 of thelow cost tester 410 may then load the kernel test patterns (SBE “420A”) into on-board memory 434 of the complex device under test (DUT) 430, via aninterface 432 atblock 914. Once loaded into the on-board memory 434 of the complex device under test (DUT) 430, thecontroller 412 of thelow cost tester 410 may enable execution of the kernel test patterns (SBE “420A”), that is, the kernel test patterns (SBE “420A”) may be automatically activated and repeatedly applied to the complex device under test (DUT) 430 atblock 916. The test results may store in the on-board memory 434 of the complex device under test (DUT) 430. Thecontroller 412 of thetester 410 may then unload the test results (device response) from the on-board memory 434 of the complex device under test (DUT) 430, via theinterface 432, and compare the test results from the on-board memory 434 of the complex device under test (DUT) 430 with the test expectedresult 420B stored in the tester memory 414 in order to check for manufacturing defects atblock 918. -
FIG. 10 illustrates a flow diagram of an example functional random instruction test (FRIT) execution sequence according to an embodiment of the present invention. As shown inFIG. 10 , after the kernel test patterns (SBE “420A”) are applied to the complex device such as a microprocessor under test (DUT) 430 from the on-board memory 434, themicroprocessor 430 may begin basic set-up atblock 1010. The kernel test patterns (SBE “420A”) are then executed by themicroprocessor 430 to generate a test sequence atblock 1012. Associated data for the test sequence may also be generated by the kernel test patterns (SBE “320A”) atblock 1014. Once the test sequence and the associated data are generated, themicroprocessor 430 may now run (execute) the test sequence atblock 1016. At the end of the test sequence, the test results may be obtained and compressed by way of the testresult compaction module 530 of the kernel test patterns (SBE “420A”) as shown inFIG. 5 , for subsequently storage in the on-board memory 434 atblock 1018. - Referring now back to
FIGS. 4-5 , theSBE 420A of eachFRIT kernel 420 may be programmed to generate one or more (“N”) loops of test sequences, where N represents an integer no less than “1” and is a user-specified number used in generating theFRIT kernel 420 by an especially designedSBE generation tool 600 shown inFIG. 6 . Each of these N test sequences may in turn employ one or more (M) different data sets. Therefore, if N is ten (10) and M is five (5) for example, then there may be ten (10) distinct instruction sequences executed, each being executed five (5) times on five (5) distinct data sets, and the test results of respective loops may be obtained, compressed and written back to the on-board memory 434. In addition, a signature may be generated to provide a unique identification of the test result of each test sequence and to indicate whether the test result of a particular test sequence is “good” or “bad”. The resulting “signature” may then be stored in the on-board memory 434. The signatures of all (N times M) loops may make up the expected test result (expected response) of the complex device under test (DUT) 430. - After the test result of a particular test sequence is obtained and compressed for compaction, the
microprocessor 430 may determine if all data sets (M) associated with a test sequence of a particular loop are completed or done atblock 1020. If all data sets associated with a test sequence of a particular loop are not completed or done, themicroprocessor 430 may return to generate associated data atblock 1014 and continue to run the test sequence atblock 1016 until the test result is obtained and compressed atblock 1018. However, if the data sets associated with a test sequence are completed or done, themicroprocessor 430 may determine if all (“N”) instruction sequences are completed or done atblock 1022. If all instruction sequences (N) are not completed or done, themicroprocessor 430 may return to generate a new test sequence atblock 1012, associated data of the new test sequence atblock 1014 and continue to run the test sequence atblock 1016 until the test result of the new test sequence is obtained and compressed atblock 1018. When all the N instruction loops and M data sets have been executed, i.e., N times M number of instruction sequences have been executed, themicroprocessor 430 may dump the test results of theFRIT kernel 420 from the on-board memory 434 of themicroprocessor 430 back to thelow cost tester 410, vialow pin interface 432. -
FIG. 11 illustrates a block diagram of an example functional random instruction test (FRIT) execution sequence shown inFIG. 10 . For simplicity, the data loops are not show inFIG. 11 . Only instruction sequences are shown but are not limited thereto.FIG. 11 shows the case when M is one “1”. Atblock 1110, theFRIT kernel 420 is loaded into the on-board memory 434 of a complex device such as microprocessor under test (DUT) 430. Atblock 1120, theFRIT kernel 420 may be executed by themicroprocessor 430 to producetest sequence # 1 and associated data fortest sequence # 1. Atblock 1130, thetest sequence # 1 may be executed by themicroprocessor 430 to produce atest result # 1, after thetest sequence # 1 and associated data fortest sequence # 1 are produced. Atblock 1140, thetest result # 1 may be compressed for compaction and may then be written into the on-board memory 434. Atblock 1150, theFRIT kernel 420 may be continued executed by themicroprocessor 430 to produce a next test sequence,test sequence # 2 for example, and associated data fortest sequence # 2 for test execution and subsequent test result compression until all test sequences are completed. The test results may then be dumped out after several data loops of test generation/execution by themicroprocessor 430 and transferred back to the tester memory 314 for comparison with the expected test result (expected response) 420B stored therein to check for manufacturing defects. -
FIGS. 12-13 illustrate an example memory image of a complex device such as a microprocessor under test (DUT) 430 at the beginning and at the end of a test according to an embodiment of the present invention. As shown inFIG. 12 , the FRITkernel test patterns 420 may be loaded into the on-board memory 434 using, for example, a test access port (TAP) controller (not shown). TheFRIT kernel 420 may also contain anexception handler 422 configured to handle illegal conditions during test (i.e., execution of the FRIT kernel 420). - As shown in
FIG. 13 , at the end of the test (i.e., execution of the FRIT kernel 420), all the test results of the complex device under test (DUT) 430 stored in the on-board memory 334 may be dumped out from the on-board memory 434 to thecontroller 412 of thetester 410 where the test results are compared with the expected test result (expected response) 420B stored in the tester memory 414 in order to check for manufacturing defects. - As described from the foregoing, the SBE generation tool according to an embodiment of the present invention advantageously generates a testing component,
SBE 420A of theFRIT kernel 420 for on-chip generation and application of functional tests. TheFRIT kernel 420 then enables automated test generation in real time that is functional test based at speed and inexpensive to implement in silicon, and can be applied on low cost structural testers in order to achieve high collateral coverage while avoiding delay defect screening issues. TheFRIT kernel 420 also allows a large number of tests to be applied without corresponding increase in test vector, that is, the increase in test data volume that exist with traditional RIT tools. The FRIT method offers tremendous benefits in containing the cost and ensuring quality of the microprocessors that are produced with practically no design changes and no silicon overhead. In addition, the FRIT kernel can be used at any test phase (SORT, Burn-In, Class) to reduce test data volume on the tester. - While there have been illustrated and described what are considered to be exemplary embodiments of the present invention, it will be understood by those skilled in the art and as technology develops that various changes and modifications may be made, and equivalents may be substituted for elements thereof without departing from the true scope of the present invention. For example, the testing system as shown in
FIGS. 1 and 4 may be configured differently or employ some or different components than those illustrated without changing the basic function of the invention. The SBE generation tool and the SBE generation tool implementation may be configured differently without changing the basic function of generating a SBE. In addition, the flow diagrams shown inFIGS. 9-13 may also be described differently without changing the basic function of the invention. Many modifications may be made to adapt the teachings of the present invention to a particular situation without departing from the scope thereof. Therefore, it is intended that the present invention not be limited to the various exemplary embodiments disclosed, but that the present invention includes all embodiments falling within the scope of the appended claims.
Claims (29)
1. A system, comprising:
user directives provided to indicate user desired actions;
instruction information provided to define a suite of instructions; and
a software built-in self-test engine generation tool arranged to generate a software built-in self-test engine based on the user directives, the instruction information and device constraints, for subsequent storage on-board of a complex device under test and activation of a re-generative functional test on the complex device under test;
wherein the software built-in self-test engine generation tool includes a test execution directive composer adapted to provide a run time environment.
2. The system of claim 1 , wherein the test execution directive composer is adapted to receive the user directives and the device constraints and create the run time environment to enable the re-generative functional test to repeatedly generate functional tests and execute generated tests on-board the complex device under test.
3. The system of claim 1 , wherein the software built-in self-test engine is to be merged with an expected test result and then loaded on-board a complex device under test so as to activate a re-generative functional test on the complex device under test and make a comparison between test results of the re-generative functional test and the expected test result to check for design validations and/or manufacturing defects.
4. The system of claim 3 , wherein the expected test result is obtained from computer modeling of the complex device under test or from a known good device.
5. The system of claim 2 , wherein the software built-in self-test engine generation tool further includes a random instruction test generator (RIT-G) composer to receive the user directives and the instruction information and generate a compact RIT-G code.
6. The system of claim 5 , wherein the software built-in self-test engine generation tool further includes a test result compaction module composer to generate a test result compaction module code.
7. The system of claim 6 , wherein the software built-in self-test engine generation tool further includes a code merger to merge code from the RIT-G composer, the test execution directive composer and the test result compaction module composer to generate the software built-in self-test engine.
8. The system of claim 7 , wherein the software built-in self-test engine generation tool is a software tool installed to generate the software built-in self-test engine, and wherein individual components of the software built-in self-test engine generation tool, including the random instruction test generator (RIT-G) composer, the test execution directive composer, the test result compaction module composer, and the code merger, are software modules written in any computer language.
9. The system of claim 8 , wherein the software built-in self-test engine generation tool is provided on a computer readable medium.
10. The system of claim 7 , wherein the software built-in self-test engine generation tool is a hardware implementation installed to generate the software built-in self-test engine.
11. The system of claim 7 , wherein the run time environment includes a test execution environment including an exception handler to handle illegal conditions such as undesirable memory accesses, deadlock, shut-down, and infinite loops, and a RIT environment to provide equivalent operating system (OS) functions needed by the RIT generator to generate the re-generative functional test.
12. The system of claim 7 , wherein the compact RIT-G code produced is a C-language program compiled by a C-compiler to produce an assembly language version of the RIT-G code, and when the run time environment, the test result compaction module code and the assembly language version of the RIT-G code are assembled by an assembler, a single program indicating the software built-in self-test engine in the target device under test's object code is obtained.
13. The system of claim 12 , wherein the compact RIT-G code includes an instruction generation module to generate individual instructions during testing application.
14. The system of claim 1 , wherein the software built-in self-test engine comprises:
a RIT generator including RIT machine code reside on-board the complex device under test for generating the re-generated functional test;
a test program execution module including test execution directives for providing a run time environment to store and run the re-generated functional test; and
a test result compaction module including compression machine code to compress test results of the re-generated functional test for storage on-board the complex device under test.
15. The system of claim 14 , wherein the test execution environment employs an exception handler to handle illegal conditions, including undesirable memory accesses, deadlock, shut-down, and infinite loops.
16. The system of claim 1 , wherein the complex device under test includes a microprocessor.
17. The system of claim 16 , wherein, when test patterns of the software built-in self-test engine are applied to the microprocessor from an on-board memory, the microprocessor performs the following:
beginning a set-up for executing test patterns;
executing the test patterns to generate a series of test sequences and associated data for respective test sequences;
running the test sequences, and at the end of the test sequences, obtaining the test results for storage in the on-board memory; and
dumping the test results of the test patterns for making a comparison with the expected test result to check for design validations and/or manufacturing defects.
18. A method for generating a software built-in self-test engine comprising:
obtaining user directives which indicate user desired actions;
obtaining instruction information which defines a suite of instructions; and
generating a software built-in self-test engine based on the user directives, the instruction information and device constraints, for subsequent storage on-board of a complex device under test and activation of a re-generative functional test on the complex device under test;
wherein the software built-in self-test engine is generating by creating a run time environment to enable the re-generative functional test to repeatedly generate functional tests and execute generated tests on-board the complex device under test based on the device constraints.
19. The method of claim 18 , wherein the software built-in self-test engine is further generated by:
generating a compact random instruction test generator code based on the user directives and the instruction information;
generating a test result compaction module code based on the user directives and the device constraints; and
merging the compact random instruction test generator code, the run time environment and the test result compaction module code to obtain the software built-in self-test engine.
20. The method of claim 18 , wherein the software built-in self-test engine is to be merged with an expected test result and then loaded on-board a complex device under test so as to activate a re-generative functional test on the complex device under test and make a comparison between test results of the re-generative functional test and the expected test result to check for design validations and/or manufacturing defects.
21. The method of claim 20 , wherein the expected test result is obtained from computer modeling of the complex device under test or from a known good device.
22. The method of claim 19 , wherein the run time environment includes a test execution environment including an exception handler to handle illegal conditions such as undesirable memory accesses, deadlock, shut-down, and infinite loops, and a RIT environment to provide equivalent operating system functions needed by the RIT generator to generate the re-generative functional test.
23. The method of claim 19 , wherein the compact RIT-G code produced is a C-language program compiled by a C-compiler to produce an assembly language version of the RIT-G code, and when the run time environment, the test result compaction module code and the assembly language version of the RIT-G code are assembled by an assembler, a single program indicating the software built-in self-test engine in the target device under test's object code is obtained.
24. The method of claim 19 , wherein the complex device under test includes a microprocessor.
25. The method of claim 19 , wherein, when test patterns of the software built-in self-test engine are applied to the microprocessor from an on-board memory, the microprocessor performs the following:
beginning a set-up for executing test patterns;
executing the test patterns to generate a series of test sequences and associated data for respective test sequences;
running the test sequences, and at the end of the test sequences, obtaining the test results for storage in the on-board memory; and
dumping the test results of the test patterns for making a comparison with the expected test result to check for design validations and/or manufacturing defects.
26. The method of claim 25 , wherein the software built-in self-test engine is programmed to generate and execute one or more (“N”) instruction sequences, each sequence being executed on one or more (M) data sets during testing, where N and M represent an integer no less than “1” and are user-specified numbers used in generating the software built-in self-test engine.
27. The method of claim 26 , wherein the software built-in self-test engine is further programmed to generate one or more signatures to provide a unique identification of the test result of each test sequence and indicate whether the test result of a particular test sequence is “good” or “bad”.
28. A computer readable medium having stored thereon a software built-in self-test engine generation software tool which, when executed by a host system, causes the system to perform:
obtaining user directives which indicate user desired actions;
obtaining instruction information which defines a suite of instructions; and
generating a software built-in self-test engine based on the user directives, the instruction information and device constraints, for subsequent storage on-board of a complex device under test and activation of a re-generative functional test on the complex device under test;
wherein the software built-in self-test engine is generated by creating a run time environment to enable the re-generative functional test to repeatedly generate functional tests and execute generated tests on-board the complex device under test based on the device constraints.
29. The computer readable medium of claim 28 , wherein the software built-in self-test engine comprises:
a random instruction test generator including compact random instruction test machine code reside on-board the complex device under test for generating the re-generated functional test;
a test program execution module including test execution directives for providing a run time environment to store and run the re-generated functional test; and
a test result compaction module including compression machine code to compress test results of the re-generated functional test for storage on-board the complex device under test.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/189,621 US20050262410A1 (en) | 2001-08-07 | 2005-07-26 | Tool for generating a re-generative functional test |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/922,639 US6928638B2 (en) | 2001-08-07 | 2001-08-07 | Tool for generating a re-generative functional test |
US11/189,621 US20050262410A1 (en) | 2001-08-07 | 2005-07-26 | Tool for generating a re-generative functional test |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/922,639 Continuation US6928638B2 (en) | 2001-08-07 | 2001-08-07 | Tool for generating a re-generative functional test |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050262410A1 true US20050262410A1 (en) | 2005-11-24 |
Family
ID=25447369
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/922,639 Expired - Fee Related US6928638B2 (en) | 2001-08-07 | 2001-08-07 | Tool for generating a re-generative functional test |
US11/189,621 Abandoned US20050262410A1 (en) | 2001-08-07 | 2005-07-26 | Tool for generating a re-generative functional test |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/922,639 Expired - Fee Related US6928638B2 (en) | 2001-08-07 | 2001-08-07 | Tool for generating a re-generative functional test |
Country Status (1)
Country | Link |
---|---|
US (2) | US6928638B2 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030235156A1 (en) * | 2002-06-24 | 2003-12-25 | Gygi Carl Edward | Methods and structure for improved testing of embedded systems |
US20060156138A1 (en) * | 2004-11-29 | 2006-07-13 | Fujitsu Limited | Test pattern generating apparatus, circuit designing apparatus, test pattern generating method, circuit designing method, test pattern generating program and circuit designing program |
US20110225400A1 (en) * | 2010-03-11 | 2011-09-15 | Stmicroelectronics (Grenoble 2) Sas | Device for Testing a Multitasking Computation Architecture and Corresponding Test Method |
US20150082107A1 (en) * | 2013-09-19 | 2015-03-19 | Jicksen JOY | State machine based functional stress tests |
CN104978249A (en) * | 2014-04-09 | 2015-10-14 | 三星电子株式会社 | System On Chip And Verification Method Thereof |
KR20150117584A (en) * | 2014-04-09 | 2015-10-20 | 삼성전자주식회사 | System on chip and verification method thereof |
CN107301039A (en) * | 2016-04-15 | 2017-10-27 | 习得智交互软件开发公司 | Prototyping methods and its device |
US20180240533A1 (en) * | 2017-02-20 | 2018-08-23 | Toshiba Memory Corporation | Memory test apparatus |
WO2020020264A1 (en) * | 2018-07-25 | 2020-01-30 | Huawei Technologies Co., Ltd. | Resource Optimization and Reuse in Resource Constrained Environment |
Families Citing this family (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6928638B2 (en) * | 2001-08-07 | 2005-08-09 | Intel Corporation | Tool for generating a re-generative functional test |
US7428661B2 (en) * | 2001-09-21 | 2008-09-23 | Sam Michael | Test and debug processor and method |
US20040088682A1 (en) * | 2002-11-05 | 2004-05-06 | Thompson Ryan C. | Method, program product, and apparatus for cache entry tracking, collision detection, and address reasignment in processor testcases |
US7051322B2 (en) * | 2002-12-06 | 2006-05-23 | @Stake, Inc. | Software analysis framework |
US7127127B2 (en) * | 2003-03-04 | 2006-10-24 | Microsoft Corporation | System and method for adaptive video fast forward using scene generative models |
US20040194063A1 (en) * | 2003-03-28 | 2004-09-30 | Joel Pereira | System and method for automated testing of a software module |
US7058864B1 (en) * | 2003-05-21 | 2006-06-06 | Hewlett-Packard Development Company, L.P. | Test for processor memory cache |
EP1491906B1 (en) * | 2003-06-24 | 2007-05-16 | STMicroelectronics S.r.l. | An integrated device with an improved BIST circuit for executing a structured test |
US20050050524A1 (en) * | 2003-08-25 | 2005-03-03 | Arm Limited | Generating software test information |
US20050102594A1 (en) * | 2003-09-26 | 2005-05-12 | The Regents Of The University Of California | Method for test application and test content generation for AC faults in integrated circuits |
US7643959B2 (en) * | 2004-01-09 | 2010-01-05 | American Megatrends, Inc. | Methods, systems, and computer readable media that provide programming for a sensor monitoring system using a softprocessor |
US20060195681A1 (en) * | 2004-12-06 | 2006-08-31 | Arm Limited | Test program instruction generation |
US20060150154A1 (en) * | 2004-12-06 | 2006-07-06 | Arm Limited | Test program instruction generation |
EP1825215B1 (en) * | 2004-12-14 | 2013-10-30 | Luna Innovations, Inc. | Compensating for time varying phase changes in interferometric measurements |
US7392441B2 (en) * | 2005-01-10 | 2008-06-24 | International Business Machines Corporation | Method of performing operational validation with limited CPU use of a communications network |
US7386759B2 (en) * | 2005-01-27 | 2008-06-10 | International Business Machines Corporation | Method of performing functional validation testing |
US8789021B2 (en) * | 2005-06-30 | 2014-07-22 | International Business Machines Corporation | Method and apparatus for object-oriented load testing of computing systems |
US20070043548A1 (en) * | 2005-07-29 | 2007-02-22 | International Business Machines Corporation | Verifying a simulated hardware environment for a simulated device under test |
US8613080B2 (en) | 2007-02-16 | 2013-12-17 | Veracode, Inc. | Assessment and analysis of software security flaws in virtual machines |
US8108745B2 (en) * | 2009-08-20 | 2012-01-31 | Honeywell International Inc. | On-device constrained random verification for device development |
US20130014084A1 (en) * | 2011-07-05 | 2013-01-10 | Microsoft Corporation | International Testing Platform |
US9286063B2 (en) | 2012-02-22 | 2016-03-15 | Veracode, Inc. | Methods and systems for providing feedback and suggested programming methods |
US9891281B1 (en) * | 2015-11-30 | 2018-02-13 | Cadence Design Systems, Inc. | Method and system for automatically identifying test runs contributing to coverage events of interest in verification test data |
CN116643140A (en) * | 2022-02-15 | 2023-08-25 | 华为技术有限公司 | Integrated circuit and testing method thereof |
CN117313595B (en) * | 2023-11-30 | 2024-02-23 | 杭州登临瀚海科技有限公司 | Random instruction generation method, equipment and system for function verification |
CN118194291A (en) * | 2024-03-15 | 2024-06-14 | 北京奇虎科技有限公司 | Test data generation method and device, storage medium and electronic equipment |
Citations (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4622669A (en) * | 1983-02-07 | 1986-11-11 | Motorola, Inc. | Test module for asynchronous bus |
US5265254A (en) * | 1991-08-14 | 1993-11-23 | Hewlett-Packard Company | System of debugging software through use of code markers inserted into spaces in the source code during and after compilation |
US5383195A (en) * | 1992-10-19 | 1995-01-17 | Motorola, Inc. | BIST circuit with halt signal |
US5416783A (en) * | 1993-08-09 | 1995-05-16 | Motorola, Inc. | Method and apparatus for generating pseudorandom numbers or for performing data compression in a data processor |
US5475843A (en) * | 1992-11-02 | 1995-12-12 | Borland International, Inc. | System and methods for improved program testing |
US5572712A (en) * | 1994-09-30 | 1996-11-05 | Vlsi Technology, Inc. | Method and apparatus for making integrated circuits with built-in self-test |
US5668947A (en) * | 1996-04-18 | 1997-09-16 | Allen-Bradley Company, Inc. | Microprocessor self-test apparatus and method |
US5761489A (en) * | 1995-04-17 | 1998-06-02 | Motorola Inc. | Method and apparatus for scan testing with extended test vector storage in a multi-purpose memory system |
US5954829A (en) * | 1996-12-30 | 1999-09-21 | Mci Communications Corporation | System, method, and computer program product for digital cross connect testing |
US5963566A (en) * | 1996-12-18 | 1999-10-05 | Lsi Logic Corporation | Application specific integrated circuit chip and method of testing same |
US6091649A (en) * | 1998-02-06 | 2000-07-18 | Samsung Electronics Co., Ltd. | Integrated circuit memory devices having built-in self test based redundancy and methods of operation thereof |
US6195616B1 (en) * | 1997-01-29 | 2001-02-27 | Advanced Micro Devices, Inc. | Method and apparatus for the functional verification of digital electronic systems |
US6249886B1 (en) * | 1997-10-17 | 2001-06-19 | Ramsesh S. Kalkunte | Computer system and computer implemented process for performing user-defined tests of a client-server system with run time compilation of test results |
US6285974B1 (en) * | 1997-03-28 | 2001-09-04 | International Business Machines Corporation | Hardware verification tool for multiprocessors |
US6327556B1 (en) * | 1998-02-21 | 2001-12-04 | Adaptec, Inc. | AT-speed computer model testing methods |
US6349393B1 (en) * | 1999-01-29 | 2002-02-19 | International Business Machines Corporation | Method and apparatus for training an automated software test |
US6400173B1 (en) * | 1999-11-19 | 2002-06-04 | Hitachi, Ltd. | Test system and manufacturing of semiconductor device |
US6415403B1 (en) * | 1999-01-29 | 2002-07-02 | Global Unichip Corporation | Programmable built in self test for embedded DRAM |
US20020121913A1 (en) * | 2000-12-28 | 2002-09-05 | Advanced Micro Devices, Inc. | Tester with independent control of devices under test |
US6484135B1 (en) * | 1999-08-30 | 2002-11-19 | Hewlett-Packard Company | Method for adaptive test generation via feedback from dynamic emulation |
US20030014734A1 (en) * | 2001-05-03 | 2003-01-16 | Alan Hartman | Technique using persistent foci for finite state machine based software test generation |
US6553527B1 (en) * | 1999-11-08 | 2003-04-22 | International Business Machines Corporation | Programmable array built-in self test method and controller with programmable expect generator |
US6658611B1 (en) * | 1998-11-19 | 2003-12-02 | Samsung Electronics Co., Ltd. | Programmable built-in self-test system for semiconductor memory device |
US6698012B1 (en) * | 1999-09-17 | 2004-02-24 | Nortel Networks Limited | Method and system for testing behavior of procedures |
US6708305B1 (en) * | 2000-10-18 | 2004-03-16 | International Business Machines Corporation | Deterministic random LBIST |
US6728901B1 (en) * | 1997-03-10 | 2004-04-27 | Janusz Rajski | Arithmetic built-in self-test of multiple scan-based integrated circuits |
US6732297B2 (en) * | 2000-02-08 | 2004-05-04 | Fujitsu Limited | Pipeline testing method, pipeline testing system, pipeline test instruction generation method and storage method |
US6760888B2 (en) * | 1999-02-05 | 2004-07-06 | Tensilica, Inc. | Automated processor generation system for designing a configurable processor and method for the same |
US6769115B1 (en) * | 2000-05-01 | 2004-07-27 | Emc Corporation | Adaptive interface for a software development environment |
US6769081B1 (en) * | 2000-08-30 | 2004-07-27 | Sun Microsystems, Inc. | Reconfigurable built-in self-test engine for testing a reconfigurable memory |
US6871298B1 (en) * | 1999-11-12 | 2005-03-22 | Obsidian Software, Inc. | Method and apparatus that simulates the execution of paralled instructions in processor functional verification testing |
US6928638B2 (en) * | 2001-08-07 | 2005-08-09 | Intel Corporation | Tool for generating a re-generative functional test |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5382195A (en) * | 1992-12-22 | 1995-01-17 | Atlas Bolt & Screw Company | Method for making a self-drilling and self-tapping screw |
US5983380A (en) * | 1997-09-16 | 1999-11-09 | International Business Machines Corporation | Weighted random pattern built-in self-test |
US6249893B1 (en) * | 1998-10-30 | 2001-06-19 | Advantest Corp. | Method and structure for testing embedded cores based system-on-a-chip |
US6647524B1 (en) * | 1999-04-30 | 2003-11-11 | Worldwide Semiconductor Manufacturing Corporation | Built-in-self-test circuit for RAMBUS direct RDRAM |
-
2001
- 2001-08-07 US US09/922,639 patent/US6928638B2/en not_active Expired - Fee Related
-
2005
- 2005-07-26 US US11/189,621 patent/US20050262410A1/en not_active Abandoned
Patent Citations (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4622669A (en) * | 1983-02-07 | 1986-11-11 | Motorola, Inc. | Test module for asynchronous bus |
US5265254A (en) * | 1991-08-14 | 1993-11-23 | Hewlett-Packard Company | System of debugging software through use of code markers inserted into spaces in the source code during and after compilation |
US5383195A (en) * | 1992-10-19 | 1995-01-17 | Motorola, Inc. | BIST circuit with halt signal |
US5475843A (en) * | 1992-11-02 | 1995-12-12 | Borland International, Inc. | System and methods for improved program testing |
US5416783A (en) * | 1993-08-09 | 1995-05-16 | Motorola, Inc. | Method and apparatus for generating pseudorandom numbers or for performing data compression in a data processor |
US5572712A (en) * | 1994-09-30 | 1996-11-05 | Vlsi Technology, Inc. | Method and apparatus for making integrated circuits with built-in self-test |
US5761489A (en) * | 1995-04-17 | 1998-06-02 | Motorola Inc. | Method and apparatus for scan testing with extended test vector storage in a multi-purpose memory system |
US5668947A (en) * | 1996-04-18 | 1997-09-16 | Allen-Bradley Company, Inc. | Microprocessor self-test apparatus and method |
US5963566A (en) * | 1996-12-18 | 1999-10-05 | Lsi Logic Corporation | Application specific integrated circuit chip and method of testing same |
US5954829A (en) * | 1996-12-30 | 1999-09-21 | Mci Communications Corporation | System, method, and computer program product for digital cross connect testing |
US6195616B1 (en) * | 1997-01-29 | 2001-02-27 | Advanced Micro Devices, Inc. | Method and apparatus for the functional verification of digital electronic systems |
US6728901B1 (en) * | 1997-03-10 | 2004-04-27 | Janusz Rajski | Arithmetic built-in self-test of multiple scan-based integrated circuits |
US6285974B1 (en) * | 1997-03-28 | 2001-09-04 | International Business Machines Corporation | Hardware verification tool for multiprocessors |
US6249886B1 (en) * | 1997-10-17 | 2001-06-19 | Ramsesh S. Kalkunte | Computer system and computer implemented process for performing user-defined tests of a client-server system with run time compilation of test results |
US6091649A (en) * | 1998-02-06 | 2000-07-18 | Samsung Electronics Co., Ltd. | Integrated circuit memory devices having built-in self test based redundancy and methods of operation thereof |
US6327556B1 (en) * | 1998-02-21 | 2001-12-04 | Adaptec, Inc. | AT-speed computer model testing methods |
US6658611B1 (en) * | 1998-11-19 | 2003-12-02 | Samsung Electronics Co., Ltd. | Programmable built-in self-test system for semiconductor memory device |
US6349393B1 (en) * | 1999-01-29 | 2002-02-19 | International Business Machines Corporation | Method and apparatus for training an automated software test |
US6415403B1 (en) * | 1999-01-29 | 2002-07-02 | Global Unichip Corporation | Programmable built in self test for embedded DRAM |
US6760888B2 (en) * | 1999-02-05 | 2004-07-06 | Tensilica, Inc. | Automated processor generation system for designing a configurable processor and method for the same |
US6484135B1 (en) * | 1999-08-30 | 2002-11-19 | Hewlett-Packard Company | Method for adaptive test generation via feedback from dynamic emulation |
US6698012B1 (en) * | 1999-09-17 | 2004-02-24 | Nortel Networks Limited | Method and system for testing behavior of procedures |
US6553527B1 (en) * | 1999-11-08 | 2003-04-22 | International Business Machines Corporation | Programmable array built-in self test method and controller with programmable expect generator |
US6871298B1 (en) * | 1999-11-12 | 2005-03-22 | Obsidian Software, Inc. | Method and apparatus that simulates the execution of paralled instructions in processor functional verification testing |
US6400173B1 (en) * | 1999-11-19 | 2002-06-04 | Hitachi, Ltd. | Test system and manufacturing of semiconductor device |
US6732297B2 (en) * | 2000-02-08 | 2004-05-04 | Fujitsu Limited | Pipeline testing method, pipeline testing system, pipeline test instruction generation method and storage method |
US6769115B1 (en) * | 2000-05-01 | 2004-07-27 | Emc Corporation | Adaptive interface for a software development environment |
US6769081B1 (en) * | 2000-08-30 | 2004-07-27 | Sun Microsystems, Inc. | Reconfigurable built-in self-test engine for testing a reconfigurable memory |
US6708305B1 (en) * | 2000-10-18 | 2004-03-16 | International Business Machines Corporation | Deterministic random LBIST |
US20020121913A1 (en) * | 2000-12-28 | 2002-09-05 | Advanced Micro Devices, Inc. | Tester with independent control of devices under test |
US20030014734A1 (en) * | 2001-05-03 | 2003-01-16 | Alan Hartman | Technique using persistent foci for finite state machine based software test generation |
US6928638B2 (en) * | 2001-08-07 | 2005-08-09 | Intel Corporation | Tool for generating a re-generative functional test |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030235156A1 (en) * | 2002-06-24 | 2003-12-25 | Gygi Carl Edward | Methods and structure for improved testing of embedded systems |
US7385927B2 (en) * | 2002-06-24 | 2008-06-10 | Lsi Logic Corporation | Methods and structure for improved testing of embedded systems |
US20060156138A1 (en) * | 2004-11-29 | 2006-07-13 | Fujitsu Limited | Test pattern generating apparatus, circuit designing apparatus, test pattern generating method, circuit designing method, test pattern generating program and circuit designing program |
US7334171B2 (en) * | 2004-11-29 | 2008-02-19 | Fujitsu Limited | Test pattern generating apparatus, circuit designing apparatus, test pattern generating method, circuit designing method, test pattern generating program and circuit designing program |
US20110225400A1 (en) * | 2010-03-11 | 2011-09-15 | Stmicroelectronics (Grenoble 2) Sas | Device for Testing a Multitasking Computation Architecture and Corresponding Test Method |
US20150082107A1 (en) * | 2013-09-19 | 2015-03-19 | Jicksen JOY | State machine based functional stress tests |
KR20150117584A (en) * | 2014-04-09 | 2015-10-20 | 삼성전자주식회사 | System on chip and verification method thereof |
US20150293835A1 (en) * | 2014-04-09 | 2015-10-15 | Sung-Boem PARK | System on chip and verification method thereof |
CN104978249A (en) * | 2014-04-09 | 2015-10-14 | 三星电子株式会社 | System On Chip And Verification Method Thereof |
US9448917B2 (en) * | 2014-04-09 | 2016-09-20 | Samsung Electronics Co., Ltd. | System on chip and verification method thereof |
US20160371092A1 (en) * | 2014-04-09 | 2016-12-22 | Samsung Electronics Co., Ltd. | System on chip and verification method thereof |
US9990205B2 (en) * | 2014-04-09 | 2018-06-05 | Samsung Electronics Co., Ltd. | System on chip and verification method thereof |
KR102147172B1 (en) | 2014-04-09 | 2020-08-31 | 삼성전자주식회사 | System on chip and verification method thereof |
CN107301039A (en) * | 2016-04-15 | 2017-10-27 | 习得智交互软件开发公司 | Prototyping methods and its device |
US20190064759A1 (en) * | 2016-04-15 | 2019-02-28 | Studio Xid Korea, Inc. | Method for creating prototype and apparatus therefor |
US10775754B2 (en) * | 2016-04-15 | 2020-09-15 | Studio Xid Korea, Inc. | Method for creating prototype and apparatus therefor |
US20180240533A1 (en) * | 2017-02-20 | 2018-08-23 | Toshiba Memory Corporation | Memory test apparatus |
US10636509B2 (en) * | 2017-02-20 | 2020-04-28 | Toshiba Memory Corporation | Memory test apparatus |
WO2020020264A1 (en) * | 2018-07-25 | 2020-01-30 | Huawei Technologies Co., Ltd. | Resource Optimization and Reuse in Resource Constrained Environment |
Also Published As
Publication number | Publication date |
---|---|
US6928638B2 (en) | 2005-08-09 |
US20030033558A1 (en) | 2003-02-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6928638B2 (en) | Tool for generating a re-generative functional test | |
US6948096B2 (en) | Functional random instruction testing (FRIT) method for complex devices such as microprocessors | |
Kiefer et al. | Application of deterministic logic BIST on industrial circuits | |
US7979764B2 (en) | Distributed test compression for integrated circuits | |
Murray et al. | Testing ICs: Getting to the core of the problem | |
US7058869B2 (en) | Method and apparatus for debug, diagnosis, and yield improvement of scan-based integrated circuits | |
US6463560B1 (en) | Method for implementing a bist scheme into integrated circuits for testing RTL controller-data paths in the integrated circuits | |
EP0640920B1 (en) | Boundary-scan-based system and method for test and diagnosis | |
Chen et al. | DEFUSE: A deterministic functional self-test methodology for processors | |
Lai et al. | Test program synthesis for path delay faults in microprocessor cores | |
US6886145B2 (en) | Reducing verification time for integrated circuit design including scan circuits | |
KR20000029368A (en) | Method and structure for testing embedded cores based system-on-a-chip | |
JP3830550B2 (en) | Integrated circuit design test method | |
US6883150B2 (en) | Automatic manufacturing test case generation method and system | |
US6721923B2 (en) | System and method for generating integrated circuit boundary register description data | |
Nadeau-Dostie et al. | ScanBist: a multifrequency scan-based BIST method | |
US6349398B1 (en) | Method and apparatus for partial-scan built-in self test logic | |
US7308631B2 (en) | Wrapper serial scan chain functional segmentation | |
US6427217B1 (en) | System and method for scan assisted self-test of integrated circuits | |
Ghosh et al. | A BIST scheme for RTL circuits based on symbolic testability analysis | |
EP1763677B1 (en) | Circuit arrangement and method of testing an application circuit provided in said circuit arrangement | |
Chen et al. | Automatic test program generation for transition delay faults in pipelined processors | |
US6212656B1 (en) | Automated scan chain sizing using Synopsys | |
Pateras et al. | BIST: a test a diagnosis methodology for complex, high reliability electronics systems | |
JP3709034B2 (en) | Boundary scan compatible integrated circuit design support device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |