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

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

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)

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

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

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

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

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

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)

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)

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

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)

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

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

Scope (cont.)

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

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

Test routines description (cont.) EDMA  Schedule the following transfers finalized by EDMA interrupt: Data Block Backup Image Source Data Block 1.Data Block -> Backup 2.Source -> Data Block 3.Data Block -> Image 4.Backup -> Data Block 5.Comparison: Source – Image

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

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

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)

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 … Text file format:

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