FPGA-Based DSP - Signal Processing Systems - page 710

operations implemented in this fashion is huge, but mostly focuses on standard DSP
operations such as filters and transforms, and extends to matrix computations, for
example [ 21 , 50 , 51 ] . Furthermore, this style of architecture design enables powerful
automatic core synthesis tools to be created. These convert Signal Flow Graph
(SFG) algorithms automatically to systolic cores using graph transformation tech-
niques such as folding and unfolding to balance throughput with resource [ 25 , 48 ] .
Given FPGA's suitability as host to high performance core architectures, the
device vendors themselves provide tools to automatically generate cores for varying
real-time and resource requirements; tools such as Xilinx's Core Generator and
Altera's MegaCore IP Library provide easy access to these cores, and promote a
design reuse strategy for FPGA-based DSP system design. Further, this graph-based
design style for rapid generation of custom core architectures is actively adopted in
a number of commercial design tools, as outlined in Sect. 4.1.2 .

4.1.2 Core-Based Implementation of DSP Applications from Simulink

Since simple cores are easily available in libraries such as Core Generator, the
MegaCore IP Library or others, there is considerable potential for rapid creation of
custom core-based architectures from these component parts. In particular, graph-
based design tools for automatic composition of these to create more complex
custom cores are widely evident. For instance, Synplicity Inc.'s Synplify DSP
allows a user to automatically convert their DSP function, described as a MATLAB
Simulink model, to a custom core. This tool can automatically pipeline and retime
the graph to produce pipelined and multi-channel versions of a corresponding
core. Xilinx and Altera use their System Generator and DSP Builder design tools
respectively to enable a similar process, easing and promoting the uptake of their
Core Generator and MegaCore IP library cores respectively. In both cases there
is a tight coupling between the core behaviour, specified using a Simulink graph,
and the resulting core architecture; a node on the Simulink graph translates to a
component in the resulting circuit, implemented using a core exported from the
vendor repository and cores are connected in a topology identical to that of the
Simulink graph. A generalised version of the process used by both these tools is
shown in Fig. 12 [ 4 , 43 ] .
Behavioural models of the library cores are used to construct a Simulink .mdl
model of the behaviour. After verificaton of the functionality, implementation-
specific models of the cores addressing physical characteristics such as wordlengths
and core timing are integrated into the Simulink model, which must then be
manually manipulated to produce the same functionality taking account of these
physical factors. This process allows verification that the functionality of the core
matches that of the original algorithm. Once this is verified, this graph is exported
to a RTL HDL description and passed to vendor-specific programming tools such
as Xilinx ISE and Altera Quartus-II.
If a development platform exists, this may be integrated into the Simulink
environment. A new Simulink graph which only creates the source stimulus for the