Online Testing of Embedded Systems - 2 | Embedded Systems (Web) - Computer Science Engineering (CSE) PDF Download

Non-concurrent testing

This form of testing is either event-triggered (sporadic) or time-triggered (periodic) and is characterized by low space and time redundancy. Event triggered testing is initiated by key events or state changes such as start-up or shutdown, and its goal is to detect permanent faults. Detecting and repairing permanent faults as soon as possible is usually advisable. Eventtriggered tests resemble manufacturing tests. Any such test can be applied online, as long as the required testing resources are available. Typically, the hardware is partitioned into components, each exercised by specific tests. RAMs, for instance, are tested with manufacturing tests such as March tests [3].

Time-triggered testing occurs at predetermined times in the operation of the system. It detects permanent faults, often using the same types of tests applied by event-triggered testing. The periodic approach is especially useful in systems that run for extended periods during which no significant events occur to trigger testing. Periodic testing is also essential for detecting intermittent faults. Such faults typically behave as permanent faults for short periods. Since they usually represent conditions that must be corrected, diagnostic resolution is important. Periodic testing can identify latent design or manufacturing flaws that appear only under certain environmental conditions. Time-triggered tests are frequently partitioned and interleaved so that only part of the test is applied during each test period.

Concurrent testing

Non-concurrent testing cannot detect transient or intermittent faults whose effects disappear quickly. Concurrent testing, on the other hand, continuously checks for errors due to such faults. However, concurrent testing is not particularly useful for diagnosing the source of errors, so test designers often combine it with diagnostic software. They may also combine concurrent and non-concurrent testing to detect or diagnose complex faults of all types.

A common method of providing hardware support for concurrent testing, especially for detecting control errors, is a watchdog timer [4]. This is a counter that the system resets repeatedly to indicate that the system is functioning properly. The watchdog concept assumes that the system is fault-free—or at least alive—if it can reset the timer at appropriate intervals. The ability to perform this simple task implies that control flow is correctly traversing timer-reset points. One can monitor system sequencing very precisely by guarding the watchdog- reset operations with software-based acceptance tests that check signatures computed while control flow traverses various checkpoints. To implement this last approach in hardware, one can construct more complex hardware watchdogs.

A key element of concurrent testing for data errors is redundancy. For example, the duplication-with-comparison (DWC) technique5 detects any single error at the expense of 100% space redundancy. This technique requires two copies of the CUT, which operate in tandem with identical inputs. Any discrepancy in their outputs indicates an error. In many applications, DWC’s high hardware overhead is unacceptable. Moreover, it is difficult to prevent minor timing variations between duplicated modules from invalidating comparison.

A possible lower-cost alternative is time redundancy. A technique called double execution, or retry, executes critical operations more than once at diverse time points and compares their results. Transient faults are likely to affect only one instance of the operation and thus can be detected. Another technique, re-computing with shifted operands (RESO) [5] achieves almost the same error coverage as DWC with 100% time redundancy but very little space redundancy. However, no one has demonstrated the practicality of double execution and RESO for online testing of general logic circuits.

A third, widely used form of redundancy is information redundancy—the addition of redundant coded information such as a parity-check bit[5]. Such codes are particularly effective for detecting memory and data transmission errors, since memories and networks are susceptible to transient errors. Coding methods can also detect errors in data computed during critical operations.

Built-in self-test

For critical or highly available systems, a comprehensive online-testing approach that covers all expected permanent, intermittent, and transient faults is essential. In recent years, BIST has emerged as an important method of testing manufacturing faults, and researchers increasingly promote it for online testing as well.

BIST is a design-for-testability technique that places test functions physically on chip with the CUT, as illustrated in Figure 42.1. In normal operating mode, the CUT receives its inputs from other modules and performs the function for which it was de-signed. In test mode, a test pattern generator circuit applies a sequence of test patterns to the CUT, and a response monitor evaluates the test responses. In the most common type of BIST, the response monitor compacts the test responses to form fault signatures. It compares the fault signatures with reference signatures generated or stored on chip, and an error signal indicates any discrepancies detected. We assume this type of BIST in the following discussion.

