C4I: Meeting the demand for complex communications design | ADM Oct 2010

Communications engineers today must design to accommodate changing missions, shorter product life cycles, and increasing computer power.

Jon Friedman | Michigan

As a result, they create hybrid systems that include RF, high-speed signal processing, lower speed signal processing, and controls logic and control systems.

In the initial stages of the design process, it is often unclear whether to use analog or digital components and what portion of a design should be implemented in software or hardware.

System designers and implementers take their best guess on how to partition the design which might result in sub-optimal designs and system performance.

Typically, it is only near the end of the design process that the system designers and implementers can know whether their initial guess meets system performance requirements.

If it doesn’t, significant rework needs to be done which leads to cost and time overruns on the project.

To address these challenges earlier in the design process, communications engineers have adopted Model-Based Design.

With Model-Based Design, engineers develop an executable model, often referred to as an executable specification, which is independent of the implementation.

Within this model, design and system engineers can develop, test, and partition the design prior to implementation and integration.

This approach enables them to find errors early in the process, when errors are easier and less expensive to fix.

Often the initial algorithm is developed in floating point using textual-based languages such as MATLAB or C/C++.

Example tasks could include designing filter cascades for digital up/down conversion or developing carrier tracking loops.

The algorithm engineer focuses on verifying that the signal processing algorithm meets the design objectives, such as fitting the system response within a specified frequency mask or tracking expected Doppler profiles.

After testing the algorithm, the model can be further elaborated with the implementation details and the system performance can be verified against the design objectives with the additional implementation details.

For example, if the target for the algorithm is an FPGA (field programmable gate array which is an integrated circuit designed to be configured by the customer or designer after manufacturing), then fixed-point details must be added to the model and system performance must be assessed to confirm that objectives are still met.

Also at this stage, the effect of introducing non-ideal component performance to the system model can be assessed. For example, RF amplifier behavior can be added to the model using measured S-parameter data.

Typically RF amplifier behavior is modeled and analysed in the frequency domain, while the communications algorithm is developed in the complex-time domain.

By combining these models into a common executable modeling environment, system-level behavior and performance metrics such as bit-error rate (BER) can be determined.

Testing

When the algorithm elaboration is complete and the system-level performance is verified in the model, testing can be done on the host with different implementation languages to uncover errors introduced in the implementation.

For example, if part of the algorithm is partitioned for low-speed signal processing on a digital signal processor (DSP), the implementation of the algorithm will be C/C++.

In this case, engineers can use automatic code generation to rapidly create a prototype implementation that can be tested in the modeling environment with the same test vectors used to verify the model performance.

Similarly, if the target is a high-speed implementation on an ASIC (application-specific integrated circuit) or FPGA, then automatic code generation can be used to create an HDL (hardware description language) implementation that can be tested within Simulink and an EDA simulator, such as ModelSim from Mentor Graphics, Incisive from Cadence, or Discovery from Synopsis.

When host testing is complete, the final version of the generated code can be used for production.

If highly optimised or specialised code is required for deployment, this last implementation step can be done by hand.

Whether automatically generated or hand coded, the final implementation can be tested on the target hardware (microprocessor, DSP, or FPGA).

Given this background, let’s look at an example of how Model-Based Design could be used to develop a GPS receiver.

The GPS system has been fully operational with 24 satellites in its constellation since 1994, and its use is ubiquitous.

The example involves using code-division multiple access (CDMA) for time-delay measurement to yield range.

All satellites share the same carrier frequency of 1.57542 GHz for civilian access, which has not changed in the past 30 years.

The design process starts with the creation of a system-level model of a GPS receiver from the written specification for a GPS physical layer.

The model, shown in Figure 1, contains the transmitter, channel, receiver, and measurement visualisation subsystems, and has numerous levels of hierarchy.

The transmitter model introduces timing errors to test the receiver timing recovery control loop while the channel model adds Doppler shift to test the receiver carrier tracking loop.

Once the simulation of the design meets the required performance goals, the system-level model becomes an executable specification.

Finding the best path

Next, the algorithm model can be partitioned into a portion that will reside in the FPGA and a portion that will reside in the floating-point DSP.

For example, an incoming I/Q data arriving at a rate of 8 million samples per section (MSPS) and passing through a root-raised cosine FIR filter is best suited for the FPGA.

On the other hand, once the signal has been de-spread, the data rate is 1000 Hz, and can easily be handled by a DSP.

After the receiver model is working with floating-point arithmetic, the next step is to elaborate the model with fixed-point attributes that will be required for the FPGA partition.

Implementation on the FPGA can be automated at this point using the fixed-point model of the FPGA partition with tools such as Simulink HDL Coder or Xilinx System Generator.

Then, using HDL simulators it’s possible to verify that the implementation is functionally equivalent to the design model.

Similarly, using the model of the DSP partition, the C code can be automatically generated by tools such as Real-Time Workshop Embedded Coder for deployment.

Before integrating the C onto the DSP, it can be pulled back into the simulation environment and checked against the model to confirm functional equivalence, as was done with the HDL code.

The last step is to deploy the HDL to the FPGA and the C to the DSP and confirm that there are no errors introduced on the target hardware.

Using Model-Based Design, engineering teams developing advanced communications systems can collaborate in a common environment that enables them to capture the algorithm design as well as system-level effects of non-idealised hardware.

As a result, the teams can optimise their designs through design exploration, identify design errors prior to implementation, and use modern commercial off-the-shelf (COTS) tools to automate much of the work.

Dr. Jon Friedman is the Aerospace & Defense and Automotive Industry Marketing Manager at The MathWorks, Inc.