US20140358514A1 - System and method for automatically generating offline result emulation files from a testflow - Google Patents
System and method for automatically generating offline result emulation files from a testflow Download PDFInfo
- Publication number
- US20140358514A1 US20140358514A1 US13/906,473 US201313906473A US2014358514A1 US 20140358514 A1 US20140358514 A1 US 20140358514A1 US 201313906473 A US201313906473 A US 201313906473A US 2014358514 A1 US2014358514 A1 US 2014358514A1
- Authority
- US
- United States
- Prior art keywords
- file
- testflow
- recited
- device under
- supported
- 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/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/366—Software debugging using diagnostics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Definitions
- This application is directed, in general, to circuit testing and, more specifically, to a system and method for debugging or regressing-testing test programs or fabricated circuits, such as ICs.
- testflow test procedures tailored for the IC to be tested and then write the test program from the testflow.
- test program is then verified using a fabricated IC. Samples of ICs may then be tested “online” as they are fabricated.
- Offline Result Emulation introduced a feature, called “Offline Result Emulation,” or ORE, that allows an IC or the test program itself to be verified (e.g., debugged and regression tested) “offline,” or without the IC being employed in the process.
- ORE provides a description of expected results and errors in functional test patterns. Advantest estimates that ORE can reduce engineering time spent verifying test programs only after IC fabrication by over two weeks, which is significant.
- the system includes: (1) a testflow integrator configured to populate a supported testsuite with parameters from a testflow corresponding to a test program and (2) a DUT description integrator associated with the testflow integrator and configured further to populate the supported testsuite with parameters from at least one DUT description file.
- Another aspect provides a method of automatically generating a structured data file for ORE.
- the method includes: (1) allowing a testflow corresponding to a test program to be selected, (2) providing a plurality of selectable supported testsuites, (3) populating a selected one of the supported testsuites with parameters from the testflow, (4) further populating the selected one of the supported testsuites with parameters from at least one DUT description file thereby to yield a structured data file and (5) employing the structured data file in the ORE.
- the ORE emulator includes: (1) a testflow integrator configured to populate a supported testsuite with parameters from a testflow corresponding to a test program and (2) a DUT description integrator associated with the testflow integrator and configured further to populate the supported testsuite with parameters from a complete device directory describing a DUT corresponding to the testflow and the test program.
- FIG. 1 is a block diagram of one embodiment of an IC test tool
- FIG. 2 is a block diagram of one embodiment of a system for automatically generating an ORE XML file
- FIG. 3 is a portion of an example ORE setup file rendered in XML
- FIG. 4 is a portion of an example supported testsuite employable to create an ORE setup file
- FIG. 5 is a portion of an example of an XML ORE setup file created from the supported testsuite of FIG. 3 ;
- FIG. 6 is a screenshot produced by one embodiment of a system for automatically generating an ORE XML file
- FIG. 7 is a diagram illustrating the generation of an ORE setup file from a supported testsuite and a simulation values file
- FIG. 8 is a diagram of one embodiment of a screenshot illustrating the import of testsuite values.
- FIG. 9 is a flow diagram of one embodiment of a method of automatically generating an ORE XML file.
- ORE allows a test program to be verified before ICs to be tested by the test program are fabricated.
- ORE allows a test program to verify an IC that is not physically available for online testing.
- ORE is claimed significantly to reduce engineering time that would otherwise be spent verifying test programs only after an IC is fabricated or shipping fabricated ICs to test tools for online testing. In an ideal situation, a test program would be verified just before it is needed to test newly-fabricated ICs or should problems occur during manufacturing. Such “offline” testing could be performed remotely, perhaps far from the manufacturing line itself.
- the structured data file takes the form of an eXtensible Markup Language (XML) data file, which has a structure and syntax known to those of skill in the pertinent art.
- XML eXtensible Markup Language
- the XML data file should be both accurate and complete. It is realized herein that since such a data file incorporates data derived from several different sources, including the testflow and various files descriptive of the IC (e.g., pin configuration, pattern master and header files), generating the data file by hand can be a daunting task, even when the testflow involves relatively few inputs or outputs (pins). It is further realized herein that manually generating a data file for a testflow involving many dozens or hundreds of pins, which is the case for many testflows, is tedious and prone to error.
- FIG. 1 is a block diagram of one embodiment of an IC test tool.
- the test tool employs a test controller 110 configured to control a test fixture 120 .
- a DUT 130 is coupled to the test fixture 120 , allowing the test controller 110 to execute a test program 140 to test the DUT 130 .
- the test program 140 which is almost always particularly designed specifically to test the specific DUT 130 being tested, causes electrical power and signals, which may be analog or digital signals, to be applied to the DUT 130 through the test fixture 120 . Signals are produced by the DUT 130 in response thereto. The signals may be analog or digital signals. At least some of the signals are captured through the test fixture 120 and stored as test results 150 .
- the test controller 110 may be embodied in a general-purpose or special-purpose processor, and the test program 130 and test results 150 may be stored in one or more memory devices, such as dynamic random-access memory (DRAM) or disk storage.
- the test fixture 120 may take the form of a conventional “bed-of-nails” or other conventional or later-developed test fixture configured to hold and test the DUT 130 .
- the DUT 130 may be an IC, a circuit board containing multiple ICs or discrete parts or any other physical electrical or electronic circuit of any conventional or later-developed type or configuration.
- the test program 140 is almost always particularly designed specifically to test the specific DUT 130 being tested.
- a DUT 130 suitable for verifying the proper operation of the test program 140 may not be available when the time for verification comes.
- ORE was developed, conventional circumstances dictated that verification of the test program 140 had to wait until a DUT 130 had been fabricated.
- the operation of the test program 140 can be verified before a DUT 130 is available.
- the structured data file required by ORE must be generated by hand, which is realized herein to be a tedious, time-consuming and error-fraught process. Accordingly, various embodiments of a system and method for automatically generating a structured data file, such as an XML file, for ORE will now be described.
- ORE is defined as hardware, firmware, software or hybrid process of employing information regarding the design of a DUT to emulate the DUT such that the operation of a test program designed to test the DUT can be verified without requiring an actual, fabricated DUT to be available.
- the above-referenced ORE implementation available from Advantest Corporation meets the definition of ORE, but so would ORE implementations by other companies.
- FIG. 2 is a block diagram of one embodiment of a system for automatically generating an ORE XML file.
- the test program 140 of FIG. 1 is generated in a conventional manner using the test flow 210 .
- the test program 140 needs to be verified before any ICs for which it has been designed have been fabricated.
- the test program 140 can be used to verify the operation of an IC that is not available for online testing, which may be because the IC is far away from the test tool that would execute the test program 140 .
- the system is embodied in a structured data file generator 230 that includes a testflow integrator 231 and a DUT description integrator 232 .
- the testflow integrator 231 is configured to populate a supported testsuite 233 with parameters from the testflow 210 corresponding to the test program 140 .
- the DUT description integrator 232 is associated with the testflow integrator 231 and is configured further to populate the supported testsuite 233 with parameters from at least one DUT description file.
- FIG. 2 illustrates DUT description files 220 , including a pin configuration file 221 , a pattern master file 222 and a header file 223 .
- a structured data file 240 results.
- the structured data file 240 takes the form of an XML file. Also in the illustrated embodiment, the structured data file 240 is further populated with simulation values 250 .
- the structured data file is employed in a conventional or later-developed ORE process 260 through which a test program or at least one of the DUT description files is verified.
- FIG. 3 is a portion of an example ORE setup file rendered in XML and is presented primarily for the purpose of illustrating one example of a structured data file. Though the file of FIG. 3 is extremely simple, it is apparent that even it involves several measurements.
- a second measurement, “myMeasurement3,” involves a pin Q4 at which a waveform including three values, 1.23, 1.24 and 1.25, are applied.
- a third measurement, “myMeasurement2,” involves a pin Q4 at which a waveform contained in the file “tx106ml.txt.”
- FIG. 4 is a portion of an example supported testsuite employable to create an ORE setup file.
- the supported testsuite example of FIG. 4 is a continuity test involving primary conditions, called “Primaries,” and a test method involving the various parameters illustrated.
- FIG. 5 is a portion of an example of an XML ORE setup file 510 created from the supported testsuite of FIG. 3 .
- the supported testsuite of FIG. 4 is very simple. Even so, transforming the supported testsuite into the XML ORE file 510 of FIG. 5 is nontrivial. For example, it must be determined that PinGroups 1 through 5 are associated with Site 1 in the IC to which the XML ORE file corresponds. Only then can each of the PinGroups be assigned values, as FIG. 5 shows.
- a real-world testsuite is typically far more complex, involving perhaps dozens, if not hundreds, of pingroups. Further complicating matters is that ORE setup files may be required for many, e.g., separate testsuites.
- FIG. 6 is a screenshot produced by one embodiment of a system for automatically generating an ORE XML file.
- the screenshot includes an area 610 in which a file containing a testflow can be selected, an area 620 in which an output name for the structured data file can be entered, an area 630 in which various supported testsuites are listed, an area 640 in which the number of sites can be designated and an area 650 that provides an output console for displaying messages from the system.
- FIG. 7 is a diagram illustrating the generation of the ORE setup file 510 of FIG. 5 from a supported testsuite and a simulation values file.
- a list of supported testsuites 710 is displayed, allowing one to be selected.
- the selected supported testsuite is a continuity testsuite 720 .
- Simulation values 730 are likewise made available in a list and correspond to sites and pingroups in the DUT.
- a value 740 of ⁇ 0.41 is assigned to pingroup 3 of site 1. It can be seen in FIG. 7 that the value 740 has been populated as a value 750 in the ORE setup file 510 .
- FIG. 8 is a diagram of one embodiment of a screenshot illustrating the import of testsuite values.
- FIG. 8 is presented primarily for the purpose of demonstrating that one embodiment of the system is capable of importing testsuite values for subsequent population of a supported testsuite.
- FIG. 9 is a flow diagram of one embodiment of a method of automatically generating an ORE XML file.
- the method begins in a start step 910 .
- a testflow corresponding to a test program is allowed to be selected.
- a plurality of selectable supported testsuites is provided.
- the selected supported testsuite is populated with parameters from the selected testflow.
- the selected supported testsuite is further populated with parameters from at least one DUT description file.
- the selected supported testsuite is further populated with simulation values.
- the resulting structured data file is employed for offline result emulation. The method ends in an end step 970 .
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Tests Of Electronic Circuits (AREA)
Abstract
A system for, and method of automatically generating a structured data file for offline result emulation (ORE). In one embodiment, the system includes: (1) a testflow integrator configured to populate a supported testsuite with parameters from a testflow corresponding to a test program and (2) a device under test description integrator associated with the testflow integrator and configured further to populate the supported testsuite with parameters from at least one device under test description file.
Description
- This application is directed, in general, to circuit testing and, more specifically, to a system and method for debugging or regressing-testing test programs or fabricated circuits, such as ICs.
- As those skilled in the pertinent art are aware, it is highly advantageous to test fabricated integrated circuits (ICs) to verify that they operate according to design. For this reason, various tools have been developed to test ICs (such as systems-on-a-chip, or SoCs). Advantest Corporation of Tokyo, Japan, sells one such tool, called the SmarTest V93000 SOC. Such tools employ a test program of functional test patterns that provide known signals to, and analyze signals received from, the IC under test (also called a “device under test,” or DUT). To create the test program, engineers first devise test procedures (“testflow”) tailored for the IC to be tested and then write the test program from the testflow. The test program is then verified using a fabricated IC. Samples of ICs may then be tested “online” as they are fabricated.
- Revision 7.0 of Smartest introduced a feature, called “Offline Result Emulation,” or ORE, that allows an IC or the test program itself to be verified (e.g., debugged and regression tested) “offline,” or without the IC being employed in the process. According to Advantest, ORE provides a description of expected results and errors in functional test patterns. Advantest estimates that ORE can reduce engineering time spent verifying test programs only after IC fabrication by over two weeks, which is significant.
- One aspect provides a system for automatically generating a structured data file for ORE. In one embodiment, the system includes: (1) a testflow integrator configured to populate a supported testsuite with parameters from a testflow corresponding to a test program and (2) a DUT description integrator associated with the testflow integrator and configured further to populate the supported testsuite with parameters from at least one DUT description file.
- Another aspect provides a method of automatically generating a structured data file for ORE. In one embodiment, the method includes: (1) allowing a testflow corresponding to a test program to be selected, (2) providing a plurality of selectable supported testsuites, (3) populating a selected one of the supported testsuites with parameters from the testflow, (4) further populating the selected one of the supported testsuites with parameters from at least one DUT description file thereby to yield a structured data file and (5) employing the structured data file in the ORE.
- Yet another aspect provides an offline result emulator. In one embodiment, the ORE emulator includes: (1) a testflow integrator configured to populate a supported testsuite with parameters from a testflow corresponding to a test program and (2) a DUT description integrator associated with the testflow integrator and configured further to populate the supported testsuite with parameters from a complete device directory describing a DUT corresponding to the testflow and the test program.
- Reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
-
FIG. 1 is a block diagram of one embodiment of an IC test tool; -
FIG. 2 is a block diagram of one embodiment of a system for automatically generating an ORE XML file; -
FIG. 3 is a portion of an example ORE setup file rendered in XML; -
FIG. 4 is a portion of an example supported testsuite employable to create an ORE setup file; -
FIG. 5 is a portion of an example of an XML ORE setup file created from the supported testsuite ofFIG. 3 ; -
FIG. 6 is a screenshot produced by one embodiment of a system for automatically generating an ORE XML file; -
FIG. 7 is a diagram illustrating the generation of an ORE setup file from a supported testsuite and a simulation values file; -
FIG. 8 is a diagram of one embodiment of a screenshot illustrating the import of testsuite values; and -
FIG. 9 is a flow diagram of one embodiment of a method of automatically generating an ORE XML file. - ORE allows a test program to be verified before ICs to be tested by the test program are fabricated. Alternatively, ORE allows a test program to verify an IC that is not physically available for online testing. ORE is claimed significantly to reduce engineering time that would otherwise be spent verifying test programs only after an IC is fabricated or shipping fabricated ICs to test tools for online testing. In an ideal situation, a test program would be verified just before it is needed to test newly-fabricated ICs or should problems occur during manufacturing. Such “offline” testing could be performed remotely, perhaps far from the manufacturing line itself.
- ORE seems to offer a promising new capability. However, it requires a structured data file, representing the testflow and the IC that is to be tested, be created beforehand. In the case of SmarTest V93000, the structured data file takes the form of an eXtensible Markup Language (XML) data file, which has a structure and syntax known to those of skill in the pertinent art.
- It should be apparent to those skilled in the pertinent art that for ORE to be efficacious, the XML data file should be both accurate and complete. It is realized herein that since such a data file incorporates data derived from several different sources, including the testflow and various files descriptive of the IC (e.g., pin configuration, pattern master and header files), generating the data file by hand can be a daunting task, even when the testflow involves relatively few inputs or outputs (pins). It is further realized herein that manually generating a data file for a testflow involving many dozens or hundreds of pins, which is the case for many testflows, is tedious and prone to error.
- It is realized herein that an automated tool and method that would generate a data file, perhaps taking the form of an XML file, for ORE would be advantageous. It is further realized that a conventional scripting language may be employed to effect such a tool. It is further realized herein that such tool or method could also automatically import test data from datalog files and thereby provide useful input parameters to the test program.
- Accordingly, described herein are various embodiments of an IC test tool and a system and method for automatically generating an ORE XML file.
-
FIG. 1 is a block diagram of one embodiment of an IC test tool. The test tool employs atest controller 110 configured to control atest fixture 120. ADUT 130 is coupled to thetest fixture 120, allowing thetest controller 110 to execute atest program 140 to test theDUT 130. Thetest program 140, which is almost always particularly designed specifically to test thespecific DUT 130 being tested, causes electrical power and signals, which may be analog or digital signals, to be applied to theDUT 130 through thetest fixture 120. Signals are produced by theDUT 130 in response thereto. The signals may be analog or digital signals. At least some of the signals are captured through thetest fixture 120 and stored astest results 150. In terms of hardware, thetest controller 110 may be embodied in a general-purpose or special-purpose processor, and thetest program 130 andtest results 150 may be stored in one or more memory devices, such as dynamic random-access memory (DRAM) or disk storage. Thetest fixture 120 may take the form of a conventional “bed-of-nails” or other conventional or later-developed test fixture configured to hold and test theDUT 130. TheDUT 130 may be an IC, a circuit board containing multiple ICs or discrete parts or any other physical electrical or electronic circuit of any conventional or later-developed type or configuration. - As stated above, the
test program 140 is almost always particularly designed specifically to test thespecific DUT 130 being tested. Unfortunately, aDUT 130 suitable for verifying the proper operation of thetest program 140 may not be available when the time for verification comes. Until ORE was developed, conventional circumstances dictated that verification of thetest program 140 had to wait until aDUT 130 had been fabricated. Now that ORE has been developed, the operation of thetest program 140 can be verified before aDUT 130 is available. However, as stated above, the structured data file required by ORE must be generated by hand, which is realized herein to be a tedious, time-consuming and error-fraught process. Accordingly, various embodiments of a system and method for automatically generating a structured data file, such as an XML file, for ORE will now be described. - “ORE,” as the term is used herein, is defined as hardware, firmware, software or hybrid process of employing information regarding the design of a DUT to emulate the DUT such that the operation of a test program designed to test the DUT can be verified without requiring an actual, fabricated DUT to be available. The above-referenced ORE implementation available from Advantest Corporation meets the definition of ORE, but so would ORE implementations by other companies.
-
FIG. 2 is a block diagram of one embodiment of a system for automatically generating an ORE XML file. In the embodiment ofFIG. 2 , thetest program 140 ofFIG. 1 is generated in a conventional manner using thetest flow 210. In one embodiment, thetest program 140 needs to be verified before any ICs for which it has been designed have been fabricated. In an alternative embodiment, thetest program 140 can be used to verify the operation of an IC that is not available for online testing, which may be because the IC is far away from the test tool that would execute thetest program 140. - In
FIG. 2 , the system is embodied in a structureddata file generator 230 that includes atestflow integrator 231 and aDUT description integrator 232. In the illustrated embodiment, thetestflow integrator 231 is configured to populate a supportedtestsuite 233 with parameters from the testflow 210 corresponding to thetest program 140. In the illustrated embodiment, theDUT description integrator 232 is associated with thetestflow integrator 231 and is configured further to populate the supportedtestsuite 233 with parameters from at least one DUT description file. Accordingly,FIG. 2 illustrates DUT description files 220, including apin configuration file 221, apattern master file 222 and aheader file 223. - After the supported
testsuite 233 is selected and thus populated, a structureddata file 240 results. In the illustrated embodiment, the structured data file 240 takes the form of an XML file. Also in the illustrated embodiment, the structured data file 240 is further populated with simulation values 250. - Whether or not further populated with
simulation values 250, the structured data file is employed in a conventional or later-developedORE process 260 through which a test program or at least one of the DUT description files is verified. -
FIG. 3 is a portion of an example ORE setup file rendered in XML and is presented primarily for the purpose of illustrating one example of a structured data file. Though the file ofFIG. 3 is extremely simple, it is apparent that even it involves several measurements. A first measurement, “myMeasurement1,” involves a testsuite, “myTestSuite1,” applied to pin Q2 at aparticular site 2 at which a value of 1.25 is applied. A second measurement, “myMeasurement3,” involves a pin Q4 at which a waveform including three values, 1.23, 1.24 and 1.25, are applied. A third measurement, “myMeasurement2,” involves a pin Q4 at which a waveform contained in the file “tx106ml.txt.” -
FIG. 4 is a portion of an example supported testsuite employable to create an ORE setup file. The supported testsuite example ofFIG. 4 is a continuity test involving primary conditions, called “Primaries,” and a test method involving the various parameters illustrated. -
FIG. 5 is a portion of an example of an XMLORE setup file 510 created from the supported testsuite ofFIG. 3 . The supported testsuite ofFIG. 4 is very simple. Even so, transforming the supported testsuite into the XML ORE file 510 ofFIG. 5 is nontrivial. For example, it must be determined thatPinGroups 1 through 5 are associated withSite 1 in the IC to which the XML ORE file corresponds. Only then can each of the PinGroups be assigned values, asFIG. 5 shows. A real-world testsuite is typically far more complex, involving perhaps dozens, if not hundreds, of pingroups. Further complicating matters is that ORE setup files may be required for many, e.g., separate testsuites. -
FIG. 6 is a screenshot produced by one embodiment of a system for automatically generating an ORE XML file. The screenshot includes anarea 610 in which a file containing a testflow can be selected, anarea 620 in which an output name for the structured data file can be entered, anarea 630 in which various supported testsuites are listed, anarea 640 in which the number of sites can be designated and anarea 650 that provides an output console for displaying messages from the system. -
FIG. 7 is a diagram illustrating the generation of theORE setup file 510 ofFIG. 5 from a supported testsuite and a simulation values file. As described above, a list of supportedtestsuites 710 is displayed, allowing one to be selected. In the illustrated embodiment, the selected supported testsuite is acontinuity testsuite 720. Simulation values 730, are likewise made available in a list and correspond to sites and pingroups in the DUT. As can be seen, avalue 740 of −0.41 is assigned topingroup 3 ofsite 1. It can be seen inFIG. 7 that thevalue 740 has been populated as avalue 750 in theORE setup file 510. Though they are unreferenced, it is apparent thatother site 1 values from the list of simulation values are similarly populated into theORE setup file 510. The process continues until the supported testsuite is transformed into an ORE setup file for the testsuite and typically further continued through other supported testsuites until the testflow is captured in an ORE setup file. -
FIG. 8 is a diagram of one embodiment of a screenshot illustrating the import of testsuite values.FIG. 8 is presented primarily for the purpose of demonstrating that one embodiment of the system is capable of importing testsuite values for subsequent population of a supported testsuite. -
FIG. 9 is a flow diagram of one embodiment of a method of automatically generating an ORE XML file. The method begins in astart step 910. In astep 920, a testflow corresponding to a test program is allowed to be selected. In astep 930, a plurality of selectable supported testsuites is provided. In astep 940, the selected supported testsuite is populated with parameters from the selected testflow. In astep 950, the selected supported testsuite is further populated with parameters from at least one DUT description file. In astep 960, the selected supported testsuite is further populated with simulation values. In astep 970, the resulting structured data file is employed for offline result emulation. The method ends in anend step 970. - Those skilled in the art to which this application relates will appreciate that other and further additions, deletions, substitutions and modifications may be made to the described embodiments.
Claims (20)
1. A system for automatically generating a structured data file for offline result emulation, comprising:
a testflow integrator configured to populate a supported testsuite with parameters from a testflow corresponding to a test program; and
a device under test description integrator associated with said testflow integrator and configured further to populate said supported testsuite with parameters from at least one device under test description file.
2. The system as recited in claim 1 wherein said at least one device under test description file is selected from the group consisting of:
a pin configuration file,
a pattern master file, and
a header file.
3. The system as recited in claim 1 wherein said structured data file is further populated with testsuite values.
4. The system as recited in claim 1 wherein said testflow is further employed to develop a test program and said offline result emulation is operable to verify operation of said test program.
5. The system as recited in claim 1 wherein said offline result emulation is employed to verify said at least one device under test description file.
6. The system as recited in claim 1 wherein said device under test description integrator is further configured further to populate said supported testsuite with parameters from a complete device directory containing said at least one device under test description file.
7. The system as recited in claim 1 wherein said structured data file is an eXtensible Markup Language file.
8. A method of automatically generating a structured data file for offline result emulation, comprising:
allowing a testflow corresponding to a test program to be selected;
providing a plurality of selectable supported testsuites;
populating a selected one of said supported testsuites with parameters from said testflow;
further populating said selected one of said supported testsuites with parameters from at least one device under test description file thereby to yield a structured data file; and
employing said structured data file in said offline result emulation.
9. The method as recited in claim 8 wherein said at least one device under test description file is selected from the group consisting of:
a pin configuration file,
a pattern master file, and
a header file.
10. The method as recited in claim 8 further comprising further populating said structured data file with testate values.
11. The method as recited in claim 8 wherein said testflow is further employed to develop a test program, said method further comprising verifying an operation of said test program with said offline result emulation.
12. The method as recited in claim 8 further comprising said at least one device under test description file with said offline result emulation.
13. The method as recited in claim 8 wherein said further populating comprises further populating said supported testsuite with parameters from a complete device directory containing said at least one device under test description file.
14. The method as recited in claim 1 wherein said structured data file is an eXtensible Markup Language file.
15. A offline result emulator, comprising:
a testflow integrator configured to populate a supported testsuite with parameters from a testflow corresponding to a test program; and
a device under test description integrator associated with said testflow integrator and configured further to populate said supported testsuite with parameters from a complete device directory describing a device under test corresponding to said testflow and said test program.
16. The system as recited in claim 15 wherein said at least one device under test description file is selected from the group consisting of:
a pin configuration file,
a pattern master file, and
a header file.
17. The system as recited in claim 15 wherein said structured data file is further populated with testate values.
18. The system as recited in claim 15 wherein said testflow is further employed to develop a test program and said offline result emulation is operable to verify operation of said test program.
19. The system as recited in claim 15 wherein said offline result emulation is employed to verify said at least one device under test description file.
20. The system as recited in claim 15 wherein said structured data file is an eXtensible Markup Language file.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/906,473 US20140358514A1 (en) | 2013-05-31 | 2013-05-31 | System and method for automatically generating offline result emulation files from a testflow |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/906,473 US20140358514A1 (en) | 2013-05-31 | 2013-05-31 | System and method for automatically generating offline result emulation files from a testflow |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140358514A1 true US20140358514A1 (en) | 2014-12-04 |
Family
ID=51986099
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/906,473 Abandoned US20140358514A1 (en) | 2013-05-31 | 2013-05-31 | System and method for automatically generating offline result emulation files from a testflow |
Country Status (1)
Country | Link |
---|---|
US (1) | US20140358514A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160349312A1 (en) * | 2015-05-28 | 2016-12-01 | Keysight Technologies, Inc. | Automatically Generated Test Diagram |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7171324B1 (en) * | 2005-10-14 | 2007-01-30 | Agilent Technologies, Inc. | System and method for removing measurement errors from measurement systems |
US20080010524A1 (en) * | 2003-02-14 | 2008-01-10 | Advantest Corporation | Test emulator, test module emulator and record medium storing program therein |
-
2013
- 2013-05-31 US US13/906,473 patent/US20140358514A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080010524A1 (en) * | 2003-02-14 | 2008-01-10 | Advantest Corporation | Test emulator, test module emulator and record medium storing program therein |
US7171324B1 (en) * | 2005-10-14 | 2007-01-30 | Agilent Technologies, Inc. | System and method for removing measurement errors from measurement systems |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160349312A1 (en) * | 2015-05-28 | 2016-12-01 | Keysight Technologies, Inc. | Automatically Generated Test Diagram |
US10429437B2 (en) * | 2015-05-28 | 2019-10-01 | Keysight Technologies, Inc. | Automatically generated test diagram |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7178115B2 (en) | Manufacturing method and apparatus to avoid prototype-hold in ASIC/SOC manufacturing | |
CN104797948B (en) | Debugging in semiconducter device testing environment | |
US7480826B2 (en) | Test executive with external process isolation for user code modules | |
US10156611B2 (en) | Executing code on a test instrument in response to an event | |
JP2010146592A (en) | Test program debug device, semiconductor test device, test program debug method, and test method | |
CN112444731B (en) | Chip testing method and device, processor chip and server | |
US20020163351A1 (en) | Method for producing test patterns for testing an integrated circuit | |
CN105511868A (en) | IOS application program packing method | |
CN114548027A (en) | Method for tracking signal in verification system, electronic device and storage medium | |
US20140358514A1 (en) | System and method for automatically generating offline result emulation files from a testflow | |
JP2011248597A (en) | Tester simulation apparatus, tester simulation program, and tester simulation method | |
US7065724B2 (en) | Method and apparatus for generating and verifying libraries for ATPG tool | |
US11803456B2 (en) | Distributed event-based test execution | |
Kim | Test driven mobile applications development | |
El-Kharashy et al. | A novel assertions-based code coverage automatic cad tool | |
JP2004348596A (en) | Device, method and program for debugging ic tester program | |
CN113640655B (en) | Arbitrary waveform generator verification platform | |
Widhalm et al. | A common platform for bridging pre-and post-silicon verification in mixed-signal designs | |
RU2740546C1 (en) | Multifunctional automated workstation for testing radioelectronic equipment | |
US10394643B2 (en) | Distributed run-time auto-calculation of measurement uncertainty | |
JPH07319950A (en) | Test system | |
Schott et al. | Closed-Loop Approach on Formal Specification for Semiconductor Test | |
TW202316225A (en) | Arbitrary waveform generator verification platform | |
Coons et al. | High-Speed Digital Bus Testing using Automatic Test-Markup Language (ATML) | |
CN116431473A (en) | Test program development method and system and electronic equipment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NVIDIA CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LIU, SHENG-LIANG;REEL/FRAME:030520/0378 Effective date: 20130527 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |