Building tests and code for a “software radio” Introduction to Test Driven Development (To be used throughout the course) Building tests and code for a “software radio”

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Stages in a conventional radio Stages in a software radio Goals for the “long term” project Concept of test driven development Digital rectification Tests for integer array rectification Tests for float array rectification (C++ compiler) Tests for rectification in assembly code More details of test driven development 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Conventional “AM” radio RF STAGE Antenna Pickup AUDIO STAGE Low pass Filter + amplifier Low pass Filter Rectifier Mixer Local Oscillator IF STAGE Audio out 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Review of AM radio operation Analog Version Incoming signal @ frequency 1010 kHz IF-STAGE Local (tunable) oscillator @ 660 kHz Mixed with incoming signal (multiplication) Get sum and difference frequencies 350 kHz and 1670 kHz Low pass filter to get constant frequency for remainder of audio date at 350 kHz AUDIO STAGE Rectify signal to get AM modulation Rectification means that you spread the signal over a wide band of frequencies Low pass filter to get required audio range 50Hz to 7 kHz 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Software “AM” radio concept RF STAGE Antenna Pickup AUDIO STAGE Low pass Filter + amplifier Low pass Filter Rectifier Mixer Local Oscillator IF STAGE Audio out Most stages handled with high speed software 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Software “FM” radio concept RF STAGE AUDIO STAGE Antenna Pickup Low pass Filter + amplifier What ever is needed Rectifier Audio out Most stages handled with high speed software 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Real “software” radio Looking at RF stage to bring in wireless signal Software radio is the rest of it Update communication protocols Change noise suppression characteristics “on the fly” Etc. Dr. Gannouchi is doing research in this area Joint M. Sc. student Andrew Kwan Excellent topic for pair presentation (12 minute talk – 14 slides max – at the end of term). Exact details to be given later. 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

A basic example for the coding practices adopted through the term Going to use the rectification stage of this “soft-radio” as a “code example” all through the course. We may also look at “single-side band modulation” (involves IIR filtering) as a second “code example” followed all though the term. 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Customer Requirements Wants to get “product out of the door” as fast as possible Less time spend on development the better, but it has to work Developing in C++ is easier than developing in assembler code, but is it fast enough Risk analysis – take one representative part of the code and explain the differences between the speeds from C++ code (Debug and Release Mode) and assembly code 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Expected relative advantages Compiler debug mode Slow but easy to understand the code flow when doing “very low level debug at assembly level” (A real NO-NO) Compiler release (optimized) mode Faster than debug mode Optimized, possibly out of order instructions, difficult to follow “US” – assembly mode Probably faster than compiler debug Gain skills needed to handle optimized assembly “US” – optimized assembly mode Time consuming; use only after profiling the compiler code Faster than compiler when “we” understand the special situations that arise Probably based on “trying assembly code” to see where the issues are, then “optimizing the output from the release compiler version” 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Standard testing practice Heavy on documentation TLD Test Last Development 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Test Driven Development Requires “automated testing framework” High Level customer tests for embedded systems – personally find these hard to do. This example is “an exception” because we have “really knowledgeable” customer. Done in consultation with customer. Even better if customer writes the tests. Doing research into developing a process for this. Read paper handed out Developer Tests for embedded systems – E-TDD Have found many advantages – research and teaching Being used by local firm 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Test Driven Development Work with customer to check that the tests properly express what the customer wants done. Iterative process with customer “heavily involved” – “Agile” methodology. CUSTOMER DEVELOPER 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Lets apply TDD to rectification issue Overall technique Decide on a particular test action with the customer Write the test(s) Write the simplest possible code to satisfy the test(s) “Refactor” the code to improve “quality” Definition of “quality” is unclear in the literature Ease of “use” or “reuse” of code Reliable to use – “robust” My additional idea – meets speed requirements for the embedded situation See paper handed out for more details 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Express Customer Requirements as tests using E-TDD Tests 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Now expand the Customer Tests to do what the customer has requested 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Note that writing the tests has automatically generated the function interface information Why int* and float* rather than just void as you are passing in the address of the output Design decision – sort of standard with “C” to pass back a pointer to thing being changed 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Floating point version of the Tests Essentially a cut-and-paste version of integer code 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Stage 1 – Compile / Link the tests Obviously the Link is not going to work – as the code for functions HalfWaveRectifyXXX( ) have not been written If obviously going to fail – WB (why bother)? Basically – You are TESTING THE TESTS Are you calling the functions you expect to call. Better handled by doing Code Review first, and then use compiler / linker to CHECK the Code Review did not miss something (PSP – personal software process). C++ can overload function names (done via name mangling). What are the name-mangled names needed for the assembly code? – This stage will show you. 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Name mangled names can be seen from linker C++ name as used The name mangled name generated by in C++ code by the C++ compiler in response to function overloading. These are the “assembly code” names 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Next step: Write just enough code to satisfy the linker – C++ stubs 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Problems uncovered The following unanswered question has been raised when developing the C++ code How does the processor know how to run a function in debug mode or in release mode? Explain later – compiler option which you will use during Assignment 1 Just how do you write an assembly code stub? 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Write assembly code using a couple of techniques Use knowledge of what you need to do from other assembly code functions Need to specify section of memory where the code will be placed Need to specify name of function (linker told us that) Need to do a “return to “C” Cheat -- use mixed mode in IDDE Compile and link a “C++” function with the same name (in debug mode). Load the code into the processor Bring up the source code window, right click and select MIXED MODE 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Assembly code stubs assemble (compile) but generate 200 linker error messages 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Understanding the error messages TigerSHARC is a high speed processor designed for “32-bit” operation 68K designed for 8-bit and 16-bit. Can do 32-bit but much slower Blackfin designed for 16-bit and 32-bit. Can do 8-bit but slower. Strings are normally handled as 8-bit characters TigerSHARC has two character modes CHAR8 bit – like normal “C++” string, minimizes space usage, but slow. CHAR32 bit – Maximizes speed, but storage area is larger C++ compiler (debug mode) normally generates CHAR32 type of strings – so we must do that in our assembly code. 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Fix the code for CHAR32, and run the tests We lost control of the processors in the debug environment. 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Why did we lose control? IDDE environment uses a “boundary scan” approach to debug (another lecture) That’s the ICE interface discussed in Tuesday’s class It is possible to get the IDDE environment (on the PC) out of sync with the processors (on the evaluation board). I find this happens when I generate poor code, or when I spent a lot of time coding before down loading anything to the board 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Recovery process Don’t lose control – write good code Do incremental builds so you are continually writing and testing code E-TDD encourages this – write a test, then write just enough code to satisfy the tests If you lose control Try selecting each processor (DSPA then DSPB) in processor window. Then select DEBUG | HALT If that fails, then in this order (easier restart process) Exit from E-TDD GUI, Exit from VisualDSP IDDE Power down the board Walk-around your chair twice (or count to 10)  Power up board, then reactivate VisualDSP IDDE and the GUI 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

We “accidentally” pass some tests without writing any code 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada With the GUI running, we can just “click” on failed test to see details 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts of TDD, M. Smith, ECE, University of Calgary, Canada Concepts covered Stages in a conventional radio Stages in a software radio Goals for the “long term” project Concept of test driven development Digital rectification Tests for integer array rectification Tests for float array rectification (C++ compiler) Tests for rectification in assembly code More details of test driven development 9/27/2019 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada