Choosing Block-Diagram Tools For DSP Design
Reprinted from DSP & Multimedia Technology, April, 1995.
Copyright © 1995 Berkeley Design Technology, Inc.
Contents
Introduction
Design Capabilities
Computational Model
Fixed-Point Data
Simulation
Implementation
Conclusions
Introduction
In the past five years, block-diagram-based DSP tools have become extremely popular. Manually-drawn block diagrams have been used for decades to document DSP systems, so it is not surprising that tools supporting block diagram methodologies find wide acceptance. These tools help engineers manage complicated designs by representing a system's functions expressively and compactly. Moreover, because they run on computers, they can provide features such as version control and automatic checking of design rules. But the biggest advantage of these DSP tools is that they also provide support for many design activities such as simulation, test data generation, search and optimization of system characteristics, software generation, and hardware synthesis. In this article, we describe some of the most important features of these tools and outline how these features affect a tool's utility for various aspects of DSP design.
Design Capabilities
Signal processing systems can be expressed as a network of transfer functions, data sources, data sinks, and control functions. Such networks can, in turn, be represented clearly by diagrams, with icons or "blocks" (representing the functions) linked by lines (which depict communication between the functions). An example of such a diagram is shown in Figure 1. Each block represents a function, such as addition, subtraction, FFT, etc. The blocks are connected with lines or arrows, called directed arcs, which indicate how data moves between the blocks. Such diagrams are called dataflow graphs, or more commonly, block diagrams, and they provide a convenient method of describing, documenting, and analyzing a signal processing system.
Figure 1: A block diagram (or dataflow graph)
Block-diagram-based tools allow the user to create a block-diagram representation of a system using an assortment of functions available in block libraries. The libraries of blocks supplied with a tool have a strong impact on the types of designs that can be readily created with the tool. For example, libraries of advanced communications functions are provided with Elanix' SystemView and ICUCOM's ACOLADE, making these tools well-suited for communications system design. Visual Solutions' VisSim has a library of analog control system functions, positioning it for control system design. National Instruments' LabVIEW and Intelligent Instrumentation's Visual Designer have many data acquisition and graphical user interface functions, orienting them to the design of virtual instruments and data acquisition applications.
Historically, the most advanced communications libraries were available only in workstation-based tools. Recently, some very advanced communications libraries have become available in PC-based tools. These tools include Elanix' SystemView, ICUCOM's ACOLADE, and Hyperception's Hypersignal for Windows Block Diagram. The ACOLADE library is especially extensive, containing approximately 400 blocks. This library is so extensive that another vendor has now licensed it for use with their workstation-based tool.
Most block-diagram-based DSP tools allow users to add custom blocks to their libraries, usually by programming them in C. This allows the user to adapt these tools to new applications by creating any needed blocks. If source code is supplied for the vendor-supplied blocks, then new blocks may be created by copying and modifying the vendor-supplied blocks. Otherwise, the user must create new blocks from scratch. In any case, creating and debugging blocks is time-consuming. Having an appropriate vendor-supplied set of blocks available helps a design proceed more quickly and with fewer errors.
Computational Model
Block-diagram-based DSP tools have an underlying computational model that defines how the blocks in a system behave. The computational model strongly influences the classes of systems that can be designed, simulated, or implemented with a given tool. The most significant computational model for block-diagram-based DSP tools is dataflow. With the dataflow model, each block consumes and produces data samples on its inputs and outputs. When data is present at their inputs, blocks execute (fire) to produce data on their outputs. For example, an "add" block might have two inputs and a single output. When samples are available on both inputs, the add block can fire and produce an output which is the sum of the two inputs. The dataflow computational model is appropriate for modeling systems for which transformations of data (not timing details) are of primary interest. As a result, it is widely used for modeling DSP systems.
There are two major variants of the dataflow computational model that are differentiated by the order and frequency in which blocks execute:
Dynamic dataflow (DDF): the most general case of dataflow. In DDF, a block can consume and produce varying numbers of samples on its inputs and outputs. For example, a particular block might consume three samples on its input on one firing, and perhaps only consume two samples the next time it fires. To support this behavior, the sequence in which the blocks fire is determined dynamically at run-time. The ability to change the amount of data consume or produced by a block allows DDF to accurately model functions which produce data at varying rates. A phase-locked loop used for timing recovery in a modem is an example of such a function. DDF also supports system models that contain multiple data rates, or multirate systems. Only a few block-diagram-based tools support DDF. Examples of tools that support it for simulation are Mentor Graphics' DSP Station and Synopsys' COSSAP.
Synchronous dataflow (SDF): a more restrictive version of dataflow in which the number of samples a block produces or consumes is fixed prior to execution, and cannot vary during the execution of the system. This limits the types of functions that can be used in the design to those that consume and produce data at static rates. A decimator is an example of such a function, as are most basic functions for DSP applications, such as adders, multipliers, and FFTs. SDF also supports multirate systems, as long as all blocks consume and produce data at static rates. Examples of tools that support SDF are Alta Group's SPW and Hyperception's Hypersignal for Windows Block Diagram.
In a limited case of synchronous dataflow called cycle-driven computation, each block executes only once in a cyclic sequence of all blocks. The cycle-driven model is sometimes called the clock-driven model, because all blocks seem to execute exactly once on a tick of a global clock. The cycle-driven model is particularly well-suited for modeling synchronous digital hardware in which every hardware component executes on every clock cycle. However, unlike DDF or SDF models, the cycle-driven model does not have intrinsic support for multirate behavior. To model a multirate system with a cycle-driven tool, the system must be converted to a single-rate system. Alternatively, the system can be broken up into single-rate sections which can be modeled separately. Converting a multirate system to a single-rate system requires the user to add control blocks to the system, which is inconvenient for the user and increases the number of blocks in the design.
A tool's computational model is less prominent than other features such as the types of block libraries that are included with the tool. However, unlike the functions in the block libraries, the computational model cannot be changed. Therefore, the computational model has a fundamental effect on a tool's utility, and should be considered when choosing a tool.
Fixed-Point Data
Another important characteristic of some block-diagram-based DSP tools is support for fixed-point data types. Typically, algorithm development begins using floating-point arithmetic, without regard to fixed-point effects. However, in most cases it is advantageous to implement a system using simpler, smaller numeric formats with lower dynamic range to reduce system complexity and cost. For example, the lowest-cost digital signal processors use 16-bit, two's complement fractional (fixed-point) arithmetic. To be implemented practically on such DSPs, an algorithm must use a 16-bit, fixed-point numeric format.
Block-diagram-based DSP tools support fixed-point data types by allowing users to specify the numeric formats of signals or coefficients in designs. Sometimes they also include fixed-point analysis tools that assist the designer in determining the simplest formats necessary to meet system performance goals, resulting in less-expensive, more efficient designs. Although nearly all block-diagram-based DSP tools allow designs that use floating-point data types, few tools also support fixed-point design or analysis. Some tools — such as Hypersignal for Windows Block Diagram and COSSAP — support integer data types, which are a limited case of fixed-point. Alta Group's SPW and Mentor Graphics' DSP Station support general fixed-point formats and offer advanced analysis tools for optimizing number formats. In general, DSP designers must make trade-offs in numerical formats in order to achieve highest-performance, lowest-cost implementations of their designs. Integer number formats are restrictive and make an algorithm designer's task more difficult than it would be with general fixed-point formats.
Fixed-point design and analysis capabilities come at a price: The Alta and Mentor tools cost approximately $30,000. Adding optimization tools boosts their prices by approximately $20,000. In some applications, the Alta and Mentor optimization tools can save weeks of engineering time and reduce costly design mistakes, which partially justifies the tools' high prices.
Simulation
Block-diagram-based DSP tools typically include a simulator for modeling systems described by block diagrams. One of the most important features of a simulator is the computational model that it supports. As mentioned previously, the computational model defines how the blocks in a system behave. The SDF computational model is currently the most common model for these simulators, although a few tools support the DDF model.
From an abstract standpoint, the SDF model is more computationally efficient than the DDF model. Theoretically, given a system that could be simulated either by an SDF simulator or a DDF simulator, an SDF simulator would simulate that system faster. In practice, a DDF simulator may be faster than an SDF simulator due to more efficient simulator implementation or other factors. For example, Mentor Graphics' DSP Station contains an SDF simulator called "TSim" and a DDF simulator called "DDSim." Mentor has stated that the DDF simulator can run approximately ten times faster than the SDF simulator. Simulators allow varying amounts of user interaction with a running simulation. Most tools can plot data while the simulation runs to allow the user to monitor the simulation's progress. This capability is especially useful while designing or debugging a system. For example, viewing the dynamics of an adaptive filter can lead to a much better understanding of its function in a design. However, most tools prohibit the user from changing system parameters, data sources, and data sinks while the simulation is running, requiring the user to select these items prior to starting the simulation. The user might want to change these items in order to investigate system features discovered during the simulation. Tools that allow parameters to be modified during a simulation include ICUCOM's ACOLADE, which has parameter control blocks and a symbolic parameter language. Tools that allow the user to interactively choose any signals for plotting during the simulation include ORINCON Technologies' RIPPEN and Synopsys' COSSAP.
Typically, programs to help analyze the results of a simulation are provided in block-diagram-based tools, either within the simulator or via an associated program. Signal analysis tools can be valuable for preparing stimulus data for a simulation, for inspecting simulation results, or for modifying simulation results for use in later tests of prototype systems. One of the most elaborate examples of an analysis program is the Signal Calculator tool included in Alta's SPW. Signal Calculator presents the user with an interface that resembles a calculator, but performs operations on signals instead of scalar values. Signal Calculator has one of the most intuitive user interfaces of all signal analysis programs. However, its signal analysis capabilities are not as elaborate as those in some stand-alone signal analysis tools such as Entropic Research Laboratory's ESPS. This is generally true of all signal analysis tools that are bundled with block-diagram-based DSP tools.
Implementation
Practically all block-diagram-based tools can simulate designs, but fewer block-diagram-based tools can generate software that implements designs, and still fewer tools support hardware synthesis of the system.
Software code generation is used to transform a block diagram design into a program which is distinct from the block diagram tool or its simulator. This program can then be used in a stand-alone fashion or combined with handwritten code to form a complete system. Because this program often runs faster than the intrinsic simulator in a block-diagram-based tool, another use of software code generation can be the creation of a fast simulation.
The two languages commonly used in DSP software code generation are C and processor-specific assembly language. The quality of the generated code can vary widely. In general, generated C or assembly language code is less efficient than handwritten code of the same type.
Most generated C code is targeted for floating-point implementations only. That is, most block-diagram systems do not allow the user to generate C code that represents a fixed-point design. Exceptions include Mentor Graphics' DSP Station, Alta Group's SPW, and Synopsys' COSSAP. Although the code generated by these tools can perform fixed-point computations, this code is not intended for implementation on fixed-point digital signal processors. This code would be extremely inefficient on digital signal processors because it does not use the native data types or fixed-point operations of those processors. Rather, it is intended for simulating fixed-point systems.
Generated assembly language code uses the native data type of the target processor. For example, Real Time Signal Processing's EZDSP-Lab generates fixed-point assembly code for Analog Devices' ADSP-21xx chips, and Mentor Graphics' ASSYNT generates floating-point assembly code for Texas Instruments' TMS320C3x/4x chips.
Several block-diagram-based DSP tools offer hardware synthesis capabilities. The most prominent among these are DSP Station (via its MISTRAL 1 and MISTRAL 2 tools), SPW (via its HDS tool), and COSSAP (via its HDL Code Generator). These tools provide ASIC and FPGA hardware synthesis capabilities through links to general-purpose synthesis tools like Synopsys' Design Compiler and Cadence's Synergy. The block-diagram-based tool creates VHDL or Verilog HDL code, which is then fed to a compatible synthesis tool.
There are two main techniques used in block diagrams to specify the system for synthesis: RTL (register-transfer-level) design and behavioral-level design:
RTL design: The block diagram describes a DSP system using register-transfer-level hardware elements such as registers, multipliers, and shifters. That is, each block represents a specific piece of hardware that will be created at synthesis time. This type of design is similar to designing hardware by explicitly writing HDL code, and requires the designer to be familiar with hardware implementation considerations.
Behavioral-level design: The block diagram describes a DSP system using algorithmic elements such as filters and decimators. That is, each block represents a function in an algorithm, but not a specific piece of hardware. Decisions about how each function will be implemented in hardware are made by a synthesis tool later. A given block may or may not actually be synthesized as a distinct piece of hardware. Instead, the block might be combined with other blocks in a single piece of hardware in order to save space or power.
The main attraction of behavioral-level design is that many decisions about how to implement the algorithm in hardware are made by an optimizing synthesis tool. The tool can be directed to synthesize hardware which is optimized for size, speed, or cost. This can reduce the number of hardware details that must be specified by the user and allow him or her to concentrate on algorithmic (i.e., higher-level) considerations. However, behavioral-level design involves less user control over the implementation than RTL design. Behavioral-level design can result in an implementation which is not fully understood by the user. Also, automatic optimizations used in behavioral-level design may not be as good as those made manually by an experienced RTL designer.
Block-diagram DSP environments that provide synthesis capabilities for behavioral-level designs include Mentor Graphics' DSP Station and Synopsys' COSSAP. Both of these also provide some RTL design capability.HDS, which is part of Alta Group's SPW, supports only RTL design. However, its RTL block library is more extensive than those in the Mentor and Synopsys tools.
Only the most expensive block-diagram-based tools have the capability to support hardware synthesis. These tools tend to run only on UNIX workstations, not personal computers, and cost $30,000 or more. In contrast, tools that do not support hardware synthesis usually run on personal computers and typically cost around $500 to $5,000.
In block-diagram-based tools, support for hardware synthesis is normally accompanied by the ability to generate software code as described previously. Although supporting hardware synthesis does not directly require software generation capability, it is useful to have software generation capability in tools that support hardware synthesis for two reasons: First, generated software can be used as a fast simulation of a design. Second, DSP systems that contain custom hardware often contain custom software code, too, and generated software code can be used to prototype that custom software.
Conclusions
There is great value in block-diagram-based DSP tools because of their applicability across many stages of the design process. Some of these tools can support design, simulation, software generation, and hardware synthesis, thus integrating activities that are otherwise performed using separate tools. Unfortunately, tools that support the latter two activities are expensive and are not abundant. We can expect the number of tools supporting implementation to increase, and with this increase in number we can expect the costs of these tools to decrease. Block-diagram-based DSP tools that run on PCs will be part of this trend, and their low costs will also help to decrease the prices of tools supporting implementation.
Top of page