Test and debug based on high speed functional protocol

Abstract

Integrated circuit (IC) devices and methods for communicating test data utilize test control circuitry and a test controller. The test controller is coupled with the test control circuitry and decodes packetized test pattern data to identify configuration data for the test controller and test data for the test control circuitry. The test controller also communicates the test data to the test control circuitry and packetizes result data received from the test control circuitry. The result data corresponds to errors identified by tests performed based on the test pattern data.

Description

Technical Field

[0001] This disclosure relates to testing and debugging integrated circuit chips, and more specifically, to testing and debugging integrated circuit chips via high-speed communication interfaces. Background Technology

[0002] As the size of integrated circuit (IC) devices (e.g., the number of circuit components and devices) increases, the requirements for test and debug data increase accordingly. Furthermore, as the size of IC devices increases, their complexity also increases. Therefore, to support testing the connections and circuit elements of the IC device, the amount of test data (e.g., boundary scan data and scan data) increases. In many current implementations, test data is transmitted to the IC device via general purpose input / output (GPIO) pins. In this implementation, the data rate used for communication corresponds to the data rate of the GPIO pin. Therefore, as GPIO pins have low data rates (e.g., less than 1 megabit per second (Mbps)) and as the size of the test data increases, the test time for the IC device increases. Increased test time for IC devices leads to a reduction in the number of IC devices tested in a given cycle, increasing the manufacturing cost of the IC device. Summary of the Invention

[0003] In one example, an integrated circuit (IC) device includes a test control circuitry and a test controller. The test controller is coupled to the test control circuitry and decodes grouped test mode data to identify configuration data for the test controller and test data for the test control circuitry. The test controller also transmits test data to the test control circuitry and groups result data received from the test control circuitry. The result data corresponds to errors identified by tests performed based on the test mode data.

[0004] In one example, a method includes receiving grouped test pattern data from a test device, and decoding the grouped test pattern data to identify configuration data and test data of a test controller. The method also includes transmitting the test data to a test control circuitry and grouping result data received from the test control circuitry. The result data corresponds to errors identified by tests performed within an IC device based on the test data. Furthermore, the method includes outputting the grouped result data from the IC device to the test device.

[0005] In one example, the test controller for the IC device includes an interconnect bridge circuitry that receives packetized test mode data. The test controller also includes a test bridge circuitry that decodes the packetized test mode data to identify configuration data and test data for the IC device's test control circuitry, and transmits the test data to the test control circuitry. Furthermore, the test controller packets result data from the test control circuitry. The result data corresponds to errors identified by tests performed based on the test mode data. Attached Figure Description

[0006] This disclosure will be more fully understood from the following detailed description and the accompanying drawings illustrating embodiments of the present disclosure. The drawings are provided to give knowledge and understanding of embodiments of the present disclosure, but are not intended to limit the scope of the disclosure to these particular embodiments. Furthermore, the drawings are not necessarily drawn to scale.

[0007] Figure 1 A block diagram of a test system based on one or more examples is shown.

[0008] Figure 2 A flowchart is shown illustrating a method for generating test data and result data based on one or more examples.

[0009] Figure 3 A block diagram of a test system based on one or more examples is shown.

[0010] Figure 4 A block diagram of a test system based on one or more examples is shown.

[0011] Figure 5 A block diagram illustrating a portion of an integrated circuit device based on one or more examples.

[0012] Figure 6 A block diagram illustrating a portion of an integrated circuit device based on one or more examples.

[0013] Figure 7 The test data is grouped according to one or more examples.

[0014] Figure 8 The test data is grouped according to one or more examples.

[0015] Figure 9 A flowchart is shown illustrating a method for generating result data from test data, based on one or more examples.

[0016] Figure 10 Flowcharts depicting various processes used during the design and manufacture of integrated circuits according to some embodiments of the present invention.

[0017] Figure 11A diagram depicts an example computer system in which embodiments of the present disclosure may operate. Detailed Implementation

[0018] Various aspects of this invention relate to the testing and debugging of high-speed functional protocols.

[0019] Integrated circuit (IC) device testing methods utilizing high-speed interfaces (e.g., serial high-speed interfaces) reduce the corresponding test application time and / or the pin count used during testing. Therefore, an increased number of ICs can be tested within a given cycle time. Furthermore, an increased number of ICs can be tested in parallel. Reducing the amount of IC device testing time and increasing the number of ICs that can be tested within a given time period lowers the manufacturing cost of IC devices.

[0020] In various examples, after the IC device has been manufactured and integrated into the electronic system, the high-speed functional interface provides access to the design-for-test (DFT) infrastructure for system-level testing. In various examples, a common schema format for test data can be utilized across all stages of the IC development process. For example, this common schema format for test data can be used with automated test equipment (ATE), system-level testing, and field testing for diagnostics.

[0021] The following describes a test controller capable of utilizing a high-speed serial functional interface. Using such a test controller reduces the number of pins used during testing and the amount of time spent during testing. In one or more examples, the test controller operates with high-speed peripherals such as Peripheral Component Interconnect (PCIe), Universal Serial Bus (USB), or Mobile Industrial Processor Interface (MIPI). Furthermore, the test controller may include interconnect hardware compatible with functional peripherals via high-speed bus protocols. In various examples, the test controller operates using scan test data and / or boundary scan test data. Moreover, the test data mode format can be used for ATE, System-Level Test (SLT), and Field Test, and the same test data mode format can be used at various stages of IC testing.

[0022] As will be described in more detail below, to test IC devices, test equipment converts test data from a traditional format to a high-speed communication format. Furthermore, the output data from the IC device is converted into a format readable by DFT tools to diagnose faults within the IC device. A test controller communicating via a high-speed communication interface provides a way to access the DFT infrastructure within the IC device through high-speed input and output (I / O). In these examples, DFT structures such as scan, scan compression, scan dump, logic built-in self-test (LBIST), memory built-in self-test (MBIST), boundary scan test, and input / output built-in self-test (IO-BIST) can be accessed via high-speed peripherals. Using a high-speed interface reduces the number of I / Os used for DFT. Therefore, scan data can be driven at a faster rate and / or with higher bandwidth compared to using general-purpose input / output (GPIO) pins. Utilizing a high-speed interface reduces test application time and test pin count, resulting in reduced electronic complexity of the test equipment (e.g., the test device). Furthermore, by using a functional high-speed interface, the DFT infrastructure is accessible at the system level, even after the IC device has been implemented within the system.

[0023] In one or more of the above examples, test data patterns are transmitted to the IC device, and result data is transmitted from the IC device application using a high-speed function interface. Therefore, the testing time for the IC device is reduced, the number of IC devices that can be tested within a given time period is increased, and the manufacturing cost of the IC device is lowered.

