Diagnostic Analysis

The proposed approach at first identifies the diagnostic properties of the existing test sequence, i.e., which fault pairs can be distinguished by it, and which cannot.

The diagnostic analysis is based on simulation and determines the behavior of the network when each possible fault is present and some given input stimuli are applied.

Please note that during test application, each session may result in one of the three possible outcomes:

1. The expected output is produced: the first bit of the alternated sequence appears at the expected clock cycle on the scan output.

2. The output sequence does not include the alternated sequence: a fixed value (0 or 1) is produced on the scan output. This means that one of the TDRs in the path is faulty (stuck-at-0 or stuck-at-1).

3. The alternated sequence appears on the scan output at an unexpected time.

This means that a SIB or a ScanMux belonging to the path is faulty, i.e., works

1These faults could be tested in functional mode if suitable assumptions on the instruments can be made (e.g., if they are input instruments and the values they produce are known). However, for sake of generality, this approach is not considered in this work.

in the opposite mode than expected (e.g., a SIB is configured as asserted, but behaves as de-asserted). Hence, the path between scan input and scan output is different than the expected one.

The goal of the diagnostic analysis phase is to compute for each possible fault which is the behavior of the network, and then to determine which pairs of faults are distinguished, and which are not.

Diagnostic Analysis on TDRs

According to the presented functional fault model, faults affecting TDRs produce a different network behavior than faults affecting reconfigurable modules. Hence, all faults affecting TDRs are by definition distinguished from faults affecting reconfig-urable modules.

In order to determine which pair of TDR faults are distinguished by a given test session, one may note that if a faulty TDR exists in the RSN, at least one session will fall into case 2 (among the three outcomes mentioned above). The faulty TDR can thus be identified by checking which sessions fail. All sessions whose path includes it should fail. In other words, the following properties can be stated:

• If two TDRs belong to the same segment, they will always appear together in any session, and all the related faults are undistinguishable.

• If two TDRs belong to different segments, but appeared together in all sessions of the current diagnostic sequence, the related faults are undistinguished.

Hence, the algorithm for diagnostic analysis should:

1. identify all TDRs tested in each session;

2. for each pair of TDRs, check whether there is at least one session, in which only one of the two TDRs appear:

(a) if this is the case, the two TDRs are marked as distinguished;

(b) otherwise, the two TDRs are marked as undistinguished.

Diagnostic Analysis on Reconfigurable Modules

In order to determine which fault pairs composed of faults affecting SIBs and ScanMuxes are distinguished by a given test session, one may note that if a faulty

SIB or ScanMux exists in the network (according to the presented fault model), at least one session will fall into case 3. By looking at when the alternated sequence appears on the scan output, the length of the path existing between the scan intput and scan output pins is obtained. Using this length, a diagnostic procedure can try to identify the faulty SIB or ScanMux. In practice, the faulty paths should be preliminary computed for every session S_i.

By computing, for every session S_i, the related fault set SFS_i, the following properties can be stated:

1. given a session S_iin the existing test sequence, all faults belonging to SFS_i are distinguished from all faults related to SIBs and ScanMuxes which do not belong to the session path; in fact, if one of the faults in SFS_iarises, S_i will produce a failure, and a diagnostic procedure will be able to state that the fault responsible for the failure belongs to SFS_i;

2. given S_iin the existing test sequence, and for every pair of faults both belonging to SFS_i, they can be distinguished one from the other if the two faulty paths have different lengths.

Using the example RSN of Fig. 5.6, and focusing a session S_iwhich selects the path highlighted in Fig. 7.1a, the diagnostic analysis will come to the following conclusions:

• in case the network is fault free, the first bit of the alternated sequence will appear on TDO 11 clock cycles after it has been shifted in through TDI;

• in case any FF in TDR₂is affected by a fault, the alternated sequence will not appear on TDO; by looking at the fixed value on TDO one can understand whether the fault is a stuck-at-0 or stuck-at-1; faults on TDR2are distinguished from all the other TDR faults, since any other TDR fault will not cause any effect during this session;

• in case a stuck-at-asserted fault in SIB1 exists in the network, the segment controlled by SIB₁will be added to the active path; thus, the faulty path length will be increased by the length of TDI1(i.e., 11 + 8 = 19);

• in case of SIB₂stuck-at-de-asserted fault, the segment it controls will be re-moved from the active path, which simply becomes TDI→sc1→sc₂→sc₃→TDO;

the faulty path length will be reduced by the length of TDR2(i.e., 11 − 8 = 3):

the first bit of the alternated sequence will appear on TDO three clock cycles after having being shifted-in;

0 Fig. 7.1 Examples of active path in a RSN and related faulty path lengths

• in case of ScanMux stuck-at-0 (or stuck-at-up), the selected segment will be the one including TDR₀, thus the active path length becomes 3 (i.e., the length of TDR₀plus one);

• the faults SIB₁stuck-at-asserted is distinguished from SIB₂stuck-at-de-asserted and ScanMux stuck-at-0, since the latter will produce different observable misbehavior during S_i; moreover, SIB₂ stuck-at-de-asserted and ScanMux stuck-at-0 are undistinguished, since their faulty path lengths will be the same.