Abstract:
A technique of generation of a job for a digital testing unit for a test station from a circuit simulation unit includes completing fault simulation on electronic circuitry, then executing a first program without a fault dictionary, generating a pin map of the electronic circuitry and appending any pin groups, generating test vectors using the pin groups by the first program, generating additional pin groups to accommodate any orphan pins, converting the pin maps and pattern files to pin maps and pattern files, executing the first program to generate the fault dictionary, inputting a minimum scope level of analysis of the circuitry, generating the fault dictionary in fault dictionary data files according to the minimum scope level, generating a fault retriever file from the first program; and transporting the fault dictionary data files, test vectors, new pin maps, and fault retriever file to a second program for run-time fault analysis on the electronic circuitry testing unit. Wire path files and test vectors are generated. The scoring of a mismatch between predicted test responses and actual tester responses can be done by assigning a partial credit for primary output patterns being detected.

Description:
STATEMENT OF GOVERNMENT INTEREST 
   The invention described herein may be manufactured and used by or for the Government of the United States of America for governmental purposes without payment of any royalties thereon or therefor. 

   BACKGROUND OF THE INVENTION 
   1. Field of the Invention 
   The present invention relates to a technique for the interfacing of a circuit simulation unit and a circuit testing unit, and more particularly, to streamlining circuit simulation output into data for an automated circuit testing program of a circuit testing device. 
   2. Description of the Background Art 
   Currently there is a use of automatic test stations (ie., CASS for consolidated automatic support system test stations) to test electronic circuitry found in many different devices such as avionic devices. The test station hosts a digital test instrument such as the L200 by TERADYNE to handle all of the digital device testing. Digital test developers must use a high-level program (ie., LASAR) to create generic test vectors for very complex digital circuits. LASAR is a digital circuit simulator (program) with fault simulation capability. A test engineer will develop models of a digital circuit using LASAR, provide it with stimulus which he wants to inject into the board, then debug and analyze the circuit using LASAR&#39;s screen output capability. Once the test stimuli are performing correctly, the developer will use LASAR to simulate real world fault conditions. LASAR will then create “snapshots” of these fault conditions which can be compared to fault-free output following a real world test. These snap-shots are to be collected into a file, much like a database, called a fault dictionary. The fault dictionary must be tailored for the particular tester that will be used to test the digital board. 
   The CASS test station is equipped with an instrument called the DTU (Digital Test Unit). It is the instrument which tests digital circuitry. While the CASS, in general, uses ATLAS, the DTU has its own unique language called L200. Digital test code must be written in the L200 language to be used at run-time by the CASS test station. Some method is needed to convert LASAR output to L200 test code. 
   The standard method to generate a complete L200 test job for CASS using LASAR output is cumbersome, unwieldy, and is a path fraught with error. Test vectors generated are anything but readable, even on jobs with a small number of patterns, because only pin state changes are shown. The method does not work very well with hierarchical model design such as one would employ to test a box, an Interface Device (ID), for example. Often the test engineer needs to build two or more nets and combine them into one large model. LASAR permits this feature but post-processing into L200 is difficult if not prohibitive. The L200 post-processor does not allow names of chips to exceed four characters which precludes the use of scoping type fault callouts required by hierarchical modeling. 
   Furthermore, the standard 9-9-1 mismatch scoring algorithm is simply not adequate in some situations. The 9-9-1 weighting factor method of mismatch scoring sometimes punishes the real fault signature too severely by overlooking valid matches. A typical 9-9-1 mismatch scoring fault analyzer had much difficulty producing accurate fault callouts for the signatures represented in the fault dictionary. Some of the faults were totally erroneous and directed the technician to replace many good components while never touching the actual faulty one. Apparently, the correct fault signature was scored for mismatch too punitively. Analysis revealed that the correct POPATs (primary output patterns) found were not given adequate credit. Furthermore, the 9-9-1 method has great difficulty handling anomalies such as multiple faults or poor initialization. 
   SUMMARY OF THE INVENTION 
   It is therefore an object to increase the efficiency of converting the output of circuit simulation data into data for automated circuit testing program of a circuit testing device. 
   It is another object to have programs that generate readable test vectors. 
   It is still another object to have programs that accommodate hierarchical model structuring. 
   It is still yet another object to enhance the mismatch scoring algorithm. 
   To achieve the objectives of the present invention, there is provided a technique of generation of a job for digital testing unit for a test station from the output of a program for circuit simulation. The present invention includes completing fault simulation on electronic circuitry, then executing a first program without a fault dictionary, generating a pin map of the electronic circuitry and appending any pin groups, generating test vectors using the pin groups by the first program, generating additional pin groups to accommodate any orphan pins, converting the pin maps and pattern files to pin maps and pattern files, executing the first program to generate the fault dictionary, inputting a minimum scope level of analysis of the circuitry, generating the fault dictionary in fault dictionary data files according to the minimum scope level, generating a fault retriever file from the first program; and transporting the fault dictionary data files, test vectors, new pin maps, and fault retriever file to a second program for run-time fault analysis on the electronic circuitry testing unit. 
   The present invention may also generate wire path files for analysis. 
   The present invention may also include the scoring of a mismatch between predicted test responses and actual tester responses by assigning a partial credit for primary output patterns being detected. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     A more complete appreciation of this invention, and many of the attendant advantages thereof, will be 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  is the LSR — POST — L main menu of the present invention; 
       FIG. 2  is the creating of the PATTERNS files; 
       FIG. 3  is the creating of the fault dictionary; 
       FIG. 4  is the creating of the run-time fault retriever; 
       FIG. 5  is the creating of the optional wire-path file; 
       FIG. 6  is the creating of the “WIRE — PATH.TXT” file for the wire-path; 
       FIG. 7(   a ) is an ATLAS header code to implement “ATG — FLT — L”; 
       FIG. 7(   b ) is the beginning ATLAS code to implement ATG — FLT — L; 
       FIG. 7(   c ) is the remaining ATLAS code to implement ATG — FLT — L; 
       FIG. 8  is an example of hierarchical modeling; 
       FIG. 9  is hierarchical modeling in LASAR; 
       FIG. 10  is the overall scheme of the streamlined technique of LASAR to L200 conversion; 
       FIG. 11  is the output of the run-time fault analyzer; 
       FIG. 12  is a view of the LSR — POST — L and ATG — FLT — L; and 
       FIG. 13  is another view of the LASAR to L200 conversion. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   A new system was developed in the present invention to generate the L200 job for CASS ( 110 ) from the LASAR ( 5 ) output ( 20 ). This new method greatly reduces the unwieldiness of the process, produces very readable test vectors, encourages and even enhances hierarchical model structuring, and offers a better mismatch scoring algorithm not based on the 9-9-1 weighting rule. This system is implemented in a duet software package containing the post-processor ‘LSR — POST L’ and the run-time fault analyzer ‘ATG — FLT — L’. 
   First, there is a completion of a successful fault simulation in a LASAR job (S 10 ). All LASAR simulation is completed on a computer workstation such as a DEC ALPHA workstation. The test vectors (patterns), input and output vectors are in LASAR format. Concerning the fault circuit simulation, the fault diagnostics database (fault — dictionary) is also in LASAR format. 
   In the next set of steps, a test job is built on the same workstation where the simulation is completed. Referring to  FIG. 2 , the LSR — POST — L program is used to create L200 style pattern files. In LASAR, after all Good Machine Response (GMR) simulation results are satisfactory (S 10 ), simply post-process using LASAR&#39;s ‘LSRTAP’ without fault — dictionary (S 20 ). The LSRTAP generates .TAP files (S 30 ). The TAP files are text file database of 1&#39;s and 0&#39;s input stream representing the states of each pin. The .TAP files are not easily readable by a user. Now the developer creates the L200 $PINMAP file and appends any pin groups that he or she wishes to see (S 40 ). The $PINMAP file has the pin map of the simulated circuit used to perform LASAR simulation. ‘LSR — POST — L’ will generate test vectors using these pin groups. If no pin groups are supplied, it will create them automatically. Then a copy of the ‘LSR — POST — L’ program will be brought into the directory where the TAP files from the LASAR job reside. Then, bring in the $PINMAP, copy as ‘PINMAP.TXT’ and run ‘LSR — POST — L’. At the menu options (see  FIGS. 1 and 2 ), select the “Build PATTS.SYM Files” option (S 50 ) to build the pattern files. ‘LSR — POST — L’ will create a new pinmap file, ‘PINMAP.NEW’ (S 70 ), which has additional pin groups to accommodate any orphan pins. Basically the pin map file is appended with the added information. The LSR — POST — L program also creates the new (stimulus and response) pattern files (‘PATTS.SYM’, ‘PATTS — 001.SYM’, ‘PATTS — 002.SYM’, etc.) in the current subdirectory (S 60 ). All pattern (vector) files are created by LSR — POST — L for the L200 tester. The pattern files are now enhanced as they are now readable to the developer. In L200, simply do a “convert-in” to bring the new pin map (must change name to ‘.PMP’, of course) and new pattern files (‘PATTS.SYM’, ‘PATTS — 001.SYM’, ‘PATTS — 002.SYM’, etc.) into XEC (L200&#39;s test operating system) (S 80 ). 
   Creating the fault dictionary is just as streamlined as seen in  FIG. 3 . All fault simulations are completed in LASAR (S 10 ) and then post-process again using ‘LSRTAP’, this time with the /DIA=FAULT — DICT option where “/DIA” stands for diagnostics and FAULT — DICT refers to the fault dictionary (S 110 ). The LSRTAP produces a plurality of TAP files (S 120 ). Then, again, run the program ‘LSR — POST — L’ and use the option “Build FAULT — DICTIONARY” from the main menu (see  FIG. 3 ) (S 130 ). The user is asked to enter the Minimum Scope Level (MSL) he or she wishes to see (S 140 ); this guarantees that the fault analyzer will always show the correct hierarchical fault call-out at run-time. The special fault dictionary file ‘FAULT — D.DAT’ is created (S 150 ). This fault dictionary file will be used at run-time on the L200. This fault dictionary is not converted into the L200 environment. Instead, the fault dictionary resides in the run-time test program directory. 
   Next, referring to  FIG. 4 , a user creates the fault retriever file ‘ATGPOP.SYM’ file (S 230 ) for the L200 by running that option (“Build ATGPOP.SYM”) from the main menu (S 220 ). This file, too, must be converted into XEC (S 240 ). 
   Finally, referring to  FIG. 5 , the optional “wire paths file,” is created if desired. The “wire paths file” is a text file called ‘WIRE — PTH.TXT’ and is created using any text word editor. The “WIRE — PTH.TXT” file is submitted (S 300 ). This file associates main net pin I/O (input/output) with cable or connector or both cable and connector information; it also offers the feature to associate a page number of a schematic to the main net I/O pins. Then, run ‘LSR — POST — L’ again and select the main menu option “Build WIRE — PTH.DAT File” (as seen in  FIG. 5 ) (S 310 ). LSR — POST — L creates the WIRE — PTH.DAT file which is the wire path data file in the current subdirectory (S 320 ). The file resides in the test program run-time directory and not in the L200. The LSR — POST — L compiles the file to a run-time file for the tester (CASS workstation).  FIG. 6  discloses the format of this wire path text file. 
   All of these main menu options may be run at once, if the test engineer wishes to do the whole job at once. For example, at the main menu, simply type in each option number delimited by commas. ‘LSR — POST — L’ will run the options selected in the order they are input. 
   The output files ‘FAULT — D.DAT’ and ‘WIRE — PTH.DAT’  20  are transported  30  to the TPS (test program set) run-time directory. The test program set contains all of the software and hardware excluding the tester (i.e., interface device, miscellaneous cables, etc.). The files for the L200 test vectors, fault dictionary, new pinmap, wire paths, and fault retriever can be transported through a data line or an optical disc that is carried from one system to another. At this point, all files created by LSR — POST — L must now reside on the tester (CASS workstation), either in the run-time directory or in the L200 (XEC) environment as described above. Then the run-time fault analyzer ‘ATG — FLT — L’  100  is brought in. One must be sure to convert the new pinmap file, all of the newly generated pattern files, and ‘ATGPOP.SYM’ into XEC as described above. The test engineer must supply all L200 timing and levels parameters as well as the other L200 files such as the cross reference and debug files. 
   There is an unlimited numbers of vectors in the creation of the fault dictionary. Further, there is test vector generation capability. The LSR — POST can accept very large jobs (32-bits will handle virtually unlimited size jobs) and create the test vectors needed for the L200 job at the CASS test station. The tester (CASS Workstation) houses the digital tester L200 and will run the digital test using the files generated above. It will accept the developer&#39;s own pin groups and create the test vector files written in the verbage of those pin groups using the syntax of the L200. The individual digital state for each pin group is shown for every pattern. Since L200 can only accept a limited number of bytes per file, the new 32-bit version monitors the size of each file &amp; creates the quantity of files to accommodate this limitation. 
   Concerning the problems of hierarchical modeling, with this new post-processing duet, testing IDs and other boxes (WRAs, LRUs) is now easily implemented. The MSL variable in ‘LSR — POST — L’ in the “Build FAULT — DICTIONARY” option permits the test engineer to set the depth to which he has modeled. 
   For instance, there was the use of a two-card ID. A net for each of the cards, a net for output buffering (to accommodate LASARs insistence that wired nets never cross scope boundaries, a fault simulation requirement), and a net for some pull-up resistors (see  FIGS. 8 and 9 ) were created. These were each pre-compiled in LASAR and then referenced as components in the main ID net. It was desired that the fault call-out go down to the secondary net level, ie. call out faulty components on each of the sub-nets. So, the MSL was set to two thus permitting fault callouts such as ‘A1A2.U17’, where U17 is a component on the A2 board in the ID A1. 
   The standard test language ATLAS will run the L200 tests. ATLAS requests execution of the patterns in the L200, and makes the L200 take and evaluate the response. ATLAS checks to see if the L200 found a fault on the circuit being tested. If a fault is found, then ATLAS calls ATG — FLT — L which is the second program of the duet and is only callable from ATLAS. ATG — FLT — L looks at the fault dictionary (fault — dictionary) that was previously created and compares its entries to the fault “snapshot” just taken on the faulty board being tested. ATG — FLT — L uses algorithms to decide which entry in the database most closely resembles or matches the real-world, run-time fault scenario just found. ATG — FLT — L sends back to ATLAS all of the information on the best four matches (best scoring are those that have the fewest mismatches). ATLAS then prints out for the operator the four possibilities of what it thinks actually failed in the real world scenario, i.e. the test just performed. 
   All test programs executed on the CASS are written in the standard test language of ATLAS. The ATLAS test program calls all testing operations at run-time. The functions of ATLAS and ATG — FLT — L are stated in more detail below. Typically, for all digital tests, ATLAS must interface with the L200 through Functional Extension Programs (FEP) which run in the background. The special FEP, ‘L2 — LASAR’, normally used to launch LASAR-type digital tests, is not used with this new scheme. The test pattern generator of ‘LSR — POST — L’ creates the working L200 pattern files, a quantity of which is needed to accommodate the XEC compiler. At run-time, the first pattern file will call, in succession, the remaining pattern files. Following the last pattern file, it will call an L200 routine ‘get — popats’ (POPAT, primary output patterns) contained in the file ‘ATGPOP.SYM’ generated by ‘LSR — POST — L’ also. If failures were found, ‘get — popats’ will create a file in the TPS directory called ‘popats.dat’. 
   The ATLAS calls the first pattern file in the L200 using the standard FEP ‘L2 — EXECUTE’. When the patterns have been executed, control goes back to the ATLAS. The ATLAS then tests for failures using the variable ‘TEST-FAILED’ that is returned from the FEP. If failures occurred, ATLAS then calls the new FEP ‘ATG — FLT — L’, the run-time fault analyzer of the duet. ‘ATG — FLT — L’ examines the ‘popats.dat’ file just created, matches the signature there with those in the fault — dictionary and returns the best matching faultsets with scores to the ATLAS. 
   As seen in  FIG. 7 , to use the FEP ‘ATG-FLT-L’, simply send it the name of the fault — dictionary file (‘FAULT — D.DAT’ used here) and the name of the optional wire paths file (‘WIRE — PTH.DAT’ shown here) or ‘NONE’, if not used. The FEP will send back the quantity of faultsets (maximum of four of the best scoring) it has compiled, the scores for each faultset, the print strings for each faultset, a small character array containing “news” relating the quality of the match, faultset information (not used), and lastly, the wire path callouts. The ATLAS procedure ‘SHOW — ATG — FAIL’ is offered here to demonstrate how the returned data is used to produce the fault callout on the display. The first parameter in this procedure just enables output to the printer, the second enables the wire paths to be displayed or printed or both displayed and printed. 
   Often the test engineer needs to build two or more nets and combine them into one large model, i.e. build a hierarchical LASAR model. LASAR permits this feature but post-processing into L200 is difficult if not prohibitive. The L200 post-processor does not allow names of chips to exceed four characters which precludes the use of scoping type fault callouts required by hierarchical modeling. With this new post-processing duet, testing IDs and other boxes (WRAs, LRUs) is now easily implemented. The MSL variable in ‘LSR — POST L’in the “Build FAULT — DICTIONARY” option permits the test engineer to set the depth to which he has modeled. As seen in  FIGS. 8 and 9  an example of hierarchical modeling using LASAR is given. 
   There is a need that hierarchical schemes report the wire paths from the panel interface to the main net I/O and show a page number of a schematic where the I/O and wire path can be found. Rather than try to build all of this into some clunky model scheme using pseudo components, this new method allows the test developer to submit a wire path text file containing sections for the page numbers and the I/O association. ‘LSR — POST — L’ then converts the data in this file into a special wire-paths file which is accessed at run-time by ‘ATG — FLT — L’. These wire-paths and schematic page numbers are correlated by ‘ATG — FLT — L’ when a fault is discovered and appended to the fault callout which is then printed by the ATLAS. Thus a full-bodied LASAR test for the system of boards is implemented. 
   Another feature of the duet method is an enhanced method of scoring mismatch between predicted test responses and actual tester responses. The 9-9-1 weighting factor method of mismatch scoring sometimes punishes the real fault signature too severely by overlooking valid matches. Furthermore, the 9-9-1 method has great difficulty handling anomalies such as multiple faults or poor initialization. Because of this, an alternative algorithm which is not based upon the standard 9-9-1 weighting factors was developed. This new algorithm instead offers partial credit for significant Primary Output Patterns (POPAT) that are actually detected. Rather than punishing deficiencies in the fault signature, tester POPATs are positively valued for the matches found. This results in a far better picture of the needed replacement action to repair the board or box. Most faults result in a mismatch of zero but the occasional anomaly such as discussed above is redemptively handled. The mismatch may be higher than ideal but, at least typically the faulty component is shown for repair action. For example, an easy fault inserted was not correctly diagnosed using prior techniques of 9-9-1 weighting factors. In fact, the actual fault &lt;A1A2.U21&gt;9@0 inserted was never mentioned in the output. As seen in  FIG. 11 , however, ‘FAULTR’ of the present invention, a troubleshooting version of ‘ATG — FLT — L’ caught the fault without problem. 
     FIG. 10  shows the roles of ‘LSR-POST — L’  10  and ‘ATG — FLT — L’  100 . This duet post-processor and run-time fault analyzer offers a streamlined method of converting LASAR output to a run-time L200 job. Ease of use, eliminating the $CHAR — LIB and other files, is but one of the features of this duet. Very readable test vectors, both stimulus and response, using the engineer&#39;s own pin groups is another advantage of the present invention. Additionally, the programs facilitate the simple use of hierarchical LASAR modeling of boxes and enhance this by offering the addition of the wire-paths in the fault callouts as well as schematic page numbers for the repair action. 
     FIGS. 10 and 13  show the LSR — POST — L  10  running on the memory  42  of a computer  40  with LASAR having a central processing unit  44 . The computer  40  with LASAR may be connected to a computer  200  of the CASS test station  110  having a program ATG — FLT — L  100  on the memory  202  and including a central processing unit  204 . The computer  200  may be connected to an L200 digital tester  300 . As seen in  FIG. 12 , a fault dictionary  400  and L200 test vector files  500  can be generated. 
   As shown above, the present invention provides a multi-featured program duet for streamlining LASAR output into L200 test code and fault dictionary for digital program on CASS. The efficiency of converting the output of circuit simulation data into data for automated circuit testing program of a circuit testing device has been increased by the present invention. The programs generate readable test vectors and accommodate hierarchical model structuring. The mismatch scoring algorithm has also been enhanced. 
   While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention.