Read about transparency conception before using TASTE

Precision of a testability analysis method (and thus also of the method implemented in TASTE) highly depends on how precisely diagnostic properties of in-circuit modules are modeled. Especially, it is important how module ability to transport test vectors or responses through its structure (so-called transparency of the module) is modeled.

As an example of probably the most popular transparency model, let us present basics of I path conception [AB85] now. The conception supposes n -bit diagnostic data transfer is possible between port x and port y of a module iff both x and y are n -bit ports and each n -bit data can be transferred unchanged in the direction from x to y (i.e., one-to-one identity mapping exists between x -data and y -data).

I path conception is easy to understand and implement, but it is too strict in definition of data-paths suitable for diagnostic data-transfer. I path's strict "one-to-one identity mapping" requirement leads to unneeded restriction of set of data-paths suitable for transferring diagnostic data. The strict requirement can be soften by analyzing data-path separately for transferring test vectors (responses) between x and y. Efficiency of such a softening including impact on fault-coverage parameter of resulting circuit was shown, e.g., in [PSKS06].

The idea of such a separate analysis (presented, e.g., in [MO99]) is as follows: test vectors (responses) can be transferred from x to y iff a surjection (injection) exists between x -data and y -data. Using this less-strict principle, much more data-paths can be considered suitable for transferring diagnostic data than in case of I path conception.

Let the idea of the conception be presented now. As an ilustrative example, let us take 2-input multiplexer with data inputs a, b, selection input s and output y. When thinking about transparency of particular module, we should think about how it is possible transport data from module inputs to module outputs?.

multiplexer: ilustration to transparency conception

For multiplexer module, the answer is easy when thinking about I path conception: data present at whole a can be transported to whole y iff s=0. Alike, data present at whole b can be transported to whole y iff s=1. Such an information can be stored in TRANIS field placed in a file in a following format (see Templatized module type library format for more details) supported by actual version of TASTE:

MODULE_TYPE MX
INTERFACE in@a[n] in@b[n] in@s[1] out@y[n] 
IMPL area@2*n+1 power@n/0.03
TRANI                                        // not used in actual TASTE version 
TRANS                                        // not used in actual TASTE version 
TRANIS a(n-1:0)|y(n-1:0)|s(0) b(n-1:0)|y(n-1:0)|s(0)
TRND                                         // not used in actual TASTE version 

If more precise testability analysis results are required, more precise input data should be given to TASTE. The simplest way of getting such an information is to detect all possible bijective mappings (bijections, i.e. mappings which are both injective and surjective) between input data and output data and detect all stimuli conditioning the bijections.

For multiplexer, e.g., it surely holds (for each bit i) that data present at a(i) can be transported to y(i) iff s=0 and data present at b(i) can be transported to y(i) iff s=1.

Such an information can be stored in TRANIS field placed in a file in a following format (see Templatized module type library format for more details) supported by actual version of TASTE:

    MODULE_TYPE MX
    INTERFACE in@a[n] in@b[n] in@s[1] out@y[n] 
    IMPL area@2*n+1 power@n/0.03
    TRANI                                        // not used in actual TASTE version 
    TRANS                                        // not used in actual TASTE version 
    TRANIS a(i)|y(i)|s(0) b(i)|y(i)|s(0)
    TRND                                         // not used in actual TASTE version 

Thus, problem lies in selection of proper granularity related to transparency information: the last mentioned (bit-level) information is much better than the first presented one. If all inputs will be testable, there will be no difference between those two types of information. However, if any of input bits become untestable (e.g., a(0) - that is, bit 0 of port a), then in case of "whole a can be transported to whole y iff s=0" approach, whole y become untestable too. On the other hand, in case of "data present at a(i) can be transported to y(i) iff s=0" approach, only y(0) become untestable; other y's bits will remain unaffected by testability of \ a(0).

Try yourself to think about transparency information related to following basic components:

register: ilustration to transparency conception

adder: ilustration to transparency conception

multiplier: ilustration to transparency conception

References

[AB85] Abadir, M.S., Breuer, M. A.: A Knowledge-Based System for Designing Testable VLSI Chips, IEEE Design and Test of Computers, Vol. 2, No. 4, 1985, pp. 56-68

[MO99] Y. Makris, A. Orailoglu, Property-Based Testability Analysis for Hierarchical RTL Designs, Proceedings of the IEEE International Conference on Electronics Circuits and Systems (ICECS), pp. 1089-1092, 1999

[PSKS06] Pecenka, T., Strnadel, J., Kotasek, Z., Sekanina, L.: Testability Estimation Based on Controllability and Observability Parameters, In: Proceedings of the 9th EUROMICRO Conference on Digital System Design, Cavtat, IEEE CS, 2006, pp. 504-514