[0024] Figure 1 A test system 100 according to one or more examples is illustrated. Test system 100 includes an IC device 110 and a test device 120. The IC device 110 may be referred to as a device under test (DUT). In one example, the IC device 110 is a field-programmable gate array (FPGA). In other examples, the IC device 110 is an application-specific integrated circuit (ASIC) or a general-purpose controller (e.g., a central processing unit (CPU) or a graphics processing unit (GPU)). The IC device 110 includes a test control circuit arrangement 112, a test controller 114, a communication device 116, and core logic 118. In one example, the test control circuit arrangement 112 includes a test access port (TAP) circuit arrangement and a scan chain circuit arrangement. Furthermore, the test control circuit arrangement 112 includes one or more registers (e.g., a test data register (TDR) and / or a boundary scan shift register (BSR)). The TDR may conform to IEEE 1149.1, IEEE 1500, and / or IEEE 1687. Additionally, the TDR and scan chain may be collectively referred to as a scan channel and / or scan I / O.

[0025] In one example, test control circuitry 112 transmits test data to core logic 118 and receives result data from core logic 118. The scan chain circuitry of test control circuitry 112 acts as a shift register to provide (e.g., shift) predetermined (e.g., known) states to circuit elements (e.g., internal circuitry) of core logic 118 to determine the functionality of the circuit elements of core logic 118. In one example, each in the scan chain includes multiple link scan units, which operate as shift registers when placed in test mode. Furthermore, test control circuitry 112 includes TAP circuitry for performing boundary scan tests on IC device 110. Boundary scan tests interconnects and / or sub-blocks within IC device 110.

[0026] Test controller 114 is electrically coupled to test control circuit device 112 and communication device 116. Test controller 114 receives group test mode data from communication device 116 and decodes the group test mode data to identify the configuration data of test controller 114 and the test data of test control circuit device 112. Test controller 114 outputs the test data to test control circuit device 112. The configuration of test controller 114 is changed based on the configuration data.

[0027] Communication device 116 is a high-speed communication device. For example, communication device 116 is particularly a Universal Serial Bus (USB) device, a High-Speed ​​Peripheral Component Interconnect (PCIe) device, or a Mobile Industrial Processor Interface (MIPI) device. In one example, communication device 116 is a high-speed communication device supporting a data rate of at least 1 megabit per second (Mbps). In other examples, communication device 116 supports a data rate of at least 2 Mbps. In one or more examples, communication device 116 supports a data rate of at least 100 Mbps, at least 500 Mbps, at least 1 gigabits per second (Gbps), or at least 10 Gbps.

[0028] Communication device 116 is connected to test device 120 and receives packet test mode data from test device 120. Communication device 116 transmits the received packet test mode data to test controller 114.

[0029] Test device 120 generates grouped test pattern data and transmits it to IC device 110 via communication interface 130. Test controller 114 receives grouped test pattern data from communication device 116, processes the grouped test pattern data, and transmits the processed test pattern data to test control circuit device 112. Test controller 114 receives result data from test control circuit device 112 and transmits the result data to test device 120 via communication interface 130. Before being transmitted to test device 120, the result data may be encoded (e.g., grouped) by test controller 114. In one example, the resulting data is generated based on boundary scan tests performed using the processed test pattern data and / or scan chain tests of core logic 118 performed using the test pattern data. Furthermore, the result data includes error data from test control circuit device 112 and / or core logic 118.

[0030] Test device 120 includes communication device 122. Communication device 122 is connected to communication device 116 via communication interface 130. Communication device 122 is, in particular, a USB device, a PCIe device, or a MIPI device. Communication device 122 is a high-speed communication device similar to communication device 116. In one example, communication device 122 supports data rates similar to those supported by communication device 116. For example, both communication devices 116 and 122 support data rates of at least 1 Mbps, at least 5 Mbps, at least 100 Mbps, or at least 1 Gbps.

[0031] Communication interface 130 includes one or more traces (e.g., wires) connecting communication device 116 to communication device 122. In one example, the communication interface is a high-speed interface that supports at least similar data rates to those of communication devices 116 and 122.

[0032] Test device 120 also includes one or more processing devices (not shown) and a memory (not shown). Test device 120 generates grouped test pattern data and transmits it to IC device 110 via communication interface 130. In one example, test controller 114 receives grouped test pattern data from communication device 116, processes the grouped test pattern data, and transmits the processed test pattern data to test control circuit device 112. Furthermore, test controller 114 receives result data (e.g., error data) from test control circuit device 112 and transmits the result data to test device 120 via communication device 116 and communication interface 130. Result data is generated by performing one or more of boundary scan tests and scan chain tests with the processed test pattern data.

[0033] Figure 2A method 200 for generating test pattern data and processing received result data, according to one or more examples, is shown. At block 210, test pattern data is generated. Test pattern data is data that can be applied to IC device 110 to distinguish between correct circuit behavior and faulty circuit behavior caused by defects. The test pattern data is transmitted in a Standard Test Interface Language (STIL) or similar language. At block 220, the test pattern data is grouped and transmitted to the DUT. For example, refer to... Figure 1 The test device 120 groups the test mode data and transmits the grouped test mode data to the IC device 110. The test controller 114 receives the test mode data via the communication device 116 and the communication interface 130. As will be described in more detail below, the test controller 114 initiates tests within the test control circuit device 112 and / or core logic 118 based on the test mode data.

[0034] At block 230, result data is generated based on test mode data. Test control circuitry 112 generates result data based on test mode data. The result data is based on boundary scan testing and / or scan chain testing. In one example, test controller 114 generates result data as an error map in response to performing a test. The error map includes a list of identified faults (defects). At block 240, reverse mapping is performed on the result data (e.g., the error map). For example, test controller 114 performs reverse mapping on the error data to associate the identified faults with different functions and / or parts of IC device 110, thereby generating a mode fault file. The mode fault file is transmitted to test device 120 via communication interface 130 and communication devices 116 and 122. At block 250, diagnostics are performed on the mode fault file to generate a diagnostic report. For example, test device 120 performs diagnostics on the mode fault file to generate a diagnostic report. The diagnostic report may be stored in the memory of test device 120 and / or displayed on the display screen of test device 120.

