Introduction to Test Driven Development (To be used throughout the course) Building tests and code for a software radio Concepts 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 2/ 28 Conventional AM radio Antenna Pickup Local Oscillator RF STAGE Mixer IF STAGE Rectifier AUDIO STAGE + amplifier Audio out 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 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 filter to get required audio range 50Hz to 7 khz 3/ 28 4/ 28
Software AM radio concept Software FM radio concept RF STAGE Antenna Pickup AUDIO STAGE RF STAGE AUDIO STAGE Mixer Rectifier + amplifier Antenna Pickup What ever is needed Rectifier + amplifier Local Oscillator IF STAGE Audio out Audio out Most stages handled with high speed software Most stages handled with high speed software 5/ 28 6/ 28 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. A basic example for the coding practices adopted through the term Going to use the rectification stage of this softradio 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. 7/ 28 8/ 28
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 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/ 28 10 / 28 Standard testing practice Test Driven Development Heavy on documentation Describe Requirements Design Solution Build Solution Test Solution Analysis Document Design Document Test Plan Document TLD Test Last 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 11 / 28 12 / 28
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 Describe Requirements Design Solution Acceptance Tests Unit Tests Lets apply TDD to rectification issue Overall technique Decide on a particular test action with the customer the test(s) 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 Build Solution Test Solution See paper handed out for more details 13 / 28 14 / 28 Express Customer Requirements as tests using E-TDD Tests Now expand the Customer Tests to do what the customer has requested 15 / 28 16 / 28
Note that writing the tests has automatically generated the function interface information Floating point version of the Tests Essentially a cut-and-paste version of integer code 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 17 / 28 18 / 28 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. 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 19 / 28 20 / 28
Next step: just enough code to satisfy the linker C++ stubs 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? 21 / 28 22 / 28 assembly code using a couple of techniques Assembly code stubs assemble (compile) but generate 200 linker error messages 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 23 / 28 24 / 28
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. Fix the code for CHAR32, and run the tests We lost control of the processors in the debug environment. 25 / 28 26 / 28 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 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) 1. Exit from E-TDD GUI, 2. Exit from VisualDSP IDDE 3. Power down the board 4. Walk-around your chair twice (or count to 10) 5. Power up board, then reactivate VisualDSP IDDE and the GUI 27 / 28 28 / 28
We accidentally pass some tests without writing any code With the GUI running, we can just click on failed test to see details 29 / 28 30 / 28 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 31 / 28