Silicon Programming--Testing1 Completing a successful project (introduction) Design for testability

Silicon Programming--Testing2 Completing a successful project Project components: product—your desired end result process—steps to achieve the result people—team that works together, using the process, to achieve the result We need all 3 components to complete a successful project

Silicon Programming--Testing3 Steps in successful hardware design (basic “process”): 1.Understand the requirements (“product’) 2.Write a complete specification 3.Make a modular design 4.Use incremental implementation 5.Write well-structured, well-commented code 6.Use standard testing strategies, including: design for testability hierarchical testing scan path testing

Silicon Programming--Testing4 One area that is often overlooked: TESTING In particular, we need to use the strategy of “design for testability”, i.e., we need to include steps that will support hierarchical testing in our process from the very beginning of the project

Silicon Programming--Testing5 System testing goals: verification--functions correctly implemented validation--we are implementing the correct functions (according to requirements) (which task is more difficult?) TEST: does the system perform as required? DIAGNOSIS: if not, what is causing the error(s)? (Here we are concentrating more on verification)

Silicon Programming--Testing6 Basic requirements (not hardware-specific)--a testing strategy must be: thorough ongoing DEVELOPED WITH DESIGN (design for testability) note: this implies that several LEVELS of testing will be carried out efficient able to ensure observability of the results of each test applied

Silicon Programming--Testing7 Successful testing strategy requires a different perspective from that of the designer and/or implementer: good test: has a high probability of finding an error ("bad test": not likely to find anything new) successful test: finds a new error Testing should be done by a person or team that is INDEPENDENT of the designer /implementer

Silicon Programming--Testing8 Testing cannot be exhaustive (“testing is NP-complete”): Example: suppose we wish to test the functionality of a VLSI chip which has 90 inputs 2,304 flip-flops (16,384 RAM bits) How many tests to we require for exhaustive testing? What is the overall time to test if we can do 1 test / msec? 1 test /  sec?  test  sec?

Silicon Programming--Testing9 Some strategies for dealing with the complexity of testing: heuristics (genetic algorithms, random testing, testing of critical cases, boundary cases, …) to choose a reasonable set of test cases to ensure good “fault coverage” integration of each new test identified into a test suite which can be reapplied to the system under test whenever a new error is found or a change is made modularity, with hierarchical design and testing incremental development, with thorough testing at each stage

Silicon Programming--Testing10 example: for an ALU containing adder, complementer, ander, multiplier: what testing strategy should we use? What about for a 16-bit adder?

Silicon Programming--Testing11 General testing hierarchy (hardware or software): white box: individual component black box: module (only look at inputs and outputs) system: are overall specifications met? For your homeworks and project: you need to use hierarchical testing each VHDL component should have an associated.vec file.vec file needs to include comments to show what you are trying to test

Silicon Programming--Testing12 Where can errors arise in hardware? How can we detect these errors? specification errors design errors fabrication defects physical failures wrong outputs (behavior) timing errors other errors such as “glitches”

Silicon Programming--Testing13 design errors include: incomplete or inconsistent specifications incorrect mappings between design levels and / or views failure to follow design rules errors made by the designer (“coding errors”) errors due to undiscovered bugs in the design tools

Silicon Programming--Testing14 fabrication defects include: unwanted shorts or open circuits improper doping mask alignment errors Improvement in the fabrication process can reduce these types of errors and increase the yield (% of good chips per wafer) of the given process

Silicon Programming--Testing15 physical failures arise from wear on the system and from environmental factors physical faults include fabrication defects and physical failures a physical fault may be permanent, intermittent, or transient for purposes of testing physical faults are usually modeled as logical faults, for example “stuck at 1” or “stuck at 0”

Silicon Programming--Testing16 testing methods: in this course we will use simulation to “test” our circuits; when results of the simulation are acceptable, the actual circuit can then be tested through downloading onto the board we will mainly be concerned with two types of design errors: behavioral errors (the output values are not what was predicted) timing errors (delay between registers is too long for the correct values to be saved)

Silicon Programming--Testing17 controllability and observability: in the physical device, we need to be able to 1. control the internal state of each flip-flop and of inputs 2. observe the output values at various points in the circuit we do not have enough I/O pins to access all desired sites directly solution: use scan path testing

Silicon Programming--Testing18 using a scan path: flip-flop outputs flip-flop inputs normal operation mode: f_i gets input in_i, produces output out_i scan mode: f_i gets input from f_(i+1) (f_3 gets input from scanin) protocol: scan in a vector; perform test; scan out results note: only 3 pins needed (scanin, scanout, one-bit control line) instead of 8 pins (in general, 3 pins instead of 2N pins for N ff’s) f_3f_2f_1f_0 scanout scanin in_3in_1in_2 out_0out_1out_2 out_3 in_0

Silicon Programming--Testing19 Some important testing terms: ATG: "automatic test generation” (for stuck-at faults) BIST: "built-in-self test” (either for new components or “in the field”)

Silicon Programming--Testing20 For your homeworks and project--simulation will support logic testing and some timing analysis--for overall chip, this should be verified in the actual circuit 1. Use hierarchical testing; test as you design; use incremental design and testing, with system tests each time a new component is integrated 2. Implement scan path(s) to test register and flip-flop behavior 3. Document your testing through well-commented.vec files