Application Notes

Introduction to RTDX for Cosimulation and Verification of DSP Applications Through Simulink

Kerry Schutz
August 2006

Abstract

Verifying that a DSP algorithm functions the same way on the target board as it did in a simulation environment is a critical and often time-consuming task. Designing a complex DSP algorithm takes years of education and experience. Learning to code them efficiently on a DSP is a real art. At the same time, deciding on a verification strategy is not something to underestimate either. You have to verify the DSP code using different stimuli in a variety of configurations or system states while monitoring a number of performance criteria.

Traditionally engineers have treated the task of DSP algorithm verification as a step very distinct from simulation. Typically engineers would simulate in one environment with one test bench, manually convert or hand-code the simulation into something that would run on a DSP, and then verify the coded implementation is working in another environment using a separately developed test bench.

This paper describes a more unified approach  using Model- Based Design for verification. Model-Based Design provides a single framework to bridge the gap between system designers, system builders, and system testers, with transparent test bench reuse. Staying within a single framework for the different phases of product design also allows everyone working on the project to communicate their ideas more effectively. The workflow discussed in this paper is general enough to be applied to almost any DSP algorithm. Subsequent papers in this series will focus on particular applications.

Introduction

This document describes how to test a DSP design once you have it simulated to your satisfaction and are ready to implement the code on a DSP. This paper introduces a method of testing your design using RTDX (Real-Time Data Exchange) by Texas Instruments. Follow-on papers will focus on specific applications running on a fixed-point DSP.

Historically engineers have used a number of different ways to test their DSP designs once they had a successful compilation, which in itself can feel like a big achievement.

One way is to employ blind faith. That is, you burn the code in flash and hope it boots and runs the way you want. Maybe you look at some LEDs or a signal on a scope. That usually doesn’t get you very far in complicated designs, and most designs are in fact complicated. If things don’t come out as expected, then you edit the code and try again or get out logic probes and start debugging.

One step better than the blind-faith approach is to “roll your own” by setting up your own communications interface between the DSP and the host application running on the PC. That host application could be as simple as a terminal program, such as Hyperterminal communicating over RS232 with the DSP. Or it could be a program you develop yourself, communicating over one of many interfaces including serial, USB, Ethernet, the PCI Bus, etc. In either case you need to write a lot of code on the DSP side to support command handling. This command handling code can evolve to become bigger than the data processing code itself! Also customers don’t really want your custom debugging code, nor are they willing to pay extra for it.

Another common way is to purchase a JTAG emulator and a commercial debugger and use it as a communications interface for testing. JTAG (Joint Test Action Group) is essential if you plan on using Code Composer Studio™. But you might ask why go through the trouble of developing a home-brew interface when you can just use JTAG? The answer is that JTAG works fine in the lab or in the office, but it’s not feasible in the field or at a customer site. You can’t ship a JTAG with every system you sell. Eventually the system being developed must be able to communicate with the outside world independent of JTAG, using a readily available interface such as serial, USB, or Ethernet. In the end your system should support at least two interfaces to the DSP: something like JTAG for in-house development, and something else for the field.

RTDX stands for Real-Time Data Exchange and is a data communications technology developed by Texas Instruments (TI) for sending and receiving data between the DSP and Code Composer Studio™ over a JTAG interface. JTAG was originally developed for boundary-scan testing of printed circuit boards and in-system programming (ISP) of flash memory. That’s different from the way we are using it here. In this example, we are using JTAG is as a communications and control interface between CCS and a DSP. It’s a clocked serial interface commonly using seven lines. Engineers use RTDX as a way to debug and test their DSP designs in-situ with real data.

This technical note shows how to take advantage of RTDX using Simulink. In a series of subsequent documents, I will show how RTDX is used with Simulink by showing examples that start with simulation and progress towards implementation and test. In The MathWorks R2006a product release, we introduced an improved RTDX capability that allows the use of RTDX without writing separate MATLAB scripts. We introduced the concept of separate target and host RTDX blocks. This document does not describe RTDX technology in general; only how to use it with Simulink. For more detailed information on RTDX, refer either to www.ti.com or the on-line help in Code Composer Studio™.

Figure 1. The four Simulink RTDX blocks.

Where Does RTDX Fit in the Framework of Model-Based Design?

To understand how to take advantage of the Simulink RTDX blocks, it helps to see how these blocks fit into the overall development process. I will use Model-Based Design as the framework to introduce our new RTDX capability. We can break Model-Based Design down into a series of steps. These steps can vary in their details depending on the particular project, but the general flow still holds.

1. Behavioral Model. Build a high-level model that captures the specifications of your design at a system level. This model may or may not include such details as fixed-point effects, analog circuit effects, RF effects, filter structure details, noise, non-linearities, etc. These effects can and should be included in models to follow once the simpler model is proven to work according to your requirements. With the behavioral model, try not to get bogged down in the details before you can make something with ideal characteristics work. Take baby steps. This step is all simulation; no RTDX or hardware is involved yet.

Figure 2. A simple behavioral model, for simulation only. Click on image to see enlarged view.

2. More Detailed Models. Elaborate on the behavioral model to include the effects described in step 1. Model elaboration may consist of a series of models, each one incrementally more complex and building upon the previous one. This step is again all simulation, with no RTDX or hardware involved yet.

Figure 3. Model elaboration. Click on image to see enlarged view.

Model Elaboration. In this figure we have added more details to the existing subsystems from step 1. In practice we might break this step down into a number of models to isolate one set of effects from another. Or we might take advantage of configurable subsystems.

3. A Model for Implementation. This model has a particular DSP in mind and is very likely a subset of the model where you left off in step 2. That subset being the Simulink blocks you wish to generate code for and run on the DSP. The target-side RTDX blocks enter the picture here but you are still not running anything on the DSP yet. You generate C code, compile it, link it to an .out file, and stop there.

Figure 4. A conceptual implementation model. Click on image to see enlarged view.

4. A Model for Testing. Finally, the hardware is here. Again, one of the virtues of Model-Based Design is that you don’t need costly hardware and test equipment until you are pretty sure your ideas work in simulation. When you arrive here at step 4, the leap of faith is then much smaller. You might also call this model the test harness model. In step 3 we cut out and used the portion of the system model in step 2 to be implemented on the DSP, but in this step we do just the opposite. In this step we cut out and use the test harness from either step 1 or 2 that interfaced with the DSP blocks. Basically we remove the DSP block and use the rest. The RTDX HOST blocks enter the picture here. To run this model successfully you need your hardware platform and a JTAG emulator.

Figure 5. The testing model. Click on image to see enlarged view.

The Testing Model. Notice in this model the DSP block is not present as an explicit block. However, when one presses the play button, the DSP .out file we built in step 3 is loaded on the target processor and starts running. The DSP is then reading and writing from or to the RTDX Host blocks to communicate with Simulink. This is what we call processor-in-the-loop (PIL) simulation. Here we take advantage of the test harness we used during our simulation using Simulink only. Reusing the same test harness is a tremendous benefit of using Model-Based Design, and it comes at no extra cost. Essentially, by using the same test harness, you should get the same answers during testing that you get during simulation (assuming a purely digital system). If you don’t, then you need either to fix the problem or to justify the differences logically.