In-System/In-Field Testing Using High-Quality Deterministic Test Patterns

The amount of electronic content in passenger cars is growing rapidly, primarily due to the integration of advanced safety features. The shift towards fully autonomous vehicles, which must comply with stringent safety standards, will further increase the number of electronic components required. Testing efforts must be of exceptional quality. The target test time is often limited to less than 10 milliseconds, with a defect tolerance greater than 99% and a non-latent defect rate of more than 90%. Pseudo-random testing patterns are inadequate for meeting these stringent requirements. Generating deterministic patterns that comply with the automotive safety standards outlined in the American National Standards Institute (ANSI) ISO 26262 standard is required. ISO 26262 is a comprehensive recommendation that covers all aspects of the automotive hardware and software lifecycle from design to testing and regular in-field operation.

Need for deterministic in-system test

Aggressive test-time requirements, design complexity and updating test content based on defectivity rates necessitate using in-system deterministic test (IS-EDT) methods that combine the generation and retargeting of deterministic test patterns. Tessent In-System Test, a Siemens EDA solution that combines IS-EDT with Tessent Streaming Scan Network (SSN), allows users to run deterministic patterns in-system. While the need for IS-EDT patterns is particularly significant in the automotive industry, their use extends beyond this sector; data center and networking designs can also benefit from this technology.

Automotive electronic applications are classified into four Automotive Safety Integrity Levels (ASILs) – A through D, with ASIL A being the least critical and ASIL D being the most critical, with fatal consequences resulting from compromise. Sophisticated testing methods are designed to meet the specific test standards required for each ASIL category. Safety-critical automotive applications that require ASIL-D certification will benefit from the use of this new technology.

Automotive manufacturers worldwide are adopting and strictly adhering to these established guidelines. Many of these methods rely on Built-In Self-Test (BIST) techniques for testing memory and logic, including in-field or mission-mode testing, which can be conducted during manufacturing or at any stage of the product’s life cycle. LBIST is the proven conventional solution for meeting automotive testing standards. However, it can be challenging for pseudo-random LBIST patterns to achieve high-quality testing requirements due to increased design complexity. LBIST is especially sensitive to unknown state propagation within the design, necessitating a scheme to fence the X-propagation due to these unknowns. The X-masking schemes introduce additional area and timing overhead.

Fig. 1: Conventional in-system test implementations using LBIST.

The Tessent product family has numerous deterministic ATPG and in-system test solutions. The In-System Embedded Deterministic Test solution is based on the combination of Tessent SSN and Tessent In-System Test. Tessent SSN is the Tessent solution for packetized deterministic test data streaming; Tessent In-System Test provides the hardware solution for implementing an in-system test controller (IST). It enables the generation and retargeting of deterministic test patterns using SSN through the IST controller. The protocol for delivering the data is to use the SSN parallel data bus or to operate the single datapath in a special SSN mode. Tessent In-System Test can be used to test safety-critical automotive applications, data center applications and networking designs.

In-system test

Tessent In-System Test caters to all in-system test needs. A superset of its predecessor, Tessent MissionMode, it can be used for IS-EDT implementations. Tessent In-System Test supports the AXI-subordinate interface for the IST controller (ISTC). Of the various interfaces supported by Tessent In-System Test, the subordinate interfaces for Advanced Peripheral Bus (APB) and Advanced eXtensible Bus (AXI) are the only ones that support IS-EDT patterns. Since published material on the Mission Mode (MM) Direct Memory Access (DMA) interface is available [1], we will focus this discussion on the APB and AXI subordinate interfaces of ISTC, particularly in the context of IS-EDT implementations. In either case, the IJTAG interface of the ISTC delivers the configuration data, while the SSN interface of the ISTC delivers the scan payload. Due to the high volume of deterministic test patterns, they are typically stored off-chip in an external memory.

Fig. 2: Tessent In-System Test is a superset of Tessent MissionMode.

APB subordinate interface for ISTC

With the APB subordinate interface, the ISTC can be connected to an APB bridge, which in turn is connected to a CPU subsystem. The ISTC’s APB subordinate interface features ports of the APB protocol that are relevant for IST operation.

Fig. 3: ISTC with APB subordinate interface.

In IST mode, the PCLK provides clocking for the SSN data bus. APB protocol requires at least two PCLK cycles to perform write or read transactions. A single SSN clock cycle has both a write and a read operation on the datapath, which translates to a minimum of four PCLK cycles. The APB protocol also restricts the bus size to 32 bits, which implies that throughput will be compromised for SSN configurations with datapath widths greater than 32 bits.

AXI subordinate interface for ISTC

When implemented with an AXI subordinate interface, the ISTC operates as a peripheral subordinate to the AXI bus and can be used with high-speed buses in the design-under-test (DUT). The AXI protocol supports data bus widths up to 1024 bits, although the limit is set by the design as well. The AXI subordinate interface also accounts for read/write FIFOs that ensure bandwidth matching between the AXI and SSN buses. An AXI manager, such as a CPU, initiates write and read transactions. As an AXI subordinate, the IST controller receives write data from and provides read data to the CPU/manager. The IST controller can only act in a subordinate role on the AXI interconnect. This means that a manager in the AXI interconnect (such as a CPU or system DMA) must initiate the transfer of test program data, including stimulus and responses, to and from the IST controller. The AXI protocol has many ports, but only those relevant for IST operation are present in the ISTC. The AXI subordinate interface has the best throughput of all supported ISTC interfaces.

