|
Look-up tables, function generators, block
RAMs, and multipliers provide an ideal foundation
for creating programmable hardware
solutions. Combine these useful primitives
with mature integrated toolsets that are capable
of simulating complex systems and synthesizing
FPGA hardware designs, and it is easy
to think that the hard work is behind you.
However, as the famous saying goes,
“the devil is in the details” – the difficulty is
found when you look deeper into the challenge.
Although the components necessary
for many of today’s hardware systems are
often reasonably refined and well understood,
their integration in applicationspecific
contexts is not always as straightforward.
Although programmable logic is steadily
maturing, the complex systems utilizing
them are evolving at a much more rapid
pace. This increasing system complexity is
beginning to introduce an unacceptable
level of risk into product development
cycles. Time to market and development
costs are increasing, product reliability is
more difficult to ensure, and we’re forced
to focus our efforts on tasks unrelated to
our core competencies.
Fortunately, although system requirements
are increasingly complex, so are the
tools available for building them.
Decreasing FPGA costs, coupled with significant
improvements in performance
and capacity, are paving the way for a new
breed of products that I call “domain-specific
product platforms” (DSPPs).
These platforms are designed to decrease
time to market and costs while increasing
product reliability, allowing you to refocus
your efforts on developing solutions
rather than infrastructure.
What are DSPPs?
You have probably used general-purpose
development boards to create early prototypes
of designs, thereby minimizing risk.
Once a design is proven on a prototype
platform, you can create a custom hardware
system that is cost-engineered and
optimized for that particular application.
Unfortunately, in today’s complex systems
much of the development risk is in creating
the custom hardware solution itself.
DSPPs are an evolution of development
boards. They remove the need for a custom
hardware system design by providing a
modular development platform that can
also serve as the end product. This eliminates
the need for a subsequent custom
hardware implementation. Historically, the
cost of providing a platform with the flexibility
required for a DSPP has been prohibitively
high. Fortunately, there is an
emerging class of FPGA-based modular
development boards targeted at specific
application domains that brings this capability
to the mass market.
A Hypothetical Development Project
Take image processing, for example.
Xilinx® FPGAs are an ideal technology for
implementing morphological image processing
systems. Creating the necessary
pipeline processing algorithms in an FPGA
fabric can produce systems with orders-of-magnitude
improvement in processing
speed over even the most powerful microprocessor
systems available today, without
sacrificing flexibility.
This tremendous processing speed opens
up numerous opportunities for real-time
image processing systems such as airborne
collision avoidance, three-dimensional
facial recognition and verification, and real-time
two-dimensional ultrasound imaging
of the heart.
The image processing algorithms
themselves can be implemented effectively
and efficiently using little more than
some Verilog/VHDL experience, Xilinx
ISE™ Foundation™ software, an FPGA
motherboard, and a Parallel Cable IV
programming pod. In reality, however,
this only begins to explore the work
required for a final product.
Let’s take an in-depth look at a hypothetical image processing application: a
collision avoidance system for the airline
industry. Our system will use input from
three cameras mounted in strategic locations
on the airplane exterior. An FPGA
processing stack will synthesize the data
from each camera to determine the probability
of a collision based on the current
flight path. A control unit will provide
communications to the pilots through an
Ethernet connection with the processing
box. A diagram of the hypothetical system
is shown in Figure 1.
After analyzing the problem and creating
an appropriate algorithm using software
simulations, we calculate the
following resource estimates:
- 225,000 logic cells
- 9,000 block RAM (kb)
- 800 18 x 18 multipliers
The analysis also resulted in the following
recommendations:
- Several portions of the algorithm are
much better suited for procedural code
using the PowerPC™ cores embedded
in Virtex™-II Pro devices
- You could efficiently implement the
floating point calculations using one of
the PowerPC processors coupled with a
third-party floating-point core
- A cost-effective implementation would
utilize five Virtex-II Pro P50 parts
(XC2VP50), implying that the algorithm
must be implemented across
several FPGA chips
Fortunately, Xilinx provides the
SelectLink interface to simplify FPGA-to-FPGA communications. However, the system
I/O is quickly beginning to look fairly
complex. At a minimum, we now need:
- Three Camera Link interfaces to
feed video data into the FPGA at
real-time rates
- A SelectLink implementation to facilitate
high-speed data transfer between
each of the FPGAs
- Integration of PowerPC peripherals
with an Ethernet PHY for control-unit
communications
- A PowerPC-to-Flash interface for booting
the microprocessor
- A PowerPC-to-SDRAM interface for
running the microprocessor
We also need to consider the implications
of loading bitsreams into the FPGA
from Flash memory at power up. A simplified
system block diagram of the system is
shown in Figure 2.
Looking at the system now, in conjunction
with the project schedule, it’s easy to
become frustrated. It has become painfully
clear that the focus of the project will
not be developing and implementing a
collision avoidance algorithm, but more
about developing various I/O interfaces
between the FPGA, the PowerPC cores,
and the outside world.
Now we need an army of engineers – or
at least a few engineers with an army of
skills – to bring everything together. Any
hiccups along the way (schematic design,
PC board layout, and fabrication, including
any signal integrity issues, PowerPC
programming, and FPGA design) could
wreak havoc on the project schedule.
Reducing Risk
DSPPs provide a much-needed alternative
to system design and are becoming a viable
option for reducing project risk. One such
example of a DSPP for the image processing
domain is the Silver Bullet from Pixel
Velocity (Figure 3). Although appropriate
for many FPGA-based embedded systems,
its design is focused on easing the development
of high-speed, image-processingbased
systems.
Returning to our hypothetical example,
Silver Bullet can help solve our collision
avoidance system I/O problem by providing
a scalable and modular platform that
relieves us from focusing on mundane system
details, allowing us to turn our attention
back to algorithm development.
You can configure the core platform to
use anywhere from one to eight FPGA
motherboards, each populated with a
XC2VP30, XC2VP40, or XC2VP50
Xilinx FPGA. Daughtercards are available
to add functionality as necessary for
Ethernet, FireWire, Camera Link, and
LVDS communications.
High-speed communication between
the FPGAs is handled through the
SelectLink interface, which easily provides
bandwidth of more than 500 Mbps/pin
and allows you to partition algorithms
across multiple FPGAs. The burden of
developing PowerPC-based embedded
solutions is minimized by providing working
reference implementations that include
the use of custom general-purpose I/O FPGA fabric interfaces; peripherals such as
UARTs for RS-232 and custom serial communications;
an Ethernet MAC; and memory
interfaces for Flash, SRAM, and
SDRAM.
In the context of our example, the project
requirements are starting to
look much different, and much
more manageable:
- Determine required performance
and which Silver Bullet
modules we need
- Use the reference implementations
to get a better understanding
of the inner
workings of Silver Bullet
- Modify the reference implementations
to suit the needs
of our project
- Develop and integrate the
FPGA hardware modules and
software necessary to calculate
collision probabilities
- Test, perform Q/A, and ship
Of course there will still be
plenty of work necessary to
build our application, but there
is no need to reinvent the wheel
and introduce the many levels
of risk involved in developing
each of the required I/O interfaces.
In this scenario we can
focus on what we’re good at, which is the
development and implementation of
image-processing algorithms.
What’s Next
Utilizing DSPPs as an end product is a fundamental
shift that is taking place in the
industry. In the past, designers used evaluation
boards to develop prototypes that would
then be refined to into cost-effective product
implementations, likely using ASICs.
But with the rapidly rising performance
and capabilities of FPGAs – in conjunction
with rapidly falling costs – it is
becoming standard practice to include
FPGAs in final products. Not only is this
becoming cost-effective for products that
ship in volume, but it offers a new level of
flexibility by providing significant field
upgrade capability as well as the ability to
significantly redesign products at a very
low cost. This is especially important
considering that the “standards” we develop
around really seem to be rapidly evolving
guidelines.
With DSPP systems handling many of
the details that are relevant across a range of
projects, the next step in the evolution is to
create the tools necessary to simplify the
application-specific algorithm development
process. In the case of image processing,
many experts are trained in developing
floating-point C++ algorithms. As we
know, that is not always conducive to
FPGA-based hardware development,
which is more suited
to integer-based algorithm
implementations.
This can introduce another
difficult task in the development
process: converting
floating-point algorithms into
integer-based algorithms suitable
for RTL implementation.
Pixel Velocity is currently
developing a tool called
Liquid Gates, which automates
the process of creating
hardware from C++ algorithms.
Developers can use
this integer-based C++ development
environment to create
and refine algorithms that
can then be programmed
directly into Silver Bullet with
the push of a button.
Conclusion
Domain-specific product platforms
are changing the landscape
of product development.
Advances in FPGA technology
and system complexity are not
only making this new paradigm possible, but
soon may make it necessary to remain competitive.
By significantly reducing time to
market with a relatively low-cost product
platform, we can keep up with changes in the
market and reduce project risk significantly.
Xilinx is paving the way for optimized
DSPPs with their Advanced Silicon
Modular Block Architecture (ASMBL).
To learn more, visit www.xilinx.com/products/virtex4/overview/asmbl.htm.
Printable PDF version of this article with graphics.  (3/15/05) 250 KB |
