A Breakthrough In Silicon Bring-Up

The current semiconductor market is seeing increasingly complex silicon devices for applications like 5G wireless communications, autonomous driving, and artificial intelligence. One of the ways designers are working to control design time and cost is through the adoption of IJTAG (IEEE 1687) for a plug-and-play style IP integration during design. The benefits of using IJTAG are still emerging, as it allows for access and control of any embedded ‘instrument’ on a chip.

Using IJTAG makes such a difference when integrating IP because the amount of IP on SoCs is increasing all the time. According to Semico Research, IP reuse accounts for more than 60% of design starts (Fig 1). Using standardized blocks can reduce complexity, but also creates new challenges for accessing all the diverse on-chip ‘instruments.’ IJTAG allows for the easy access and control of IP, whether it’s from internal design groups of from 3rd-party providers.

Figure 1: Semico Research Corporation, “Licensing, Royalty, and Service Revenues For 3rd Party SIP: A Market Analysis and Forecast for 2018.”

Although IJTAG has been great for streamlining IP integration during the design phase, the industry did not immediately leverage the power of the ITJAG network to solve the problems during IP evaluation and debug during silicon bring-up. In-house IP can be thoroughly evaluated in the IP development phase on TEG (Test Element Group) chips and are considered “trusted” IP. Third-party IP carries more uncertainty and risk, so IP evaluation and debug in silicon bring-up becomes an important factor for quick production yield ramp-up.

Traditionally, design engineers create test patterns for scan, JTAG, and BIST in STIL format. These test patterns are then converted to a tester-specific format and executed by test engineers on ATE. The results are sent back to the designers as STDF or TXT files, which need to be translated into chip failure data and sent back to the DFT engineers to be processed by diagnosis tools. It is the DFT engineers, not the ATE test engineers, who play the main role in IP evaluation and debug. The result can be several of these long iterations that delay time-to-market (Fig 2).

Figure 2: IP evaluation requires significant learning and is prone to errors causing increased cycle time.

Even if the DFT engineer could be involved in 3rd-party IP evaluation and debug in real-time with the device on ATE, it is common for the DFT engineer to be located far from the test engineer’s site where the ATEs are placed. Using a graphical online meeting tool to share ATE graphical tools is better than nothing, but it isn’t a great solution.

But now, there is a way to bridge that gap between DFT and ATE so the DFT software can send test patterns directly to a tester, execute the tests, collect the results, and make modifications. The IJTAG network allows for the creation of an industry-standard interface to eliminate communication barriers between proprietary tester-specific software and DFT platforms. Once communication between the DFT software and the ATE is established, all the time-consuming middle steps of translations and data transfer are eliminated from the task of silicon-bring up (Fig 3).

Figure 3. ATE-Connect works with Teradyne and Advantest testers.

The result is to accelerate debug of IJTAG-compliant IP (instruments), helping speed-up product ramps, and reducing time-to-market for products in 5G wireless communications, autonomous driving, and artificial intelligence.

Using the TCP/IP network protocol, ATE-Connect provides IJTAG commands to the device under test and receives data from the device on the ATE while keeping the sensitive design information in the realm of Tessent SiliconInsight, only providing the required stimulus to the device under test on the ATE. Using this standard network communication, customers can leverage their existing secure networks to enable seamless interaction with testers around the globe.

This IP debug flow requires only a chip-level ICL file and PDL files (along with related Tcl procedures if needed). The DFT engineer can specify IJTAG commands in Tcl-based DFT software environment. IJTAG commands such as iRead and iWrite are cumulatively kept on the DFT tool environment, and IJTAG commands such as iApply, iReset and iCall incrementally send IJTAG protocols to the ATE. The tool environment reports the execution results as ICL network register values, and the Tcl program can process these register values as variables.

Enabling direct communication between platform tester and DFT software solves the key problems of IJTAG-based IP evaluation and debug. Some of the key benefits include:

• It can be run by the DFT engineers and designers in a protocol-based flow instead of a pattern-based flow by using IJTAG commands.
• It allows DFT engineers and designers to use their familiar Tcl-based Tessent Shell interface.
• It allows DFT engineers and designers to access ATE remotely with incremental and light-weight communication through TCP.

Directly linking the power of IJTAG with the ATE eliminates a significant bottleneck in the silicon debug and characterization processes, reducing silicon bring-up from weeks to days so silicon can get to the customers faster.