Fig. 4: ISTC with AXI subordinate interface.

Gate count for AXI subordinate interface

Here we present the normalized gate counts for several configurations for the AXI subordinate interface-based ISTC. Table 1 describes the two configurations used. Configuration 1 utilizes the FastIJTAG feature with IST, while configuration 2 employs a memory without read enable, allowing you to observe the area impact with FIFO pipelining enabled.

Configuration 1

Configuration 2

Table 1: Gate count for ISTC-AXI configurations.

Deciding the ISTC interface

The table below compares the three supported ISTC interfaces to help you make an informed choice. Finalizing an interface requires considering various aspects, such as the application, the amount of debugging necessary, the desired throughput and the area.

Table 2: ISTC interfaces and features supported.

ISTC implementations

When using an AMBA bus-based subordinate interface for the ISTC, the controller is fully ready to support either DFT techniques – BIST or IS-EDT (Figure 5). It is possible to use a single ISTC for both BIST and IS-EDT implementations when using APB or AXI subordinates. The IJTAG interface of the ISTC connects to the downstream IJTAG network that feeds the BISTs and delivers configuration data in IST mode. The SSN interface of the ISTC is responsible for connecting to all Streaming Scan Hosts of the cores connected along the IST path. This is also responsible for delivering scan payload to the design in IST mode. The essence of the IS-EDT implementations is for the ISTC to intercept the SSN datapath, in part or whole, thereby enabling IST mode operation in addition to the regular GPIO mode.

Fig. 5: Tessent In-System Test Controller interfacing with both BIST and SSH.

Each ISTC has a single SSN interface and hence can intercept only a single SSN datapath. Figure 5 provides a comprehensive overview of the ISTC’s current design status and its connection to the AXI/APB system bus, which is driven by the CPU subsystem.

Flow

Tessent In-System Test’s flow, in general, and the IS-EDT flow, in particular, follow the standard approach for all Tessent solutions. The sequence of steps involves IP insertion, synthesis, scan insertion and finally ATPG. These constitute a robust, highly automated and streamlined flow that makes it easy to follow, debug and learn. All output files are written in an organized database.

One of the key aspects of the ISTC insertion is that it intercepts the SSN datapath. The user is at liberty to decide whether the ISTC intercepts the entire SSN datapath from the input ports to the output ports or if it intercepts only a section of the datapath by excluding specific nodes. When the ISTC intercepts the datapath, the tool adds a multiplexer to switch between GPIO and IST mode of operation. Figure 6 illustrates a simple case where the ISTC intercepts the entire SSN datapath.

Fig. 6: ISTC intercepting SSN datapath.

As described above, the multiplexer enables switching between the modes of operation. During pattern generation, the user must enable the secondary input path of the mux to generate IS-EDT patterns. Figure 7 provides an overview of the overall flow for IS-EDT, excluding interim steps such as synthesis and scan insertion. During pattern retargeting, the tool writes out the testbench, a transactions file and a C program for each pattern. The transactions file provides better readability of the APB or AXI transactions routed through the ISTC.

Fig. 7: Standard Tessent flow for IS-EDT hardware insertion and pattern generation.

The testbench simulations serve as immediate verification of the ISTC inputs without validating CPU connectivity, as the ISTC inputs are directly forced in the testbench. If the CPU is not present at this level, the transactions file can be used for verification using a standard Verification IP (VIP). When the CPU is present, the C program-based verification provides the functional verification of the ISTC. As it involves integrating with the design verification environment, it requires expertise beyond DFT. Numerous unique types of patterns exist to verify various instances of IS-EDT implementation.

Conclusion

Meeting the quality and reliability requirements of complex designs is becoming increasingly challenging. Conventional methods, such as logic BIST, often fall short of these stringent requirements. This issue is particularly relevant for specific applications, including safety-critical devices in automotive designs, data center infrastructures and networking solutions. To address these challenges, employing in-system deterministic test patterns with In-System Embedded Deterministic Testing can significantly reduce test application time without sacrificing test quality.

This approach offers a robust and streamlined DFT flow for logic testing. Tessent In-System Test is designed to meet IS-EDT requirements. It provides two advanced interface options for the In-System Test Controller —APB or AXI. Both options are sophisticated and hardware-efficient, allowing users to choose based on specific design needs such as area overhead, throughput and clock speeds, among other factors. This flow promises to be a simpler yet more reliable alternative to existing solutions that rely on pseudo-random patterns.

To read more on Tessent In-System Test, please visit www.siemens.com/tessent.

Reference

1. Siemens-SW-IC-test-solutions-for-the-automotive-market-WP-81124-C2.pdf