|
N. R. Satish
Bio:
N. R. Satish is currently a Ph.D. student in Electrical Engineering at
the University of California, Berkeley. His research interests include
automated design space exploration and mapping of DSP/multimedia
applications onto modern programmable processors. He received a
Bachelors of Technology (Honors) degree in Computer Science and
Engineering from the Indian Institute of Technology, Kharagpur. He is a
student member of the ACM and IEEE.
Abstract:
DSP applications are typically highly data parallel computations which
can typically be expressed as vector or matrix operations.
Matlab/Simulink has become the de-facto standard for developing new
applications in the DSP and telecom sectors. This is not only due to its
inherent ability to express the data parallelism but also the support
infrastructure around it, consisting of pre-optimized libraries for most
common kernels as well as good debug and visualization tools.
Unfortunately, there exists no flow from Matlab to implementation on DSP
platforms.
DSP platforms have traditionally been processors that are specialized
for digital processing applications. Such processors perform well for a
variety of DSP applications, since they have hardware accelerators for
common kernels, as well as specialized memory architectures. The problem
with such platforms is that the set of hardware accelerators are
predefined. An FPGA would serve well as an acceleration platform on
which users can customize their accelerators on a per-application basis.
Such platforms would also contain a processor to perform the
control-dominated portion of the application. One way of exposing the
functionality of the accelerators is to introduce additional
instructions that the processor can execute, thereby setting up a
processor-coprocessor system. One such recent platform is the Stretch
platform, which is developed by a startup company, Stretch Incorporated.
Furthermore, recently there has been a push towards multiprocessor DSP
solutions.
Matlab is not well suited to target such platforms. One major problem is
that Matlab deals with floating point data representations, which are
very different from irregular fixed point representations used on FPGAs.
While Matlab has good constructs for data parallelism, there is no
natural construct for process level parallelism. Most importantly, there
is no path from Matlab to a language that the compilation tools for the
target platform support. This results in an implementation gap. One way
to bridge this gap is to use a Simulink wrapper around Matlab code that
has been pre-optimized for the target platform. This would require a
flow to be present between Matlab and the target language. There has
been interest recently in tools converting Matlab to C and HDL
implementations. We intend to explore the completion of the flow from C
to the modern platforms and show a complete design flow from Simulink to
uniprocessor and multiprocessor platforms with instruction set
instructions on FPGAs.
Links:
|
