HWBIST refers to circuitry and scan patterns generated by an ATPG tool used to screen out logic failures within the targeted circuitry. This methodology is used extensively in semiconductor device testing. All C2000 devices make use of some level of hardware-assisted test during device manufacturing. Some of the newer C2000 devices support customer use of this test technology as part of their system test, to test the integrity of the CPUs (US 8,799,713 B2). This document describes how and why to make use of HWBIST at a system level.

Table 1-1 lists the terms and abbreviations used in this application report.

On C2000 devices that have HWBIST, the HWBIST targets the C28x CPU and the FPU, VCU, CRC, and TMU accelerators. Also included is the emulation analysis circuitry, which manages communications between these processing elements and the emulator, as well as manages features like breakpoints, watch points, and single stepping.

The HWBIST does not target the rest of the logic on the device. The other logic on the device may be tested with other self-test or diagnostic mechanisms as described in the device-specific safety manual.

For the availability of HWBIST, see the device-specific data sheet. You can also check the documents below for HWBIST and other functional safety features and collateral:

• Automotive Functional Safety for C2000™ Real-Time Microcontrollers
• Industrial Functional Safety for C2000™ Real-Time Microcontrollers

While this document focuses on HWBIST, for functional safety compliant C2000 devices without HWBIST (like those in the F28004x device family), a C28x Self-Test Library (C28x STL) is provided to test the integrity of the CPU logic using a software-based method. Similarly, HWBIST does not cover the Control Law Accelerator (CLA), so for devices with CLA, a separate CLA Self-Test Library (CLA STL) is available. These libraries are provided upon request—reach out to your local TI Sales Person to request access.

Figure 1-1 shows a block diagram of HWBIST, as used in the C2000 device. The orange and pink portions show the logic targeted for testing. In system use, this logic is the processing engine for the system code. Data flows through the latches as the executing system code instructs.

Figure 1-1 HWBIST Block Diagram

However, these same latches include scan access so that during tests of this logic, a high-speed test flow can validate the operation of the gates in the circuitry. In the case discussed here there are many parallel scan paths through the logic so that significant portions of the logic can be tested in parallel. While in this test mode, the logic does not operates like the processor would when running code.

The Pattern Generator provides seeds to these parallel scan paths to provide activity necessary to logically validate the operation of the targeted gates. These seeds are computer generated and the coverage is validated with standard ATPG tools. The seeds are optimized to meet a particular fault grade target in a minimum number of cycles. The vendors of these optimizers take great pride in this optimization.

The capture and MISR portion picks up the results of the scanning operation across all the parallel chains. The interaction of the stepping of the scan patterns through the paths interacts with other logic gates in the circuitry tied to the latches. The optimization software injects faults into the gates, and if the MISR does not recognize a failure, then additional seeds are necessary to validate the faulted gate. The optimizer is given a coverage target and will continue to generate seeds until this metric is met. Reaching coverage of 60% is relatively simple; reaching 95% takes significantly more seeds, and reaching 99% requires significantly more seeds than 95% does.

The clocking of the scan operations is driven by SYSCLK. The BIST controller manages how the data is shifted and clocked during the scan flow. The BIST controller also manages the loading of seeds and comparison values for the MISR. In device manufacturing test flow, the BIST controller and clock source are established using a device test port like JTAG.

This is an oversimplified description of this testing methodology. A number of detailed and scholarly articles on scan-based testing are available on the web.

As stated earlier, some C2000 devices support the use of the HWBIST to screen the CPU for logic failures in the system rather than just during device manufacture testing. Figure 1-2 shows a block diagram, which includes the additional circuitry to support this option.

Figure 1-2 HWBIST In-System Block Diagram

When using HWBIST in a device test environment, testers manage each targeted logic portion to provide the overall test of the device. However, when the device is in a system, aspects of the system may be adversely affected by the activity of the under test targeted logic. These aspects are both on the device and outside the device. For this reason, the HWBIST includes a barrier around the targeted logic so that the activity of the HWBIST testing is isolated from the rest of the system. The CPU is disconnected from peripherals and interrupt signals during a micro-run test. After the test, the core is reconnected to these signals. This is known as core bounding. In Figure 1-2, the isolation barrier is shown in green. It is also true that the logic under test must be isolated from activity elsewhere in the system. This barrier provides this as well.

However, if the system must get the attention of the CPUs under test, then it can provide interrupts. These interrupts are captured in a buffer and provided to the CPU logic under test when the BIST controller releases the targeted logic. The complete coverage testing of the targeted logic takes a while. The higher the coverage goal, the longer it takes. The BIST controller in the C2000 devices executes and validates the total coverage seeds in small portions to minimize the latency to these captured interrupts. This also addresses some of the power concerns of the higher transistor switching rates generated through the parallel scan paths.

In extreme situations, the system resources can generate an NMI that halts the HWBIST operation and brings back the CPU under test using a HWBIST Reset. As soon as the context restore is complete, the NMI vector is taken and the NMI service routine can decode the NMI flag register to determine the source of the interruption. The NMI will trap before the HWBIST software returns to the calling sequence. The user application must manage the NMI responses accordingly.

A significant difference between device-manufacturing HWBIST and in-system HWBIST, is that the device tester communicates with the BIST controller over a test port, while the in-system HWBIST uses the CPU to communicate with the BIST controller. The CPU that the HWBIST is testing, is the CPU which manages the HWBIST controller. More specifically, the C28x CPU under test, where all the latches are changed multiple times, controls the BIST operation.

Here is how this process works. Code running on the CPU does the following:

1. Initializes the mode of operation in the HWBIST, mapping the CPU reset to respond to the HWBIST return to service routine specially coded for return from HWBIST.
2. Turns on the Interrupt Capture Buffer.
3. Saves the context of the CPU and the associated code-based accelerators.
4. Starts up the small time-slice of the HWBIST execution. At this point the CPU stops being a CPU and starts being logic under test.
5. Upon completion of the small time-slice of the HWBIST execution the HWBIST controller:
   • Captures the results in a status register. If a logic failure is detected, the BIST controller generates a NMI to the CPU.
   • Generates CPU reset to the CPU logic:
     • This reset puts the CPU into a known and controlled state.
     • Upon release of this reset, the logic under test becomes a CPU again.
6. The CPU executes the HWBIST reset service routine:
   • Restores saved context
   • Shuts down residuals of the HWBIST controller operation
   • Releases the interrupts stored in the Interrupt Capture Buffer
   • Returns to the calling sequence where the HWBIST status register can be read

While the HWBIST is executing, other aspects of the system can operate as well. As previously mentioned, interrupts coming from off-chip or on-chip sources are saved in the Interrupt Capture Buffer. However, triggers mapped to DMA channels are processed while the HWBIST is actively testing the CPU. For example, system-related commands from a SCI or I2C port can be collected and moved from the port to system memory to be processed as soon as Step 6 is completed. This is because all the device buses are isolated using the HWBIST Barrier.

All of the operations listed in the previous outline are executed in the C2000 Software Diagnostic Library (SDL), which is a component of C2000Ware. The SDL provides implementations of functional safety software mechanisms to help system developers meet their safety goals. The details of how the application code can call the provided HWBIST driver are documented in the User's Guide that is included in the SDL package. The SDL User's Guide is the best source for device-specific details about HWBIST, such as supported diagnostic coverage and execution time. Look for this document in <C2000Ware install directory>/libraries/diagnostic/<device>/docs.