[0035] In one example, method 200 can be used in the manufacture of IC devices (e.g., Figure 10 This occurs after the chip (1040) is manufactured using the process.

[0036] Figure 3 An example test system 300 according to one or more examples is shown. The test system 300 includes an IC device 310 and a test device 340. The test device 340 is connected to the IC device 310 via a communication interface 330. The test device 340 transmits grouped test mode data to the IC device 310 and receives error data from the IC device 310 via the communication interface 330.

[0037] IC device 310 is configured similarly to IC device 110. For example, IC device 310 includes test control circuitry 312, test controller 314, and communication device 316. IC device 310 also includes core logic (not shown). Test control circuitry 312 is configured similarly to test control circuitry 112. Test control circuitry 312 includes a scan chain circuit 313 having inputs and outputs connected to test controller 114 and TAP control circuitry 311.

[0038] IC device 310 may be referred to as a manufactured IC device. For example, the components of IC device 310 are mounted on one or more circuit boards to form IC device 310.

[0039] Test controller 314 is configured similarly to test controller 114. Furthermore, test controller 314 includes an interconnect bridge 315 and test bridge circuitry 317. Interconnect bridge 315 is an AXI bridge. For example, interconnect bridge 315 could be ARM AMBA AXI. In other examples, interconnect bridge 315 is another type of point-to-point interconnect bridge. Interconnect bridge 315 communicates with communication device 316, memory 318, and processor 320 via interconnect 322. Interconnect 322 and interconnect bridge 315 use similar protocols. For example, interconnect 322 and interconnect bridge 315 are AXI interconnect protocols or another type of point-to-point interconnect protocol.

[0040] In one or more examples, the AXI read and write data widths can be the same. For example, the AXI read and write data widths can be referred to as AXI_DATA_WIDTH and can be 32, 64, 128 bits or more. Furthermore, the AXI read and write data widths can also be ARM AMBA AXI read and write data widths.

[0041] In an example where the width of the test bridge circuit device 317 is smaller than the width of the test data pattern, the width of each test pattern data group includes more than one shifted data. Furthermore, in one or more examples, the test data pattern is divided into split groups to drive the scan chain circuit device 313.

[0042] In one example, the scan chain circuitry 313 includes a decompressor and compressor circuitry 323. In one or more examples, the decompressor and compressor circuitry 323 is external to the scan chain circuitry 313 but internal to the test control circuitry 312. In other examples, the decompressor and compressor circuitry 323 is external to the test control circuitry 312. The decompressor and compressor circuitry 323 is used to drive the scan chain of the scan chain circuitry 313 when the number of pins available to drive the scan chain (e.g., scan pins) is less than the number of scan chains within the scan chain circuitry 313. The decompressor and compressor circuitry 323 receives test data from the test bridge circuitry 317 and processes the test data pattern to generate test data for each scan chain of the scan chain circuitry 313. For example, the decompressor and compressor circuitry 323 generates test data for each scan chain of the scan chain circuitry 313 based on decoded test data generated by the test controller 314. In one example, test mode data is received by test controller 314 via communication device 316, decoded by test controller 314, and transmitted to decompressor and compressor circuit 323 via test bridge circuit device 317. Decompressor and compressor circuit device 323 generates test data for each scan chain of scan chain circuit device 313 from the decoded test data and transmits the test data to each scan chain of scan chain circuit device 313. In one or more examples, decompressor and compressor circuit device 323 may be omitted, and test data may be provided directly from test bridge circuit device 317 to scan chain circuit device 313.

[0043] In one example, group test mode data is received by test controller 314 from test device 340 via communication device 316 and communication interface 330. Communication device 316 is configured similar to Figure 1 The communication device 116. Furthermore, the communication interface 330 is configured similar to... Figure 1 The communication interface 130, and the test device 340 is configured to be similar to Figure 1 The testing equipment is 120.

[0044] Test controller 314 transmits test data to TAP control circuitry 311 and scan chain circuitry 313 of test control circuitry 312 via test bridge circuitry 317. Test bridge circuitry 317 is connected to TAP control circuitry 311 and scan chain circuitry 313. In one example, test bridge circuitry 317 is connected to decompressor and compressor circuitry 323. In this example, test bridge circuitry 317 is coupled to scan chain circuitry 313 via decompressor and compressor circuitry 323. Furthermore, in this example, test bridge circuitry 317 may or may not be directly connected to scan chain circuitry 313. TAP control circuitry 311 may be referred to as boundary scan circuitry. TAP control circuitry 311 is used to test interconnects and circuit elements within IC device 310. In one example, test controller 314 transmits test enable signal 319 to test control circuitry 312 to initiate the test via TAP control circuitry 311 and scan chain circuitry 313. In addition, the test controller 314 transmits the clock signal to the test control circuit device 312.

[0045] Processor 320 initializes and enumerates the high-speed communication protocol of communication device 316. Processor 320 initializes and enumerates communication device 316 via interconnect 322. In one example, processor 320 is a Joint Test Action Group (JTAG) processor. Processor 320 receives initialization signals and / or other control signals from test device 340. For example, test device 340 transmits initialization signals to processor 320 to initialize test programs (e.g., test modes) within IC device 310. For example, initialization signals initialize test controller 314 to send test data to test control circuitry 312.

[0046] IC device 310 also includes general purpose input / output (GPIO) pins 324. GPIO pins 324 are connected to test controller 314. One or more of the GPIO pins 324 receive control signals, test data, and / or configuration data from test device 340. Test controller 314 receives one or more control signals, test data, and configuration data from test device 340 via one or more GPIO pins 324. In one example, the data rate supported by GPIO pins 324 is less than the data rate supported by communication device 316 and communication interface 330.

[0047] IC device 310 also includes a TAP bypass multiplexer (mux) 326 and a scan bypass multiplexer 328. The TAP bypass multiplexer 326 is connected to GPIO pin 324, test controller 314, and test control circuitry 312. The scan bypass multiplexer 328 is connected to GPIO pin 324, test controller 314, and test control circuitry 312. (About...) Figure 5 The TAP bypass multiplexer 326 and the scan bypass multiplexer 328 are described in more detail.

[0048] Figure 4 An example of a test system 400 according to one or more examples is shown. Test system 400 includes an IC device 310 and a test device 410. Test device 410 includes a housing engine 420 and a host circuit device 430. Housing engine 420 includes components configured to execute operations stored in memory (e.g., ...). Figure 11 Instructions in main memory 1104 or machine-readable medium 1124 (e.g., Figure 11 One or more processors (e.g., instruction 1126) Figure 11 The processor device 1102). The shell engine 420 generates a grouped test data pattern and transmits the grouped test data pattern to the host circuit device 430. In addition, the shell engine 420 receives error information from the host circuit device 430 and identifies errors within the error information.

[0049] The host circuitry 430 includes driver circuitry, communication device 432, and JTAG processor 434. Driver circuitry 440 receives packet test pattern data from enclosure engine 420 and transmits the packet test pattern data to IC device 310 via communication device 432. Additionally, driver circuitry 440 receives error data (e.g., result data) from IC device 310 via communication device 432. Driver circuitry 440 compares the error data with the packet test pattern to determine fault information. The fault information is transmitted to enclosure engine 420. Enclosure engine 420 processes the fault information to generate data logs and diagnose any faults within the core logic of IC device 310.

[0050] JTAG processor 434 sends the test initialization signal to processor 320.

[0051] Figure 5An example architecture of a portion of a test controller 314 according to one or more examples is shown. The junction architecture of the test controller 314 includes a slave bridge circuit arrangement 510, a block decoder circuit arrangement 512, a control circuit arrangement 514, a TAP bridge circuit arrangement 516, a scan bridge circuit arrangement 518, a block encoder circuit arrangement 520, and a debug circuit arrangement 522. The test controller 314 also includes first-in-first-out (FIFO) circuit arrangements 524 and 526. In other examples, FIFO 524 and / or FIFO 526 may be other types of buffers or memory devices.

[0052] Packet test pattern data is received from bridge circuit device 510 and stored in FIFO 524. FIFO 524 is connected to packet decoder circuit device 512. FIFO 524 transmits the packet test pattern data to packet decoder circuit device 512 on a first-in-first-out basis. Packet decoder circuit device 512 decodes the test pattern data to generate decoded test data. Packet decoder circuit device 512 transmits the decoded test data to control circuit device 514, TAP bridge circuit device 516, and / or scan bridge circuit device 518.

[0053] The group encoder circuit 520 receives result data from the control circuitry 514, the TAP bridge circuitry 516, and / or the scan bridge circuitry 518. The group encoder circuit 520 groups the result data and transmits any erroneous data from the groups to the FIFO 526. The FIFO 526 then transmits the grouped result data to the slave bridge interface circuitry 610 for transmission via a communication device (e.g., [missing information]). Figure 3 Communication device 316) and communication interface (e.g., Figure 3 The communication interface 330) transmits data from the test controller 314 to the test equipment (e.g., Figure 3 Test equipment 340).

