US20100229058A1 - Method and apparatus for system testing using scan chain decomposition - Google Patents

Method and apparatus for system testing using scan chain decomposition Download PDF

Info

Publication number
US20100229058A1
US20100229058A1 US12/495,336 US49533609A US2010229058A1 US 20100229058 A1 US20100229058 A1 US 20100229058A1 US 49533609 A US49533609 A US 49533609A US 2010229058 A1 US2010229058 A1 US 2010229058A1
Authority
US
United States
Prior art keywords
instructions
test
testing
tisa
scan
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
Application number
US12/495,336
Other languages
English (en)
Inventor
Suresh Goyal
Michele Portolan
Bradford Van Treuren
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent Ireland Ltd
Alcatel Lucent USA Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority to US12/495,336 priority Critical patent/US20100229058A1/en
Application filed by Alcatel Lucent Ireland Ltd, Alcatel Lucent USA Inc filed Critical Alcatel Lucent Ireland Ltd
Assigned to ALCATEL-LUCENT IRELAND LTD. reassignment ALCATEL-LUCENT IRELAND LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PORTOLAN, MICHELE
Assigned to ALCATEL-LUCENT USA INC. reassignment ALCATEL-LUCENT USA INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VAN TREUREN, BRADFORD, GOYAL, SURESH
Priority to US12/827,556 priority patent/US8621301B2/en
Publication of US20100229058A1 publication Critical patent/US20100229058A1/en
Assigned to ALCATEL LUCENT reassignment ALCATEL LUCENT ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ALCATEL-LUCENT USA INC.
Assigned to ALCATEL LUCENT reassignment ALCATEL LUCENT ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ALCATEL-LUCENT IRELAND LTD.
Priority to US13/338,431 priority patent/US8775884B2/en
Priority to US13/338,581 priority patent/US8719649B2/en
Assigned to CREDIT SUISSE AG reassignment CREDIT SUISSE AG SECURITY AGREEMENT Assignors: ALCATEL LUCENT
Assigned to ALCATEL LUCENT reassignment ALCATEL LUCENT RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: CREDIT SUISSE AG
Assigned to OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP reassignment OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WSOU INVESTMENTS, LLC
Assigned to WSOU INVESTMENTS, LLC reassignment WSOU INVESTMENTS, LLC RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: OCO OPPORTUNITIES MASTER FUND, L.P. (F/K/A OMEGA CREDIT OPPORTUNITIES MASTER FUND LP
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G01R31/318533—Reconfiguring for testing, e.g. LSSD, partitioning using scanning techniques, e.g. LSSD, Boundary Scan, JTAG
    • G01R31/318558—Addressing or selecting of subparts of the device under test

Definitions

  • the invention relates to the field of system testing and, more specifically but not exclusively, to generation and control of instructions for system testing.
  • PCB printed circuit board
  • a circuit board substrate having conductive traces interconnecting various device terminals to form an electrical circuit.
  • board testing apparatuses have evolved from simple I/O functional testers that connect to I/O connectors of a populated PCB for high level automated functional testing, to test fixtures that include probe pins for making electrical contact with all or some of the circuit nodes of a tested board for performance of high level and lower level testing, to integrated testing devices that provide for automated testing of a PCB without the need to externally probe individual circuit nodes of the tested board.
  • testing Automation Tools which support the steps needed to proceed from a definition of the test algorithm to the actual testing operation.
  • testing resources often are embedded inside the boards and devices, and can be accessed using a standardised interface, usually called a Test Access Port (TAP).
  • TAP Test Access Port
  • SUT system under test
  • Testing Automation Tools can apply their own algorithms in order to generate testing sequences exploiting the TAP.
  • TCU Test Control Unit
  • the features and performance of the testing operations depend on each of these elements, namely, the access standard, the data format, and the TCU implementation.
  • JTAG The Joint Test Action Group
  • IEEE 1149.1 specifies a Test Access Port (TAP) for testing circuit boards.
  • IEEE 1149.1 supports Boundary Scan (BS) testing of hardware via test devices included on the tested circuit boards. Boundary Scan testing involves controlling and monitoring boundary pins of a JTAG-compatible device under the control of software to provide test coverage beyond that which might otherwise be available.
  • Instruction JTAG IJTAG is being standardized (denoted as P1687) to overcome existing JTAG limitations associated with moving from board-level JTAG to chip-level JTAG.
  • JTAG and IJTAG may be used by Automated Test Generation (ATG) tools to test chips and electronic devices.
  • JTAG presents a simple 5-wire TAP that allows serially access, with minimal overhead, to resources implemented inside a chip.
  • the access infrastructure can then be described into a specific language such as the Boundary Scan Description Language (BSDL), which can be used by many commercial TGTs to generate testing vectors.
  • BSDL Boundary Scan Description Language
  • SVF Serial Vector Format
  • a more complex alternative to SVF is STAPL, which extends the vector operations of SVF to allow for basic flow control (if-then-else) and arithmetic operations on the test vectors.
  • a JTAG-compliant TAP receives commands from a SVF or STAPL player, and generates simple Go/NoGo results which can later be interpreted offline.
  • a first limitation is in the data format, because the test player does not have any knowledge of the system under test and, therefore, can perform only very basic operations.
  • a second limitation is that interactive testing (local or remote) cannot be supported; rather, any testing results must be examined offline. Further, these existing approaches are implementation-dependent and are typically proprietary.
  • a method for testing a portion of a system under test via a scan chain of the system under test.
  • the method includes decomposing the scan chain into a plurality of segments, generating a set of instructions for testing the portion of the system under test, and executing the set of instructions for testing the portion of the system under test.
  • the scan chain is composed of a plurality of elements, and each segment includes at least one of the elements of the scan chain.
  • the set of instructions includes a plurality of processor instructions associated with an Instruction Set Architecture (ISA), and a plurality of test instructions.
  • the test instructions include, for each of the plurality of segments of the scan chain, at least one scan operation to be performed on the segment.
  • an apparatus for testing a portion of a system under test via a scan chain of the system under test.
  • the apparatus includes means for decomposing the scan chain into a plurality of segments, means for generating a set of instructions for testing the portion of the system under test, and means for executing the set of instructions for testing the portion of the system under test.
  • the scan chain is composed of a plurality of elements, and each segment includes at least one of the elements of the scan chain.
  • the set of instructions includes a plurality of processor instructions associated with an Instruction Set Architecture (ISA), and a plurality of test instructions.
  • the test instructions include, for each of the plurality of segments of the scan chain, at least one scan operation to be performed on the segment.
  • FIG. 1 depicts a high-level block diagram of a system testing environment including a testing system and a system under test;
  • FIG. 2 depicts a high-level block diagram of one embodiment of the testing system of FIG. 1 , including a test generation tool and a software compiler cooperating to generate test instructions for a system under test;
  • FIG. 3 depicts a high-level block diagram of one embodiment of the testing system of FIG. 1 , including a test generation tool and a software compiler cooperating to generate test instructions for a system under test;
  • FIGS. 4A-4E depict an implementation of the TISA using a SPARC V8 ISA, illustrating the details of instruction coding for the implementation of the TISA using a SPARC V8 ISA;
  • FIG. 5 depicts an implementation of the TISA using a SPARC V8 ISA, illustrating an exemplary TISA architecture for implementation of the TISA using a SPARC V8 ISA;
  • FIG. 6 depicts an embodiment of a TISA-based testing environment supporting interactive testing capabilities
  • FIG. 7 depicts an exemplary implementation of the TISA-based testing environment of FIG. 6 ;
  • FIG. 8 depicts an exemplary program architecture for performing optimization of the transmitter-receiver channel of the system under test of FIG. 5A ;
  • FIG. 9 depicts one embodiment of a method for adapting an Instruction Set Architecture (ISA) flow of a processor to form a Test Instruction Set Architecture (TISA) flow;
  • ISA Instruction Set Architecture
  • TISA Test Instruction Set Architecture
  • FIG. 10 depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test
  • FIG. 11A depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test
  • FIG. 11B depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test
  • FIG. 12 depicts an exemplary embodiment of a TISA processor architecture
  • FIG. 13 depicts an exemplary embodiment of a test processor architecture utilizing multiple processors to provide system testing capabilities
  • FIG. 14 depicts an exemplary embodiment of a test co-processor architecture
  • FIG. 15 depicts an exemplary embodiment of a test adjunct processor architecture
  • FIG. 16 depicts an exemplary register set that can be used by a TISA processor
  • FIG. 17 depicts a high-level block diagram of a system under test, illustrating an exemplary decomposition of an exemplary scan chain of the system under test;
  • FIG. 18 depicts a high-level block diagram of one embodiment of a method for testing a portion of a system under test via a scan chain of the system under test using Scan Segment Level abstraction of the scan chain;
  • FIG. 19 depicts a high-level block diagram of a computer suitable for use in performing functions described herein.
  • SUT system under test
  • a test instruction set architecture is provided.
  • the TISA is provided for use in performing system testing.
  • the TISA combines computer science capabilities with system testing capabilities to provide improved system testing capabilities, including interactive testing capabilities, remote testing capabilities, and various other capabilities described herein.
  • the TISA is formed by adapting a software-based instruction set architecture (ISA) using system testing capabilities.
  • ISA software-based instruction set architecture
  • the software-based ISA may utilize any suitable software programming language (e.g., C++, Java, and the like, as well as various combinations thereof) and may be implemented using any suitable processor.
  • the system testing capabilities may utilize any suitable TAP, such as IEEE 1149.1 (also known as JTAG) TAPs or any other suitable TAPs.
  • the TISA is formed by combining the atomic operations of a software process with atomic testing operations of a test procedure.
  • the algorithmic portions of the test procedure are handled by the software flow, such that the algorithmic portions of the test procedure are translated into the atomic testing operations.
  • the TISA is formed by combining the atomic operations of the software process with the atomic testing operations of the test procedure, such that the atomic testing operations are treated in the same manner as the atomic operations of the software process that is handling the algorithmic portions of the test procedure. This enables finer-grain control of embedded test execution, remote test execution, and various other improved system testing capabilities as depicted and described herein.
  • FIG. 1 depicts a high-level block diagram of a system testing environment including a testing system and a system under test.
  • system testing environment 100 includes a testing system (TS) 110 and a system under test (SUT) 120 .
  • TS testing system
  • SUT system under test
  • the TS 110 may be any system suitable for testing SUT 120 .
  • the TS 110 is configured for testing SUT 120 .
  • the TS 110 may perform any testing of SUT 120 , e.g., testing one or more individual components of SUT 120 , one or more combinations of components of SUT 120 , one or more interconnections between components of SUT 120 , one or more system level functions of SUT 120 , and the like, as well as various combinations thereof.
  • the TS 110 may perform any of the functions typically associated with testing a system under test, such as executing test procedures, providing input data to the system under test, receiving output data from the system under test, processing output data received from the system under test for determining system testing results, and like functions, as well as various combinations thereof.
  • the design and use of TS 110 for testing a system under test is described in additional detail hereinbelow.
  • the SUT 120 may be any system which may be tested using TS 110 .
  • the SUT 120 may include any component(s), at least a portion of which may be tested, individually and/or in combination, by TS 110 .
  • the TS 120 may include one or more scan chains, having one or more sets of associated input and output access pins, providing access to the component(s) to be tested by SUT 120 .
  • the manner in which a scan chain(s) may be utilized in SUT 120 for testing SUT 120 will be appreciated by one skilled in the art.
  • SUT 120 may include one or more boards, testing of which may be performed using one or more scan chains having associated input and output access pins which may be used for applying input testing signals to SUT 120 and collecting output testing signals from SUT 120 .
  • TS 110 accesses SUT 120 via a test access interface (TAI) 115 .
  • TAI test access interface
  • the test access interface may be implemented using any suitable test access interface, which may depend on one or more of the TS 110 , the SUT 120 , the type of testing to be performed, and the like, as well as various combinations thereof.
  • TAI 115 may include a Joint Test Action Group (JTAG) Test Access Port (TAP) as standardized in IEEE 1149.1 standard, which is incorporated by reference herein in its entirety.
  • JTAG Joint Test Action Group
  • TAP Test Access Port
  • the IEEE 1149.1 standard defines a TAP that supports the following set of signals: Test Data In (TDI), Test Data Out (TDO), Test Mode Select (TMS), Test Clock (TCK), and, optionally, Test Reset Signal (TRST).
  • the TDI and TDO pins of SUT 120 are interconnected in a boundary scan chain by which TS 110 may access SUT 120 for testing at least a portion of SUT 120 .
  • the TAI 115 may include any other suitable test access interface.
  • TS 110 , TAI 115 , and SUT 120 may be implemented in any manner suitable for providing features of the embodiments covered herein.
  • the TISA is able to leverage computer science capabilities in combination with system testing capabilities to provide a significant improvement in system testing.
  • a general description of system testing capabilities and computer science capabilities follows, followed by a description of the manner in which computer science capabilities and system testing capabilities may be utilized together to provide the TISA.
  • the TISA improves upon system testing capabilities by leveraging computer science capabilities.
  • the system testing capabilities may include the capabilities generally supported in all stages of the “automated test” flow (which generally includes all of the steps and resources that may be needed to get from a definition of the test algorithm(s) to actual testing operations).
  • test resources In order to help test automation, test resources often are embedded inside the boards and devices, and can be accessed using a standardised interface, usually called the Test Access Port (TAP). This has the effect of limiting the pin count and rationalising resource access and management.
  • TAP Test Access Port
  • a number of languages are available for describing resources inside a system under test, and, thus, which may be used as inputs to Test Generation Tools (TGTs).
  • TGTs can apply algorithms to generate testing sequences which may be used by a Test Control Unit (TCU) to command the TAP and execute the associated testing operations.
  • TCU Test Control Unit
  • the features and performances of the testing operations depend on these three elements: the access standard, the data format, and the TCU implementation.
  • the TISA is able to leverage computer science capabilities to provide improved system testing capabilities. This may include use of computer science capabilities that are available in all stages of the “software development flow” (which generally includes any or all of the steps and resources that may be needed to get from a software algorithm coded in a software language(s) of choice to the final debugging and execution on a target processor, such as compilation, an Instruction Set Architecture (ISA), interactive debugging, and the like, as well as various combinations thereof).
  • ISA Instruction Set Architecture
  • the Instruction Set Architecture is the core of any processor, and the reason for which compilation is so effective.
  • each processor offers a set of instructions which define the manner in which the processor can be operated.
  • the instructions form at least part of the ISA of the processor.
  • the ISA may be considered to include various constructs associated with the instructions, such as registers, addressing modes, opcodes, memory structures, and the like, as well as various combinations thereof.
  • the ISA enables the processor to execute simple instructions, such as reading/writing values from/to memory, perform logical or arithmetical operations on registers, handle interruption, and the like.
  • debugging in computer science allows monitoring and verification of the software development and execution process.
  • software development is a long and difficult process, which is strictly monitored and verified to assure that the final product is free of defaults, or “bugs” are they are usually called.
  • the software development flow provides many powerful debug features.
  • common software development flow debug features include step-by-step execution; observability/controllability of all registers and memory locations, use of breakpoints and watchpoints, and the like.
  • These debug features, as well as various other debug features are more often enabled by algorithms and structures embedded into the final code by the software compiler, but may also be assisted by hardware resources available inside of the processor. From this information the debugger can reconstruct the original code and correlate all the ISA-level operations to the programming abstraction layer.
  • FIG. 2 depicts a high-level block diagram of one embodiment of the testing system of FIG. 1 , including a test generation tool and a software compiler cooperating to generate test instructions for a system under test.
  • the TS 110 includes a test generation tool (TGT) 210 and a software compiler (SC) 220 .
  • TGT test generation tool
  • SC software compiler
  • the TGT 210 includes a TGT composer 212 and TGT algorithms 214 .
  • the TGT composer 212 accepts system description files 211 as input.
  • the system description files 211 include any suitable description files which may be used by a TGT to produce testing instructions/vectors for testing a system under test.
  • system description files 211 may include circuit description files, board/fixture netlist files, other description files, and the like, as well as various combinations thereof.
  • the system description files 211 may be available on TGT 210 and/or may be obtained from one or more remote components and/or systems.
  • the system description files 211 may include one or more circuit description files,
  • the circuit description files may be specified using any suitable description language(s), such as the Boundary Scan Description Language (BSDL, which was developed as part of the IEEE 1149.1 standard for board-level JTAG), the Hierarchical Scan Description Language (HSDL, which was developed as an extension of BSDL), New Scan Description Language (NSDL), and the like, as well as various combinations thereof.
  • BSDL Boundary Scan Description Language
  • HSDL Hierarchical Scan Description Language
  • NSDL New Scan Description Language
  • the system description files 211 may include one or more board/fixture netlist files,
  • the board/fixture netlist files may include files related to the physical description of the device(s), describing the netlist, connections, and like information.
  • the board/fixture netlist files may be specified in any suitable format, such as PCB, Gerber, and/or any other format suitable for board/fixture netlist files.
  • the system description files 211 may include one or more other description files.
  • the other description files may include any other suitable description files which may be used as input for producing a circuit model.
  • other description files may include any suitable application-specific and/or tool-specific description language files, such as Asset's Macro Language, Goepel's CASLAN Language, and/or any other suitable description language files.
  • the TGT composer 212 processes the system description files 211 to produce a circuit model 213 .
  • the processing of system description files 211 by TGT composer 212 to produce circuit model 213 may be performed in any suitable manner.
  • the circuit model 213 specifies a model of the system under test or portion of the system under test for which TGT 210 is being run.
  • the TGT composer 212 provides circuit model 213 to TGT algorithms 214 .
  • the TGT algorithms 214 accept circuit model 213 .
  • the TGT algorithms 214 process the circuit model 213 to produce TGT atomic test operations 216 .
  • the processing of circuit model 213 by TGT algorithms 214 to produce the TGT atomic test operations 216 may be performed in any suitable manner.
  • the SC 220 includes SC front-end algorithms 222 and SC back-end algorithms 224 .
  • the SC front-end algorithms 222 accept computer science source files 221 as input.
  • the computer science source files 221 include any suitable computer science source files which may be compiled by a compiler.
  • computer science source files 221 may include computer science source files for any suitable computer programming language(s), such as C++, Java, Python, and the like, as well as various combinations thereof.
  • computer science source files 221 may include one or more of one or more C files, one or more C++files, and/or any other suitable computer science source files.
  • the SC front-end algorithms 222 process the computer science source files 221 to produce a program model 223 .
  • the program model 223 specifies an intermediate representation of the computer science source files 221 .
  • the SC front-end algorithms 222 provide the program model 223 to the SC back-end algorithms 224 .
  • the SC back-end algorithms 224 accept program model 223 as input.
  • the SC back-end algorithms 224 process the program model 223 to produce one or more ISA Binary Files 225 including ISA atomic operations 226 .
  • the processing of program model 223 by the SC back-end algorithms 224 to form the ISA Binary Files 225 including the ISA atomic operations 226 may be performed in any suitable manner.
  • the ISA atomic operations 226 are assembly-level instructions supported by the processor for which the TISA is implemented.
  • SC back-end algorithms 224 may initiate one or more vector computation requests 230 to TGT algorithms 214 .
  • the SC back-end algorithms 224 may initiate a vector computation request 230 when the SC back-end algorithms need to access the TAP.
  • the TGT algorithms 214 upon receiving a vector computation request 230 from SC back-end algorithms 224 , generate one or more TGT atomic test operations 216 for the TAP based on the received vector computation request 230 .
  • the one or more TGT atomic test operations 216 may then be applied to the TAP in a manner controlled by SC back-end algorithms 224 , because the TGT atomic test operations 216 are combined with the ISA atomic operations 226 to enable algorithmic control over TGT atomic test operations 216 using ISA atomic operations 226 .
  • the SC 220 provides algorithmic control of access to the TAP.
  • TS 110 further includes a TISA composer 240 .
  • the TISA composer 240 accepts the TGT atomic test operations 216 and the ISA atomic operations 226 .
  • the TISA composer 240 converts the TGT atomic test operations 216 into TISA instructions and inserts the TISA instructions into the ISA Binary File(s) 225 (i.e., combining the TISA instructions with the ISA atomic operations 226 to form thereby TISA Binary files 245 including TISA atomic operations 246 .
  • the TISA composer 240 may be part of TGT 210 , part of SC 220 , split across TGT 210 and SC 220 , implemented separate from TGT 210 and SC 220 , and the like.
  • FIG. 3 depicts a high-level block diagram of one embodiment of the testing system of FIG. 1 , including a test generation tool and a software compiler cooperating to generate test instructions for a system under test.
  • TS 110 of FIG. 3 operates in a manner similar to TS 110 of FIG. 2 , in that TISA Binary files including TISA atomic operations are generated using interaction between the test generation tool and the software compiler; however, interaction between the test generation tool and the software compiler in TS 110 of FIG. 3 is different than interaction between the test generation tool and the software compiler in TS 110 of FIG. 2 .
  • the TS 110 includes a test generation tool (TGT) 310 and a software compiler (SC) 320 .
  • TGT test generation tool
  • SC software compiler
  • the TGT 310 includes a TGT composer 312 and TGT algorithms 314 .
  • the TGT composer 312 accepts system description files 311 as input.
  • the system description files 311 include any suitable description files which may be used by a TGT to produce testing instructions/vectors for testing a system under test.
  • system description files 311 may include circuit description files, board/fixture netlist files, other description files, and the like, as well as various combinations thereof.
  • the system description files 311 of FIG. 3 may include system description files similar to system description filed 211 depicted and described with respect to FIG. 2 (e.g., one or more circuit description files, one or more board/fixture netlist files, one or more other description filed, and the like, as well as various combinations thereof).
  • the system description files 311 may be available on TGT 310 and/or obtained from one or more remote components and/or systems.
  • the TGT composer 312 accepts one or more test operation description files 331 1 - 331 N (collectively, test operation description files 331 ) as input.
  • the test operation description files 331 are generated by SC 320 .
  • the generation of test operation description files 331 by SC 320 is described in detail hereinbelow.
  • the TGT composer 312 processes the system description files 311 and the test operation description files 331 to produce a circuit model 313 .
  • the processing of system description files 311 by TGT composer 312 to produce circuit model 313 may be performed in any suitable manner.
  • the circuit model 313 specifies a model of the system under test or portion of the system under test for which TGT 310 is being run.
  • the processing of system description files 311 in conjunction with test operation description files 331 enables the TGT composer 312 to produce circuit model 313 in a manner for enabling TGT 310 to produce appropriate TAP atomic operations.
  • the TGT composer 312 provides circuit model 313 to TGT algorithms 314 .
  • the TGT algorithms 314 accept circuit model 313 .
  • the TGT algorithms 314 process the circuit model 313 to produce TGT atomic test operations 316 .
  • the processing of circuit model 313 by TGT algorithms 314 to produce the TGT atomic test operations 316 may be performed in any suitable manner.
  • TS 110 includes a TISA translator 340 .
  • the TISA translator 340 receives the TGT atomic test operations 316 .
  • the TISA translator 340 translates TGT atomic test operations 316 to form TISA atomic test operations 346 .
  • the TISA translator 340 provides TISA atomic test operations 346 to SC 320 for inclusion in the software compilation process.
  • the use of TISA atomic test operations 346 by SC 320 is described in detail hereinbelow.
  • the TISA translator 340 may be part of TGT 310 , part of SC 320 , split across TGT 310 and SC 320 , implemented separate from TGT 310 and SC 320 , and the like.
  • the SC 320 includes a SC pre-compiler 330 , SC front-end algorithms 322 , and SC back-end algorithms 324 .
  • the SC pre-compiler 330 accepts computer science source files 321 .
  • the computer science source files 321 include any suitable computer programming source files which may be compiled by a compiler.
  • computer science source files 321 may include computer programming source files for any suitable computer programming language(s), such as C++, Java, Python, and the like, as well as various combinations thereof.
  • computer science source files 321 may include one or more of one or more C files, one or more C++files, and/or any other suitable computer science source files.
  • the SC pre-compiler 330 processes the computer science source files 321 .
  • the SC pre-compiler 330 processes the computer science source files 321 , producing therefrom pre-processed computer science source files 321 P .
  • the computer science source files 321 may be pre-processed by SC pre-compiler 330 to form pre-processed computer science source files 321 P in any suitable manner.
  • the SC pre-compiler 330 provides the pre-processed computer science source files 321 P to front-end algorithms 322 .
  • the SC pre-compiler 330 detects test operations during processing of the computer science source files 321 , and generates the test operation description files 331 .
  • the test operation description files 331 may be specified using any suitable test description language (e.g., using one or more standard test description languages, using a test description language specific to the TGT 310 , and the like, as well as various combinations thereof).
  • the SC pre-compiler 330 provides the test operation description files 331 to TGT 310 (illustratively, to the TGT composer 312 of TGT 310 , which processes the test operation description files 331 in conjunction with the system description files 311 to produce circuit model 313 .
  • the SC front-end algorithms 322 accept pre-processed computer science source files 321 P .
  • the SC front-end algorithms 322 also accept the TISA atomic test operations 346 , which are produced by TISA translator 340 using TGT atomic test operations 316 produced by TGT 310 from the test operation description files 331 .
  • the SC front-end algorithms 222 compile the pre-processed computer science source files 321 P and TISA atomic test operations 346 to produce a program model 323 .
  • the program model 323 specifies an intermediate representation of the pre-processed computer science source files 321 P , which includes TISA atomic test operations 346 such that TISA atomic test operations 346 may be integrated within the ISA atomic operations to form TISA atomic operations.
  • the SC front-end algorithms 322 provide the program model 323 to the SC back-end algorithms 324 .
  • the SC back-end algorithms 324 accept program model 323 .
  • the SC back-end algorithms 324 process program model 223 to produce one or more TISA Binary Files 355 including TISA atomic operations 356 .
  • the processing of program model 323 by the SC back-end algorithms 324 to form the TISA Binary Files 355 including the TISA atomic operations 356 may be performed in any suitable manner.
  • the TISA atomic operations 356 include ISA atomic operations (i.e., assembly-level instructions supported by the processor for which the TISA is implemented) and TISA atomic test operations 346 .
  • the TISA atomic operations 356 provide algorithmic control (using ISA atomic operations) over TGT atomic test operations 316 (i.e., in the form of the TISA atomic test operations 346 ), thereby enabling improved system testing of the system under test to which the TISA atomic operations 356 are to be applied.
  • the TGT atomic test operations 316 i.e., in the form of the TISA atomic test operations 346
  • SC back-end algorithms 324 because the TGT atomic test operations 316 are combined with the ISA atomic operations to enable algorithmic control over TGT atomic test operations 316 using the ISA atomic operations.
  • the SC 220 provides algorithmic control of access to the TAP.
  • FIG. 2 and FIG. 3 although primarily depicted and described with respect to specific numbers of input files, intermediate files, models, output files, and the like, it will be appreciated that the embodiments of FIG. 2 and FIG. 3 , as well as various associated teachings provided herein, may be implemented using any suitable numbers of input files, intermediate files, models, output files, and the like.
  • FIG. 2 and FIG. 3 illustrate the manner in which computer science capabilities may be leveraged to improve system testing capabilities (e.g., providing finer-grain control of system testing, enabling interactive system testing, enabling interactive debugging during system testing, and providing various other advantages depicted and described herein).
  • the system testing schemes of FIG. 2 and FIG. 3 provide improvements over existing approaches, such as STAPL, where the goal is to add programming features to vector formats and, therefore, debugging, remote access, and interactivity features are added from scratch.
  • the TISA leverages the wealth of information from computer programming and embedded applications to control test access for system testing.
  • the capabilities and features of the TISA are defined by its abstraction level, i.e., the finer the definition of the TISA atomic operations, the better performance the TISA will provide.
  • three abstraction levels may be supported for scan operations.
  • the first abstraction level is the Vector Level.
  • the Vector Level is the coarsest grain of the three abstraction levels, where the atomic operations are inputs and outputs of scan vectors.
  • the Vector Level is best represented in a vector format, such as Serial Vector format (SVF) or any other suitable vector format, and gives the highest-level control.
  • SVF Serial Vector format
  • the second abstraction level is the TAP Level.
  • the atomic operations are enhanced to allow full control over the TAP state machine. This enables more refined control over scan operations, support of non-standard sequences (e.g., like the ones required, for instance, in the Addressable Shadow Protocol or other similar protocols).
  • the third abstraction level is the Scan Segments Level.
  • the Scan Segments Level is the finest grain of the three abstraction levels.
  • the Vector Level and TAP Level abstraction levels use the scan vector as the atomic data format, which is sufficient for traditional continuity tests where the entire scan chain is involved, but is cumbersome for instrument-based testing where there is a need for fine-grain control over the tens or hundreds of instruments that compose the scan chain.
  • the Scan Segments Level allows the definition of “scan segments” inside the overall scan path, which can be handled separately, thereby providing a flexible and powerful set of primitives that can be used to define scan operations directly in the problem space and resolve the scan operations at implementation time. This approach is advantageous in embedded applications, where the available computational resources may be quite limited.
  • the use of Scan Segments Level is depicted and described in additional detail hereinbelow.
  • the resulting TAP atomic operations (illustratively, TGT atomic test operations 216 and TGT atomic test operations 316 ) computed by the TGT are converted into corresponding TISA atomic test operations and inserted into the binary executable (i.e., into the ISA atomic operations generated by the SC).
  • TGT atomic test operations 216 and ISA atomic operations 226 can be processed to form the TISA atomic operations 246 in the TISA binary executables (illustratively, TISA binary files 245 ).
  • the TISA atomic operations 246 include TISA atomic test operations and ISA atomic operations.
  • TISA atomic test operations (generated by TISA translator 340 from TGT atomic test operations 316 produced by TGT 310 ) can be input into the SC front end 324 as pre-compiled assembly instructions, without any need to modify the SC front end 324 of SC 310 . It will be appreciated that almost all programming languages allow for such operations. In C, for example, this operation is obtained using the “asm” command. In one embodiment, minor modifications to SC back-end algorithms 324 may be required (e.g., to handle binary conversion of the TISA assembler instructions). An example of such a process is depicted and described herein with respect to FIG. 11 .
  • the TISA may be implemented using any suitable instruction set architecture (ISA).
  • ISA instruction set architecture
  • the TISA may be implemented using the SPARC V8 ISA, an INTEL ISA, and the like.
  • the TISA is implemented as a Vector Level TISA, which allows direct coding of the instructions that compose the SVF format; however, as described hereinabove, it will be appreciated that implementation of the TISA using the SPARC V8 ISA also may be performed where the TISA is implemented as a TAP Level TISA or a Scan Segment Level TISA.
  • the SPARC V8 ISA is implemented in many products, such as the open-source soft processor family Leon 2 and Leon 3.
  • SPARC Architecture Manual The SPARC Architecture Manual Version 8,” published by SPARC International, Inc, 1992 (hereinafter “SPARC Architecture Manual”), reveals that there are many code words not exploited by the SPARC V8 ISA. This is evident at least from a review of the “opcodes and condition codes” of Appendix F.
  • FIG. 4A depicts the unexploited code words of the SPARC V8 ISA.
  • the unexploited code words depicted in FIG. 4A may be used to code the “test” instructions for the TISA. More specifically, when both “op” and “op 2 ” are set to 0, the instruction is marked as unimplemented in “The SPARC Architecture Manual Version 8,” such that the instruction may be used for the TISA.
  • FIG. 4B depicts a coding format able to represent all thirteen of the SVF instructions.
  • bits 30 - 25 include the instruction coding itself, bits 21 - 18 may be used to code a TAP state if one is to be used with the instruction, and bits 17 - 14 can be used by each instruction to specify optional information where needed.
  • FIG. 4C depicts an exemplary bit coding of the TAP states for an IEEE 1149.1 TAP.
  • the bit coding of the TAP states is represented using a first column that identifies the IEEE 1149.1 TAP State Name, a second column that identifies the SVF TAP State Name associated with the IEEE 1149.1 TAP State Name, and a third column that identifies the bit coding for bits 21 - 18 of FIG. 4B . It will be appreciated that the bit codings may be assigned to the TAP states in various other ways.
  • the SVF instructions allow for multiple parameters, which need to be coded inside the final code.
  • register-based parameter passing is defined for this exemplary implementation of a Vector Level TISA.
  • the Vector Level TISA presents six dedicated 32-bit registers: GENERIC1, GENERIC2, TDI, TDO, MASK and SMASK.
  • the six dedicated 32-bit registers are depicted in FIG. 4D .
  • the usage of the six dedicated 32-bit registers is described in detail hereinbelow, but, as a general rule, these registers are used either to store a parameter or to point to the memory location in which a parameter is stored.
  • normal ISA instructions can be used to load these registers before the TISA instruction is invoked.
  • coprocessor registers may be used directly as parameters for the usual load/store instructions.
  • the SVF instructions which may be utilized in this SPARC V8 ISA implementation of the TISA include ENDDR, ENDIR, STATE, FREQUENCY, PIO, PIOMAP, HDR, HIR, TDR, TIR, SDR, SIR, and RUNTEST. These SVF instructions may be better understood by way of reference to the “Serial Vector Format Specification,” by ASSET InterTech, Inc., 1997 (hereinafter referred to as the SVF Manual), which is herein incorporated by reference in its entirety. The use of these SVF instructions in this SPARC V8 ISA implementation of the TISA is described in more detail hereinbelow.
  • the ENDDR and ENDIR instructions indicate the TAP state at which the TAP interface ends its operation.
  • the STATE instruction forces the TAP interface to a specified state.
  • the SVF codings for the ENDDR, ENDIR, and STATE instructions are “000000”, “000001”, and “000010”, respectively, as depicted in FIG. 4E .
  • the SVF coding of these SVF instructions may be performed using the “TAP STATE” file (i.e., the exemplary bit coding of the TAP states as depicted in FIG. 4C ) as needed.
  • the STATE instruction can optionally take the explicit sequence of states as parameters. In this exemplary implementation of the TISA, taking the explicit sequence of states as parameters would be coded by a series of instructions, one for each state in the sequence.
  • the FREQUENCY instruction is used to specify the working frequency of the TAP interface.
  • the FREQUENCY instruction is expressed as a 32-bit integer of Hz cycles.
  • the SVF coding for the FREQUENCY instruction is “000011”, as depicted in FIG. 4E .
  • the value for the FREQUENCY instruction is stored in the GENERIC 1 register.
  • the PIO instruction can be used to handle parallel vectors, in a format previously set by a call to PIOMAP.
  • PIOMAP is seen as a pre-processor directive that generates the appropriate commands to set up the TAP interface.
  • the PIO instruction merely needs to express the parallel vector, which can be expressed by indicating (in the GENERIC 1 register) the address in which the parallel vector is stored.
  • the SVF coding for the PIO instruction is “000100”.
  • HDR HDR, HIR, TDR, TIR
  • MASK (optional): a mask to be used when comparing actual values with TDO. A ‘1’ indicated a care, a ‘0’ a don't care; and
  • SMASK (optional): a mask to mark which bits are to be considered in TDI. ‘1’ indicates a care, ‘0’ a don't care.
  • the SVF codings for the HDR, HIR, TDR, and TIR instructions are “000110”, “000111”, “001010”, and “001011”, respectively, as depicted in FIG. 4E .
  • O 1 is ‘1’ when TDI is present, ‘0’ otherwise. If set, the TDI register contains the address at which the input vector is stored;
  • O 3 is ‘1’ when MASK is present, ‘0’ otherwise. If set, the MASK register contains the address at which the output mask is stored;
  • O 4 is ‘1’ when SMASK is present, ‘0’ otherwise. If set, the SMASK register contains the address at which the output mask is stored.
  • the SDR and SIR instructions have the same syntax as the HDR, HIR, TDR, and TIR instructions, but have a functional difference: SDR and SIR trigger the actual scan operation on the TAP.
  • the TISA offers the possibility of storing the actual output vector in memory.
  • the GENERIC 2 register indicates the storage location of the actual output vector.
  • SDR and SIR can support a maximum of seven parameters. If TDO is specified and the actual output vector is different from the expected output vector, an overflow flag is set in the Processor State Register (PSR), as described in Section 4.2 of the SPARC Architecture Manual.
  • PSR Processor State Register
  • the RUNTEST instruction forces the TAP interface to run a test at a specified state for a specified amount of time, and is used mainly to control RUNBIST operations (e.g., as defined in IEEE 1149.1).
  • the RUNTEST instruction accepts one or more of the following parameters (all of which are optional):
  • run_state the state the interface must maintain during test execution
  • run_count the number of clock cycles the test must take
  • min_time minimum run time in seconds, expressed as a real number
  • the SVF coding for the RUNTEST instruction may be “000101” or “100101”.
  • TAP STATE it contains run_state of which it is defined
  • a test program is composed of two main portions: the algorithmic portion (as represented by the software compiler) and the test access portion (as represented by the test generation tool).
  • the algorithmic portion as represented by the software compiler
  • the test access portion as represented by the test generation tool.
  • a script takes care of all TAP operations at the Vector Level.
  • the interface or “player” is able to communicate with the TAP protocol, and send/receive vectors to/from the system under test.
  • STAPL also allows some basic flow control (if-then-else) and algorithmic operations on the bit vectors. If there is need for more sophisticated processing (e.g., identifying a register inside a received vector, or computing the vector to access a specific device), the player hands control over to the algorithmic portion. In STAPL, this is done through the “export” command.
  • neither SVF nor STAPL has a standardized format for this (e.g., in the case of STAPL, the handoff process is usually proprietary to a given vendor).
  • the TISA integrates the test access portion (i.e. the test operations) inside the algorithmic portion (i.e., the classical ISA), such that the test access portion and the algorithmic portion share the same physical memory space, thereby making handoff (and, thus, data passing) between the test access portion and the algorithmic portion automatic.
  • the test access portion and the algorithmic portion is made at the instruction level, such that the processor can freely mix scan and algorithm (i.e., freely mix test operations and algorithmic operations) as required according to the associated scheduling strategy.
  • testing vectors may be used like normal variables inside the ISA program, thereby making the interface between the test access portion and the algorithmic portion automatic.
  • the following steps exemplify an archetypical testing sequence:
  • An SDR instruction is used to obtain testing output data from the system under test.
  • the resulting output data is places in a specific memory location (e.g., the “actual” parameter in the GENERIC 2 register);
  • a classical LOAD instruction can transfer this output data to be loaded into a register
  • a classical STORE instruction is used to transfer the result of the algorithm into memory
  • An SDR instruction can send new testing input data to the TAP (e.g., using the “TDI” parameter in the TDI register).
  • TISA can be supported using any given algorithm or computer program, with a natural and efficient hand-off between the algorithmic portion and the test access portion.
  • the abstraction level is the Vector Level
  • the exemplary TISA implementation depicted and described herein may be modified such that the abstraction level of the TISA is the TAP Level or the Scan Segment Level.
  • the TISA is implemented as a Vector Level TISA using a SPARC V8 ISA and SVF (i.e., in continuation of the exemplary implementation depicted and described with respect to FIGS. 4A-4E ).
  • FIG. 5A and FIG. 5B depicts an exemplary use of the TISA to perform testing on a system under test.
  • FIG. 5A depicts a system test environment 500 including a JTAG TAP 510 and a system under test 520 .
  • the JTAG TAP 510 provides test access to a system under test 520 .
  • the JTAG TAP 510 provides test access to the system under test 520 , for sending input data to system under test 520 and receiving output data from system under test 520 .
  • the JTAG TAP 510 includes an instruction register (IR) 512 , which is an 8-bit instruction register.
  • the JTAG TAP 510 is controlled by a testing system (e.g., such as testing system 110 depicted and described with respect to FIG. 3 , which is omitted for purposes of clarity).
  • a testing system e.g., such as testing system 110 depicted and described with respect to FIG. 3 , which is omitted for purposes of clarity.
  • the system under test 520 includes a first board 521 (denoted as B 1 ) and a second board 525 (denoted as B 2 ).
  • the first board 521 includes a transmitter 522 (denoted as T).
  • the second board 525 includes a receiver 526 (denoted as R).
  • the transmitter 522 sends data, on a connection 529 , to receiver 526 .
  • the connection 529 is an 8-bit connection.
  • each board is accessible from JTAG TAP 510 via its own scan chain.
  • first board 521 is accessible via a first scan chain 523
  • second board 525 is accessible via a second scan chain 527 .
  • the transmitter 522 and the receiver 526 are not alone on their boards; rather, they are part of wider scan chains (e.g., for purposes of this example, 24 bits and 16 bits, respectively).
  • line 2 includes the C module that is handling JTAG operations, where the functions “apply_JTAG” and “Read_JTAG”, used in lines 12 and 13 , respectively, are defined.
  • the pre-compiler 330 of SC 320 recognizes these functions, and generates test operation description files 331 for TGT 310 .
  • the format of the test operation description files 331 may vary, depending on the actual implementation of first board 521 and second board 525 . For example, if first board 521 and second board 525 both are IJTAG compliant, test operation description files 331 could be specified, for example, using New Scan Description Language (NSDL) code.
  • NDL New Scan Description Language
  • the TGT 310 uses test operation description files 331 , generates TGT atomic test operations 316 , which are translated, by TISA translator 340 , into TISA atomic test operations 346 .
  • the TISA atomic test operations 346 are provided to front-end 324 of SC 320 .
  • the TGT atomic test operations 316 , the associated TISA atomic test operations 346 , and the resulting TISA binary code are depicted in FIG. 5B .
  • FIG. 5B depicts a mapping from C commands to TISA coding for use by a testing system performing testing of the system test environment 500 of FIG. 5A .
  • the mapping from C commands to TISA coding is represented using a table 540 having four columns: a “C command” column 541 , an “SVF instructions” column 542 , a “TISA assembler” column 543 , and a “TISA coding” column 544 .
  • the table 540 from left to right, illustrates the manner in which a C command can be translated into an SVF instruction, which can be translated into TISA assembler, which can be coded into TISA binary coding.
  • Apply_JTAG(value,B 1 .T) command is translated into two SVF instructions: SIR 8 TDI(00) and SDR 24 TDI(value).
  • the SIR 8 TDI(00) SVF instruction is translated into TISA assembler as three operations:
  • the SDR 24 TDI(value) SVF instruction is translated into TISA assembler as three operations:
  • the Read_JTAG(value,B 2 .R) command is translated into two SVF instructions: SIR 8 TDI(01) and SDR 16 ACTUAL(value).
  • the SIR 8 TDI(01) SVF instruction is translated into TISA assembler as three operations:
  • the SDR 16 ACTUAL(value) SVF instruction is translated into TISA assembler as three operations:
  • TISA coding of the SET operations is not specified because the SPARC V8 Manual identifies them as “pseudo-instructions” which can have a different coding following the implementation of the processor.
  • the pre-compiler 330 may now substitute the high-level JTAG accesses with their associated TISA assembler instructions.
  • the result is the following code, specified using C, in which the calls to the JTAG TAP have been replaced by the associated TISA assembler coding:
  • This code can be input into the front-end algorithms 322 , which will generate the program model 323 .
  • the program model 323 can be input into the back-end algorithms 324 , which will generate the executable TISA binary file(s) 355 including the TISA atomic operations 356 .
  • the “TISA coding” column 544 of table 540 depicts the binary coding of the TISA assembler instructions (e.g., using the various rules defined with respect to the exemplary implementation of the TISA using a SPARC V8 ISA, as depicted and described with respect to FIGS. 4A-4E ).
  • test patterns may be computed using explicit queries by the Software Compiler to the Test Generation Tool, such that the only limit for the software algorithm is the resolution of the queries themselves.
  • queries from the SC to the TGT may involve the entire scan chain of the system under test (e.g., such as in classical BSDL-based Boundary Scan testing).
  • queries from the SC to the TGT may involve registers or even bits.
  • dedicated Scan Segment primitives could significantly accelerate instrument access and TAP reconfiguration, boost code reuse, and provide various other advantages.
  • queries from the SC to the TGT may be done functionally (e.g., using standards such as IJTAG and other suitable standards, and using description languages such as NSDL and other suitable object-oriented description languages).
  • the TISA does not force device/register access to be resolved at the model space (i.e., in the TGT), but, rather, allows developers to handle device/register access at the problem space (i.e., in the SC), thereby enabling developers to adapt the analysis grain to their needs and to the available resources.
  • the TISA processor has sufficient resources, e.g., such as in the case of Automated Test Equipment (ATE), at least a portion of the circuit model may be implemented within the program model, thereby enabling the TISA machine to directly compute the vector patterns.
  • ATE Automated Test Equipment
  • TISA enables support for various other system test capabilities not previously possible without TISA, such as interactive testing including interactive debugging (locally and/or remotely), concurrency, portability, and the like, as well as various combinations thereof.
  • FIG. 6 depicts an embodiment of a TISA-based testing environment supporting interactive testing capabilities.
  • TISA-based testing environment 600 includes a host computer (HC) 601 , a testing system (TS) 610 , and a system under test (SUT) 620 .
  • HC host computer
  • TS testing system
  • SUT system under test
  • the HC 601 is configured to control TS 610 for controlling testing of SUT 620 .
  • the HC 601 includes a processor 602 coupled to a memory 604 .
  • the processor 602 and memory 604 may be any suitable processor and memory.
  • the memory 604 stores one or more debugger control programs 605 .
  • the debugger control program(s) enable HC 601 to trace and, where desired or necessary, alter, the execution of computer program(s) running on TS 610 .
  • debugger control program(s) 605 may include one or more of the GNU Debugger (GDB), the dbx debugger, the Perl debugger, the Bash debugger, the Python debugger, and like suitable debugger programs, as well as various combinations thereof.
  • GDB GNU Debugger
  • dbx debugger the Perl debugger
  • Bash debugger the Bash debugger
  • Python debugger Python debugger
  • the memory 604 also may store one or more debugger display programs 606 .
  • the debugger display program(s) enable HC 601 to display information associated with the debugger control program(s) 605 .
  • the information associated with debugger control program(s) 605 may be displayed by debugger display program(s) 606 in any suitable manner (e.g., using one or more display devices).
  • debugger display program(s) 606 may include one or more of Insight (which is a graphical user interface to GDB), the Data Display Debugger (DDD, which provides a graphical user interface for various command-line debuggers, such as GDB and others), and like suitable debugger display programs, as well as various combinations thereof.
  • Insight which is a graphical user interface to GDB
  • DDD Data Display Debugger
  • the TS 610 is controlled by HC 601 for purposes of testing SUT 620 .
  • the TS 610 is configured to function in a manner consistent with the TISA (e.g., such as depicted and described with respect to TS 110 of FIG. 1-FIG . 3 ) and, further, is configured to support interactive testing (e.g., by enabling access by debuggers running on HC 601 ).
  • the TS 610 includes a TISA processor 612 coupled to a memory 614 .
  • the TISA processor 612 may be implemented using any suitable processor, such as SPARC V8 (as depicted and described hereinabove with respect to FIGS. 4A-4E and FIG. 5 ), INTEL, and the like.
  • the memory 604 may be any suitable memory.
  • the memory 614 stores one or more debugger program stubs 615 .
  • the debugger program stubs 615 understand the debugger protocol of the corresponding debugger control program(s) 605 running on HC 601 , thereby enabling HC 601 to communicate with TS 610 .
  • debugger stub(s) 615 may include one or more of GDB stub, a DBX stub, a Perl stub, a Bash stub, a Python stub, and like suitable debugger program stubs, as well as various combinations thereof.
  • the memory 614 stores TISA Binary Files 616 .
  • the TISA Binary Files 616 are generated by TS 610 in a manner as depicted and described herein with respect to FIG. 2 and FIG. 3 .
  • the TISA Binary Files 616 are executed by TISA processor 612 to perform testing on SUT 620 .
  • the TS 610 also includes a Test Access Port (TAP) 618 coupled to TISA processor 612 .
  • TAP 618 provides a test interface between TISA processor 612 and SUT 620 for enabling TISA processor 612 to perform testing of SUT 620 while being controlled by HC 601 .
  • the TAP 618 may be any suitable TAP (e.g., an 1149.1 TAP).
  • the TISA processor 612 interfaces with TAP 618 using an interface 617 .
  • the interface 617 may be any suitable interface between a TAP and a system under test (e.g., such as an interface that supports TCK, TMS, TDI, TDO, and, optionally, TRST, where TAP 618 is implemented as an 1149.1 TAP).
  • HC 601 may control interactive testing of SUT 620 via TS 610 locally and/or remotely.
  • interface 609 may be implemented as one or more of a Universal Asynchronous Receiver-Transmitter (UART) interface, serial interface, and the like, as well as various combinations thereof.
  • UART Universal Asynchronous Receiver-Transmitter
  • interface 609 may be implemented using any suitable communications capabilities, such as Transmission Control Protocol (TCP)/Internet Protocol (IP) or any other suitable communications protocols.
  • TCP Transmission Control Protocol
  • IP Internet Protocol
  • the HC 601 is able to control, step-by-step, test execution on SUT 620 , by controlling operation of TS 610 via a standard connection (e.g., UART, TCP/IP, and the like), thereby enabling interactive testing and debugging capabilities.
  • a standard connection e.g., UART, TCP/IP, and the like
  • HC 601 and TS 610 may include various other components, such as additional processors, additional memories, internal communications buses, input/output modules, additional support circuits (e.g., power supplies), and the like, as well as various combinations thereof.
  • SUT 620 may be any system under test which may be tested using the TISA.
  • TISA-based testing environment 600 may be implemented in a manner enabling fully-interactive testing capabilities using various other debugger control programs, debugger display programs, interfaces, and the like, as well as various combinations thereof.
  • FIG. 7 depicts an exemplary implementation of the TISA-based testing environment of FIG. 6 .
  • exemplary TISA-based testing environment 700 of FIG. 7 is an implementation of the TISA-based testing environment 600 of FIG. 6 in which the GNU Tool Suite is used to support interactive testing of the exemplary system testing environment 500 of FIG. 5A .
  • exemplary TISA-based testing environment 700 includes a host computer (HC) 701 , a testing system (TS) 710 , and a system under test (SUT) 720 .
  • HC host computer
  • TS testing system
  • SUT system under test
  • the HC 701 includes a processor 702 and a memory 704 .
  • the HC 701 of FIG. 7 is an implementation of HC 601 of FIG. 6 , in which debugger control program(s) 605 is implemented using GDB (GDB 705 ) and debugger display program(s) 606 is implemented using DDD (DDD 706 ).
  • GDB 705 GDB 705
  • DDD 706 DDD 706
  • the TS 710 includes a TISA processor 712 and a memory 714 .
  • the TS 710 of FIG. 7 is an implementation of TS 610 of FIG. 6 , in which the TISA processor 612 is implemented using a SPARC V8 ISA (denoted as SPARC V8 TISA processor 712 ), debugger program stub(s) 615 is implemented using a GDB stub (GDB stub 715 ), and the TISA Binary Files 616 are generated based on the SPARC V8 ISA associated with SPARC V8 TISA processor 712 (TISA Binary Files 716 ).
  • SPARC V8 ISA debugger program stub(s) 615
  • GDB stub 715 GDB stub 715
  • TISA Binary Files 616 are generated based on the SPARC V8 ISA associated with SPARC V8 TISA processor 712 (TISA Binary Files 716 ).
  • the TS 710 also includes a Test Access Port (TAP) 718 coupled to SPARC V8 TISA processor 712 .
  • TAP Test Access Port
  • the TS 710 of FIG. 7 is an implementation of TS 610 of FIG. 6 , in which the TAP 618 is implemented using a 1149.1 TAP (1149.1 TAP 718 ).
  • the SPARC V8 TISA processor 712 interfaces with 1149.1 TAP 718 using an interface 717 .
  • the interface 717 is a standard 1149.1 interface that supports TCK, TMS, TDI, TDO, and, optionally, TRST.
  • the SUT 720 is the SUT 520 of FIG. 5A .
  • the SUT 720 includes a transmitter and receiver on different boards, as in SUT 520 of FIG. 5A .
  • the 1149.1 TAP 718 provides a test interface between SPARC V8 TISA processor 712 and SUT 720 for enabling SPARC V8 TISA processor 712 to perform testing of SUT 720 while being controlled by HC 701 .
  • HC 701 may control interactive testing of SUT 720 via TS 710 locally and/or remotely.
  • the HC 701 is able to control, step-by-step, test execution on SUT 720 , by controlling the operation of TS 710 via interface 709 , thereby enabling interactive testing and debugging capabilities.
  • FIG. 7 It will be appreciated that most of the left-hand side of FIG. 7 reuses existing Computer Science elements: namely, the entire HC 701 , as well as the GDB stub 715 on TS 710 . It is the same for the central part of FIG. 7 , where analogies between HC 701 and TS 710 (as well as their associated sub-elements) are evident.
  • the TISA allows this entire infrastructure to be leveraged to provide system testing.
  • TISA can enable by leveraging on GDB (or any other suitable debuggers), such as: (a) step-by-step execution while monitoring the variables “sent_value” and “received_value”; (b) on-the-fly modification of the value to be sent to the tap (variable “sent_value”); (c) modification of the looping end condition; (d) monitoring of all variables; and the like, as well as various combinations thereof.
  • exemplary TISA-based testing environment 700 of FIG. 7 is primarily depicted and described herein with respect to using the GNU Tool Suite to support interactive testing of a specific system under test, it will be appreciated, by those skilled in the art and informed by the teachings herein, that interactive testing capabilities in a TISA-based test environment may be realized using any suitable tool suites for testing any type of system under test.
  • TISA-based testing environment 600 of FIG. 6 and exemplary TISA-based testing environment 700 of FIG. 7 are primarily depicted and described herein with respect to linear test procedures where testing is done step-by-step following a pre-determined algorithm (for purposes of clarity in describing the interactive testing capabilities that are enabled by TISA), it will be appreciated that other more complicated interactive testing scenarios are possible due to the leverage of Computer Science experience and techniques enabled by TISA.
  • An example of a more complicated interactive testing scenario enabled by TISA is depicted and described herein with respect to FIG. 8 . It will be appreciated that this is merely one example, and that one skilled in the art and informed by the teachings herein may use TISA in many other interactive testing scenarios and applications.
  • the TISA also supports concurrency.
  • TISA naturally and fully merges the system testing flow with the computer science software flow and, therefore, can leverage the best aspects of both flows.
  • approaches such as STAPL have difficulty in handling concurrent control of instruments, because such approaches are, by definition, fully sequential.
  • approaches such as the MTC and SystemBIST are intrinsically sequential and single-task and, thus, it would be difficult and awkward to program such approaches to support concurrency.
  • concurrent execution is a well-known problem in Computer Science and is now, for instance, at the base of all operating systems.
  • a large number of libraries supporting concurrent execution are available (e.g., the POSIX suite, the BOOST suite, and the like), and most modern processors are designed to efficiently support multi-tasking and context-switching (e.g., the SPARC V8, for instance, implements a rotating register window).
  • the natural interaction between the system testing flow and the computer science software flow that is enabled by the TISA allows the TISA to completely leverage such computer science approaches to concurrency.
  • the support of concurrency capabilities by the TISA may be better understood by way of an example.
  • the problem of optimizing the data transfer rate of the T-R channel between the transmitter 522 and the receiver 526 of the system under test 520 of FIG. 5A and FIG. 7 This would involve transmitting a stream of data patterns from transmitter 522 on first board 521 , receiving a corresponding stream of data patterns at receiver 526 on second board 525 , and comparing the transmitted and received streams of data patterns to compute bit/error rates and to tune parameters of transmitter 522 and/or receiver 526 accordingly.
  • This optimization may be performed efficiently using three programs operating concurrently.
  • FIG. 8 depicts an exemplary program architecture for performing optimization of the transmitter-receiver channel of the system under test of FIG. 5A and FIG. 7 .
  • exemplary program architecture includes a pattern generator 802 , a pattern receiver 804 , and a comparator 806 .
  • the pattern generator 802 , pattern receiver 804 , and comparator 806 cooperate to optimize the data transfer rate of the T-R channel between the transmitter 522 and the receiver 526 of the system under test 520 of FIG. 5A and FIG. 7 .
  • the pattern generator 802 sends the appropriate input data patterns to the transmitter 522 (T) on first board 521 .
  • the pattern generator 802 can access the TAP (illustratively, TAP 510 in FIG. 5A , TAP 718 in FIG. 7 ) in order to provide the input data patterns to transmitter 522 via the scan chain 523 of first board 521 (B 1 ).
  • the pattern generator 802 may provide the input data patterns to the transmitter 522 in any suitable manner (e.g., as specified in lines 12 - 13 of the code described herein with respect to FIG. 5A ).
  • the input data patterns may be any data patterns suitable for optimizing the T-R channel between transmitter 522 and receiver 526 .
  • the input data patterns may be pre-computed patterns, random patterns, and the like, as well as various combinations thereof.
  • the pattern receiver 804 collects the appropriate output data patterns from the receiver 526 (R) on second board 525 .
  • the pattern receiver 804 can access the TAP (illustratively, TAP 510 in FIG. 5A , TAP 718 in FIG. 7 ) in order to collect the output data patterns from receiver 526 via the scan chain 527 of second board 525 (B 2 ).
  • the pattern receiver 804 may collect the output data patterns from the receiver 526 in any suitable manner (e.g., as specified in lines 14 - 15 of the code described herein with respect to FIG. 5A ).
  • the comparator 806 communicates with pattern generator 802 and pattern receiver 804 .
  • the comparator compares the input data patterns and the output data patterns.
  • the comparator 806 evaluates the bit transmission rate and the bit error rate of the T-R channel and, based on the results of the comparison, can access the control registers of both the transmitter 522 and the receiver 526 (omitted from FIG. 5A and FIG. 7 , for purposes of clarity) to optimize the parameters of the T-R channel.
  • pattern generator 802 , pattern receiver 804 , and comparator 806 need to work in parallel, and each must be able to access the TAP independently of the others.
  • This type of control structure is very difficult to code in traditional environments, which are developed only to support one-point serial handoff control over the TAP.
  • This type of control structure also is very difficult to code in environments employing MTC or other such approaches which also share the same serial TAP access paradigm.
  • the TISA is not designed with any such assumption regarding test access; rather, in the TISA, test access is handled in a manner similar to other processor resources, and test access instructions are mixed directly with classical ISA instructions. Using the TISA, the optimization testing procedure of FIG.
  • pattern generator 802 , pattern receiver 804 , and comparator 806 can share access to the TAP, and can resolve any eventual TAP sharing issues as is done for all processor resources, e.g., using well-known constructs and algorithms such as, for example, Dijkstra's semaphores.
  • processor resources e.g., using well-known constructs and algorithms such as, for example, Dijkstra's semaphores.
  • the TISA does not make any assumptions regarding the test access method or the associated test program partitioning; rather, test instructions are treated in the same manner, or substantially the same manner, as classical ISA instructions, without any a priori separation between the two. This enables the TISA to be completely compatible with all existing (and, most likely, future) computer science algorithms and constructs, something that no existing test processor approaches can support.
  • any existing software libraries can be ported into the TISA architecture.
  • it would be easy to obtain multitasking and concurrency e.g., as depicted and described herein with respect to FIG. 8
  • multitasking and concurrency e.g., as depicted and described herein with respect to FIG. 8
  • the TISA is obtained as a generalization of an existing ISA (e.g., as depicted and described with respect to the exemplary SPARC V8 TISA implementation depicted and described with respect to the FIG. 5A and FIG. 5B )
  • porting may not even be necessary since the ISA that the TISA has been developed from will already include such software libraries.
  • TISA computer science techniques
  • some examples of such computer science techniques which may be leveraged for the TISA include: (a) use of platform-independent coding styles, (b) use of ISA-to-ISA converters; (c) use of a Virtual Machine approach, e.g., like for Java, to obtain platform-independent bytecode, or even extension of the Java Virtual Machine itself to become a TISA; and (d) use of an Application Programming Interface (API) to standardize some TISA software interfaces, which would then be translated into primitives by the appropriate drivers.
  • API Application Programming Interface
  • FIG. 9 depicts one embodiment of a method for adapting an Instruction Set Architecture (ISA) flow of a processor to form a Test Instruction Set Architecture (TISA) flow including TISA instructions adapted for use by the processor in testing at least a portion of a system under test.
  • ISA Instruction Set Architecture
  • TISA Test Instruction Set Architecture
  • method 900 may be performed contemporaneously, or in a different order than depicted and described with respect to FIG. 9 .
  • method 900 begins.
  • a first set of instructions is generated.
  • the first set of instructions includes ISA instructions supported by the processor (i.e., ISA instructions being leveraged to provide the TISA for the processor).
  • a second set of instructions is generated.
  • the second set of instructions includes test instructions associated with the system under test.
  • the second set of instructions may be generated in any suitable manner, e.g., as depicted and described with respect to TGT 210 of FIG. 2 , as depicted and described with respect to TGT 310 of FIG. 3 , and/or using any other suitable method of generating test instructions.
  • the first set of instructions and the second set of instructions are integrated to form thereby TISA instructions.
  • the TISA instructions provide the TISA for the processor.
  • the TISA instructions are stored, displayed, propagated, and/or executed, or any combination thereof.
  • the TISA instructions may be handled in any other suitable manner.
  • step 912 method 900 ends.
  • the TISA may be formed in any suitable manner, e.g., as depicted and described with respect to method 1000 of FIG. 10 , as depicted and described with respect to the test system of FIG. 2 and associated method 1110 of FIG. 11A , as depicted and described with respect to the test system of FIG. 3 and associated method 1120 of FIG. 11B , and/or using any other suitable method of forming a TISA.
  • FIG. 10 depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test. Although primarily depicted and described herein as being performed serially, at least a portion of the steps of method 1000 may be performed contemporaneously, or in a different order than depicted and described with respect to FIG. 10 .
  • method 1000 begins.
  • a first set of instructions is generated.
  • the first set of instructions includes instructions generated by compiling at least one computer science software file (e.g., ISA instructions of an ISA supported by a processor).
  • a second set of instructions is generated.
  • the second set of instructions includes test instructions generated by compiling at least one description file associated with the system under test.
  • the first and second sets of instructions are combined to form a combined set of instructions.
  • the instructions of the first set of instructions are adapted for use in controlling execution of the test instructions of the second set of instructions.
  • the combined set of instructions is stored, displayed, propagated, and/or executed, or any combination thereof.
  • the combined set of instructions may be handled in any other suitable manner.
  • step 1012 method 1000 ends.
  • FIG. 11A and FIG. 11B depict more detailed embodiments of the method 900 depicted and described with respect to FIG. 9 and/or the method 1000 depicted and described with respect to FIG. 10 .
  • FIG. 11A depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test. Although primarily depicted and described herein as being performed in a specific sequence, at least a portion of the steps of method 1110 of FIG. 11A may be performed in a different order than depicted and described with respect to FIG. 11A . FIG. 11A may be better understood by viewing it in conjunction with FIG. 2 and the associated description of FIG. 2 .
  • step 1111 method 1000 begins.
  • a program model is generated.
  • the program model is generated by compiling at least one computer science software file (e.g., ISA instructions of an ISA supported by a processor), where the at least one computer science software file includes at least one call.
  • at least one computer science software file e.g., ISA instructions of an ISA supported by a processor
  • a first set of instructions is generated.
  • the first set of instructions is generated using the program model.
  • At least one computation request also is generated using the at least one call included in the at least one computer science software file.
  • a circuit model is generated.
  • the circuit model is generated by compiling at least one system description file associated with the system under test.
  • a second set of instructions is generated.
  • the second set of instruction is generated using the circuit model and the at least one computation request.
  • the first and second sets of instructions are combined to form a combined set of instructions.
  • the instructions of the first set of instructions are adapted for use in controlling execution of the test instructions of the second set of instructions.
  • the combined set of instructions is stored, displayed, propagated, and/or executed, or any combination thereof.
  • the combined set of instructions may be handled in any other suitable manner.
  • FIG. 11B depicts one embodiment of a method for generating instructions adapted for use in testing at least a portion of a system under test. Although primarily depicted and described herein as being performed serially, at least a portion of the steps of method 1120 of FIG. 11B may be performed contemporaneously, or in a different order than depicted and described with respect to FIG. 11B . FIG. 11B may be better understood by viewing it in conjunction with FIG. 3 and the associated description of FIG. 3 .
  • method 1100 begins.
  • At step 1122 at least one pre-processed computer science software file and at least one test operation description file are generated by pre-processing at least one computer science software file.
  • a circuit model is generated.
  • the circuit model is generated by compiling at least one system description file associated with the system under test and the at least one test operation description file.
  • a set of test operations is generated.
  • the set of test operations is generated using the circuit model.
  • the test operations from the set of test operations are described using a set of test primitives (e.g., test primitives defined by a test generation tool which generates the circuit model).
  • the set of test primitives includes test operations adapted for use in testing the system under test.
  • the set of test operations is translated into a set of test instructions by translating the test primitives of the set of test operations into test instructions adapted for use in combination with software instructions of an instruction set architecture.
  • a program model is generated.
  • the program model is generated by compiling the at least one pre-processed computer science software file and the set of test instructions.
  • a combined set of instructions is generated.
  • the combined set of instructions is generated using the program model.
  • the combined set of instructions includes (a) software instructions determined from the at least one pre-processed computer science software file and (b) test instructions from the set of test instructions.
  • the combined set of instructions is stored, displayed, propagated, and/or executed, or any combination thereof.
  • the combined set of instructions may be handled in any other suitable manner.
  • step 1129 method 1120 ends.
  • FIG. 12 depicts an exemplary embodiment of a TISA processor architecture.
  • TISA processor architecture 1200 includes a TISA processor 1210 and a memory 1220 .
  • the TISA processor 1210 may be any processor that is suitable for performing system testing using a TISA, such as a SPARC V8 processor, an INTEL processor, or any other suitable processor.
  • the memory 1220 may include any memory suitable for use by TISA processor 1210 to support system testing using a TISA, including one or more of random access memory, persistent memory, and the like, as well as various combinations thereof.
  • the memory 1220 may store any information required for performing system testing using a TISA, such as test programs, TISA instructions, testing data, and the like, as well as various combinations thereof.
  • TISA processor architecture 1200 of FIG. 12 may support the TISA flows depicted and described with respect to FIG. 2 and FIG. 3 .
  • TISA processor architecture 1200 of FIG. 12 may operate in a manner similar to TISA processor 612 and memory 614 of testing system 610 depicted and described with respect to FIG. 6 .
  • TISA processor architecture 1200 of FIG. 12 may be implemented using a SPARC V8 TISA processor and associated memory, such as in the testing system 710 depicted and described with respect to FIG. 7 .
  • the TISA processor 1210 itself interprets and executes both the ISA and TISA instructions.
  • an apparatus for use in testing at least a portion of a system under test via a Test Access Port includes a memory for storing a set of instructions of a test instruction set architecture and a processor executing the set of instructions of the test instruction set architecture for testing at least a portion of the system under test via the TAP.
  • the set of instructions of the test instruction set architecture includes a first set of instructions comprising a plurality of instructions of an Instruction Set Architecture (ISA) supported by the processor and a second set of instructions comprising a plurality of test instructions associated with the TAP, where the instructions of the first class of instructions and the instructions of the second class of instructions are integrated to form thereby the set of instructions of the test instruction set architecture.
  • ISA Instruction Set Architecture
  • a TISA processor for use in testing at least a portion of a system under test via a Test Access Port includes a first class of instructions including instructions of an Instruction Set Architecture (ISA) supported by the processor and a second class of instructions including test instructions associated with the TAP, wherein the ISA instructions of the first set of instructions and the test instructions of the second set of instructions are integrated to form a TISA adapted for testing at least a portion of the system under test.
  • ISA Instruction Set Architecture
  • a computer processor for testing a system under test (SUT) via a Test Access Port (TAP), includes circuitry configured to process instructions according to a test instruction set architecture (TISA) having semantics that enable interaction with the system under test via the TAP.
  • TISA test instruction set architecture
  • the TISA includes a plurality of instructions of a first type and a plurality of instructions of a second type, where the first type of instructions include instructions of an instruction set architecture (ISA) supported by the computer processor and the second type of instructions include test instructions for testing the system under test via the TAP.
  • TISA may be defined in other ways that are fully supported by the depiction and description of various TISAs as provided herein.
  • the TISA processor architecture may be implemented using multiple processors.
  • FIG. 13 depicts an exemplary embodiment of a test processor architecture utilizing multiple processors to provide system testing capabilities.
  • test processor architecture 1300 includes a primary processor 1310 and a secondary processor 1320 in communication via a communication path 1330 .
  • the primary processor 1310 may be any processor suitable for supporting system testing, such as a SPARC V8 processor, an INTEL processor, or any other suitable processor.
  • the primary processor 1310 executes instructions for testing a system under test.
  • primary processor 1310 may support testing functions similar to the functions supported by CPU 1210 of TISA processor architecture 1200 of FIG. 12 (e.g., where test processor architecture 1300 utilizes a TISA).
  • primary processor 1310 may support testing functions supported by testing processors in test processor architectures that do not utilize a TISA.
  • the primary processor 1310 may support various other testing capabilities.
  • the secondary processor 1320 may be any processor suitable for supporting system testing, such as a SPARC V8 processor, an INTEL processor, or any other suitable processor.
  • the secondary processor 1320 supports a Test Access Port (TAP) interface to the system under test (which is omitted for purposes of clarity).
  • TAP Test Access Port
  • the TAP interface may interface with any suitable TAP.
  • the TAP interface may provide an interface to an IEEE 1149.1 TAP or any other suitable TAP which may be used for testing a system under test.
  • the primary processor 1310 and secondary processor 1320 cooperate to perform testing of at least a portion of a system under test.
  • the primary processor 1310 executes test instructions for testing a system under test.
  • the test instructions may be test instructions of a TISA (where test processor architecture 1300 utilizes a TISA) or test instructions not associated with a TISA (where test processor architecture 1300 does not utilize a TISA).
  • the primary processor 1310 detects instructions related to control of the TAP of the system under test (e.g., such as instructions for loading input data to a TAP controller of the system under test, instructions for reading output data from a TAP controller of the system under test, and like instructions, as well as various combinations thereof).
  • the primary processor 1310 provides the TAP-related instructions to secondary processor 1320 .
  • the secondary processor 1320 receives the TAP-related instructions from primary processor 1310 .
  • the secondary processor 1320 executes the TAP-related instructions.
  • the primary processor 1310 continues executing test instructions while secondary processor 1320 executes the TAP-related instructions received from primary processor 1310 .
  • primary processor 1310 may perform a context switch and continue operating while secondary processor 1320 controls scan operations via the TAP of the system under test.
  • This is difficult using a single-processor approach, because while the single processor is controlling the TAP, the single processor is prevented from performing other operations. Therefore, the use of multiple processors, as in the test processor architecture 1300 , provides a significant improvement in testing efficiency without a need to use high-end processors, especially considering that operations over the TAP typically take a long time compared to the time required for a processor to perform a single operation.
  • the cooperation between primary processor 1310 and secondary processor 1320 to perform testing of at least a portion of a system under test is facilitated by communication path 1330 .
  • the communication path 1330 may be implemented using any suitable means of communication between primary processor 1310 and secondary processor 1320 , which may depend on the type of multi-processor architecture with which the test processor architecture 1300 is implemented.
  • communication path 1330 may include one or more of a main processor interface bus, an auxiliary processor interface, a communication interface (e.g., such as a serializer-deserializer (SERDES) interface or other suitable communication interface), and the like, as well as various combinations thereof.
  • SERDES serializer-deserializer
  • test processor architecture 1300 will include memory (e.g., random access memory, persistent memory, cache memory, and the like, as well as various combinations thereof).
  • the memory of test processor architecture 1300 may include one or more of memory shared by primary processor 1310 and secondary processor 1320 , memory dedicated to primary processor 1310 , memory dedicated to secondary processor 1320 , and the like, as well as various combinations thereof.
  • test processor architecture 1300 may include various other support circuits, such as buses, I/O circuits, and the like, as well as various combinations thereof.
  • test processor architecture 1300 of FIG. 13 may be implemented in a number of ways.
  • the test processor architecture may use a test co-processor unit architecture in which a central processor unit (CPU) cooperates with a test co-processor unit (TCPU) in order to support system testing.
  • CPU central processor unit
  • TCPU test co-processor unit
  • An exemplary embodiment is depicted and described with respect to FIG. 14 .
  • the test processor architecture may use a test adjunct processor unit architecture in which a central processor unit (CPU) cooperates with a test adjunct processor unit (TAPU) in order to support system testing.
  • CPU central processor unit
  • TAPU test adjunct processor unit
  • FIG. 14 depicts an exemplary embodiment of a test co-processor architecture.
  • the test co-processor architecture 1400 is suitable for use as a TISA processor architecture for supporting system testing using a TISA.
  • the test co-processor architecture 1400 also is suitable for use as a test processor architecture for supporting system testing that does not employ a TISA.
  • the test co-processor architecture 1400 includes a central processor unit (CPU) 1410 , a test co-processor unit (TCPU) 1420 , a main memory 1430 , and a flash memory 1440 .
  • CPU central processor unit
  • TCPU test co-processor unit
  • main memory main memory
  • flash memory main memory
  • the test co-processor architecture 1400 includes a main processor interface bus 1451 .
  • the CPU 1410 , TCPU 1420 , main memory 1430 , and flash memory 1440 each are coupled to (or otherwise configured to be able to communicate with) the main processor interface bus 1451 .
  • the test co-processor architecture 1400 also may include an auxiliary processor interface 1452 which directly couples CPU 1410 and TCPU 1420 , thereby enabling direct communications between CPU 1410 and TCPU 1420 .
  • the CPU 1410 may be any CPU suitable for performing system testing of a system under test.
  • the CPU 1410 supports testing capabilities supported by primary processor 1310 depicted and described with respect to FIG. 13 .
  • the TCPU 1420 may be any CPU suitable for facilitating system testing of a system under test.
  • the TCPU 1420 supports a Test Access Port (TAP) interface 1460 , which may interface with any suitable TAP (e.g., such as an IEEE 1149.1 TAP or any other suitable TAP used for testing a system under test).
  • TAP Test Access Port
  • the TCPU 1420 supports testing capabilities supported by secondary processor 1320 depicted and described with respect to FIG. 13 .
  • the CPU 1410 and TCPU 1420 cooperate to perform testing of at least a portion of a system under test in a manner similar to primary processor 1310 and secondary processor 1320 depicted and described with respect to FIG. 13 .
  • the CPU 1410 and TCPU 1420 utilize instruction exception handling in order to enable CPU 1410 to continue operating to process test instructions while TCPU 1420 executes TAP-related instructions for controlling the TAP of the system under test during testing.
  • the CPU 1410 executes test instructions for testing a system under test.
  • the CPU 1410 detects instruction exceptions (i.e., instructions related to control of the TAP of the system under test) and provides the instruction exceptions to TCPU 1420 .
  • the TCPU 1420 receives the instruction exceptions from CPU 1410 and processes the instruction exceptions such that the TCPU 1420 may handle the instruction exceptions while CPU 1410 continues to operate to perform other tasks (e.g., executing other testing instructions).
  • CPU 1410 and TCPU 1420 cooperate during system testing such that CPU 1410 may switch context and continue to operate to perform other tasks while TCPU 1420 handles instruction exceptions detected by CPU 1410 , thereby improving system testing efficiency.
  • the CPU 1410 includes a cache 1411 , e.g., for improving the performance of CPU 1410 .
  • the TCPU 1420 includes a direct memory access (DMA) unit 1421 , which may be any type of DMA unit suitable for use in support system testing.
  • DMA unit 1421 is a scatter/gather (S/G) DMA unit.
  • the TCPU 1420 may utilize DMA unit 1421 for purposes of handling instruction exceptions received from CPU 1410 , and for efficiently accessing sensible data stored in memory.
  • CPU 1410 may configure S/G DMA tables prior to encountering an instruction exception.
  • the TCPU 1420 supports a set of specialized TCPU instructions.
  • the set of specialized TCPU instructions may support TAP access and control.
  • the set of specialized TCPU instructions may be used by TCPU 1420 to perform specific TAP operations on the TAP State Machine.
  • the CPU 1410 and TCPU 1420 utilize main memory 1430 and/or flash memory 1440 for performing various testing functions, such as execution of test instructions by CPU 1410 , instruction exception handling by TCPU 1420 , execution of TCPU instruction by TCPU 1420 , and the like, as well as various combinations thereof.
  • the main memory 1430 may be any suitable processor memory.
  • the flash memory 1440 may be any suitable flash memory or any other suitable form of persistent memory.
  • the CPU 1410 and TCPU 1420 share the memory with arbitrated access.
  • the CPU 1410 and TCPU 1420 also may share the memory for purposes of exchanging information. Although primarily depicted and described with respect to specific numbers and types of memory, it will be appreciated that various other memory schemes may be used for supporting the functions performed by CPU 1410 and TCPU 1420 .
  • the CPU 1410 and TCPU 1420 perform testing of the system under test using communication between CPU 1410 and TCPU 1420 and communication between CPU 1410 and/or TCPU 1420 and other components of test co-processor architecture 1400 (e.g., main memory 1430 , flash memory 1440 , and other components), and the like, as well as various combinations thereof.
  • the communications may be supported using one or both of the main processor interface bus 1441 and the auxiliary processor interface 1452 .
  • the communications between CPU 1410 and TCPU 1420 may include communications associated with instruction exception notification, interrupt access, DMA arbitration, and the like, as well as various combinations thereof.
  • the communications between CPU 1410 and TCPU 1420 and other components of the test co-processor architecture 1400 may include communications associated with reading from memory, writing to memory, and/or any other tasks which may be performed in support of testing the system under test.
  • FIG. 15 depicts an exemplary embodiment of a test adjunct processor architecture.
  • the test adjunct processor architecture 1500 is suitable for use as a TISA processor architecture for supporting system testing using a TISA.
  • the test adjunct processor architecture 1500 also is suitable for use as a test processor architecture for supporting system testing that does not employ a TISA.
  • the test adjunct processor architecture 1500 includes a central processor unit (CPU) 1510 and a test adjunct processor unit (TAPU) 1520 .
  • the CPU 1510 and TAPU 1520 may reside on the same board or may reside on different boards.
  • the CPU 1510 may be any CPU suitable for performing system testing of a system under test.
  • the CPU 1510 supports testing capabilities supported by primary processor 1310 depicted and described with respect to FIG. 13 .
  • the CPU 1510 has a main memory 1530 M , a flash memory 1530 F , and an input/output module 1540 associated therewith.
  • the CPU 1510 has a main processor interface bus 1550 associated therewith.
  • the CPU 1510 , main memory 1530 M , flash memory 1530 F , and input/output module 1540 each are coupled to (or otherwise configured to be able to communicate with) the main processor interface bus 1550 .
  • the CPU 1510 includes a cache 1511 , e.g., for improving the performance of CPU 1510 .
  • the TAPU 1520 may be any CPU suitable for facilitating system testing of a system under test.
  • the TAPU 1520 includes an input/output module 1521 .
  • the TAPU 1520 supports a Test Access Port (TAP) interface 1590 , which may interface with any suitable TAP (e.g., such as an IEEE 1149.1 TAP or any other suitable TAP used for testing a system under test).
  • TAP Test Access Port
  • the TAPU 1520 supports testing capabilities supported by secondary processor 1320 depicted and described with respect to FIG. 13 .
  • the TAPU 1520 has a local test memory 1560 associated therewith.
  • the TAPU 1520 has an internal interface bus 1570 associated therewith.
  • the TAPU 1520 and local test memory 1560 each are coupled to (or otherwise configured to be able to communicate with) the internal interface bus 1570 .
  • the input/output module 1540 associated with CPU 1510 and the input/output module 1521 of TAPU 1520 support a communication interface 1580 enabling communications between CPU 1510 and TAPU 1520 .
  • the communication interface 1580 supports streaming of TAP-related commands from CPU 1510 to TAPU 1520 .
  • the input/output module 1540 associated with CPU 1510 and the input/output module 1521 of TAPU 1520 support Serializer-Deserializer (SERDES) communications capabilities and, therefore, the communications interface 1580 is a SERDES-based communications interface.
  • the SERDES-based communications interface 1580 may be implemented using any suitable SERDES communications protocol (e.g., such as Gigabit Ethernet (GigE), Serial Rapid IO (SRIO), Peripheral Component Interconnect Express (PCIe), and the like).
  • GigE Gigabit Ethernet
  • SRIO Serial Rapid IO
  • PCIe Peripheral Component Interconnect Express
  • the CPU 1510 and TAPU 1520 cooperate to perform testing of at least a portion of a system under test in a manner similar to primary processor 1310 and secondary processor 1320 depicted and described with respect to FIG. 13 .
  • the CPU 1510 and TAPU 1520 utilize command streaming via the communication interface 1580 in order to enable CPU 1510 to continue operating to process test instructions while TAPU 1520 executes TAP-related instructions for controlling the TAP of the system under test during testing.
  • the CPU 1510 executes test instructions for testing a system under test.
  • the CPU 1510 detects instructions related to control of the TAP of the system under test.
  • the CPU 1510 propagates the TAP-related instructions to the TAPU 1520 via the communication interface 1580 (i.e., from CPU 1510 to input/output module 1540 via the main processor interface bus 1550 , for propagation via communication interface 1580 ).
  • the TAPU 1520 receives the TAP-related instructions from CPU 1510 and processes the TAP-related instructions such that the TAPU 1520 may handle control of the TAP while CPU 1510 continues to operate to perform other tasks (e.g., executing other testing instructions).
  • CPU 1510 and TAPU 1520 cooperate during system testing such that CPU 1510 may switch context and continue to operate to perform other tasks while TAPU 1520 handles TAP-related instructions detected by CPU 1510 , thereby improving system testing efficiency.
  • the TAP-related instructions detected by CPU 1510 and processed by TAPU 1520 are packetized by the CPU 1510 for propagation to TAPU 1520 .
  • the TAP-related instructions detected by CPU 1510 and processed by TAPU 1520 include opcodes supported by TAPU 1520 .
  • the TAP-related instructions also may include one or more extension commands adapted for use in performing block memory copies between memory associated with the CPU 1510 and memory associated with the TAPU 1520 (e.g., between main memory 1530 M and local test memory 1560 ).
  • the CPU 1510 utilizes main memory 1530 M and/or flash memory 1530 F for performing various testing functions, such as execution of test instructions, detection of TAP-related instructions, packetization of TAP-related instructions, and the like, as well as various combinations thereof.
  • the main memory 1530 M may be any suitable processor memory.
  • the flash memory 1530 F may be any suitable flash memory or any other suitable persistent memory.
  • the TAPU 1520 utilizes local test memory 1560 for performing various testing functions, such as storage of TAP-related instructions received from CPU 1510 , processing of TAP-related instructions received from CPU 1510 , and the like, as well as various combinations thereof.
  • the local test memory 1560 may be any suitable processor memory.
  • the local test memory 1560 may be relatively small since it handles processing of scan chain segments of the scan chain of the system under test, rather than the entire scan chain (as may be required in an on-chip memory).
  • the TISA may be implemented using any suitable processor architecture, which may include processor architectures other than the co-processor architecture or the adjunct processor architecture.
  • the TISA processor architecture may be implemented using multiple processors in various other ways, at least some of which may include use of more than two processors for supporting the TISA.
  • co-processor architecture or the adjunct processor architecture in order to implement the TISA architecture
  • the co-processor architecture and the adjunct processor architecture each may be used to implement other types of testing architectures (i.e., other testing architectures that do not employ TISA).
  • test co-processor architecture and the test adjunct processor architecture are functionally similar in that each enables a TISA to be executed by two communicating processors.
  • choice between the two architecture may be made by the designer on the basis of implementation-dependent parameters, such as available resources, costs, performances, physical constraints (integration in the same chip, in different chips and/or boards or any combination thereof), as well as any other implementation parameter.
  • TISA processor architectures depicted and described herein may employ any suitable TISA for use in performing system testing.
  • TISA A description of one exemplary embodiment of a TISA adapted for use with the TISA processor architectures follows.
  • This exemplary embodiment of a TISA is an implementation of Scan Segment Level primitives depicted and described herein.
  • Scan Segment Level abstraction level the overall scan chain of the system-under-test is divided into segments, which are then used as the data atom of the algorithm. It will be appreciated that the system-under-test may be partitioned into the scan segments by the algorithm developer, which may be a human and/or an automated tool.
  • the algorithm developer which may be a human and/or an automated tool.
  • TISA proposes a set of registers and instructions able to define and handle those scan segments.
  • the following embodiment is based on a 32-bit sized TISA, but it could be adapted to any other word size (e.g., 16-bit, 64-bit, or any other suitable word size).
  • FIG. 16 depicts an exemplary register set that can be used by a TISA processor.
  • the exemplary TISA includes the four register sets (denoted as register sets R 1 through R 4 ), which are depicted in FIGS. 16A-16D , respectively.
  • the first register set R 1 includes the following User Accessible Data Registers:
  • the second register set R 2 includes the following Internal Scratch Registers:
  • the third register set R 3 includes the following Scatter/Gather Segment Descriptions registers:
  • the fourth register set R 4 includes the following MultiBlock Scatter/Gather Segment Descriptions registers:
  • each of the exemplary register sets may be modified to include fewer, more, and/or different registers.
  • the exemplary registers may be regrouped into fewer, more, and/or different sets.
  • fewer, more, and/or different register sets may be used.
  • the exemplary TISA register sets may be replaced with any other TISA register set(s) suitable for use with TISA instructions sets to implement a TISA processor architecture.
  • the exemplary TISA may employ any suitable TISA instruction set (i.e., command dictionary) for use in performing system testing.
  • TISA instruction set i.e., command dictionary
  • the exemplary TISA instruction set includes the following opcodes, which may be utilized to manipulate register sets R 1 through R depicted and described with respect to FIGS. 16A-16D , as well as the original ISA register sets depicted and described herein:
  • the exemplary TISA instruction set includes the following register modification instructions that use explicit values:
  • CopyRegister ⁇ source register>, ⁇ destination register>
  • the exemplary TISA instruction set includes the following register modification instruction that use implicit values:
  • the exemplary TISA instruction set includes the following register preservation instructions:
  • the exemplary TISA instruction set includes the following logical operations on registers:
  • the exemplary TISA instruction set includes the following miscellaneous operation on registers:
  • the exemplary TISA instruction set includes the following values for scan state:
  • TISA implementations may be used with the TISA processor architectures depicted and described herein.
  • other TISA implementations may use fewer, more, and/or different registers, may use fewer, more, and/or different instruction sets, and the like, as well as various combinations thereof.
  • other TISA implementations may be utilized where different processor architectures are used, in order to provide TISA implementations better-suited to specific applications, and/or for any other suitable reasons.
  • TISA in a JTAG architecture enables scan operations to be performed at the Scan Segments Level, which allows the definition of independently controllable “scan segments” inside the overall scan path, thereby providing a flexible and powerful set of primitives that can be used to define scan operations directly in the problem space and resolve the scan operations at implementation time.
  • JTAG operations are based on the scan operation in which all bits are scanned in serially one-by-one while at the same time bits are being scanned out serially one-by-one.
  • TGTs typically provide this capability for traditional structural testing by computing the required vectors from a system model obtained through description languages such as BSDL. Additionally, formats like SVF and STAPL mirror this, as they allow the user to manipulate those vectors. While testing in this manner is sufficient for structural (and other types) of testing, testing in this manner is highly inefficient for interactive setups in which there is no real need to access the whole scan chain. The inefficiency may be seen by considering an example.
  • the fact that a majority of the scan bits are useless is not important, as scan efficiency is not one of the goals (rather, in this example, the goal is primarily to be able to efficiently access one particular entity of the scan chain).
  • This type of approach is a problem at least for the following reasons: (a) there is the computational need of handling long vectors (e.g., lots of memory transfers have a high impact on performances); (b) there is a need to store the entire vector(s) in memory (which may be a problem for long chains); (c) memory storage is not limited to data inputs and data outputs, but also includes expected data, input and output mask, and the like (thereby multiplying memory requirements which are already potentially strained just from the input and output data); and (d) the transformation from instrument-vector-instrument must be made each time (which demands computational power and time).
  • the Scan Segments Level abstraction level is a powerful tool for providing efficient access to individual entities, or groups of entities, of the scan chain of a system under test, without any special emphasis on scan efficiency (even if, of course, still enabling it if needed).
  • Scan Segments Level abstraction is implemented by decomposing a scan chain into a succession of segments and defining one or more scan operations on each of the segments.
  • the scan chain is composed of a plurality of elements, and each segment includes at least one of the elements of the scan chain.
  • the elements may be defined at many levels of the system under test (e.g., elements may be devices, instruments, registers, segments of a register, and the like, as well as various combinations thereof), and, thus, that the segments into which the scan chain is decomposed may be defined at many levels of the system under test (e.g., segments may include one or more devices, a portion of a device(s), one or more instruments, a portion of an instrument(s), one or more registers, a portion of a register(s), one or more register segments, and the like, as well as various combinations thereof).
  • a segment may represent the smallest control unit of the scan chain.
  • decomposition of a scan chain into segments may be hierarchical.
  • the scan chain may be decomposed into segments, at least some of which may be composed by sub-segments, at least some of which may be composed by sub-segments, and so forth.
  • the hierarchical decomposition of the scan chain may be viewed as having a tree-based structure in which a segment may be composed of other segments.
  • the segments at the leaves of the tree may be referred to as segments (in that they represent the smallest control unit of the scan chain), which the segments located above the leaves of the tree may be referred to as super-segments.
  • one or more of the segments of the scan chain may be composed of virtual sub-segments which are controllable, but only in a manner that is transparent to the user/system).
  • the hierarchical decomposition of a scan chain may be defined in any other suitable manner.
  • segmentation enables definition of entities for types of segments and/or types of segment combinations.
  • An entity is a generic description of a type of target, which is valid for and may be reused for each physical instance of that type of target.
  • an entity may define a description of a device, a group of devices, a portion of a device, an instrument, a group of instruments, a portion of an instrument, and the like, as well as various combinations thereof.
  • a scan chain may be decomposed such that segments of the scan chain include specific elements or combinations of elements, entities may be defined for respective segments and/or respective combinations of segments, of a scan chain.
  • an entity may be defined for that type of segment (i.e., each segment including that type of instrument), such that the entity may be reused for each physical instance of that type of segment in the scan chain.
  • an entity may be defined for that type of segment (i.e., each segment including that type combination of instruments), such that the entity may be reused for each physical instance of that type of segment in the scan chain.
  • segmentation allows an entity (i.e., a description of a type of segment under control) to be correlated with a physical protocol that is used to communicate with the entity.
  • description languages e.g., such as NSDL, P1687 IJTAG PDL, and the like
  • connectivity description portion e.g., the structure of the NSDL or the IJTAG HDL
  • TISA provides a reusable modularity that can be defined once for all occurrences of a particular entity type, as the TISA instructions are segment-based operations rather than model-based operations. Thus, since TISA is both modular and autonomous for the entity under test in a particular segment, TISA provides significant advantages over existing architectures.
  • TISA enables a direct mapping of the Test Data Register definition into a reusable and portable module that may be plugged into the execution flow at any point in the scan process, in any order that is necessary, without needing to define the entire connectivity as a static model up front as existing tools require.
  • TISA enables integration of the port/signal interfaces that are non-scan with the scan operations as a single solution space architecture based on a unified control flow and standard computer science techniques (providing significant advantages over solutions in which native language constructs are used to provide access to non-scan operations).
  • TISA enables reuse of instruction sequences for multiple instances of the same entity, thereby enabling a reduction in code storage requirements in the system.
  • a generalized function which maps to description language functions which are called by a managing program, may be written.
  • each of the functions are methods of native language objects that represent the entity, and there may be separate instances of these objects for each entity defined in the system, but there could be a single copy of code used to communicate with each of these instances.
  • the native language implementation models directly control the description language used to specify the connectivity and functionality of the circuit.
  • Scan Segments Level abstraction would enable definition of three segments as follows: segment S 1 including instruments 1 through 75 , segment S 2 including the instrument 76 , and segment S 3 including instruments 77 through 100 .
  • access to instrument 76 is greatly simplified.
  • access to instrument 76 could be obtained by making a “dummy shift” (e.g., ScanBlockZero) for segment S 3 , executing the instruction(s) for segment S 2 (i.e., instrument 76 ), making another dummy shift for segment S 1 , and then terminating with an update.
  • a “dummy shift” e.g., ScanBlockZero
  • segment S 2 i.e., to a specific instrument in the scan chain
  • segment S 3 apart from their length
  • FIG. 17 depicts a high-level block diagram of a system under test, illustrating an exemplary decomposition of an exemplary scan chain of the system under test.
  • the exemplary SUT 1700 includes four devices 1710 1 - 1710 4 (collectively, devices 1710 ; and denoted in FIG. 17 as Device 1 , Device 2 , Device 3 , and Device 4 , respectively).
  • the devices 1710 are arranged serially within SUT 1700 to form a scan chain 1720 .
  • the scan chain 1720 is as follows: the TDI of the TAP is connected to the input port of device 1710 4 , the output port of device 1710 4 is connected to the input port of device 1710 3 , the output port of device 1710 3 is connected to the input port of device 1710 2 , the output port of device 1710 2 is connected to the input port of device 1710 1 , and the output port of device 1710 1 is connected to the TDO of the TAP.
  • each of the devices 1710 includes (1) an input de-multiplexer providing inputs to a test instruction register (TIR) and a test data register (TDR), and (2) an output multiplexer for collecting outputs from the TIR and the TDR.
  • the TIR and TDR of each device 1710 are parallel registers.
  • the device 1710 3 includes one additional TDR, such that the input de-multiplexer provides inputs to one TIR and two TDRs and collects outputs from the one TIR and the two TDRs, where the one TIR and two TDRs are all in parallel.
  • the TIRs and TDRs each are depicted as serial shift registers, each including nine associated elements (e.g., flip-flops ).
  • the TIRs form one scan chain (denoted as an test instruction scan chain) that includes thirty-six serial elements and (b) the TDRs form another scan chain (denoted as a test data scan chain) that includes forty-five total elements and thirty-six serial elements (i.e., because the two TDRs of device 1710 3 are in parallel).
  • the test instruction scan chain has been decomposed into four segments follows: a first segment SI 4 which includes the nine elements of the TIR of device 1710 4 , a second segment SI 3 which includes the nine elements of the TIR of device 1710 3 , a third segment SI 2 which includes the nine elements of the TIR of device 1710 2 , and a fourth segment SI 1 which includes the nine elements of the TIR of device 1710 1 .
  • the testing system may access any of the TIRs of SUT 1700 , individually or in combination, with minimal knowledge of the other TIRs of SUT 1700 (other than the number of elements of which they are composed).
  • the test data scan chain has been decomposed into six serial segments (seven total segments) as follows: a first segment SD 4 that includes the nine elements of the TDR of device 1710 4 ; a second segment SD 3 that includes the nine elements of the TDR of device 1710 3 ; a third segment SD 2 that includes either the nine elements of the first TDR of device 1710 2 (denoted as sub-segment SD 2 . 1 ) or the nine elements of the second TDR of device 1710 2 (denoted as sub-segment SD 2 .
  • a fourth segment which is further decomposed into three serial sub-segments as follows: a first sub-segment that includes the first three elements of the TDR of device 1710 1 (denoted as sub-segment SD 1 . 1 ), a second sub-segment that includes the next four elements of the TDR of device 1710 1 (denoted as sub-segment SD 1 . 2 ), and a third sub-segment that includes the last two elements of the TDR of device 1710 1 (denoted as sub-segment SD 1 . 3 ).
  • the testing system may access any of the TDRs of SUT 1700 (or even sub-portions of the TDR of device 1710 1 ), individually or in combination, with minimal knowledge of the other TDRs of SUT 1700 (other than the number of elements of which they are composed).
  • SUT 1700 of FIG. 17 is merely one example of the manner in which the scan chain(s) of a system under test may be decomposed for use in providing Scan Segments Level abstraction. Although depicted and described herein with respect to specific types, numbers, and arrangements of elements, components, and the like, it will be appreciated that a system under test for which a scan chain(s) is decomposed may be include various other types, numbers, and/or arrangements of elements, components, and the like.
  • decomposition of the scan chain of a system under test enables scan operations to be defined on the segments, thereby improving testing efficiency.
  • a method, according to one embodiment, for generating a set of instructions including scan operations for segments of a decomposed scan chain is depicted and described herein with respect to FIG. 18 .
  • each board includes a segment (denoted as segments A, B, and C associated with a first board, a second board, and a third board, respectively).
  • the segment A on the first board may be composed of a plurality of sub-segments (e.g., sub-segments A 1 through A n )
  • the segment B on the second board may be composed of a plurality of sub-segments (e.g., sub-segments B 1 through B n )
  • the segment C on the third board may be composed of a plurality of sub-segments (e.g., sub-segments C 1 through C n ).
  • a segment could be: one or more registers inside an instrument, an instrument, a cluster of registers, one or more boards, and the like, as well as various combinations thereof.
  • Scan Segments Level abstraction while not exclusively limited to, are especially effective in implementations in which the atomic test operations are treated like processor operations (e.g., such as in the various TISA implementations depicted and described herein, or in any other similar implementations in which atomic test operations are treated like processor operations).
  • Scan Segments Level scan operations may require that one or more technological constraints linked to JTAG be addressed. For example, constraints such as the need to define the state of the TAP machine and the risk of using the Pause-DR state (not always implemented), among others, may need to be addressed.
  • the scan chain may be treated as a first-in-first-out (FIFO) system (given its serial nature) such that the first segment that is scanned in is also the first segment that is scanned out (as it is closest to the end of the scan chain).
  • FIFO first-in-first-out
  • the TCK may be frozen between segment operations. As all elements inside the scan chain are synchronous, the effect of freezing TCK in this manner is that the scan chain is frozen together with TCK.
  • Scan Segments Level in a TISA-based testing system may be better understood by way of a few examples, In the examples that follow, assume that a system under test (SUT) is composed of three segments (denoted as A, B, and C, in that order), and that a user needs to write a value V inside of segment B.
  • SUT system under test
  • keeping the TAP Finite State Machine (FSM) in the ShiftDR state ensures that there is no update on the scan chain. This may be seen from the first example, in which keeping the TAP FSM in the ShiftDR state from step (i) to step (ix) ensures that there is no update on the scan chain, given that the UpdateDR State will be reached only once leaving ShiftDr.
  • FSM Finite State Machine
  • the scan clock TCK is active only during the scan operations (i.e., steps (iii), (vi), and (ix)), and is frozen in the remaining states.
  • the effect is that the SUT, from the point of view of the SUT based on operations synchronous with TCK, will see steps (iii), (vi), and (ix) as a continuous bitstream.
  • the “bypass sequence” is a property of the scan segment, and can be, for instance, a given sequence (all zeros, all ones, or any other suitable sequence), or “don't care”, where it is up to the TGT to decide such sequence.
  • compositions of the above two examples are possible, with any number of segments defined on one or more JTAG devices. It will be further appreciated that the above-two examples are merely examples provided for the purpose of illustrating use of the Scan Segments Level for testing a system under test, and, thus, that embodiments in which the Scan Segments Level is used for testing a system under test are not intended to be limited by these examples.
  • the actual sequence of TISA instructions can have multiple origins, including one or more of the following: (1) the TISA instructions may be statically computed by the TGT, in which case, each time the user wants to access a segment, the entire chain must be scanned (it will be appreciated that, while this solution is not optimized for scan time, it can be useful for embedded systems with limited computational resources and little or no time constraints); (2) the TISA instructions may be issued by a software scheduler, which receives access requests and composes them into scan operations; and/or (3) the TISA instructions may be issued by a hardware scheduler (e.g., such as, but not limited to, what is done for instruction reordering and bypass in some high-performance processors).
  • a hardware scheduler e.g., such as, but not limited to, what is done for instruction reordering and bypass in some high-performance processors.
  • TISA instructions associated with Scan Segments Level control may be issued in any other suitable way, which may include a combination of the methods described above and/or one or more other suitable methods which may be used in place of or in addition to one or more of the methods described above.
  • the Scan Segments Level abstraction level is a powerful tool for handling dynamic topologies, such as the ones proposed by the IEEE P1687 standard and other dynamic topologies. If a section of the scan chain can be taken in and out the active scan path (e.g., using an SIB cell proposed by the IEEE P1687 standard or any other suitable hierarchy-enabling component(s)), that section can be marked as one (or more) segments.
  • the testing scheduler then has knowledge, from the system state, as to whether or not this segment(s) is active, and, therefore, if the segment should be included in the TISA instruction scheduling. It will be appreciated by those skilled in the art and informed by the teachings herein that this principle also may be used for other dynamic elements, such as hot-swap boards (e.g., by detecting their presence from a status register) or any other suitable dynamic elements.
  • FIG. 18 depicts a high-level block diagram of one embodiment of a method for testing a portion of a system under test via a scan chain of the system under test using Scan Segments Level abstraction of the scan chain.
  • method 1800 may be performed contemporaneously, or in a different order than depicted and described with respect to FIG. 18 .
  • method 1800 begins.
  • the scan chain is decomposed into a plurality of segments.
  • the scan chain is composed of a plurality of elements, and each segment includes at least one of the elements of the scan chain.
  • the scan chain may be decomposed into segments in any suitable manner, as described hereinabove. As described herein, decomposition of the scan chain into segments may be applied anywhere in the development flow (e.g., by the test developer, by the test generation tool, by an embedded circuit model, and the like).
  • a set of instructions is generated.
  • the set of instructions includes processor instructions associated with an ISA and test instructions for testing the portion of the system under test.
  • the test instructions include, for each of the segments of the scan chain, at least one scan operation to be performed on the segment.
  • the test instructions may be any type of test instructions, such as conventional test instructions, test instructions of a TISA, and the like, and, thus, may be generated in any suitable manner.
  • the set of instructions may be generated in any suitable manner (e.g., in a manner the same as or similar to as depicted and described hereinabove respect to
  • the set of instructions is executed for testing the portion of the system under test.
  • the set of instructions may be executed in any suitable manner, which may depend on the type of instructions of the set of instructions.
  • step 1810 method 1800 ends.
  • Scan Segments Level Although primarily depicted and described herein with respect to embodiments in which embodiments of TISA are used to enable scan operations to be performed at the Scan Segments Level, it will be appreciated that one or more of the Scan Segments Level embodiments depicted and described herein also may be provided in environments using TISA-like instructions architectures, non-TISA instruction architectures and/or non-TISA testing environment implementations, and the like.
  • the TISA for purposes of describing the enhanced system testing capabilities enabled by exemplary embodiments of TISAs which may be formed and utilized as depicted and described herein, it will be appreciated that many different TISAs may be formed depending on various factors, such as one or more of the ISA of the processor for which the TISA is formed, characteristics of the SUT for which the TISA is formed, characteristics of the test algorithm the TISA is supposed to execute, and the like, as well as various combinations thereof. Thus, references made herein to “the TISA” also may be read more generally as “a TISA” in that many different types of TISAs may be formed.
  • FIG. 19 depicts a high-level block diagram of a computer suitable for use in performing the functions described herein.
  • computer 1900 includes a processor element 1902 (e.g., a central processing unit (CPU) or other suitable processor(s)), a memory 1904 (e.g., random access memory (RAM), read only memory (ROM), and/or any other suitable types of memory), system testing module/process 1905 adapted for performing system testing functions depicted and described herein, and various input/output devices 1906 (e.g., a user input device (such as a keyboard, a keypad, a mouse, and the like), a user output device (such as a display, a speaker, and the like), an input port, an output port, a receiver, a transmitter, and storage devices (e.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, and the like)).
  • processor element 1902 e.g., a central processing unit (CPU) or other suitable processor
  • system testing process 1905 can be loaded into memory 1904 and executed by processor 1902 to implement and/or support implementation of at least a portion of the system testing functions described hereinabove.
  • system testing process 1905 (including associated data structures) can be stored on a computer readable storage medium or carrier, e.g., RAM memory, magnetic or optical drive or diskette, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Tests Of Electronic Circuits (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
US12/495,336 2009-03-04 2009-06-30 Method and apparatus for system testing using scan chain decomposition Abandoned US20100229058A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US12/495,336 US20100229058A1 (en) 2009-03-04 2009-06-30 Method and apparatus for system testing using scan chain decomposition
US12/827,556 US8621301B2 (en) 2009-03-04 2010-06-30 Method and apparatus for virtual in-circuit emulation
US13/338,431 US8775884B2 (en) 2009-03-04 2011-12-28 Method and apparatus for position-based scheduling for JTAG systems
US13/338,581 US8719649B2 (en) 2009-03-04 2011-12-28 Method and apparatus for deferred scheduling for JTAG systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15741209P 2009-03-04 2009-03-04
US12/495,336 US20100229058A1 (en) 2009-03-04 2009-06-30 Method and apparatus for system testing using scan chain decomposition

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/495,295 Continuation-In-Part US8677198B2 (en) 2009-03-04 2009-06-30 Method and apparatus for system testing using multiple processors

Publications (1)

Publication Number Publication Date
US20100229058A1 true US20100229058A1 (en) 2010-09-09

Family

ID=42167394

Family Applications (3)

Application Number Title Priority Date Filing Date
US12/495,237 Active 2031-06-15 US8533545B2 (en) 2009-03-04 2009-06-30 Method and apparatus for system testing using multiple instruction types
US12/495,295 Expired - Fee Related US8677198B2 (en) 2009-03-04 2009-06-30 Method and apparatus for system testing using multiple processors
US12/495,336 Abandoned US20100229058A1 (en) 2009-03-04 2009-06-30 Method and apparatus for system testing using scan chain decomposition

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US12/495,237 Active 2031-06-15 US8533545B2 (en) 2009-03-04 2009-06-30 Method and apparatus for system testing using multiple instruction types
US12/495,295 Expired - Fee Related US8677198B2 (en) 2009-03-04 2009-06-30 Method and apparatus for system testing using multiple processors

Country Status (6)

Country Link
US (3) US8533545B2 (ko)
EP (3) EP2404184B1 (ko)
JP (4) JP5489249B2 (ko)
KR (5) KR101533170B1 (ko)
CN (3) CN102341718B (ko)
WO (3) WO2010102019A1 (ko)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110161039A1 (en) * 2009-12-29 2011-06-30 Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd Method and system of testing electronic device
US20110225456A1 (en) * 2010-03-10 2011-09-15 Texas Instruments Incorporated Commanded jtag test access port operations
US20110231720A1 (en) * 2010-03-19 2011-09-22 Qualcomm Incorporated Data recirculation in configured scan paths
US20120159273A1 (en) * 2010-12-15 2012-06-21 International Business Machines Corporation Dynamic Scan
US9183105B2 (en) 2013-02-04 2015-11-10 Alcatel Lucent Systems and methods for dynamic scan scheduling
CN105138364A (zh) * 2015-08-21 2015-12-09 广东欧珀移动通信有限公司 一种终端系统升级的方法及装置
US20230141802A1 (en) * 2021-11-08 2023-05-11 Shanghai Zhaoxin Semiconductor Co., Ltd. Method and interconnect interface for built-in self-test
US20230342271A1 (en) * 2017-03-10 2023-10-26 Pure Storage, Inc. Performance-Based Prioritization For Storage Systems Replicating A Dataset

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007135490A1 (en) * 2006-05-24 2007-11-29 Freescale Semiconductor, Inc. Method and system for storing data from a plurality of processors
US8719649B2 (en) * 2009-03-04 2014-05-06 Alcatel Lucent Method and apparatus for deferred scheduling for JTAG systems
US8533545B2 (en) * 2009-03-04 2013-09-10 Alcatel Lucent Method and apparatus for system testing using multiple instruction types
US8112669B2 (en) * 2009-08-31 2012-02-07 Comsonics, Inc. Wireless diagnostic system
US20110087861A1 (en) * 2009-10-12 2011-04-14 The Regents Of The University Of Michigan System for High-Efficiency Post-Silicon Verification of a Processor
US8352791B2 (en) * 2010-06-04 2013-01-08 GM Global Technology Operations LLC Configurable test suite
US8570077B2 (en) 2010-12-17 2013-10-29 Qualcomm Incorporated Methods and implementation of low-power power-on control circuits
US8423343B2 (en) * 2011-01-24 2013-04-16 National Tsing Hua University High-parallelism synchronization approach for multi-core instruction-set simulation
US8677324B2 (en) 2011-01-31 2014-03-18 Hewlett-Packard Development Company, L.P. Evaluating performance of an application using event-driven transactions
CN103458086B (zh) * 2012-06-04 2016-12-14 联想(北京)有限公司 一种智能手机及其故障检测方法
CN102799528B (zh) * 2012-07-12 2015-12-09 中国科学院声学研究所 一种用于电路板级测试的脚本调试方法、装置及其系统
US9121892B2 (en) * 2012-08-13 2015-09-01 Analog Devices Global Semiconductor circuit and methodology for in-system scan testing
TWI461907B (zh) * 2012-10-11 2014-11-21 Mstar Semiconductor Inc 配合多個應用程式之整合系統和測試系統
US9959186B2 (en) * 2012-11-19 2018-05-01 Teradyne, Inc. Debugging in a semiconductor device test environment
CN103092188B (zh) * 2012-12-28 2018-01-12 派芬自控（上海）股份有限公司 一种测试方法及系统
US9810729B2 (en) * 2013-02-28 2017-11-07 Advantest Corporation Tester with acceleration for packet building within a FPGA block
US9239360B2 (en) * 2014-01-28 2016-01-19 Texas Instruments Incorporated DFT approach to enable faster scan chain diagnosis
US11042929B2 (en) 2014-09-09 2021-06-22 Oracle Financial Services Software Limited Generating instruction sets implementing business rules designed to update business objects of financial applications
CN104749515B (zh) * 2015-03-31 2017-12-15 中国人民解放军国防科学技术大学 一种基于顺序等分分段式的低功耗扫描测试方法和装置
US9640280B1 (en) * 2015-11-02 2017-05-02 Cadence Design Systems, Inc. Power domain aware insertion methods and designs for testing and repairing memory
CN108475242B (zh) * 2015-12-24 2021-09-28 英特尔公司 冲突掩码生成
WO2017129242A1 (en) * 2016-01-27 2017-08-03 Advantest Corporation Deterministic concurrent test program executor for an automated test equipment
KR102675841B1 (ko) 2016-05-17 2024-06-18 삼성전자주식회사 바이너리 벡터 기반의 테스트 장치
CN109863413B (zh) * 2016-05-20 2022-03-25 默升科技集团有限公司 Serdes应用中基于扫描的测试设计
WO2018128699A1 (en) * 2016-11-08 2018-07-12 Xcerra Corporation Multi-node testing system and method
US10592370B2 (en) * 2017-04-28 2020-03-17 Advantest Corporation User control of automated test features with software application programming interface (API)
CN110658438B (zh) * 2018-06-29 2024-09-17 是德科技股份有限公司 扫描测试系统及其控制装置和控制方法
CN109408382A (zh) * 2018-10-11 2019-03-01 网宿科技股份有限公司 一种持续集成方法和持续集成系统
JP7058759B2 (ja) * 2019-01-22 2022-04-22 株式会社アドバンテスト １または複数の被テストデバイスをテストするための自動試験装置、１または複数の被テストデバイスの自動試験のための方法、および、コマンドエラーを処理するためのコンピュータプログラム
US11069420B2 (en) 2019-07-25 2021-07-20 Micron Technology, Inc. In-system test of a memory device
CN110634530B (zh) * 2019-09-10 2021-05-25 珠海博雅科技有限公司 芯片的测试系统和测试方法
CN111176961B (zh) * 2019-12-05 2022-03-29 腾讯科技（深圳）有限公司 一种应用程序测试方法、装置及存储介质
CN111209210A (zh) * 2020-01-15 2020-05-29 北京明略软件系统有限公司 一种生成测试用例方法、装置、电子设备及存储介质
US11243252B1 (en) 2020-08-17 2022-02-08 Cisco Technology, Inc. Processor to JTAG test data register interface
CN112100954B (zh) * 2020-08-31 2024-07-09 北京百度网讯科技有限公司 验证芯片的方法、装置和计算机存储介质
CN113342583B (zh) * 2021-06-08 2022-11-29 海光信息技术股份有限公司 芯片验证系统、方法、装置、设备和存储介质
CN113358070B (zh) * 2021-07-07 2023-03-28 苏州鑫睿益荣信息技术有限公司 一种汽车刹车片平整度及销钉高度检测系统及其检测方法
CN113552473B (zh) * 2021-09-22 2021-12-28 北京紫光青藤微系统有限公司 用于芯片测试的系统和待测芯片装置
CN114416450B (zh) * 2022-01-18 2022-09-27 深圳市百泰实业股份有限公司 一种pcba生产测试管理方法
WO2024186533A1 (en) * 2023-03-08 2024-09-12 Qorvo Us, Inc. Scan test in a single-wire bus circuit

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5694399A (en) * 1996-04-10 1997-12-02 Xilinix, Inc. Processing unit for generating signals for communication with a test access port
US6061709A (en) * 1998-07-31 2000-05-09 Integrated Systems Design Center, Inc. Integrated hardware and software task control executive
US6195774B1 (en) * 1998-08-13 2001-02-27 Xilinx, Inc. Boundary-scan method using object-oriented programming language
US20020124216A1 (en) * 2000-12-22 2002-09-05 Conrado Blasco Allue Integrated circuit and method of operation of such a circuit
US6453456B1 (en) * 2000-03-22 2002-09-17 Xilinx, Inc. System and method for interactive implementation and testing of logic cores on a programmable logic device
US20030163773A1 (en) * 2002-02-26 2003-08-28 O'brien James J. Multi-core controller
US20040059437A1 (en) * 2002-05-08 2004-03-25 Conduct Prosecution Tester system having multiple instruction memories
US6832359B2 (en) * 2002-08-02 2004-12-14 Fujitsu Limited Apparatus and method for calculating simulation coverage
US20050166092A1 (en) * 1999-02-19 2005-07-28 Swoboda Gary L. Emulation system with peripherals recording emulation frame when stop generated
US6957371B2 (en) * 2001-12-04 2005-10-18 Intellitech Corporation Method and apparatus for embedded built-in self-test (BIST) of electronic circuits and systems
US7073110B1 (en) * 2002-04-26 2006-07-04 Xilinx, Inc. Method and system for programmable boundary-scan instruction register
US7089404B1 (en) * 1999-06-14 2006-08-08 Transmeta Corporation Method and apparatus for enhancing scheduling in an advanced microprocessor
US20060236176A1 (en) * 2005-03-31 2006-10-19 Alyamani Ahmad A Segmented addressable scan architecture and method for implementing scan-based testing of integrated circuits
US7139950B2 (en) * 2004-01-28 2006-11-21 International Business Machines Corporation Segmented scan chains with dynamic reconfigurations
US7149943B2 (en) * 2004-01-12 2006-12-12 Lucent Technologies Inc. System for flexible embedded Boundary Scan testing
US7234092B2 (en) * 2002-06-11 2007-06-19 On-Chip Technologies, Inc. Variable clocked scan test circuitry and method
US20080281547A1 (en) * 2007-05-11 2008-11-13 Nec Electronics Corporation Test circuit
US7539915B1 (en) * 2003-01-07 2009-05-26 Marvell Israel (Misl) Ltd. Integrated circuit testing using segmented scan chains
US8418008B2 (en) * 2008-12-18 2013-04-09 Lsi Corporation Test technique to apply a variable scan clock including a scan clock modifier on an integrated circuit

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08233904A (ja) * 1995-02-27 1996-09-13 Nec Eng Ltd バウンダリスキャン回路
JPH0926807A (ja) * 1995-07-12 1997-01-28 Keyence Corp プログラマブルコントローラ
US5838568A (en) * 1996-06-28 1998-11-17 International Business Machines Corporation Heated circuit assembly tester and method
US5828579A (en) * 1996-08-28 1998-10-27 Synopsys, Inc. Scan segment processing within hierarchical scan architecture for design for test applications
US5949692A (en) 1996-08-28 1999-09-07 Synopsys, Inc. Hierarchical scan architecture for design for test applications
JP3385210B2 (ja) 1998-03-31 2003-03-10 富士通株式会社 テストデータスキャン装置およびスキャン方法
US6370664B1 (en) * 1998-10-29 2002-04-09 Agere Systems Guardian Corp. Method and apparatus for partitioning long scan chains in scan based BIST architecture
JP2001201543A (ja) * 2000-01-18 2001-07-27 Rooran:Kk スキャン・パス構築用プログラムを記録した記録媒体とスキャン・パスの構築方法及びこのスキャン・パスを組み込んだ演算処理システム
US6640322B1 (en) * 2000-03-22 2003-10-28 Sun Microsystems, Inc. Integrated circuit having distributed control and status registers and associated signal routing means
JP3751531B2 (ja) * 2001-03-16 2006-03-01 沖電気工業株式会社 Ｊｔａｇインターフェース回路及びそれを用いたｊｔａｇ対応半導体装置のテスト方法とデバッグ方法
WO2003034202A2 (en) * 2001-10-17 2003-04-24 Koninklijke Philips Electronics N.V. On the fly configuration of electronic device with attachable sub-modules
US7047462B2 (en) * 2002-01-04 2006-05-16 Hewlett-Packard Development Company, Lp. Method and apparatus for providing JTAG functionality in a remote server management controller
JP2003228999A (ja) * 2002-02-01 2003-08-15 Rohm Co Ltd 半導体記憶装置
US6832539B2 (en) * 2002-07-15 2004-12-21 Delaware Capital Formation, Inc. Cylinder lock
EP1576739A4 (en) * 2002-10-01 2006-11-08 Christopher Frank Mcconnell SYSTEM AND METHOD FOR WIRELESS AUDIO COMMUNICATION WITH A COMPUTER
US20040078179A1 (en) * 2002-10-17 2004-04-22 Renesas Technology Corp. Logic verification system
JP2004280588A (ja) 2003-03-17 2004-10-07 Cats Kk システムｌｓｉ設計支援装置およびシステムｌｓｉ設計支援プログラム
US7406699B2 (en) * 2003-04-02 2008-07-29 Microsoft Corporation Enhanced runtime hosting
US7305586B2 (en) * 2003-04-25 2007-12-04 International Business Machines Corporation Accessing and manipulating microprocessor state
US7080789B2 (en) * 2003-05-09 2006-07-25 Stmicroelectronics, Inc. Smart card including a JTAG test controller and related methods
US7346821B2 (en) * 2003-08-28 2008-03-18 Texas Instrument Incorporated IC with JTAG port, linking module, and off-chip TAP interface
KR100880832B1 (ko) 2004-02-10 2009-01-30 삼성전자주식회사 코-디버깅 기능을 지원하는 반도체 집적회로 및 반도체집적회로 테스트 시스템
GB2411331A (en) 2004-02-19 2005-08-24 Trigenix Ltd Rendering user interface using actor attributes
US7334060B2 (en) * 2004-03-19 2008-02-19 International Business Machines Corporation System and method for increasing the speed of serially inputting data into a JTAG-compliant device
US7143324B2 (en) * 2004-11-04 2006-11-28 Avago Technologies General Ip (Singapore) Pte. Ltd. System and method for automatic masking of compressed scan chains with unbalanced lengths
JP2006146757A (ja) 2004-11-24 2006-06-08 Toshiba Corp デバッグ用レジスタおよびデータ転送方法
US7383478B1 (en) * 2005-07-20 2008-06-03 Xilinx, Inc. Wireless dynamic boundary-scan topologies for field
US7844721B2 (en) 2005-11-23 2010-11-30 Qualcomm Incorporated Method for delivery of software upgrade notification to devices in communication systems
JP2007147352A (ja) * 2005-11-25 2007-06-14 Sony Corp 無線インターフェースモジュール及び電子機器
JP2008165534A (ja) * 2006-12-28 2008-07-17 Oki Electric Ind Co Ltd 半導体装置
JP4805134B2 (ja) * 2006-12-28 2011-11-02 富士通株式会社 集積回路の内部ラッチをスキャンする方法及び装置並びに集積回路
US8533545B2 (en) * 2009-03-04 2013-09-10 Alcatel Lucent Method and apparatus for system testing using multiple instruction types
US8621301B2 (en) * 2009-03-04 2013-12-31 Alcatel Lucent Method and apparatus for virtual in-circuit emulation
US8055948B2 (en) * 2009-09-14 2011-11-08 International Business Machines Corporation Resilient software-controlled redundant array of independent disks (RAID)

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5694399A (en) * 1996-04-10 1997-12-02 Xilinix, Inc. Processing unit for generating signals for communication with a test access port
US6061709A (en) * 1998-07-31 2000-05-09 Integrated Systems Design Center, Inc. Integrated hardware and software task control executive
US6195774B1 (en) * 1998-08-13 2001-02-27 Xilinx, Inc. Boundary-scan method using object-oriented programming language
US20050166092A1 (en) * 1999-02-19 2005-07-28 Swoboda Gary L. Emulation system with peripherals recording emulation frame when stop generated
US7089404B1 (en) * 1999-06-14 2006-08-08 Transmeta Corporation Method and apparatus for enhancing scheduling in an advanced microprocessor
US6453456B1 (en) * 2000-03-22 2002-09-17 Xilinx, Inc. System and method for interactive implementation and testing of logic cores on a programmable logic device
US20020124216A1 (en) * 2000-12-22 2002-09-05 Conrado Blasco Allue Integrated circuit and method of operation of such a circuit
US7467342B2 (en) * 2001-12-04 2008-12-16 Intellitech Corporation Method and apparatus for embedded built-in self-test (BIST) of electronic circuits and systems
US6957371B2 (en) * 2001-12-04 2005-10-18 Intellitech Corporation Method and apparatus for embedded built-in self-test (BIST) of electronic circuits and systems
US20030163773A1 (en) * 2002-02-26 2003-08-28 O'brien James J. Multi-core controller
US7073110B1 (en) * 2002-04-26 2006-07-04 Xilinx, Inc. Method and system for programmable boundary-scan instruction register
US20040059437A1 (en) * 2002-05-08 2004-03-25 Conduct Prosecution Tester system having multiple instruction memories
US7234092B2 (en) * 2002-06-11 2007-06-19 On-Chip Technologies, Inc. Variable clocked scan test circuitry and method
US6832359B2 (en) * 2002-08-02 2004-12-14 Fujitsu Limited Apparatus and method for calculating simulation coverage
US7539915B1 (en) * 2003-01-07 2009-05-26 Marvell Israel (Misl) Ltd. Integrated circuit testing using segmented scan chains
US7149943B2 (en) * 2004-01-12 2006-12-12 Lucent Technologies Inc. System for flexible embedded Boundary Scan testing
US7139950B2 (en) * 2004-01-28 2006-11-21 International Business Machines Corporation Segmented scan chains with dynamic reconfigurations
US20060236176A1 (en) * 2005-03-31 2006-10-19 Alyamani Ahmad A Segmented addressable scan architecture and method for implementing scan-based testing of integrated circuits
US20080281547A1 (en) * 2007-05-11 2008-11-13 Nec Electronics Corporation Test circuit
US8418008B2 (en) * 2008-12-18 2013-04-09 Lsi Corporation Test technique to apply a variable scan clock including a scan clock modifier on an integrated circuit

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
The SPARC Architecture Manual Version 8. 1992. *

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8959396B2 (en) * 2009-03-25 2015-02-17 Texas Instruments Incorporated Commandable data register control router connected to TCK and TDI
US9121905B2 (en) * 2009-03-25 2015-09-01 Texas Instruments Incorporated TAP with commandable data register control router and routing circuit
US20150113347A1 (en) * 2009-03-25 2015-04-23 Texas Instruments Incorporated Commanded jtag test access port operations
US10024913B2 (en) 2009-03-25 2018-07-17 Texas Instruments Incorporated Tap commandable data register control router inverted TCK, TMS/TDI imputs
US8285509B2 (en) * 2009-12-29 2012-10-09 Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. Method and system of testing electronic device
US20110161039A1 (en) * 2009-12-29 2011-06-30 Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd Method and system of testing electronic device
US11604222B2 (en) 2010-03-10 2023-03-14 Texas Instmments Incorporated Commanded JTAG test access port operations
US8572433B2 (en) * 2010-03-10 2013-10-29 Texas Instruments Incorporated JTAG IC with commandable circuit controlling data register control router
US20110225456A1 (en) * 2010-03-10 2011-09-15 Texas Instruments Incorporated Commanded jtag test access port operations
US11269008B2 (en) 2010-03-10 2022-03-08 Texas Instruments Incorporated Commanded JTAG test access port operations
US10634719B2 (en) 2010-03-10 2020-04-28 Texas Instruments Incorporated Commandable data register control router including input coupled to TDI
US20110231720A1 (en) * 2010-03-19 2011-09-22 Qualcomm Incorporated Data recirculation in configured scan paths
US9316690B2 (en) * 2010-03-19 2016-04-19 Qualcomm Incorporated Data recirculation in configured scan paths
US8516318B2 (en) * 2010-12-15 2013-08-20 International Business Machines Corporation Dynamic scan
US20120159273A1 (en) * 2010-12-15 2012-06-21 International Business Machines Corporation Dynamic Scan
US9183105B2 (en) 2013-02-04 2015-11-10 Alcatel Lucent Systems and methods for dynamic scan scheduling
CN105138364A (zh) * 2015-08-21 2015-12-09 广东欧珀移动通信有限公司 一种终端系统升级的方法及装置
US20230342271A1 (en) * 2017-03-10 2023-10-26 Pure Storage, Inc. Performance-Based Prioritization For Storage Systems Replicating A Dataset
US20230141802A1 (en) * 2021-11-08 2023-05-11 Shanghai Zhaoxin Semiconductor Co., Ltd. Method and interconnect interface for built-in self-test
US12013771B2 (en) * 2021-11-08 2024-06-18 Shanghai Zhaoxin Semiconductor Co., Ltd. Method and interconnect interface for built-in self-test

Also Published As

Publication number Publication date
CN102341718A (zh) 2012-02-01
WO2010101984A1 (en) 2010-09-10
EP2404184A1 (en) 2012-01-11
JP2012519912A (ja) 2012-08-30
WO2010102019A8 (en) 2010-11-18
EP2404182A1 (en) 2012-01-11
CN102341719A (zh) 2012-02-01
US8677198B2 (en) 2014-03-18
WO2010102019A1 (en) 2010-09-10
CN102439470A (zh) 2012-05-02
CN102439470B (zh) 2014-07-16
KR20130100018A (ko) 2013-09-06
US20100229036A1 (en) 2010-09-09
JP5683502B2 (ja) 2015-03-11
US20100229042A1 (en) 2010-09-09
WO2010101995A1 (en) 2010-09-10
JP5489249B2 (ja) 2014-05-14
KR20120023601A (ko) 2012-03-13
JP2012519853A (ja) 2012-08-30
JP5684739B2 (ja) 2015-03-18
JP2014067436A (ja) 2014-04-17
US8533545B2 (en) 2013-09-10
EP2404183B1 (en) 2014-08-13
CN102341719B (zh) 2015-04-01
KR20110122165A (ko) 2011-11-09
KR20130081717A (ko) 2013-07-17
EP2404182B1 (en) 2014-05-21
JP2012519854A (ja) 2012-08-30
KR101489550B1 (ko) 2015-03-24
EP2404184B1 (en) 2013-10-02
CN102341718B (zh) 2015-05-20
KR20110124274A (ko) 2011-11-16
KR101329465B1 (ko) 2013-11-13
EP2404183A1 (en) 2012-01-11
KR101533170B1 (ko) 2015-07-02

Similar Documents

Publication Publication Date Title
US8533545B2 (en) Method and apparatus for system testing using multiple instruction types
US8621301B2 (en) Method and apparatus for virtual in-circuit emulation
US8719649B2 (en) Method and apparatus for deferred scheduling for JTAG systems
US8775884B2 (en) Method and apparatus for position-based scheduling for JTAG systems

Legal Events

Date Code Title Description
AS Assignment

Owner name: ALCATEL-LUCENT IRELAND LTD., IRELAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PORTOLAN, MICHELE;REEL/FRAME:023125/0432

Effective date: 20090730

Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GOYAL, SURESH;VAN TREUREN, BRADFORD;SIGNING DATES FROM 20090810 TO 20090819;REEL/FRAME:023125/0353

AS Assignment

Owner name: ALCATEL LUCENT, FRANCE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ALCATEL-LUCENT USA INC.;REEL/FRAME:026494/0767

Effective date: 20110621

AS Assignment

Owner name: ALCATEL LUCENT, FRANCE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ALCATEL-LUCENT IRELAND LTD.;REEL/FRAME:026647/0236

Effective date: 20110720

AS Assignment

Owner name: CREDIT SUISSE AG, NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNOR:LUCENT, ALCATEL;REEL/FRAME:029821/0001

Effective date: 20130130

Owner name: CREDIT SUISSE AG, NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNOR:ALCATEL LUCENT;REEL/FRAME:029821/0001

Effective date: 20130130

AS Assignment

Owner name: ALCATEL LUCENT, FRANCE

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:033868/0555

Effective date: 20140819

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP, NEW YORK

Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:043966/0574

Effective date: 20170822

Owner name: OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP, NEW YO

Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:043966/0574

Effective date: 20170822

AS Assignment

Owner name: WSOU INVESTMENTS, LLC, CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:OCO OPPORTUNITIES MASTER FUND, L.P. (F/K/A OMEGA CREDIT OPPORTUNITIES MASTER FUND LP;REEL/FRAME:049246/0405

Effective date: 20190516