|
The XtremeDSP™ Development Kit-II,
developed by Nallatech in partnership
with Xilinx, provides an ideal development
platform for high-performance signal
processing applications such as
software defined radio, networking,
HDTV, 3G wireless, and video imagery.
The kit provides entry into scalable
DIME-II systems from Nallatech.
The combination of the XtremeDSP kit,
Simulink™ environment in MATLAB™,
and Xilinx System Generator 6.1i software
offers a complete design framework for
FPGA and DSP designers to get partial or
entire systems running on hardware quickly
and efficiently. This approach is redefining
time to market by rapidly producing highperformance
systems with design flexibility,
as well as the possibility of reconfiguring
and upgrading the system without changing
the physical hardware.
Features
The XtremeDSP kit includes an on-board
user-programmable Xilinx XC2V3000
FPGA, two 14-bit ADC channels with as
many as 65 mega samples per second
(MSPS) per channel, and two 14-bit
DACs with as many as 160 MSPS per
channel. A Spartan-II™ FPGA is preconfigured
with 32 bit/33 MHz PCI or
USB 1.1 firmware. One bank of 1 Mb
ZBT SRAM, configured as 512K x 16, is
also available. An external power supply
allows you to power the kit on its own;
JTAG configuration headers and status
LEDs provide feedback. Figure 1 shows
the XtremeDSP kit. Figure 2 shows a
block diagram of the kit.
The XtremeDSP kit comes with
Nallatech’s Field Upgradeable Systems
Environment (FUSE) FPGA management
software. This software provides the ability
to control and configure the FPGA and
transfer data between the kit and the host
PC thorough a GUI or C-based API.
Additional options allow the use of Java or
MATLAB M-code script control.
Designing with System Generator
The first step in creating a System
Generator model is as follows:
- Open a Simulink workspace and drop
a System Generator token in at the
top level of the model.
- Open up the token. This allows you
to select various options, such as
FPGA device, package, system clock,
location of the generated VHDL, and
type of synthesis tool required. You
can also drop the token into a subsection
of the System Generator model.
This functionality allows you to construct a
system quickly by placing
and connecting traditional
System Generator
blocks. You do not have
to write any VHDL,
although a black box provides
this capability if
required.
Other user-friendly
features include the ability
to drop Xilinx efficient
handcrafted IP blocks
into the model, such as fast Fourier transforms
(FFTs), multipliers, direct digital
synthesizers (DDSs), linear feedback shift
registers (LFSRs), and finite impulse
response (FIR) filters.
Each block within the model has associated
options that allow for customization.
For example, Figure 3 depicts the different
options available for block RAM placement,
such as size, initial values, writing
options, and distribution of memory.
Grouping various System Generator
blocks together generates subsystems, creating
a hierarchy within the model. Each
subsystem has its own associated input and
output ports. Placing low-level blocks into
the Simulink environment creates a bottom-up design approach, which allows
functional verification of each subsection
before it is included in the system model.
During the design process, the Simulink
environment allows you to test and verify
the model, providing an array of test facilities
for this purpose, including scopes,
graphs, and displays. For further pre- and
post-processing and verification, you can
import to and extract the data from the
MATLAB environment. When extracting
data, MATLAB functions offer extensive
post-processing options, including three-dimensional
visualization graphs, plotting
images, and a vast collection of computation
algorithms.
Hardware Co-Simulation on the
XtremeDSP Kit-II
Verification of the software model means
that you can then test and verify the model
in hardware by creating a hardware co-simulation
block, executed by the System
Generator token in the model, which controls
the design flow. Select the compilation
target for hardware co-simulation in this
block and choose the XtremeDSP kit as the
hardware target. This will generate an
equivalent hardware Simulink co-simulation
library block.
This block is effectively an FPGA bitstream,
the result of a synthesis tool such as
XST (Xilinx Synthesis Tool). The block
takes care of board operations such as
device configuration, data transfers, and
clocking. Each port in the software model
maps to the relevant hardware co-simulation
library block.
The co-simulation library block now
offers options for hardware co-simulation
with the DIME-II XtremeDSP Kit-II.
When Simulink simulates the model, it
takes the results from the FPGA on the
XtremeDSP kit. You can treat the library
block exactly the same as any other in the
Simulink library.
TCP/IP Hardware Co-Simulation
Having produced a hardware co-simulation
library block, your next step is to select
which bus configuration over which cosimulation
will take place. The XtremeDSP
kit offers the following standard co-simulation
options: PCI and JTAG. An enhanced
option is available from Nallatech to add
support for TCP/IP, which allows you to
share the XtremeDSP kit for hardware cosimulation
through another workstation.
As the XtremeDSP kit is a derivative of
Nallatech’s DIME-II BenONE motherboard
and BenADDA module, this combination
of hardware makes the connection
to an Ethernet module possible. This provides
the capability to power the board on
its own without the need for additional
workstations and their associated licenses.
With this module interface connection on
the BenONE motherboard, the board can
now be run on its own anywhere – providing
that it has a TCP/IP location.
Therefore, if a design team wants to efficiently
utilize the FPGA development
board, the board no longer needs to be
swapped from workstation to workstation,
as each designer can change their location,
providing that the appropriate software
licenses are available.
For an extreme proof-of-concept example,
take a transatlantic hardware co-simulation
of the AES-128 (Advanced
Encryption Standard). The board runs on
its own with a loosely coupled connection
to the Internet, located in a laboratory in
San Jose, California, while the design of the
AES-128 encryption core in System
Generator is completed in the United
Kingdom. Simulation speeds were
increased by around a factor of two, but
more importantly, the FPGA engineer did
not need a board for functional hardware
verification to occur.
This capability provides significant benefits
when working with shared hardware in
both the development and debug phases of a
product’s lifecycle. To have the ability to connect
to a remote piece of hardware and carry
out co-simulation aids the development of
products within a team environment, where
independent and geographically scattered
team members need access to a single
physical piece of hardware at a particular
site. A principle example of this could be
development and support work for base
station components.
Hardware Co-Simulation Greater than 32 Bits
When simulating designs in System
Generator without an FPGA co-simulation,
you can simulate any number of binary
widths by using the library blocks in
System Generator. This is not currently
possible when converting the model for cosimulation
on the FPGA.
Once the I/O bit widths become greater
than 32 bits, System Generator will indicate
that an error has occurred. To avoid
such an error, split the bit widths down to
32 bits so that each I/O port on the co-simulation
library block has a width of 32 bits.
Incorporating a part-System Generator,
part-FPGA wrapper keeps the same bit
widths within the model and the FPGA.
Slicing the data path on entry to the cosimulation
block allows concatenation
back into the FPGA for the IP core or system.
This data path will split again before
leaving the FPGA, finally concatenating
back into the Simulink model.
Figure 4 illustrates this technique for cosimulating
bit widths of 128 for the AES-
128. The gray section in Figure 4 represents
the co-simulated area on the FPGA
achieved during the simulation process. The
area outside the gray region shows the fixed
order in which the bit widths appear in the
System Generator model. This method
applies to any number of bit widths: for
example, 64, 128, 256, and 77.
Conclusion
The XtremeDSP Kit-II offers the ideal
development platform for DSP designers.
Combining the kit with System Generator
provides the capability to design systems
without the need for programming in
VHDL, although the option exists to add
VHDL and even MATLAB M-code for
HDL auto generation.
By including a TCP/IP interface, unless
there is a need to see or connect inputs to
the board, this type of connection is a
viable option in hardware co-simulation
and offers cost-effective, efficient utilization
and time-saving benefits.
To learn more about DIME-II, please
visit www.nallatech.com/solutions/products/embedded_systems/dime2/index.asp, or e-mail contact@nallatech.com. For more information
about the XtremeDSP Development
Kit-II, please visit www.xilinx.com/ipcenter/dsp/development_kit.htm.
Printable PDF version of this article with graphics.  (4/15/04) 220 KB |