[0054] Control circuitry 514 is connected to block decoder circuitry 512 and block encoder circuitry 520. In one example, control circuitry 514 receives decoded test data and initializes the settings of test controller 314 based on the decoded test data. The decoded test data includes configuration data, and control circuitry 514 adjusts one or more settings of test controller 314 based on the configuration data. Furthermore, control circuitry 514 communicates with block decoder circuitry 512 to control the mode of decoding the received test data. Additionally, control circuitry 514 communicates with block encoder circuitry 520 to control block encoder circuitry 520 to encode the output result data.

[0055] TAP bridge circuit device 516 is connected to TAP pin 530 within test control circuit device 312. Block decoder circuit device 512 transmits decoded test data to TAP bridge circuit device 516, and TAP bridge circuit device 516 transmits decoded test data to one or more TAP pins of test control circuit device 312. In one example, block decoder circuit device 512 identifies the test data to be transmitted to TAP pin 530 from the received test data patterns. In one example, the test data to be transmitted to TAP pin 530 is associated with a boundary scan test. TAP pin 530 transmits test data received from TAP bridge circuit device 516 to boundary scan circuit device 532 within test control circuit device 312, and transmits error data received from boundary scan circuit device 532 to TAP bridge circuit device 516. Boundary scan testing can be used to verify board-level connectivity issues and other manufacturing problems. Identified problems can be transmitted as part of the result data output from boundary scan circuit device 532. In one or more examples, the TAP bridge circuit device 516 includes an addressable register that receives and stores boundary scan data and boundary error data.

[0056] Scan bridge circuit device 518 is connected to scan chain pin 534. Block decoder circuit device 512 identifies scan test data within test mode data to be transmitted to scan bridge circuit device 518. The scan test data corresponds to test data used to scan the test mode into internal circuitry within core logic 528. Scan bridge circuit device 518 transmits the scan test data to scan chain 536 via scan chain pin 534, and scan chain 536 transmits the scan test data to core logic 528. Core logic 528 transmits scan result data to scan chain 536, and scan chain 536 transmits the scan result data to scan bridge circuit device 518 via scan chain pin 534. The scan result data corresponds to errors within circuit elements of core logic 528. In one example, the scan result data indicates that one or more circuit elements of core logic 528 have incorrect logic levels compared to the scan test data. In one or more examples, scan bridge circuit device 518 includes an addressable register that receives and stores scan test data and scan result data.

