TigerSHARC processor and evaluation board Different capabilities Different functionality

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada2 / 26 6/1/2015 Concepts tackled Differences between “processor” and “evaluation board” Functionality present on TigerSHARC evaluation board Using the A/D and D/A during Lab. 1 Developing the code for a C++ “Moving sound source” and a C++ FIR filter using a test driven development approach (TDD)  Assembly code and optimized assembly code versions of this code will be developed during Lab. 2 and Lab. 3 and validated using the tests developed during Lab. 1.  A dual core version of the FIR filter will be attempted during Lab. 4. This is a “very” new laboratory to me – we will see.

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada3 / 26 6/1/2015 TS201S Evaluation board contains 2 processors P0 (DSPA) and P1 (DSPB) TWO TS201S processors Error messages when linking about P0 and P1 mean problems with code on specific processor

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada4 / 26 6/1/2015 Evaluation board – Link Ports Designed for “star” Configuration – Up to 8 processors working together P0 to P7 (selectable by switches on back of evaluation board (Never tried – Don’t destroy link ports)

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada5 / 26 6/1/2015 JTAG ONLY AVALIABLE IN 3 rd floor labs Higher speed communication rates than USB (factor of ) ICT318 TigerSHARC (some stations). ICT320 Blackfin (some stations). Audio connectors. Max input voltage around 1 V p-p with no DC. Too great a voltage destroys the board Use MPEG or other players and keep Volume down Damage and distortion issues

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada6 / 26 6/1/2015 Buttons and LEDs split between processors Much “stuff” on the board shared between processors (but NOT all)

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada7 / 26 6/1/2015 Evaluation Board Architecture P0 P1

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada8 / 26 6/1/2015 Two processor operations in ENCM515 Lab. 1, 2 and 3  During TESTS only 1 processor being used as we check the functionality of various functions written in C++ (lab1), partially optimized assembly (Lab. 2), highly optimized but not ultimate (Lab. 3). Other processor is halted  WARNING: Make sure that you “run” the processor that you loaded the code into  When running the code, one processor is “idle” Lab. 4  Plans to have the work load split between two processors.

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada9 / 26 6/1/2015 Processors can share EXTERNAL memory Memory allocation depends on ID # Processors can access each other’s INTERNAL memory and registers

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada10 / 26 6/1/2015 Note – labeled processor A and B rather than processor 0 and 1

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada11 / 26 6/1/2015 Note – labeled processor A and B rather than processor 0 and 1

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada12 / 26 6/1/2015 How to use the evaluation board capability Read a lot in the hardware manual Modify some of the example programs provided in C:\Program Files\Analog Devices\VisualDSP 4.5\TS\Examples\ADSP-TS201 EZ-Kit Lite and then Read a lot in the hardware manual

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada13 / 26 6/1/2015 Laboratory 1 This makes use of the analog to digital converter and the digital to analogue converter to provide audio sound signals that we can process with the high speed algorithms we develop during the course By the end of the course we will need to learn about  Interrupts – which, how many, why, how?  A2D, D2A – which, how many, why, how? We need to learn about all this stuff before the end of the course – but not now – Now we just want to use it  The C++ programming environment provides functions (interrupt( ), interruptf( ), interrupts( ) that handle all the interrupt overhead, and then call our functions as a subroutine.

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada14 / 26 6/1/2015 ECE-ADI-Project Was asked to develop (as part of Analog Devices University Ambassadorship) to develop demonstration programs and place on the web Have now developed  SHARC – ADSP (Previous 515) Audio project utilities  Blackfin – ADSP-BF533 (Current ENCM415, ENCM417 in 2007) Audio project utilities, Video Project utilities  Blackfin – ADSP-BF533 (Current ENCM491 – Nygren) Real time operating systems  TigerSHARC – ADSP-TS201 (Current ENCM515, ENCM619.23)  Embedded Test Driven Development Environment (E-TDD) Blackfin, TigerSHARC, SHARC, Microsoft studio Find at ECE-ADI-Project/Index/index.htm

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada15 / 26 6/1/2015 Using the Lab. 1 code You should have already done the Familiarization exercise Part of the Familiarization exercise involved loading the ENCM515Lab directory onto your U:Drive An audio talk-through program is provided at Lab. 1  Audio-In signal is sampled (A/D) automatically and placed in known “input” location in memory  An interrupt is made to happen each time a sample occurs (44kHz)  During the interrupt, the input value is “processed” and the processed value is placed in a known “output” location in memory.  The “output” value is then automatically moved to the D/A for reconstruction. WARNING: NEVER START THE PROCESSOR WITH YOUR EAR-PHONES ON YOUR EARS. IF YOU HAVE THE PROCESSING INCORRECT, YOU CAN GET AN INFINITELY LARGE SIGNAL COME OUT WHICH HURTS YOUR EARS  Start the processor with the earphones on the desk, then bring the earphones near your ears ONLY when it is safe to do so.

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada16 / 26 6/1/2015 Lab. 1 Task 1 – concept Concept  idea exact, details inexact Run the (modified) audio-talk-through program Each time an interrupt occurs 1. ProcessData(INCBuffer  OUTCBuffer); // Four circular buffers. // Lab. 1 Task 1 – ProcessData( ) is “just a copy” 2. The “oldest” processed sound sample is send to the “D/A”. There is a sound sample from both left and right channels (circular buffers) leftOUT = leftOUTCBuffer[ leftOUTIndex - 128]; rightOUT = rightOUTCBuffer[ rightOUTIndex ]; 3. The “newest” input sound sample (from A/D) overwrites the oldest sound sample. leftINCBuffer[ leftINputIndex++ ] = sample = (leftIN + rightIN) / 2; rightINCBuffer[ rightINputIndex++ ] = sample = (leftIN + rightIN) / 2; RESULT – You hear a slightly delayed version of the sound in each ear (delay = 128 / seconds). It will sound “normal”

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada17 / 26 6/1/2015 Lab. 1 Task 1 -- concept Why “average the left and the right signals” rather than putting each signal into each own array. The reason will be come obvious as we proceed through Labs. 1, 2 and 3  Basically the ProcessData( ) function gets too complicated to handle. Current plan is, in Lab. 4, to finish with one TigerSHARC core doing ProcessData( ) for the left channel and the other TigerSHARC core doing all the processing on the right channel

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada18 / 26 6/1/2015 Lab. 1 Task 2A – In C++ Left – no delay, right with delay Run the (modified) audio-talk-through program Each time an interrupt occurs 1. ProcessData(INCBuffer  OUTCBuffer); // Four circular buffers. // Lab. 1 Task 1 – ProcessData( ) is “just a copy” 2. The “oldest” processed sound sample is send to the “D/A”. There is a sound sample from both left and right channels (circular buffers) leftOUT = leftOUTCBuffer[ leftOUTIndex - 0] rightOUT = rightOUTCBuffer[ rightOUTIndex -256 ]; 3. The “newest” input sound sample (from A/D) overwrites the oldest sound sample. leftINCBuffer[ leftINputIndex++ ] = sample = (leftIN + rightIN) / 2; rightINCBuffer[ rightINputIndex++ ] = sample = (leftIN + rightIN) / 2; RESULT – With no delay on the sound going to the left ear, and delay on the sound going to the right ear, the brain “THINKS” the sound comes from close to the left ear

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada19 / 26 6/1/2015 Lab. 1 Task 2B – In C++ Left –delay, right with no delay Run the (modified) audio-talk-through program Each time an interrupt occurs 1. ProcessData(INCBuffer  OUTCBuffer); // Four circular buffers. // Lab. 1 Task 1 – ProcessData( ) is “just a copy” 2. The “oldest” processed sound sample is send to the “D/A”. There is a sound sample from both left and right channels (circular buffers) leftOUT = leftOUTCBuffer[ leftOUTIndex - 256] rightOUT = rightOUTCBuffer[ rightOUTIndex - 0 ]; 3. The “newest” input sound sample (from A/D) overwrites the oldest sound sample. leftINCBuffer[ leftINputIndex++ ] = sample = (leftIN + rightIN) / 2; rightINCBuffer[ rightINputIndex++ ] = sample = (leftIN + rightIN) / 2; RESULT – With delay on the sound going to the leftear, and no delay on the sound going to the right ear, the brain “THINKS” the sound comes from close to the right ear

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada20 / 26 6/1/2015 Lab. 1 Task 3 – Concept Left / right changing delays The “oldest” processed sound sample is send to the “D/A”. There is a sound sample from both left and right channels (circular buffers) leftOUT = leftOUTCBuffer[ leftOUTIndex LEFTIndex] rightOUT = leftOUTCBuffer[ rightOUTIndex – RIGHTIndex ]; LEFTIndex = LEFTIndex – 1; RIGHTIndex = RIGHTIndex + 1; RESULT  Sound seems to come from in front of you to start with  With changing delays, the left sound will get more delayed, and the right sound will get less delayed  The sound will move from in front of you, over to your right ear.  When the sound is at your right ear, the indexes “change direction” (right increases, left decreases) till the sound “comes” from left side, and so on

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada21 / 26 6/1/2015 Lab. 1 Task 3. Use TDD approach to develop C++ code CUSTOMER DEVELOPER Work with customer to check that the tests properly express what the customer wants done. Iterative process with customer “heavily involved” – “Agile” methodology.

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada22 / 26 6/1/2015 Lab. 1 Task 3. Use TDD approach to develop C++ code void AdjustDelayOffsetCPP (long *IndexOffset, long *IndexOffsetDirection, long DelayLength); You work in the “Lab1Tests DEVELOPERS” directory, with the code for AdjustDelayOffsetCPP( ) placed in the “LAB1 CUSTOMERS” directory. The “customer” provides you information about how this function works to adjust the index so that the sound will move correctly The information is in the form of a “case study” based on customer – developer consultation for a simple example. The information is expressed as an “executable specification document” You get the code to work for the simple example, and add additional tests (part of your report) as needed to confirm that the code will work

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada23 / 26 6/1/2015 Lab. 1 Task minutes maximum Use AdjustDelayOffsetCPP( ) “for real” void AdjustDelayOffsetCPP (long *IndexOffset, long *IndexOffsetDirection, long DelayLength); If you did the testing correctly, then this task simple means Recompiling the code in the “LAB1 CUSTOMERS” directory – 2 minutes Demonstrate to T. A. and ask (politely) please give me full marks. Note that the same tests will be used Lab. 2 for AdjustDelayOffsetASM and Lab. 3 for AdjustDelayOffsetOPtimizedASM

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada24 / 26 6/1/2015 Lab. 1 Tasks 5, 6 and 7 float FIRDebugModeCPP(float *coeffs, float *inputData, int index, int coeff_length); Task 5: Work with the customer to set up some tests for the FIR operation with is essentially SUM (*coeffs++) * (*inputData++) Task 6: Another “2 minute job” – recompile the code in the “Lab 1 CUSTOMER DIRECTORY” and demonstrate. Task 7: Another “2 minute job”  The code will work with the arrays small (N <= 128) but not for larger arrays – chronic sound distortion  Recompile the code using the C++ optimizer and show your FIR filter works – no sound distortion

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada25 / 26 6/1/2015 Later we will need to modify the timing tests from the Familiarization Laboratory so we can check the speed of the filters, and delay adjustment algorithms We may not “HEAR” a lot of distortion, but all the processing must be completed in 1 / s We must have efficient code as we increase the length of the data being processed As one exercise we will examine the code for the Analog Devices Reverb program which simulates the sound of an opera filter using discrete Fourier transforms on points at a time!  We will “look” at that code and say “oh my!” rather than writing it Speed improvements when we use the “C++” optimizer

TigerSHARC Evaluation Board, M. Smith, ECE, University of Calgary, Canada26 / 26 6/1/2015 Concepts tackled Differences between “processor” and “evaluation board” Functionality present on TigerSHARC evaluation board Using the A/D and D/A during Lab. 1 Developing the code for a C++ “Moving sound source” and a C++ FIR filter using a test driven development approach (TDD)  Assembly code and optimized assembly code versions of this code will be developed during Lab. 2 and Lab. 3 and validated using the tests developed during Lab. 1.  A dual core version of the FIR filter will be attempted during Lab. 4. This is a “very” new laboratory to me – we will see.