IEEE Circuits and Systems Magazine - Q2 2021 - 104

The program is effectively a schedule computed statically
by the compiler, exactly as in the case of staticallyscheduled
HLS. The appeal is clear: these processors do
not need all the complex hardware that superscalar outof-order
processors require to make runtime decisions.
Researchers quickly figured out that VLIW processors
need very sophisticated compilers. Today, a large
body of literature exists on VLIW compilation techniques
but such techniques often require either complex
heuristics to drive the optimizations or pragmas from
the programmers. Conversely, dynamically scheduled
out-of-order processors achieve good levels of parallelism
on-the-fly and without extensive code preparation,
yet at the price of more complex hardware. Many of the
key transformations to exploit fine-grain parallelism between
operations in statically scheduled HLS derive directly
from VLIW compilation techniques, such as trace
scheduling, software pipelining, and modulo scheduling
[27], [46], [58]. But, exactly as HLS tools producing statically
scheduled circuits, VLIWs suffer when handling
code with irregular memory or control dependences.
The dichotomy in computer architecture may tell us
something about the future of dynamically scheduled
HLS. In the mid-1990s, Hewlett-Packard and Intel partnered
to develop the first (and, to date, only) generalpurpose
VLIW processor: Itanium. Servers using Itanium
shipped mostly in the 2000s and were a major
commercial failure [23]. Today, VLIWs thrive exclusively
in markets with extremely regular and predictable
applications, and where it is acceptable for skilled developers
to tune code manually. They are, for instance,
in our smartphones where they run complex digital signal
processing applications. However, general-purpose,
irregular, and control-dominated computing tasks require
Req
Ack
Data
Four-Phase
(a)
Circuit
Clock
Data
Ready
Valid
Req
Ack
Two-Phase
the runtime flexibility of dynamic scheduling. Even in
cost-sensitive devices such as smartphones, none of
the processors which run operating systems (e.g., Android
and iOS) are VLIWs.
Today, with FPGAs moving to data centers and facing
broader application classes, HLS tools might have
to satisfy the needs of general-purpose markets as well.
Apart from the advantage of exploiting parallelism in
cases where static scheduling cannot, the ability of dynamic
scheduling to find an acceptable solution without
the programmer's help may be critical in a future where
HLS will not be driven by hardware designers (available
to study the generated circuits and to restructure the input
code) but by higher-level code generation tools (e.g.,
Delite [31]) and, ultimately, by software programmers.
V. From High-Level Code to a Dynamically
Scheduled Circuit
In this section, we outline our HLS methodology which
produces dynamically scheduled circuits out of C/C++
code. We first provide an overview of the latency-insensitive
design paradigm; we then discuss the dataflow
primitives we use and, finally, we describe our HLS conversion
strategy.
A. Latency-Insensitive Protocols
Latency-insensitive protocols [8], [18] implement dyna -
mically scheduled dataflow circuits. These circuits are
built out of dataflow units which exchange pieces of data
(referred to as tokens [50]) through channels composed
of data lines and paired with handshake control signals:
a valid signal indicates the availability of a piece of data
and the ready signal indicates the readiness of a unit to
accept new data. This distributed control system enables
dataflow circuits to adapt the schedule at runtime to variable
latencies of particular memory access patterns and
control-flow decisions.
The latency-insensitive communication strategy origiD1
X
D2
(b)
Figure
6. (a) Asynchronous and (b) synchronous latency-insensitive
protocols. We here consider synchronous dataflow
circuits. This figure is adapted from the work by Cortadella
et al. [19].
104 IEEE CIRCUITS AND SYSTEMS MAGAZINE
D3
D4
nates from the asynchronous circuit domain. Figure 6(a)
illustrates two commonly used asynchronous protocols
which employ a pair of request and acknowledge signals
to regulate data transfers. In the 4-phase protocol, a communication
cycle involves four events (i.e., rising and
falling edges) and the handshake signals return to zero
at the end of each data transfer [29]. In the two-phase
protocol, each cycle involves only two events (i.e., either
rising or falling edges of the handshake signals) [61].
In the rest of this article, we consider a synchronous
latency-insensitive protocol: the initiation and completion
of data transfers are indicated by the value of the
handshake signals at the rising clock edges [18], as illustrated
in Figure 6(b). Our perfectly synchronous designs
are therefore compatible with traditional VLSI
SECOND QUARTER 2021
IEEE Circuits and Systems Magazine - Q2 2021

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