[0057] Debugging circuit device 522 is connected via a JTAG processor (e.g., Figure 3 The processor 320 provides write / read capabilities to the internal registers of the test controller 314. In one example, the debug circuitry 522 receives a test initialization signal from the JTAG processor and configures the internal registers of the test controller 314 for read / write operations to initialize the test controller 314 for testing.

[0058] In one example, bridge circuit device 510, FIFO 524, block decoder circuit device 512, control circuit device 514, group encoder circuit device 520, and FIFO 526 operate in a first clock domain. TAP bridge circuit device 516 operates in the first clock domain and a second clock domain different from the first clock domain. Scan bridge circuit device 518 operates in the first clock domain and a third clock domain different from the first and third clock domains. Debug circuit device 522 operates in the first clock domain and a fourth clock domain different from the first, second, and third clock domains.

[0059] In various examples, the number of scan chains 536 is greater than the width of the slave bridge circuitry 510. For example, the number of scan chains 536 is 512, and the width of the slave bridge circuitry 510 is 32, 64, 128, or 256 channels. In one example, received test mode data packets are accumulated before the scan chains 536 are driven with shifted data. The slave bridge circuitry 510 is an AXI interface. Continuous sets of test mode data packets can be sent to the slave bridge circuitry 510 to generate a complete test data pattern. The test mode data packets are accumulated in the packet decoder circuitry 512. In one example, using segmented packets of test mode data improves the packet processing latency of the packet decoder circuitry 512.

[0060] In one or more examples, test controller 314 employs loopback features for the debugging process. Test controller 314 may employ three different loopbacks. The first loopback (e.g., a slave loopback) includes slave bridge circuitry 510, FIFO 524, block decoder circuitry 512, and FIFO 526. The first loopback can be used to verify the functionality of slave bridge circuitry 510 and the corresponding system integration. For example, test data is input via slave bridge circuitry 510, passes through each of FIFO 524, block decoder circuitry 512, and FIFO 526, to generate result data at slave bridge circuitry 510. The test data is compared with the result data to determine the functionality of the corresponding components. If the test data differs from the result data, a fault can be indicated. The second loopback (e.g., a scan loopback) includes FIFO 524, block decoder circuitry 512, scan bridge circuitry 518, block encoder circuitry 520, and FIFO 526. The second loopback can be used to verify the functionality of scan bridge circuitry 518. For example, test data is input to the scan bridge circuit 518 via FIFO 524 and the block decoder circuit 512, and result data is output from the scan bridge circuit 518 to the block encoder circuit 520 and FIFO 526 to generate result data. The test data is compared with the result data to verify the signal generated by the scan bridge circuit 518. If the test data differs from the result data, a fault can be indicated within the scan bridge circuit 518.

[0061] The third loopback (e.g., TAP loopback), FIFO 524, block decoder circuitry 512, TAP bridge circuitry 516, block encoder circuitry 520, and FIFO 526 are all included. The third loopback can be used to verify the functionality of the TAP bridge circuitry 516. For example, test data is input to the TAP bridge circuitry 516 via FIFO 524 and block decoder circuitry 512, and result data is output from the TAP bridge circuitry 516 to the block encoder circuitry 520 and FIFO 526 to generate result data. The test data is compared with the result data to verify the signal generated by the TAP bridge circuitry 516. If the test data differs from the result data, a fault can be indicated within the TAP bridge circuitry 516.

[0062] Based on one or more examples, Figure 6 A portion of the IC device 310 is shown. The test controller 314 is connected to the test control circuitry 312 via a TAP bypass multiplexer 326 and a scan bypass multiplexer 328.

[0063] TAP bypass multiplexer 326 is electrically connected to GPIO pin 720, while scan bypass multiplexer 328 is electrically connected to GPIO pin 722. GPIO pins 720 and 722 are configured similarly to... Figure 3 The GPIO pin 324 is used for the TAP bypass multiplexer 326. The TAP bypass multiplexer 326 receives the clock signal TCK, data input signal TDI, management signal TMS, and reset signal TRSTN, and outputs the data output signal TDO via the GPIO pin 720. Additionally, the TAP bypass multiplexer 326 receives signals TCK, TDI, TMS, and TRSTN from the test controller 314 and outputs TDO to the test controller 314. The test controller 314 also sends the select signal tap_clk_mux_sel and the enable signal tap_data_mux_en to the TAP bypass 326.

[0064] The TAP bypass multiplexer 326 transmits the reset signal test_trst, the clock signal test_tck, the data signal test_tdi, and the management signal test_tms, and receives the data output signal test_tdo from the test control circuit device 312. The signal test_trst corresponds to one of the signals TRSTN received from the GPIO pin 720 and the test controller 314. The signal test_tck corresponds to one of the signals TCK received from the GPIO pin 720 and the test controller 314. The signal test_tdi corresponds to one of the signals TDI received from the GPIO pin 720 and the test controller 314. The signal test_tms corresponds to one of the signals TMS received from the GPIO pin 720 and the test controller 314.

[0065] The TAP bypass multiplexer 326 connects the test control circuit device 312 to the GPIO pin 722 based on the tap_clk_mux_sel signal with a first value, and connects the test controller 314 to the test control circuit device 312 based on the tap_clk_mux_sel signal with a second value. The TAP bypass multiplexer 326 outputs signals TCK, TDI, TMS, and TRSTN as signals test_trst, test_tck, test_tdi, and test_tms based on the tap_clk_mux_sel signal with the first value. Furthermore, based on the tap_clk_mux_sel signal with the second value, when outputting signals test_trst, test_tck, test_tdi, and test_tms respectively, the TAP bypass multiplexer 326 outputs signals TCK, TDI, TMS, and TRSTN. A first value indicates that test controller 314 is disabled and the corresponding test operation is disabled, while a second value indicates that test controller 314 is enabled and the corresponding test operation is enabled. Furthermore, based on the tap_clk_mux_sel signal with the first value, TAP bypass multiplexer 326 outputs the output signal test_tdo as the output signal TDO to GPIO pin 720. Based on the tap_clk_mux_sel signal with the second value, TAP bypass multiplexer 326 outputs the output signal test_tdo as the output signal tdo to test controller 314. In one example, when test controller 314 is enabled and test mode is enabled, the tap_data_mux_en signal enables TAP bypass multiplexer 326.

[0066] The scan bypass multiplexer 328 receives the scan input signal SI, the scan enable signal SE, and the scan clock signal Scan Clock, and outputs the scan output signal SO to the GPIO pin 722. Additionally, the scan bypass multiplexer 328 receives the scan enable signal scan_enable, the scan input signal scan_in, and the scan clock signal scan_clk, and outputs the scan signal scan_out to the test controller 314. The test controller 314 also outputs the selection signal scan_clk_mux_sel and the enable signal scan_data_mux_en to the scan bypass multiplexer 328.

[0067] The scan bypass multiplexer 328 outputs the test input signal test_si, the test clock signal test_clk, and the test scan enable signal test_se to the test control circuit device 312, and receives the test scan output signal test_so from the test control circuit device 312.

[0068] In one example, signal test_si corresponds to one of signal SI and signal scan_in, signal test_clk corresponds to one of signal scan_clk and signal scan_clk, and signal test_se corresponds to one of signal SE and signal scan_enable.

[0069] The scan bypass multiplexer 328 connects the test control circuit device 312 to the GPIO pin 722 based on the tap_clk_mux_sel signal with a first value. The scan bypass multiplexer 328 connects the test controller 314 to the test control circuit device 312 based on the tap_clk_mux_sel signal with a second value. Based on the scan_clk_mux_sel signal with the first value, the scan bypass multiplexer 328 outputs signal SI as signal test_si, signal SE as signal test_se, and the scan clock as signal test_clk. Based on the scan_clk_mux_sel signal with the second value, the scan bypass multiplexer 328 outputs signal scan_in as signal test_si, signal scan_clk as signal test_clk, and signal scan_enable as signal test_se. Furthermore, based on the scan_clk_mux_sel signal with a first value, the scan bypass multiplexer 328 outputs the signal test_so to the GPIO pin 722 as signal SO, and based on the scan_clk_mux_sel signal with a second value, the scan bypass multiplexer 328 outputs the signal test_so to the test controller 314 as signal scan_out. The first value indicates that the test controller 314 is not enabled and the corresponding test operation is not enabled, while the second value indicates that the test controller 314 is enabled and the corresponding test operation is enabled. In one example, when the test controller 314 is enabled and the test mode is enabled, the scan_data_mux_en signal enables the scan bypass multiplexer 328.

[0070] Figure 7 A grouping structure 700 based on one or more examples is shown. Grouped test data is generated from a test device (e.g., Figure 1 Test equipment 120 or Figure 3The test equipment 340) transmits the data to the IC device (e.g., Figure 1 IC device 110 or Figure 3 IC device 310). Grouping structure 700 includes a test controller (e.g., Figure 1 Test controller 114 or Figure 3 The test controller 314 contains configuration data and test data for the IC device (e.g., boundary scan test data and scan chain test data). The grouping structure 700 consists of the test controller (e.g., ...). Figure 1 Test controller 114 or Figure 3 The test controller 314 is supported.

[0071] In one example, group structure 700 is a separate group used to configure the control registers of the test controller using a single group. For example, group structure 700 contains register addresses, data, and other information in a single merged group. Group structure 700 can be used to configure the control registers of the test controller. For example, bit 702 of group structure 700 includes the configuration data of the test controller. In one example, bit 702 includes 6 bits of group structure 700. In one example, the test controller (e.g., Figure 1 Test controller 114 or Figure 3 The test controller 314 processes packet test data transmitted via a packet structure to identify the value of identifier bit 702, thereby identifying the test controller's configuration data. The configuration data configures the test controller to operate in test mode and perform test operations. In one example, the test controller uses the configuration data to perform boundary scan tests and / or scan chain tests. The test controller uses the configuration data to identify which tests(s) to perform (e.g., boundary scan tests and scan chain tests). The test controller uses the configuration data to configure one or more registers of the test controller.

[0072] The grouping structure 700 also includes bit 704. Bit 704 includes the data payload, which contains test data. Bit 704 consists of 24 bits. In one example, the test controller (e.g., Figure 1 Test controller 114 or Figure 3 The test controller 314 processes the packet test data transmitted via the packet structure 700 to identify the test data by the value of the identifier bit 704.

[0073] The block structure 700 consists of 32 bits. However, in other examples, the block structure is less than or greater than 32 bits.

[0074] Figure 8 A grouping structure 800 according to one or more examples is shown. Grouping structure 800 is configured similarly to grouping structure 700. For example, grouping structure 800 includes a test controller (e.g., Figure 1 Test controller 114 or Figure 3 The test controller 314) is used to configure bit 802 of the test controller, as per the information provided. Figure 7 As described by bit 702. Grouping structure 800 is a segmented sequence of groups. For example, grouping structure 800 includes two N-bit groups. N is 32. In other examples, N may be greater than or less than 32.

[0075] Packet structure 800 includes bit 804. Bit 804 identifies the number of test packets included in the segmented packet sequence. Bit 806 is unused. In one example, bits 802, 804, and 806 could be referred to as control (or header) bits. Bit 810 is the test data bit. The configuration of bit 810 is similar to... Figure 7 Bit 704 in the table. In one example, packet structure 800 is a split packet that includes an initial control packet (e.g., bits 802, 804, and 806), followed by multiple data payload packets (e.g., bit 810). In one example, packet structure 800 is used to send a continuous stream of data over multiple clock cycles without causing additional latency between consecutive data payloads. Compared to packet structure 700, packet structure 800 can be used to load larger control registers and larger data payloads.

[0076] Figure 9 A flowchart of a method 900 for receiving and processing test data, based on one or more examples, is shown. Figure 9 At box 910, test mode data is received from the test equipment. For example, refer to... Figure 3 IC device 310 receives test mode data from test device 340. In one example, the test mode data is packet test mode data. In this example, test device 340 generates packet test mode data and transmits it via communication interface 330 to a communication device (e.g., Figure 1 Communication device 122) transmits packet test mode data. The packet test mode data is received by communication device 316 of IC device 310. The communication device, communication interface 330, and communication device 316 of test device 340 form a high-speed communication system. For example, the high-speed communication system is a communication system capable of transmitting packet test mode data at speeds greater than 1 Mbps or 1 Gbps. Communication device 316 transmits the packet test mode data to test controller 314 via interconnect 322. For example, interconnect bridge 315 of test controller 314 receives packet test mode data from communication device 316 via interconnect 322.

[0077] At box 920, the test mode data is decoded. (See reference.) Figure 3The test controller 314 decodes test mode data (e.g., grouped test mode data) to generate decoded test data. In one example, refer to... Figure 5 The test mode data is received from the bridge circuit device 510 and stored in the FIFO 524. The packet decoder circuit device 512 receives the test mode data from the FIFO 524 and decodes the test mode data to generate decoded test data. The decoded test mode data identifies the configuration data of the test controller 314 (e.g., the first part of the test mode data) and the test data. The test data may be boundary scan test data or scan chain test data.

[0078] At box 930, the decoded test data is transmitted to the test control circuitry. (Reference) Figure 3 The decoded test data is transmitted from test controller 314 to test control circuit device 312. Test bridge circuit device 317 of test controller 314 transmits the test data to TAP control circuit device 311 and / or scan chain circuit device 313 of test control circuit device 312. In one example, test bridge circuit device 317 transmits the test data to scan chain circuit device 313 via decompressor and compressor circuit 323. See also... Figure 5 The TAP bridge circuit device 516 outputs test data (e.g., test data associated with boundary scan tests) to the TAP pin 530 and boundary scan circuit device 532 of the test control circuit device 312. Furthermore, the scan bridge circuit device 518 outputs test data (e.g., test data associated with scan test data) to the scan chain pin 534 and scan chain 536 of the test control circuit device 312. Additionally, scan test data is output to core logic 528. Furthermore, configuration data is output to the control circuit device 514 to configure the registers of the test controller 314.

[0079] At box 940, result data is received from the test control circuitry. (Reference) Figure 3 The result data is received by the test controller 314 from the test control circuitry 312. The result data is error data and includes error information based on the corresponding test performed. In one example, the test bridge circuitry 317 receives the result data from the TAP control circuitry 311 and / or the scan chain circuitry 313. See also... Figure 5 The result data corresponding to the boundary scan test is output from the boundary scan circuit 532 to the TAP bridge circuit device 516 via the TAP pin 530. The TAP bridge circuit device 516 transmits the result data to the group encoder circuit device 520. The group encoder circuit device 520 encodes (e.g., groups) the result data and outputs the encoded result data to the FIFO 526.

[0080] Alternatively or additionally, the result data corresponding to the scan chain test is output from scan chain 536 to scan bridge circuit device 518 via scan chain pin 534. The result data is received from core logic 528. Scan bridge circuit device 518 transmits the result data to group encoder circuit device 520. Group encoder circuit device 520 encodes (e.g., groups) the result data and outputs the encoded result data to FIFO 526.

[0081] At box 950, the result data is transmitted to the test device. (Reference) Figure 3 The test controller 314 transmits the result data to the test device 340 via the communication device 316 and the communication interface 330. The result data is packetized result data. The result data is transmitted from the interconnect bridge 315 to the communication interface 330 via the interconnect 322.

[0082] Test device 340 processes the result data to determine detection errors. For example, test device 340 compares the result data with test data to determine if an error exists in the result data. In addition, test device 340 identifies the error type (e.g., boundary scan error or scan chain error) and the location of the error within IC device 310.

[0083] Figure 10 A set of exemplary processes 1000 used during the design, verification, and manufacturing of an article of art, such as an integrated circuit, are illustrated for converting and verifying design data and instructions representing the integrated circuit. Each of these processes can be constructed and implemented as multiple modules or operations. The term "EDA" stands for "Electronic Design Automation." These processes begin with the creation of a product idea 1010 with information provided by a designer, which is converted to create an article of art using a set of EDA processes 1012. When the design is completed, the design is tape-out 1034, which is when the pattern (e.g., geometric pattern) of the integrated circuit is sent to a manufacturing facility to create a mask set, which is then used to manufacture the integrated circuit. After tape-out, semiconductor dies are manufactured 1036, and packaging and assembly processes 1038 are performed to produce a finished integrated circuit 1040.

[0084] The specifications of circuits or electronic structures can range from low-level transistor material placement to high-level description languages. Hardware description languages ​​(“HDLs”) such as VHDL, Verilog, SystemVerilog, SystemC, MyHDL, or OpenVer can be used to design circuits and systems using high-level examples. HDL descriptions can be translated into logic-level register-transfer-level (“RTL”) descriptions, gate-level descriptions, placement-level descriptions, or mask-level descriptions. Each lower level adds more useful details to the design description, such as including more details of the described modules. Lower levels can be computer-generated, exported from design libraries, or created by another design automation process. An example of a specification language used to specify more detailed descriptions is SPICE, which is used for detailed descriptions of circuits with many analog components. The description at each level is allowed to be used by the corresponding tool for that layer (e.g., a formal verification tool). The design process can use… Figure 10 The order shown. The EDA product (or tool) should enable the described process.

[0085] During system design phase 1014, the functionality of the integrated circuit to be manufactured is specified. The design can be optimized for desired characteristics such as power consumption, performance, area (physical and / or lines of code), and cost reduction. At this stage, the design can be divided into different types of modules or components.

[0086] During logic design and functional verification (1016), modules or components in a circuit are specified using one or more description languages, and the functional accuracy of the specifications is checked. For example, components of a circuit can be verified to generate outputs that match the specification requirements of the designed circuit or system. Functional verification can use simulators and other programs, such as testbench generators, static HDL checkers, and formal verifiers. In some embodiments, a specific system of components, referred to as a “simulator” or “prototype system,” is used to accelerate functional verification.

[0087] During the synthesis and design of the 1018 test circuit, HDL code is converted into a netlist. In some embodiments, the netlist can be a graphical structure, where the edges of the graphical structure represent components of the circuit, and the nodes of the graphical structure represent how the components are interconnected. Both HDL code and netlist are hierarchical artifacts that EDA products can use to verify that the integrated circuit was manufactured according to a specified design. The netlist can be optimized for a target semiconductor manufacturing technology. Furthermore, the completed integrated circuit can be tested to verify that it meets specification requirements.

[0088] During netlist verification 1020, the netlist is checked to ensure it conforms to timing constraints and HDL code. During design planning 1022, the overall layout of the integrated circuit is constructed and analyzed for timing and top-level routing.

[0089] During the layout or physical implementation of 1024, physical layout (location of circuit components such as transistors or capacitors) and routing (connection of circuit components through multiple conductors) occur, and cells can be selected from a library to enable specific logic functions. As used herein, the term "cell" can specify a set of transistors, other components, and interconnections that provide Boolean logic functions (e.g., AND, OR, NOT, XOR) or storage functions (e.g., flip-flops or latches). As used herein, a circuit "block" can refer to two or more cells. Both cells and circuit blocks can be referred to as modules or components and are implemented as physical structures and simulations. Parameters (based on "standard cells"), such as dimensions, are specified for selected cells and accessed in a database for use in EDA products.

[0090] During Analysis and Extraction 1026, circuit functionality is verified at the layout level, allowing for improvements to the layout design. During Physical Inspection 1028, the layout design is checked to ensure that manufacturing constraints are correct, such as DRC constraints, electrical constraints, lithographic constraints, and that circuit functionality matches the HDL design specifications. During Resolution Enhancement 1030, the layout geometry is transformed to improve the fabrication methods of the circuit design.

[0091] During the tape-out process, data is created for the production of a photomask (if appropriate, after the application of lithographic enhancement). During mask data preparation 1032, the "tape-out" data is used to generate a photomask that is used to produce the finished integrated circuit.

[0092] Computer systems (e.g.) Figure 11 The storage subsystem of the computer system 1100 can be used to store programs and data structures used by some or all of the EDA products described herein, as well as products for developing libraries and for physical and logical designs of the libraries.

[0093] Figure 11 An exemplary machine of computer system 1100 is shown, in which a set of instructions can be executed to cause the machine to perform any one or more methods discussed herein. In alternative implementations, the machine may be connected (e.g., networked) to other machines in a LAN, intranet, extranet, and / or the Internet. The machine may operate as a server or client machine in a client-server network environment, as a peer-to-peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0094] The machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, web device, server, network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) specifying the actions to be taken by the machine. Furthermore, although a single machine is shown, the term "machine" should also be understood to include any collection of machines that individually or jointly execute a set (or more) of instructions to perform any one or more methods discussed herein.

[0095] Example computer system 1100 includes processing devices 1102 that communicate with each other via bus 1130, main memory 1104 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), static memory 1106 (e.g., flash memory, static random access memory (SRAM), etc.), and data storage devices 1118.

[0096] Processing device 1102 represents one or more processors, such as a microprocessor, a central processing unit, etc. More specifically, the processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor that implements other instruction sets, or a processor that implements combinations of instruction sets. Processing device 1102 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 1102 may be configured to execute instructions 1126 for performing the operations and steps described herein.

[0097] The computer system 1100 may also include a network interface device 1108 that communicates via a network 1120. The computer system 1100 may also include a video display unit 1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 1112 (e.g., a keyboard), a cursor control device 1114 (e.g., a mouse), a graphics processing unit 1122, a signal generation device 1116 (e.g., a speaker), a graphics processing unit 1122, a video processing unit 1128, and an audio processing unit 1132.

[0098] Data storage device 1118 may include machine-readable storage medium 1124 (also referred to as non-transient computer-readable medium) on which one or more sets of instructions 1126 or software embodying any one or more methods or functions described herein are stored. During execution by computer system 1100, instructions 1126 may also reside wholly or at least partially in main memory 1104 and / or processing device 1102, which also constitute machine-readable storage media.

[0099] In some implementations, instruction 1126 includes instructions that implement functions corresponding to this disclosure. Although machine-readable storage medium 1124 is shown as a single medium in the example implementation, the term "machine-readable storage medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more sets of instructions. The term "machine-readable storage medium" should also be understood to include any medium capable of storing or encoding a set of instructions executable by a machine and causing the machine and processing device 1102 to perform any one or more methods of this disclosure. Therefore, the term "machine-readable storage medium" should be understood to include, but is not limited to, solid-state memories, optical media, and magnetic media.

[0100] Certain parts of the foregoing detailed description are presented based on algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are the methods used by those skilled in the art of data processing to most effectively communicate the substance of their work to others skilled in the art. An algorithm can be a sequence of operations that leads to a desired result. These operations are those that require the physical manipulation of physical quantities. These quantities can take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Such signals can be referred to as bits, values, elements, symbols, characters, terms, numbers, etc.

[0101] However, it should be remembered that all these and similar terms will be associated with appropriate physical quantities and are merely convenient notations applied to those quantities. Unless otherwise stated, as is apparent from this disclosure, it should be understood that throughout the specification, certain terms refer to the actions and processes of a computer system or similar electronic computing device that manipulate and convert data representing physical (electronic) quantities within the registers and memories of the computer system into other data representing physical quantities similarly represented within the computer system's memory or registers or other such information storage devices.

[0102] This disclosure also relates to an apparatus for performing the operations described herein. The apparatus may be specifically constructed for its intended purpose, or it may comprise a computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0103] The algorithms and demonstrations presented herein do not inherently relate to any particular computer or other device. Various other systems can be used with the program based on the teachings herein, or it may prove convenient to construct more specialized devices to perform the method. Furthermore, this disclosure is described without reference to any particular programming language. It should be understood that the teachings of the invention described herein can be implemented using a variety of programming languages.

