U. Glaeser

FIGURE 37.6 Design flow using an HDL (e.g., VHDL).
Note the absence of a feedback loop in the synthesis
branch: for a design verified in simulation, the synthesis
process is a black box.
communication outside the array. Logic blocks take up to four 2-bit inputs and produce 2-bit outputs:
a row of the array can thus process up to four 46-bit words. Garp’s designers hypothesize that the
reconfigurable section may be used effectively to implement the critical kernels found in most code: the
ability to hard-wire the control logic will reduce instruction fetch bottlenecks and better exploit parallelism.
Memory queues, which handle streaming of data to and from memory, were added because many
applications which use reconfigurable systems effectively process streams of data.
Results from the Garp simulator on a wavelet image compression program showed an overall
speedup of 2.9 compared to the MIPS processor. Individual kernels within this program showed
speedups up to 12, observed when a kernel had high exploitable instruction level parallelism and the
configuration loading time could be amortized over many compute cycles. Comparisons of Garp’s
performance with a 4-issue superscalar processor also showed significant speedups, indicating that
Garp was able to exploit more instruction level parallelism, sustaining 10 instructions per cycle in
many cases.
Programming Reconfigurable Systems
High-Level Hardware Design Languages
The design flow for a reconfigurable system is shown in Fig. 37.6; a high-level hardware design language
(HDL) is usually used for the software modeling stage: VHDL and Verilog are widely used as excellent
support tools are available. The design process is basically identical to that used for any software system:
specifications are drawn up and validated, software models created and verified and the compiled
“program” is loaded onto the target devices or burnt into ROMs. The only significant difference is that
two compilers are generally used. A simulator compiles VHDL or Verilog source and produces diagnostic
output not only as text to consoles or logged to files, but as waveforms or lists of changes in signal values.
When the designer has verified that the models perform in accordance with their specifications under
simulation, a synthesizer compiles the source again to a netlist—an intermediate representation of the
final circuit. Device-specific place-and-route tools take netlists as input and place logic into logic blocks
and configure the FPGA’s routing resources to make the necessary connections between logic blocks and
I/O pins. The output of this stage is a configuration file—a stream of bits which are loaded onto the
device to program its internal registers, multiplexors, etc. For many designs, the whole process (synthesis →
place-and-route → configuration bit stream) can be viewed as a single step black-box, which turns verified
HDL models into configuration files. Whilst it may take several hours for a complex system, it does not
require any input from the user. The designer will usually simply advise the tools whether speed or area
is the primary constraint. Significant interaction with the place-and-route tools is needed only if there
are performance constraints which cannot be met with default parameters: in this case, manual placement
of logic blocks can assist in satisfying the constraints.
© 2002 by CRC Press LLC
HDL Code
Specification
Software Models
Simulation Synthesis
Waveforms
Signal lists
Reports
HDL Code
Net lists
Place and Route
Configuration
bit stream
Program Device