Completing a successful project (introduction)

1
Completing a successful project
(introduction) Design for testability
2

• Completing a successful project
• Project components
• productyour desired end result
• processsteps to achieve the result
• peopleteam that works together, using the
  process, to achieve the result
• We need all 3 components to complete a successful
  project

3

• Steps in successful hardware design (basic
  process)
• Understand the requirements (product)
• Write a complete specification
• Make a modular design
• Use incremental implementation
• Write well-structured, well-commented code
• Use standard testing strategies, including
• design for testability
• hierarchical testing
• scan path testing

4
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
5

• 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)

6

• 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

7

• 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

8
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 / msec? 1 test
/nsec?
9

• 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

10
example for an ALU containing adder,
complementer, ander, multiplier what testing
strategy should we use? What about for a 16-bit
adder?
11
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

12

• 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

13

• 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

14

• 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

15
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
16

• 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)

17
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
18
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_(i1) (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 ffs)




19
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)
20
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