[0104] This disclosure can be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, which can be used to program a computer system (or other electronic device) to perform processes according to this disclosure. Machine-readable media include any mechanism for storing information in a machine-readable (e.g., computer-readable) form. For example, machine-readable (e.g., computer-readable) media include machine-readable (e.g., computer-readable) storage media, such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory devices, etc.

[0105] In the foregoing disclosure, implementations of this disclosure have been described with reference to specific example implementations thereof. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of the implementations of this disclosure as set forth in the following claims. Where elements are referred to in the singular in this disclosure, more than one element may be depicted in the drawings, and the same elements are labeled with the same numerals. Therefore, this disclosure and the drawings are to be considered illustrative rather than restrictive.

Claims

1. An integrated circuit device, comprising: The test control circuit device includes a test access port circuit device and a scan chain circuit device; as well as A test controller, electrically coupled to the test control circuit device, the test controller comprising: A packet decoder circuit is configured to decode packet test mode data to identify configuration data for the test controller and test data for the test control circuit. A test access port bridge circuit device, connected to the packet decoder circuit device and configured to receive the test data and transmit the test data to the test control circuit device; and A scan bridge circuit device, connected to the packet decoder circuit device and configured to receive the test data and transmit the test data to the test control circuit device, wherein the test controller is configured to packetize result data received from the test control circuit device, wherein the result data corresponds to errors identified by tests performed based on the test data.

