Next-Gen Tools Iron Out Design-Flow Discontinuities

Oct. 1, 2010
Communication-system design must pull together the disparate threads of algorithm design, system architecture definition, and hardware design. Here's how a unified behavioral-level design flow can help.

Simulation techniques

ISM band

Power spectral density

Symmetric fixed-point

FIR filter

Simulink HDL Coder

Utilization report

Communication system

Design-flow discontinuities plague the development of complex signal-processing and communications technologies by causing disruptions and, thus, adding to cost. Shorter design cycles magnify the impact of these discontinuities. However, significant advances in modeling, simulation, and code-generation tools and methods will bring some much-needed relief to these headaches.

Use cases in algorithm design, system architecture, and hardware design help better illustrate these recent advances. For algorithm design, several hundred ready-to-use signal-processing and communications System objects are now available in Matlab, accelerating the development of complex algorithms. System architects can now model RF and baseband system components in a unified environment and perform true multi-frequency simulations. In hardware design, several new developments such as workflow advisor, critical path highlighting, distributed pipelining, back annotation, and resource utilization reports provide a framework for faster design iterations.

Algorithm Design For Streaming Systems
At the onset, many engineers will use floating-point arithmetic for the development of signal-processing and communications algorithms in Matlab. These algorithm developers can exploit the powerful signal-acquisition and analysis capabilities of Matlab as well as the built-in algorithm libraries of several toolboxes.

In some organizations, though, these algorithms are then rewritten in C code to refine them for implementation, conversion to fixed-point or integer arithmetic, or to integrate them with other design elements. Rewriting code is one example of a potentially costly and disruptive discontinuity in the design flow.

System objects, an important new addition to Matlab, enable engineers to design signal-processing system models for streaming applications directly in Matlab. Moreover, they can utilize several hundred new library components for signal processing, image and video processing, and communications.

A case in point is a basic communication system with transmitter, channel, and receiver components (Fig. 1). To model and simulate such a system, some engineers write many thousands of lines of C code and then look for ways to integrate the design with test equipment or analyze simulation results.

In contrast, Matlab code uses several available System objects from Signal Processing Blockset and Communications Blockset (see the code listing). To model the transmitter, an engineer can instantiate and call the Reed-Solomon Encoder, Convolutional Encoder, Block Interleaver, Rectangular QAM Modulator, and Orthogonal Space-Time Block Coder System objects from Communications Blockset in sequence.

In addition, unlike traditional functional programming styles, System objects in Matlab are object-oriented implementations of algorithms. They implicitly handle indexing, buffering, and state management, which makes the code much simpler to write, debug, and maintain. Thanks to the code structure, engineers can easily compare it with the original specification or block diagram. Algorithm designers can rapidly combine this code with their existing Matlab code and test the algorithms with live data acquired from measurement instruments.

Continue on next page

Algorithms coded using System objects facilitate code reuse in the system design process. Floating or fixed-point Matlab code can be included directly in a Simulink model as part of the system architecture, modeling, and design process. Engineers can also generate C code automatically from Matlab code that uses System objects and then use that C code for simulation or integration with other C/C++ design elements after proper verification.

RF And Digital System Architecture
Static link budget calculations are a common first step in RF designs based on specifications for LTE, Bluetooth, ZigBee, Wi-Fi, or other technologies. These calculations provide a good starting point, but they don’t account for input signal modulation, image effects, and other real-world phenomena. To effectively model and simulate the effects of RF impairments on communication systems, system architects currently juggle multiple disconnected tools that support either digital or analog/RF designs, but not both.

With a circuit envelope simulation tool like SimRF, however, multi-frequency dynamics can be simulated in RF receivers and three-port components such as mixers. SimRF and Simulink together provide a common environment for modeling and simulating RF and baseband subsystems in a unified design. When combined, these tools enable system architects to perform realistic simulations early in the development process and help them make tradeoff decisions in designs that include digital and analog/RF components.

Figure 2 shows the overall system model of an industrial, scientific, and medical (ISM) band low IF receiver that includes both the digital signal-processing components and the RF receiver subsystem. Also shown are details of the RF subsystem with a Hartley IF receiver. Unlike traditional methods of IF receiver modeling that apply cascades of two-port elements and single-frequency approximations, the use of three-port elements simplifies the receiver model. The model also employs circuit envelope simulation technology and supports multi-frequency modeling.

Furthermore, system architects can explore the feasibility and relative merits of alternate approaches for image rejection, such as super heterodyne or direct conversion architectures in the unified environment (Fig. 3). In addition to simulating the effects of RF impairments, system architects can use the same system models to perform lab-bench-type verification tasks in simulation.

Hardware Design
After completing the algorithm design and system architecture, the next step in many development cycles is FPGA implementation and verification of the digital portions. Primary sources of inefficiency in FPGA prototyping and implementation include the time-consuming design iterations needed to find the proper balance of power consumption, performance, and area.

Take, for instance, a symmetric finite impulse response (FIR) filter implemented in fixed-point arithmetic (Fig. 4). To realize such a filter in hardware, engineers must carefully balance the throughput and latency and monitor the amount of hardware resources used.

Continue on next page

Critical path highlighting is a new capability that provides actionable information on potential system bottlenecks. Using the post-synthesis information generated by the Xilinx ISE synthesis tool, Simulink HDL Coder annotates the critical path timing in the Simulink model. By coupling this information together with pipelining techniques, engineers can partition their designs and the critical path latencies (Fig. 5). Here, the same filter design is shown with the critical paths automatically highlighted, along with estimated latency for each path segment.

As mentioned, pipelining is one of the key techniques for addressing critical path latencies. One potential challenge, though, is that parallel paths may have unmatched latencies, which can lead to unexpected or unwanted system behavior. Distributed pipelining is often used to address this problem. Now that technique can be automated. By choosing this option, engineers can automatically retime the model and balance the latencies introduced by pipeline registers across relevant parallel paths.

In the past, these types of design iterations and tradeoff evaluations required lots of time and effort. To that end, a new workflow advisor (Fig. 6) lets engineers go through design iterations more quickly and intuitively. It’s especially helpful to those who aren’t experts in hardware description language (HDL) programming, but need to take advantage of FPGA processing.

Another recourse beyond critical path highlighting and distributed pipelining is to examine an automatically generated resource utilization report (Fig. 7). The report allows engineers to monitor the type and number of critical hardware components being used and determine the best architectural choice for a given situation by quickly iterating through several viable design options.

Today’s engineering managers face the challenge of coordinating geographically dispersed teams that are working on different parts of an overall system using different, disconnected tools. In many cases, system-level designs are best done in graphical environments, while some lower-level details are best expressed as text in Matlab or C. Whether small or large, geographically distributed or located in the same office, teams struggling with discontinuities in their design workflow can apply the technologies discussed in this article to streamline and accelerate the development of complex signal-processing and communications systems


To join the conversation, and become an exclusive member of Electronic Design, create an account today!