Design of DSP testing environment

1. Technion - Israel institute of technology department of Electrical Engineering הטכניון - מכון טכנולוגי לישראלהפקולטה להנדסת חשמל Design of DSP testing environment Performed By: Safovich Yevgeny 307015578 Instructors: Eli Shoshan Yevgeni Rifkin

2. Table of Content: • Introduction • Goal • Testing Environment • Architecture • Principles of Architecture • Scope • Test routines description • Module for Tests Control • Status

3. Introduction • Satellites are exposed to several sources of ionizing radiation: • Trapped radiation • Galactic cosmic rays • Solar flares • This radiation induces transient and permanent changes in semiconductor devices • Single Event Latch-Ups (SEL) • Total Ionizing Doze (TID)

4. Introduction (cont.) • We are going to measure the impact of radiation on DSP • DSP 6416 has been chosen for: • Requested by the customer • It is used for calculations and control on satellites • Project “LOKO” of an archiving algorithm has been developed in EE faculty for this DSP • It is one of the most advanced of its type

5. Goal • Test DSP operation during radiation • Total Ionizing Doze (TID) • Quantify reversal of bits per each module • Output statistical summary of the results

6. Host TEB 6416 XDS510 JTAG cable Environment • Tests Execution: • Initial settings • Behavior verification • Output results • Tests Control GUI: • Parameters Setting • Control • Results • Analysis

7. PC Tests Control UI (VB) COM Code Composer TEB C6416 DSP (C & Asm) XDS510 emulator JTAG Architecture

8. Architecture (cont.) • PC (Host) • Connection to DSP via JTAG • DSP control by using COM technology (Code Composer is exposed by COM interface) • Access to DSP memory space • Ability to run program routines • Ability to analyze test results externally • Convenient GUI

9. Architecture (cont.) • DSP (controlled by the Host) • Used in TEB development environment • Availability of external memory (EMIF) • The test program is executed from external memory (with minor exceptions) • “Fast” tests execution (vs. running tests on Host)

10. Principles of Architecture • DSP • All tests are executed by DSP • PC (Host) • Control the testing routines • Gather & Output results • Interface • All data exchange is done by DSP external memory (not influenced by radiation)

11. Principles of Architecture (cont.) • PC • Initialize development environment • Reset TEB & DSP • Load the test program to DSP • Set active testing routine(s) according to user’s selection • Run program on DSP • Gather & present immediate results from DSP (EMIF) • Complete collection of results & analysis

12. Principles of Architecture (cont.) • DSP • Separate testing route per each module • Module state initialization • Test execution • Behavior verification & errors’ analysis (+counters) • Output results to external memory space (EMIF)

13. Scope • Only state containing modules to be tested • Each module should be tested “separately” • Errors (“damaged” addresses / modules) should be counted

14. Scope (cont.) • Modules to be tested: • Internal Memory (1Mb) • CPU • EDMA • MCBSP (0 – 2) • Timers (0 – 2) • Modules not to be tested (defined by customer): • VCP • TCP • EMIF A/B (no buffers) • UTOPIA • HPI • PCI • External memory • PLL

15. Scope (cont.)

16. Test routines description • CPU • All 6416 opcodes are tested • Each opcode is given “sample” input values • Opcode result is compared to the pre-calculated one • MCBSP • A “sample” data is written to each port • The data is read from the port and compared to the input one

17. Test routines description (cont.) • Internal Memory • Backup critical program • Interrupts handlers • Timer test routines • Fill memory by sample data (the addresses values) • Wait for reversal of bits • Repeat the above for data = NOT of address

18. Data Block Data Block Data Block Data Block Source Image Backup Test routines description (cont.) • EDMA • Schedule the following transfers finalized by EDMA interrupt: • Data Block -> Backup • Source -> Data Block • Data Block -> Image • Backup -> Data Block • Comparison: Source – Image

19. Test routines description (cont.) • Timers • Each timer is tested by the following routine: • Set clock to 1/8 of the internal clock • Start timer • Run a loop of with a counter variable • The code is written in such a way that: • Each loop iteration takes 8 CPU cycles • Counter variable should reach the same number as the timer’s one • Loop is finished upon timer interrupt

20. Module for Tests Control • Tests execution control: • Reset TEB & DSP • Reset Statistics • Run single test once (loop) • Run all tests once (loop) • Automatic Reset upon program failure (watchdog) • Immediate results presentation

21. Module for Tests Control (cont.) • Full results analysis: • Gather all errors counters • Show errors counters per module • Present graph of errors distribution on memory • Presentation of errors average, std. dev, min, max • Ability to save results (addresses sorted by errors frequency)

22. Module for Tests Control (cont.)

23. Module for Tests Control (cont.)

24. Module for Tests Control (cont.) Summary: Total tests count: 6 Total errors: 18 Auto resets performed: 0 CPU: Tests count: 1 Total errors: 1 … Memory: Tests count: 2 Total errors: 14 Avg. total errors per test: 7 Min. errors per address: 0 Max. errors per address: 2 Memory - errors per address report: Addr.[hex] Errors 70000 2 … Text file format:

25. Status • DSP Test routines are ready • Host Control Module is ready • Documentation – in progress