Presentation is loading. Please wait.

Presentation is loading. Please wait.

ECE 553: TESTING AND TESTABLE DESIGN OF DIGITAL SYSTES Functional testing.

Similar presentations


Presentation on theme: "ECE 553: TESTING AND TESTABLE DESIGN OF DIGITAL SYSTES Functional testing."— Presentation transcript:

1 ECE 553: TESTING AND TESTABLE DESIGN OF DIGITAL SYSTES Functional testing

2 3/1/20162 Overview Motivation and introduction Structure independent approach Structure dependant approach Organization/architecture dependant approachOrganization/architecture dependant approach –Microprocessor testingMicroprocessor testing –Memory testingMemory testing Summary

3 3/1/20163 Motivation and Introduction Ref: Abramovici, et. Al – Reference book Section 18.2 of the text (for understanding the problem) Motivation –Structural information can facilitate testing – we show this for combinational and sequential circuitsStructural information can facilitate testing – we show this for combinational and sequential circuits –Organization/Architecture information can make testing of microprocessors and memories practicalOrganization/Architecture information can make testing of microprocessors and memories practical –Develop fault models when we are to use this kind of informationDevelop fault models when we are to use this kind of information

4 3/1/20164 Structure independent approach Combinational circuit testing –Exhaustive testing of circuits that do not have very large number of inputsExhaustive testing of circuits that do not have very large number of inputs –Note: if a fault can cause the circuit to behave like a circuit with states (i.e. causes increase in the number of states – combinational circuit becomes sequential in nature) then exhaustive testing may not fully test the circuit. Example of such a fault is stuck-open fault in a CMOS implementationNote: if a fault can cause the circuit to behave like a circuit with states (i.e. causes increase in the number of states – combinational circuit becomes sequential in nature) then exhaustive testing may not fully test the circuit. Example of such a fault is stuck-open fault in a CMOS implementation

5 3/1/20165 Structure independent approach Combinational circuit testing (contd.) –A non-exhaustive functional test must be carefully designed otherwise it may not achieve the desired objective. Consider a 2-to-1 mux. A non-exhaustive functional test is given below:A non-exhaustive functional test must be carefully designed otherwise it may not achieve the desired objective. Consider a 2-to-1 mux. A non-exhaustive functional test is given below: A B S D SABD 1x 0 0 0 00 0x x x 1 1 11 1

6 3/1/20166 Structure independent approach Combinational circuit testing (contd.) –A fully specified test can potentially be (the one that repeats values in the test) as follows:A fully specified test can potentially be (the one that repeats values in the test) as follows: –This test can not test stuck-at fault on the control line SThis test can not test stuck-at fault on the control line S A B S D SABD 11 0 0 0 00 00 1 0 1 1 11 1

7 3/1/20167 Structure independent approach Sequential circuit testing –An example of this method and its limitations has been discussed in detail in the checking experiment approach to testingAn example of this method and its limitations has been discussed in detail in the checking experiment approach to testing

8 3/1/20168 Structure dependant approach Combinational circuit testing –Structure can potentially provide the information about dependence of outputs on inputs. This leads to two methods of structure dependant functional testingStructure can potentially provide the information about dependence of outputs on inputs. This leads to two methods of structure dependant functional testing Pseudo-exhaustive testing Sensitized partition testing

9 3/1/20169 Structure dependant approach Pseudo-exhaustive testing ABCDEFG f1f1 f2f2 The circuit will require 128 patterns for exhaustive testingThe circuit will require 128 patterns for exhaustive testing Function description may not tell us the dependence of the output on partial input setFunction description may not tell us the dependence of the output on partial input set Both f 1 and f 2 can be tested exhaustively with 16 pattern each, thus requiring a total of 32 patternsBoth f 1 and f 2 can be tested exhaustively with 16 pattern each, thus requiring a total of 32 patterns

10 3/1/201610 Structure dependant approach Sensitized partition testing –Testing an ALU – control signals are determined and applied in such a way that each smaller part (say 4-bit ALU) is exhaustively testedTesting an ALU – control signals are determined and applied in such a way that each smaller part (say 4-bit ALU) is exhaustively tested –An example from the book by Abramovici et. al.An example from the book by Abramovici et. al.

11 3/1/201611 Structure dependant approach Sequential circuit testing –Testing iterative logic arraysTesting iterative logic arrays –Machine partitioning approach to testingMachine partitioning approach to testing Substantial literature in this area but has not been applied to real applications of todaySubstantial literature in this area but has not been applied to real applications of today –An example – testing of shift registerAn example – testing of shift register A simple test 0 1 1 0 0 x x x x x … can test the shift register completely. This test is often used in testing “scan chains” to be discussed under DFT and BIST methods

12 3/1/201612 Organization/architecture dependant approach In many cases architecture and/or organization information is available and such information can be used to facilitate testing. We will show two applications of such an approachIn many cases architecture and/or organization information is available and such information can be used to facilitate testing. We will show two applications of such an approach