2. The integrated circuit device according to claim 1, further comprising: The communication equipment is configured as follows: Receive the test mode data of the group from the test equipment; as well as The test mode data of the group is transmitted to the test controller.

3. The integrated circuit device according to claim 1, wherein the test data corresponds to one of the test access port circuit device and the scan chain circuit device.

4. The integrated circuit device of claim 1, wherein the test controller further comprises: A group encoder circuit device, connected to the test access port bridge circuit device and the scan bridge circuit device, is configured to: Receive result data from the test access port bridge circuit device and the scan bridge circuit device; The resulting data is grouped as described above; as well as The grouped result data is output to the test device.

5. The integrated circuit device of claim 1, wherein the packet decoder circuitry is further configured to accumulate packet test mode data before decoding the packet test mode data.

6. A method for generating result data from test data, comprising: Receive group test mode data from the test equipment; The packet test mode data is decoded by the packet decoder circuit of the test controller of the integrated circuit device to identify the configuration data and test data of the test controller; The test data is transmitted to the test access port circuit of the test control circuit via the test access port bridge circuit of the test controller. The test data is transmitted to the scan chain circuit of the test control circuit via the scan bridge circuit of the test controller. The result data received from the test control circuit device is grouped, wherein the result data corresponds to errors identified by tests performed within the integrated circuit device based on the test data; as well as The grouped result data is output from the integrated circuit device to the test device.

