IEEE Circuits and Systems Magazine - Q2 2021 - 43

in Spark, and the nodes we have selected to accelerate on
FPGA. The optimization pass that was added to the Spark
scheduler transforms the DAG by replacing these nodes
with a custom Fletcher Exec node that calls the accelerator.
The row-column conversion step is not necessary
through the use of Arrow; the file reader was replaced by
the Parquet reader library function provided by the Arrow
library, and the FPGA accelerator is based on Arrow and
Fletcher, as discussed in previous sections.
The filter and projection step are composed into an
accelerator design using the Tydal language associated
with Tydi, shown schematically in Figure 9. Both the summation
and regular expression are treated as a primitives.
They can be either IP cores, manually implemented
by the designer, and should be available in the component
library. For the sum, a simple VHDL implementation
is used. We use a tool that generates VHDL for the implementation
of the regular expression matcher [42].
The regular expression matcher checks the predicate,
producing a boolean that is in turn used by the FilterStream
component. At an operating frequency of 200 MHz
(matching the interface frequency of OpenCAPI), it can process
up to 20 characters per cycle. As the company names
in the schema have a maximum length of 40 characters, the
matcher can process a string every 2 cycles or less. The
other components are fully pipelined and can process an
element every cycle. As a result, this accelerator is capable
of processing between 100 and 200 Mrecords/s, depending
on how many records have a name string longer than 20
characters. As the kernel interfaces are 4 bytes wide for
the integer input and 20 bytes wide for the string input, the
theoretical maximum throughput is 4.8 GB/s.
Important to note is that the presented Proof-of-Concept
uses only a single instance of the accelerator. Because
the query uses a commutative aggregation operator, it is
straightforward to duplicate it, and distribute the input to
them using an arbiter. This arbiter does need to keep the
integer and string streams synchronized. When processing
more complex queries, multiple instances of accelerators
need to be managed by software. Development frameworks
exist with the purpose of duplicating a kernel design
provided by the developer, such as Fleet [43] and TaPaSCo
[44]. As the tool-chain is currently in a very early prototyping
stage, implementing parallel kernel instances is left as a
future development.
B. Performance
Executing the query on the dataset, we measured the
accelerator provides a throughput of 135 M records/s,
for this particular dataset equaling 2.75 GB/s. The area
utilization of the FPGA design is presented in Table II.
This kernel can be duplicated several times, especially
considering a large fraction of the logic will be shared.
SECOND QUARTER 2021
This design will in practice saturate the bandwidth of
the OpenCAPI interface when using approximately 8 instances,
which will likely fit in the available FPGA logic.
The most important result is that this performance was
achieved from a very high-level implementation, even while
the tool-chain used is in a very early stage of prototyping.
This gives a reassuring perspective on the ability of the approach
to generate high-performance FPGA circuits from
these highly abstract big data applications.
In Figure 10, a comparison is plotted of running the query
on a single instance of the FPGA accelerator versus a vanilla
Spark installation running on a single thread. The
Spark framework does not allow differentiating the Parquet
reading from the actual execution (because Spark will interleave
these steps and only perform reads from the file
when blocks of data are being requested by lazy evaluation).
However, for the FPGA-accelerated execution we can
see that the actual execution takes only a small fraction of
the total time.
From Fletcher Interface
Seconds
Company
i
Regex
o
i
Filter
o
i
Reduce
Operation:
Sum
o
Result
To Fletcher Interface
Figure 9. Schematic of the hardware design created using
the composition language.
Table II.
FPGA resource utilization.
Resource
CLBs
LUTs
Registers
BRAM tiles
Used
17322
85193
101305
108
Available
162960
1303680
2607360
2016
Utilization
10.63%
6.53%
3.89%
5.36%
IEEE CIRCUITS AND SYSTEMS MAGAZINE
43
Predicate
Top
IEEE Circuits and Systems Magazine - Q2 2021

Table of Contents for the Digital Edition of IEEE Circuits and Systems Magazine - Q2 2021
