Migrating Designs From High-Level To Hardware Using
Block-Diagram-Based DSP Tools
Reprinted from Proceedings of the 1995 International Conference on Signal Processing
Applications and Technology, October 1995.
Copyright © 1995 Berkeley Design Technology, Inc.
Contents
Abstract
As DSP hardware designs become increasingly complex and time-to-market
windows shrink, designers are increasingly looking to high-level
tools to help manage complexity and boost productivity. High-level,
block-diagram-based tools have long been used for DSP algorithm development
and recently have begun to support software and hardware development
as well. However, the tools themselves can be complex and costly, and
impose many restrictions on the designer.
In this paper, we explore the important considerations in evaluating
block-diagram-based tools for DSP hardware design. These include
issues of design abstraction, data types, optimization, synthesis,
and libraries.
1. Introduction
Block-diagram-based DSP tools allow users to create graphical representations
of DSP systems using an assortment of functions provided in
block libraries. For nearly a decade, such tools have supported simulation
of DSP systems, primarily at a high level of abstraction. Recently,
block-diagram-based tools such Alta Group's SPW, Mentor Graphics'
DSP Station, and Synopsys' COSSAP have also begun to support
the implementation of DSP designs in ASIC and FPGA hardware, often
through links to hardware synthesis tools. In this paper, we
explore the important considerations for evaluating
block-diagram-based tools for DSP hardware design. These include
issues of design abstraction, data types, optimization, synthesis, and libraries.
We examine three block-diagram-based DSP tools that support hardware design:
Alta Group's SPW, Mentor Graphics' DSP Station, and Synopsys' COSSAP, and
analyze how these tools support hardware design and synthesis. In particular,
we compare the hardware design methodologies employed with the Alta, Mentor,
and Synopsys tools and explain the types of design modifications that must be
performed to migrate a behavioral design into a hardware implementation.
2. Design Abstraction
A critical issue to consider when evaluating block-diagram-based tools
for DSP hardware design is the level of abstraction at which the design will
be expressed. In their traditional role as simulation-only tools,
block-diagram-based DSP tools have typically been used at a high level of
abstraction, with the designer manipulating elements such as filters,
modulators, and encoders drawn from a library. We call this type of design
behavioral design, since the focus is on defining and verifying the behavior
of a system or algorithm, rather than on developing an implementation.
Working at this high level of abstraction allows the designer to rapidly
experiment with a variety of approaches, and to efficiently verify
the functionality of a design.
2.1 Moving Down in Abstraction
When implementing a design in hardware, it is necessary to descend to
lower levels of abstraction. After the design has been defined at the
behavioral level, the next step is usually to define a hardware architecture,
which is the basic structure of hardware elements that will be used to
implement the behavior.
Block-diagram-based DSP tools differ significantly in the ways in which they
allow the user to transition a design from the behavioral level to the
architectural level. In some cases, this step must be performed manually by
the designer. This is the case, for example, with Alta Group's SPW. When
developing a hardware design using SPW, the designer manually generates the
desired hardware architecture. This architecture is entered as a block
diagram using a special library of register-transfer-level elements such as
multipliers, adders, and registers. These blocks are lower level than the
blocks typically used for behavioral DSP design, usually necessitating some
redesign as the system is implemented at the architectural level.
Additionally, the designer may want different parts of the design to "share"
expensive hardware elements. For example, the designer may want a a four-tap
filter to be implemented using a single multiplier instead of four separate
multipliers. In this case, the designer would have to manually create
multiplexing and control circuitry to manage this sharing.
Once the hardware architecture has been designed, SPW generates either VHDL
or Verilog HDL code for use with logic synthesis tools. These logic synthesis
tools partially automate the process of migrating the design from a
register-transfer-level hardware architecture to a gate-level implementation
suitable for mapping to an ASIC or FPGA.
There are some clear benefits to manually designing the hardware architecture
in this way. These include the ability to use a single design entry and
simulation environment to design at the behavioral and architectural levels,
and the ability to simulate mixed-level designs (where part of the design is
specified at the behavioral level and part at the architectural level).
However, the fact that the designer must manually create and specify the
architectural-level design means that he or she cannot rapidly experiment
with a wide range of architectural design options. This is unfortunate,
since such experimentation often yields significant improvements in terms
of design speed, cost, or power consumption.
2.2 Behavioral Synthesis
The other approach used by block-diagram tools for generating a hardware
architecture from a behavioral DSP design is behavioral synthesis. Behavioral
synthesis tools generate architectural-level designs from behavioral-level
designs. While these tools are not completely automatic, they provide an
environment that allows the designer to experiment with a range of
architectural alternatives.
Starting with a behavioral description of a design and user-specified
constraints (such as allowable execution time), behavioral synthesis tools
allocate hardware elements (such as multipliers and memories) and
interconnections between them, assign computations to be performed on these
hardware elements, schedule the sequence of computations on each element,
and generate a controller to manage the sequencing of computations and data
transfers.
Mentor Graphics' DSP Station and Synopsys' COSSAP environments both support
behavioral synthesis. DSP Station was the first commercial high-level DSP
design environment to provide behavioral synthesis capabilities. To provide
these capabilities, it incorporates the MISTRAL 1 and MISTRAL 2 behavioral
synthesis tools. These tools are oriented towards synthesizing specific types
of architectures for DSP designs. MISTRAL 1 synthesizes bit-serial
architectures for low-complexity, low-cost designs, and MISTRAL 2 synthesizes
bus-oriented, serial-parallel architectures for medium-performance designs.
Synopsys' COSSAP DSP environment relies on Synopsys' general-purpose
Behavioral Compiler to generate hardware architectures. Unlike Mentor
Graphics' MISTRAL tools, Behavioral Compiler does not target a specific
style of architecture.
Both DSP Station and COSSAP also allow designers to enter their hardware
architecture manually as is done with SPW, bypassing behavioral synthesis.
Effective use of behavioral synthesis tools often requires that the designer
provide directives (sometimes called pragmas) to the tools, specifying that
certain parts of the behavior should be implemented in certain ways, or
limiting the freedom of the tool in some respects.
Behavioral synthesis tools generate hardware architectures described at the
register-transfer level. Once a behavioral synthesis tool has generated a
hardware architecture, lower-level logic synthesis tools are used to create a
gate-level implementation suitable for mapping to an ASIC or FPGA.
The key benefits of behavioral synthesis for DSP hardware design are the
ability to rapidly explore and evaluate a wide range of architectural
designs, and the ability to find new architectural-level optimizations that
might not otherwise have been discovered. They main drawbacks of this
approach are the fact that to obtain good results, the designer often must
very carefully supervise and direct the tool, and the fact that behavioral
synthesis tools tend to be very costly, typically in the range of
$50,000-100,000, not including related tools needed to perform other steps
of the design process.
3. Libraries
One of the most important features of a block-diagram-based DSP tool is its
block libraries. These libraries give a tool much of its power, by allowing
the designer to reuse existing design elements for much of his or her design.
This is another area where high-level DSP design tools differ significantly.
The key differences among block libraries provided by high-level DSP design
tools are the size and scope of the libraries, the levels of abstraction of
the blocks, and their flexibility.
The block-diagram-based DSP tools mentioned earlier each provide libraries of
several hundred blocks, ranging in abstraction from very high level (e.g., a
complete transmitter) to very low level (e.g., an adder). While all of these
blocks can be used to create simulations, typically only a subset of blocks
can be used for hardware development. Often, this subset is comprised largely
of low-level blocks such as adders, multipliers and registers. This means
that if a behavioral design is first created at a high level of abstraction
for simulation, the designer may have to modify the design by substituting
combinations of lower-level blocks for more complex blocks in order to be
able to generate a hardware implementation.
The scope of a block library can't be judged solely by the number of blocks
it contains. Some tools provide libraries with highly configurable blocks
that can take on different functions based on parameter values set by the
user. This is the case, for example, with some of Mentor Graphics' DSP
Station libraries.
3.1 Adding to Libraries
No matter how large and flexible a tool's block libraries are, it is very
often the case that the user must create new blocks in order to complete a
design, or that the design can be optimized or simplified by creating new
blocks. Therefore, it is important that block-diagram-based tools provide a
straightforward means for creating new blocks.
One way that tools facilitate the creation of new blocks is by providing
source code for their block libraries. This allows the user to modify an
existing, similar block rather than starting anew. Fortunately, the three
commercial block-diagram-based tools that support hardware design all provide
source code for most or all of their block libraries.
Another consideration is the language used to add blocks. DSP Station uses a
single proprietary language (DFL) both for simulation within DSP Station and
for hardware synthesis. COSSAP and SPW, in contrast, use the C language for
simulation and VHDL or Verilog HDL for hardware synthesis. This means that
when creating a new block to be used for simulation and synthesis, the user
must provide two versions of the block: one in C or one in VHDL. This
requires the designer to be familiar with both languages. This may be offset
by the fact that both languages are increasingly widely used standards.
4. Data Types
Most DSP hardware designs use fixed-point numeric data types and arithmetic
because these are simpler and less costly to implement than floating-point.
Therefore, it isn't surprising that block-diagram-based tools for DSP
hardware design only support fixed-point formats for hardware design. Despite
this similarity, there are some important differences in the data type
support of these tools.
While all block-diagram-based tools for DSP hardware design support
fixed-point formats, not all support the fractional arithmetic formats
commonly used in DSP design. In a fractional format, a number is represented
by some number of integer bits to the left of an imaginary radix point,
some number of fractional bits to the right of the radix point, and possibly
a sign bit. While Mentor's DSP Station and Alta Group's SPW allow users good
flexibility to use fractional formats and to vary the formats used throughout
a design, Synopsys' COSSAP currently only supports integer formats. While
designers can work around this limitation and emulate fractional formats by
manually tracking the positions of radix points, this can be a burden.
4.1 Converting Designs from Floating-Point to Fixed Point
It is common for DSP algorithm and system designers to begin their designs at
a high-level using floating-point numeric formats, which frees them from
concerns of overflow, quantization, and scaling. If the design is to be
implemented in hardware, it may later be converted to use fixed-point
formats. A unique advantage of DSP Station's DFL library is that each block
can be configured to use fixed-point or floating-point numeric formats. This
allows the designer to manually convert a design from floating-point to
fixed-point simply by changing parameters, assuming the designer knows what
fixed-point formats to use.
4.2 Fixed-Point Optimization
When developing custom DSP hardware, the designer can use many different
fixed-point numeric formats in a single ASIC, tailoring the precision and
range of the numeric representation to the needs of various intermediate
signals. This allows the designer to reduce the complexity and size of the
needed hardware, lowering production costs and power consumption. However,
this additional freedom comes at a cost: the designer must determine the
numeric formats to be used at each point in the design, making sure to
maintain adequate signal fidelity. Some block-diagram-based DSP tools offer
capabilities to assist the designer in this optimization process.
Both Alta Group's SPW and Mentor Graphics' DSP Station provide the
ability to automatically optimize numeric formats while maintaining
the design's behavior within specified limits. For example, such an
optimization might attempt to reduce the number of bits used to
represent each signal or constant. The two vendors take very different
approaches to fixed-point optimization. Alta's Fixed-Point Optimizer
tool works with any type of signal processing design, but only
optimizes for minimum numeric format size. Mentor's Constant
Optimization Tool is limited to optimizing constants (such as filter
coefficients) in linear, time-invariant, single-rate systems, but can
use a variety of optimization goals (such as minimizing the number of
"1" bits in a set of coefficients) that are appropriate for different
types of hardware architectures. In addition, DSP Station provides a
unique set of fixed-point analysis tools that enable the designer to
predict the severity of limit cycles and quantization noise, given a
particular selection of fixed-point numeric formats.
5. Conclusions
As DSP hardware designs become increasingly complex and time-to-market
windows shrink, high-level, block-diagram-based DSP tools are becoming
increasingly attractive due to their ability to boost productivity,
facilitate the exploration of many design alternatives, and encourage design
re-use. However, these tools are complex and expensive: a single copy of a
complete environment can cost $100,000-200,000, and mastering the tools
requires a significant investment in training.
In this paper, we've explored some of the most important considerations
involved in evaluating block-diagram-based DSP tools for hardware design.
We have also examined how the three commercially available environments
compare in terms of these criteria.
Our focus here has been exclusively on tools targeting ASIC and FPGA
implementation of DSP hardware, as these are the most commercially advanced
of DSP hardware synthesis tools. However, there are also tools emerging to
support the synthesis of larger DSP systems at the printed-circuit-board and
system level.
From our analysis, it should be apparent that each tool has unique strengths
and weaknesses; no single tool is best for all types of hardware designs and
design methodologies. Therefore, when selecting such tools, it is critical to
evaluate them in the context in which they will be used.
6. References
[1] Buyer's Guide to DSP Processors
, Berkeley Design Technology,
Inc. (Berkeley, California), 1995.
7. Acknowledgments
The authors would like to thank Franz Weller for his help in the preparation of this article.
|