7. The method of claim 6, wherein the group test mode data is received via a communication device of the integrated circuit device, and the method further comprises transmitting the group test mode data from the communication device to the test controller.

8. The method of claim 6, wherein the test data corresponds to one of the test access port circuit device and the scan chain circuit device.

9. The method of claim 6, further comprising: The result data is received from the test access port bridge circuit and the scan bridge circuit via the group encoder circuit of the test controller, wherein the group encoder circuit is configured to group the result data.

10. The method of claim 8, further comprising accumulating the grouped test pattern data before decoding the grouped test pattern data.

11. A test controller for an integrated circuit device, comprising: The interconnecting bridge circuit device is configured to receive packet test mode data; as well as Test bridge circuit device, including: A packet decoder circuitry is configured to decode the packet test mode data to identify configuration data and test data for a test control circuitry of the integrated circuit device. A test access port bridge circuit device is configured to receive test data from the packet decoder circuit device and transmit the test data to the test access port circuit device of the test control circuit device; and A scan bridge circuit device is configured to receive the test data and transmit the test data to a scan chain circuit device of the test control circuit device; The test bridge circuit device is configured to group result data received from the test control circuit device, wherein the result data corresponds to errors identified by tests performed based on the test data.

12. The test controller of claim 11, wherein the group test mode data is received from the test device by a communication device, and wherein the communication device is connected to the interconnect bridge circuit device and configured to transmit the group test mode data to the test bridge circuit device via the interconnect bridge circuit device.

13. The test controller of claim 11, wherein the test data corresponds to one of the test access port circuit device and the scan chain circuit device.

14. The test controller of claim 11, wherein the test bridge circuitry further comprises: A group encoder circuit device, connected to the test access port bridge circuit device and the scan bridge circuit device, is configured to: Receive result data from the test access port bridge circuit device and the scan bridge circuit device; The resulting data is grouped as described above; as well as The grouped result data is output to the test device.

Images