13 3/1/201613 Microprocessor testing References –Reference book – Abramovici et. Al.Reference book – Abramovici et. Al. –Thatte and Abraham, “Test generation of microprocessors”, IEEE Transactions on Computers, June 1980, pp. 429-441Thatte and Abraham, “Test generation of microprocessors”, IEEE Transactions on Computers, June 1980, pp. 429-441

14 3/1/201614 Microprocessor testing Basic concept –Need to develop test programs that can be executed on the processorNeed to develop test programs that can be executed on the processor –Need an open loop strategy to force instructions in the order we wish to execute – e.g. after a jump instruction we may wish to execute an instruction from an address different from the address provided by jump instructionNeed an open loop strategy to force instructions in the order we wish to execute – e.g. after a jump instruction we may wish to execute an instruction from an address different from the address provided by jump instruction –Develop a model (or models) for faults in different organizational sub-units of the microprocessorDevelop a model (or models) for faults in different organizational sub-units of the microprocessor

15 3/1/201615 Microprocessor testing What do we know? –Different sub-unitsDifferent sub-units Register file, bus, ALU, memory (cache), … –How instructions are executedHow instructions are executed How data moves from sub-unit to other subunit Data movement from and to the external world –Sequencing and timingSequencing and timing Number of clocks, atomic and semi-atomic actions, e.g. PUSH – causes increment PC, send SP as address, send register as data, increment SP, etc.Number of clocks, atomic and semi-atomic actions, e.g. PUSH – causes increment PC, send SP as address, send register as data, increment SP, etc.

16 3/1/201616 Microprocessor testing Method –Test each instructionTest each instruction –Test each subunit such as ALUTest each subunit such as ALU –Test bussesTest busses –Test register file and decodersTest register file and decoders –Test sequencing of instructionsTest sequencing of instructions Key concept –Start small – test components and instructions that are easy to test and then use the tested parts to test other partsStart small – test components and instructions that are easy to test and then use the tested parts to test other parts

17 3/1/201617 Microprocessor testing Model development –Determine which instructions are “easy” to execute – such as used fewest resources, fewest cycles – easy to control and observe (graph model)Determine which instructions are “easy” to execute – such as used fewest resources, fewest cycles – easy to control and observe (graph model) –Use such instructions to read and write register file to test register file(s) and address decoding logicUse such instructions to read and write register file to test register file(s) and address decoding logic –Test busses by moving different types of data on bussesTest busses by moving different types of data on busses –Test ALU by executing ALU related instructions such as ADD, SUB, …Test ALU by executing ALU related instructions such as ADD, SUB, …

18 3/1/201618 Microprocessor testing Fault model development –Busses: stuck-at and bridging faultsBusses: stuck-at and bridging faults –ALU: stuck-at (assume that the structural information is available)ALU: stuck-at (assume that the structural information is available) –Register file: stuck-at, arbitrary decoder failure – this will use similar fault model and tests as used for testing memoriesRegister file: stuck-at, arbitrary decoder failure – this will use similar fault model and tests as used for testing memories –Instruction decoder:Instruction decoder: No instruction is executed (I j /  )No instruction is executed (I j /  ) Different instruction is executed (I j /I k )Different instruction is executed (I j /I k ) An additional instruction is also executed (I j /I j +I k )An additional instruction is also executed (I j /I j +I k )

19 3/1/201619 Microprocessor testing Algorithm development –Develop simple sub-programs for each sub-unit testingDevelop simple sub-programs for each sub-unit testing –Put them togetherPut them together –Testing jumps and call will require intervention of tester – open loop strategy of testing microprocessorTesting jumps and call will require intervention of tester – open loop strategy of testing microprocessor

20 3/1/201620 Microprocessor testing Results (case study on an 8-bit HP processors) –Program size 1K – FC about 90%Program size 1K – FC about 90% –Additional complexities introduced in the test program (8K program) raised the coverage by 6%Additional complexities introduced in the test program (8K program) raised the coverage by 6% –Other faults were associated with the power-up logic, intialization, interrupts, … (hard to test by functional tests)Other faults were associated with the power-up logic, intialization, interrupts, … (hard to test by functional tests) Limitations –Lack of good and practical model of modern microprocessorsLack of good and practical model of modern microprocessors –Automating the program generation difficult and impracticalAutomating the program generation difficult and impractical –Structural methods with the use of DFT provide better coverage with fewer test vectorsStructural methods with the use of DFT provide better coverage with fewer test vectors

21 3/1/201621 Memory testing Basic reasoning –Logic design methods may not be applicableLogic design methods may not be applicable Special design methods Not designed using logic gates –Cutting edge technologyCutting edge technology High density Novel and non-traditional design methods and layout –Can be stand alone or embeddedCan be stand alone or embedded Need to develop –Fault modelFault model –Test algorithmsTest algorithms

22 3/1/201622 Summary Described structure independent and structure dependent methods of testing logic Microprocessor testing using organization information – model, fault model, test algorithms, results and limitations Memory testing – its need –Model, fault model and test algorithms to be discussed next


Download ppt "ECE 553: TESTING AND TESTABLE DESIGN OF DIGITAL SYSTES Functional testing."

Similar presentations


Ads by Google