In developing a BIST methodology for embedded systems, we must consider four primary parameters related to those listed earlier for online-testing techniques:

• Fault coverage—the fraction of faults of interest that the test patterns produced by the test generator can expose and the response monitor can detect. Most monitors produce a faultfree signature for some faulty response sequences, an undesirable property called aliasing.
• Test set size—the number of test patterns produced by the test generator. Test set size is closely linked to fault coverage; generally, large test sets imply high fault coverage. However, for online testing, test set size must be small to reduce fault and error latency.
• Hardware overhead—the extra hardware needed for BIST. In most embedded systems, high hardware overhead is not acceptable.
• Performance penalty—the impact of BIST hardware on normal circuit performance, such as worst-case (critical) path delays. Overhead of this type is sometimes more important than hardware overhead. 

System designers can use BIST for non-concurrent, online testing of a system’s logic and memory[6]. They can readily configure the BIST hardware for event-triggered testing, tying the BIST control to the system reset so that testing occurs during system start-up or shutdown. BIST can also be designed for periodic testing with low fault latency. This requires incorporating a test process that guarantees the detection of all target faults within a fixed time.

Designers usually implement online BIST with the goals of complete fault coverage and low fault latency. Hence, they generally design the test generator and the response monitor to guarantee coverage of specific fault models, minimum hardware overhead, and reasonable test set size. Different parts of the system meet these goals by different techniques.

Test generator and response monitor implementations often consist of simple, counter like circuits; especially linear- feedback shift registers [5]. An LFSR is formed from standard flipflops, with outputs of selected flip-flops being fed back (modulo 2) to its inputs. When used as a test generator, an LFSR is set to cycle rapidly through a large number of its states. These states, whose choice and order depend on the LFSR’s design parameters, define the test patterns. In this mode of operation, an LFSR is a source of pseudorandom tests that are, in principle, applicable to any fault and circuit types. An LFSR can also serve as a response monitor by counting (in a special sense) the responses produced by the tests. After receiving a sequence of test responses, an LFSR response monitor forms a fault signature, which it compares to a known or generated good signature to determine whether a fault is present.

Ensuring that fault coverage is sufficiently high and the number of tests is sufficiently low are the main problems with random BIST methods. Researchers have proposed two general approaches to preserve the cost advantages of LFSRs while greatly shortening the generated test sequence. One approach is to insert test points in the CUT to improve controllability and observability. However, this approach can result in performance loss. Alternatively, one can introduce some determinism into the generated test sequence—for example, by inserting specific “seed tests” known to detect hard faults.

Some CUTs, including data path circuits, contain hard-to detect faults that are detectable by only a few test patterns, denoted Thard. An N-bit LSFR can generate a sequence that eventually includes 2N - 1 patterns (essentially all possibilities). However, the probability that the tests in Thard will appear early in the sequence is low. In such cases, one can use deterministic testing, which tailors the generated test sequence to the CUT’s functional properties, instead of random testing. Deterministic testing is especially suited to RAMs, ROMs, and other highly regular components. A deterministic technique called transparent BIST [3] applies BIST to RAMs while preserving the RAM contents—a particularly desirable feature for online testing. Keeping hardware overhead acceptably low is the main difficulty with deterministic BIST.

A straightforward way to generate a specific test set is to store it in a ROM and address each stored test pattern with a counter. Unfortunately, ROMs tend to be much too expensive for storing entire test sequences. An alternative method is to synthesize a finite-state machine that directly generates the test set. However, the relatively large test set size and test vector width, as well as the test set’s irregular structure, are much more than current FSM synthesis programs can handle.

Another group of test generator design methods, loosely called deterministic, attempt to embed a complete test set in a specific generated sequence. Again the generated tests must meet the coverage, overhead, and test size constraints we’ve discussed. An earlier article [7] presents a representative BIST design method for data path circuits that meets these requirements. The test generator’s structure, based on a twisted-ring counter, is tailored to produce a regular, deterministic test sequence of reasonable size. One can systematically rescale the test generator as the size of anon-bit-sliced data path CUT, such as a carry-look-ahead adder, changes. Instead of using an LFSR, a straightforward way to compress test response data and produce a fault signature is to use an FSM or an accumulator. However, FSM hardware overhead and accumulator aliasing are difficult parameters to control. Keeping hardware overhead acceptably low and reducing aliasing are the main difficulties in response monitor design.

