Let's take a look at a basic application example, a simple FRS modulation, and see how the platform capabilities can be used in a typical design scenario. In fact, this example comes with the platform, and is designed entirely using a model-based approach, in order to showcase rapid-prototyping capabilities. The application also shows how an application can be partitioned between DSP and FPGAs and the effect of ‘shifting’ different processing sections from the FPGA to the DSP (and vice versa).

Let's begin with system simulation. System simulations have been conducted at the Simulink level using a top system simulation model. Then, this model has been broken down in DSP and FPGA sections (Figure 5). Once again, DSP and FPGA models have been re-verified in simulation and corresponding code is then generated directly from these models. The DSP and FPGA code now run in real-time on their respective processors.

As a “first take,” the designer tends to put most of the processing in the FPGA, probably because the initial attention is toward implementing up/down sampling conversion, and using a quadrature FM demodulator with the arctg of CORDIC FPGA cores for phase unwrapping. This is understandable since it gives the possibility of performing end-to-end testing of the design within the FPGA. Processing of the continuous tone coded squelch system (CTCSS) tones (that are low-frequency out-of-band tones allowing FRS “privacy” on shared channels) also was done in the FPGA on a first take, which is overkill, considering we are processing under 300 Hz signals in an FPGA that can run well above 300 MHz.

Now, we can move processing tasks to the DSP. To illustrate this process, let us go with the CTCSS processing. The CTCSS processing is demanding because there is a need for some “brick wall filters.” Simulink, by default, will tend to generate rather hefty floating-point code. This is the approach that was used for our first pass, which fully exploited processing capability of the 6446 DSP.

Next, the strategy is to use a tool kit called “Embedded Target for TI DSP” to instantiate pre-optimized DSP cores. One can see the modified DSP model in Figure 6. The TI DSP optimized core “block sets” have been used here and the effect is significant on the processing load. Table 1 shows the effects on processing and power “footprint” of this shift. Final power has thus been reduced from 26 mW in the FPGA to 8 mW in the DSP, down by a factor of 3.

The next step could be for example to displace the FM modulation and iterate design cycles until the optimal balance is attained. The design flow would then be complete and code generated in this implementation study phase can be “productized” in a final product.

However, one has to admit that this is a pretty simple modulation to target on this advanced hardware. However, the hardware is reprogrammable and the same development paradigms can be used for much more advanced modulation. For example, the FPGA part of the GSM physical layer with all the intricate capabilities (and difficulties) mandated by GSM has been made.

Note, however, that model-based design might not be used for the DSP part, which will implement the lower GSM protocol layers. Regular C code combined with optimized signal-processing libraries will rather be used to implement these layers. Typically, basic signal processing and layer 1 protocol will run on the DSP. Higher layers will eventually run on a GPP processor, and hence on the ARM9 present on the DM6446 chip.

The SFF SDR development platform provides a flexible platform for handset developers. Based on advanced processors from silicon vendors such as TI and Xilinx, software tools from leading vendors such as Green Hills and The Mathworks, it provides handset developers a true Lego box to build advanced products in the ever accelerating and competitive wireless devices marketplace.

Louis N. Bélanger is the CTO and co-founder of Lyrtech, in Quebec City, Quebec, Canada. He graduated in 1979 from Laval University's Electrical Engineering Department, and earned his MSEE in 1985 in signal processing.

Previous 1 2 3

RSS    Save to Del.icio.us  Digg This