Sankar Gurumurthy

1

• Sankar Gurumurthy
• Sriram Sambamurthy
• Prof. Jacob A. Abraham
• Computer Engineering Research Center
• The University of Texas, Austin

2
Outline

• Introduction and motivation
• Technique
• Reverse driver
• Generating the software
• Experiments
• Summary and Discussion

3
Systems-on-a-chip

• Systems-on-a-chip (SOCs) are becoming
  increasingly popular ITRS 2005
• Testing them very important
• Generic bus-based SOC
• Embedded processor
• System bus connecting all the blocks
• Embedded processor represents the intelligence on
  the SOC
• Hub of the data transfer

4
System-on-a-chip testing

• SOCs designed using the design reuse paradigm
• Blocks of previously designed modules used
• Blocks can be bought from intellectual property
  vendors ? known as IP cores
• Test vectors already exist
• From vendors or previous use
• Test delivery ? focus of research
• Test access mechanisms (TAMs)

5
Test access mechanisms

• Non-functional access
• Uses a kind of access to core not allowed during
  the normal functional operation
• Generally based on scan chains or other design
  for test (DFT) structures
• Can also use the embedded processor as the test
  source/sink ? Needs wrappers around the core
  under test
• Functional access
• Embedded processor is the test source/sink ? No
  DFT structures or wrappers around the cores

6
Non-functional TAMs

• Boundary scan based Touba
• Uses the JTAG/boundary scan mechanism to
  load/capture the tests
• Slow since the access is serial
• Direct access based Immaneni
• Direct access to core test pins given through
  external pins
• Faster
• High overhead to route the access pins and also
  multiple pins required

7
Functional TAMs

• Uses the intelligence of the embedded processor
  to test the SOC
• At-speed tests are possible

• Empirical evidence that tests applied at speed
  are better for detecting defects McCluskey
• Overhead is minimal or non-existent
• Known as software-based self test (SBST)

Gelsinger
8
Software-based self tests

• Functional capabilities of embedded processors
  (or DSP) replace BIST hardware
• Embedded processors test themselves, other modules

Compression Hardware
Compression in Software
for each data value Di to be compressed
Shift_Right_Through_Carry(S) if (Carry) S
XOR(S, feedback_polynomial) S
XOR(S, Di)
11/15/2009
8
9
SBST approaches

• Many approaches proposed
• Hierarchical approach using ATPG and SAT engines
  proposed Gurumurthy
• Instruction template based approach to test
  combinational blocks Chen
• Most target only the embedded processor
• Not applicable to test the other cores in the SOC

10
Testing the non-processor cores

• Cores in the SOC can be of three kinds
• White box ? All the internals visible and
  structure of the core can be changed
• Grey box ? All the internals visible, but
  structure of the core can not be changed
• Black box ? No internals visible, no change can
  be made on the core
• Any methodology for testing black box cores
  should not depend on knowledge of the cores
  internals

11
Our approach

• Uses functional TAM
• Uses pre-existing vectors
• Generates software to be loaded on to the
  embedded processor

12
Pre-existing vectors

• If using a core bought from vendor
• Vectors might also be provided by the vendor
• Reusing a core
• Vectors from the previous use
• Newly designed core
• Validation vectors
• Only constraint these vectors must be functional
  test patterns for the core

13
Reverse driver

• Parses the vector sequence to generate the data
  set to be sent to the core being tested
• Is specific to each core as many as the number
  of driver programs
• Only overhead involved
• Generates the output in a format readable by the
  driver program

14
Reverse driver Illustration

• Peripheral core communicating with external
  environment (send/receive 32-bit data)
• Five 8-bit registers addresses 0 4
• Register 0 Control
• Registers 1 to 4 Data

if (address 0) getcontrolinfo (in_data)
elsif (address 1) insert_data(0,7,data)
elsif (address 2) insert_data(8,15,data)
.
15
Reverse driver Illustration

• Peripheral core communicating with external
  environment (send/receive 32-bit data)
• Five 8-bit registers addresses 0 4
• Register 0 Control
• Registers 1 to 4 Data

Reverse
Send at speed rate 1 Data 0x54DF7178
Driver
16
Software generation

• Use the driver program associated with each core
  being tested
• Driver programs
• Software code that actually talks with the
  non-processor cores
• Know about the bus protocol
• Generally able to take in the data to be sent to
  the core or read back data from the core
• Developed as part of designing the SOC

17
Software generation example

• Pass the data set generated by the reverse driver
  program to the driver
• Data set should be in the same format as what the
  driver program expects

If (operation send) send_data(speed_rate,da
ta) elsif (operation receive)
receive_data(speed,data)
18
Coverage measurement

• Simulate the SOC using the software generated
• Platform used SOC validation can be used
• Monitor the core boundaries to capture the pin
  data
• Fault simulate the core with the captured data

19
Experimental setup

• Implemented a SOC containing ARM core, AES
  cryptographic core and a Wishbone bus interface
  (Verilog)
• AES 128-bit data/key encryption/decryption
  available from opencores

Validation vectors ? Set of random values
encrypted and decrypted
20
Experiment results
Details about the synthesized AES core
Results
21
Summary

• SOC testing technique presented
• Capable of testing black-box cores
• Used pre-existing test sequences
• Illustrated the effectiveness on a SOC model
  containing a cryptographic core
• Fault coverage obtained within 0.5 of the
  coverage of the original sequence

22
Discussion

• Coverage depends on vectors given
• Necessitated by black box cores
• Lower coverage might still be an effective test
  Maxwell
• Hierarchical approach can be used in case of grey
  box or white box cores
• Use test generation tools to get the vectors
• Hierarchical approach can be modified for black
  box cores
• Generate tests on functional representation of
  the cores

23
References

• ITRS 2005 International technology roadmap for
  semiconductors, 2005 edition
• Touba N. A. Touba and B. Pouya, Testing
  embedded cores using partial isolation rings, in
  VLSI test symposium. Los Alamitos, CA, 1997, p.
  10.
• Immaneni V. Immaneni and S. Raman, Direct
  access test scheme-design of block and core cells
  for embedded ASICs, in International Test
  conference, 1990, pp. 488492.
• Gelsinger P. Gelsinger, Discontinuities driven
  by a billion connected machines, IEEE Design and
  Test of Computers, vol. 17, no. 1, pp. 715,
  2000.
• McCluskey E. J. McCluskey and C.W. Tseng,
  Stuck-Fault Tests vs. Actual Defects, in
  Proceedings of the International Test Conference
  2000.
• Shen J. Shen and J. A. Abraham, Native mode
  functional test generation for processors with
  applications to self test and design validation,
  in Proceedings of the International Test
  Conference 1998.
• Gurumurthy S. Gurumurthy, S. Vasudevan, and J.
  A. Abraham, Automatic generation of instruction
  sequences targeting hard-to-detect structural
  faults in a processor, in International Test
  Conference, Oct 2006, p. 27.3.
• Chen L. Chen, S. Ravi, A. Raghunathan, and S.
  Dey. A scalable software-based self-test
  methodology for programmable processors. In
  Proceedings of the 40th Design Automation
  Conference, pages 548553, June 2003.
• Maxwell P. C. Maxwell, R. C. Aitken, V.
  Johansen, and I. Chiang, The effect of different
  test sets on quality level prediction When is 80
  better than 90? in International Test
  Conference, 1991, pp. 358364.

24
Thank you!