Fig. 42.1 A General BIST Scheme

An Example

IEEE 1149.4 based Architecture for OLT of a Mixed Signal SoC

Analog/mixed signal blocks like DCDC converters, PLLs, ADCs, etc. and digital modules like application specific processors, micro controllers, UATRs, bus controllers etc. typically exist in SoCs. The have been used as cores of the SoC benchmark “Controller for Electro-Hydraulic Actuators” which is being used as the case study. It is to be noted that this case study is used only for illustration and the architecture is generic which applies for all Mixed Signal SoCs.

All the digital blocks like instruction specific processor, microcontroller, bus controller etc. have been designed with OLT capability using the CAD tool descried in [8]. Further, all these digital cores are IEEE 1149.1 compliant. In other words, all the digital cores are designed with a blanket comprising an on-line monitor and IEEE 1149.1 compliance circuitry. For the analog modules the observer have been designed using ADCs and digital logic [9]. The test blanket for the analog/mixed signal cores comprises IEEE 1149.4 circuitry. A dedicated test controller is designed and placed on-chip that schedules the various lines tests during the operation of the SoC. The block diagram of the SoC being used as the case study is illustrated in Figure 42.2. The basic functionality of the SoC under consideration is discussed below.

Electronic Controller Electro Hydraulic system

Actuator systems are vital in the flight control system, providing the motive force necessary to move the flight control surfaces. Hydraulic actuators are very common in space vehicle and flight control systems, where force/ weight consideration is very much important. This system positions the control surface of aircraft meeting performance requirement which acting against external loads. The actuator commands are processed in four identical analog servo loops, which command the four coils of force motor driving the hydraulic servo valve used to control the motion of the dual tandem hydraulic jack. The motion of the spool of the hydraulic servo valve (Master control Valve), regulates the flow of oil to the tandem jacks, thereby determine the ram position. The Spool and ram positions are controlled by means of feedback loops. The actuator system is controlled by the on-board flight electronics. A lot of work has been done for On-line fault detection and diagnosis of the mechanical system, however OLT of the electronic systems were hardly looked into. It is to be noted that as Electro Hydraulic Actuators are mainly used in mission critical systems like avionics; for reliable operation on-line fault detection and diagnosis is required for both the mechanical and the electronic sub-systems.

The IEEE 1149.1 and 1149.4 circuitry are utilized to perform the BIST of the interconnecting buses in between the cores. It may be noted that on-line tests are carried only for cores, which are more susceptible to failures. However, the interconnecting buses are tested during startup and at intervals when cores being connected by them are ideal. The test scheduling logic can be designed as suggested in [10].

The following three classes of tests are carried in the SoC:

1. Interconnect test of the interconnecting buses (BIST)

Interconnect testing is to detect open circuits in the interconnect betweens the cores, and to detect and diagnose bridging faults anywhere in the Interconnect --regardless of whether they are normally carry digital or analog signals. This test is performed by EXTEST instruction and digital test patterns are generated from the pre-programmed test controller.

2. Parametric test of the interconnecting buses (BIST)

Parametric test: Parametric test permits analog measurements using analog stimulus and responses. This test is also performed by EXTEST instruction. For this only three values of analog voltages viz., V_H=VDD, V_Low=VDD/3, V_G= VSS are given as test inputs by the controller and the voltages at the output of the line under test is sampled after one bit coarse digitization as mentioned in the IEEE 1149.4 standard

3. Internal test of the cores (Concurrent tests)

This test is performed by INTEST instruction and this enables the on-line monitors placed on each of the cores present in the SoC. This test can be enabled concurrently with the SoC operation and need not be synchronized to start up of the normal operation of the SoC. The asynchronous startup/shutdown of the on-line testers facilitates power saving and higher reliability of the test circuitry if compared to the functional circuit.