SNAFU: An Ultra-Low-Power, Energy-Minimal CGRA-Generation Framework and Architecture
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
S NAFU: An Ultra-Low-Power, Energy-Minimal
CGRA-Generation Framework and Architecture
Graham Gobieski Ahmet Oguz Atli Kenneth Mai Brandon Lucia Nathan Beckmann
gobieski@cmu.edu aatli@andrew.cmu.edu kenmai@ece.cmu.edu blucia@andrew.cmu.edu beckmann@cs.cmu.edu
Carnegie Mellon University
Abstract—Ultra-low-power (ULP) devices are becoming per- require sophisticated processing [45, 46]. Machine learning
vasive, enabling many emerging sensing applications. Energy- and advanced digital signal processing are becoming important
efficiency is paramount in these applications, as efficiency de- tools for applications deployed on ULP sensor devices [22].
termines device lifetime in battery-powered deployments and
performance in energy-harvesting deployments. Unfortunately, This increased need for processing is in tension with the ULP
existing designs fall short because ASICs’ upfront costs are too domain. The main constraint these systems face is severely
high and prior ULP architectures are too inefficient or inflexible. limited energy, either due to small batteries or weak energy
We present S NAFU, the first framework to flexibly generate harvesting. One possible solution is to offload processing to
ULP coarse-grain reconfigurable arrays (CGRAs). S NAFU pro- a more powerful edge device. However, communication takes
vides a standard interface for processing elements (PE), making
it easy to integrate new types of PEs for new applications. Unlike much more energy than local computation or storage [22,
prior high-performance, high-power CGRAs, S NAFU is designed 40]. The only viable solution is therefore to process data
from the ground up to minimize energy consumption while locally and transmit only a minimum of filtered/preprocessed
maximizing flexibility. S NAFU saves energy by configuring PEs data, discarding the rest. This operating model has a major
and routers for a single operation to minimize switching activity; implication: the capability of future ULP embedded systems
by minimizing buffering within the fabric; by implementing a
statically routed, bufferless, multi-hop network; and by executing will depend largely on the energy-efficiency of the onboard
operations in-order to avoid expensive tag-token matching. compute resources.
We further present S NAFU -A RCH, a complete ULP system Existing programmable ULP devices are too inefficient:
that integrates an instantiation of the S NAFU fabric alongside Commercial-off-the-shelf (COTS) ULP devices are general-
a scalar RISC-V core and memory. We implement S NAFU in
RTL and evaluate it on an industrial sub-28 nm FinFET process purpose and highly programmable, but they pay a high energy
across a suite of common sensing benchmarks. S NAFU -A RCH tax for this flexibility. Prior work has identified this failing
operates atSpeedup vs. Scalar
Energy vs. Scalar 1.0 10 process with compiled memories. S NAFU -A RCH operates
atUltra-low-power CGRAs High-performance CGRAs
ULP-SRP [34] CMA [55] IPA [17] HyCube [33] Revel [75] SGMF [71] S NAFU
Fabric size 3×3 8×10 4×4 4×4 5×5 8×8 + 32 mem N×N (6×6 in
S NAFU -A RCH)
NoC Neighbors only Neighbors only Neighbors only Static, bufferless, Static & dynamic Dynamic routing Static, bufferless,
multi-hop NoCs (2×) multi-hop
PE assignment Static Static Static Static Static or dynamic Dynamic Static
Time-share PEs? Yes Yes Yes Yes Yes Yes No
PE firing Static Static Static Static Static or dynamic Dynamic Dynamic
Heterogeneous PEs? No No No No Yes Yes Yes
Buffering (approx.) — — 188 B / PE 272 B / PE ≈1 KB / PE 1 KB / PE 40 B / PE
Power 22 mW 11 mW 3–5 mW 15–70 mW 160 mW 20 W104
Bring your own rd module PE
functional da e RTL
Log power (mW)
2-3 orders of an ac (input clk,
St terf Generation
103 magnitude unit in input data);
SystemVerilog
102 Description
101 Your logic Synthesisr r r r r
masked_prodsum():
1. vload v1, &a 1 2 2 M
1 M
M 5 M Memory layout
r r r r r
2. vload v0, &m
3. vmuli v1.m, v1, 5
Extract 3 Compile S 3
C 4B a[0] a[1]
4. vredsum v3, v1 4 ILP
r r r r m[0] m[1] …
5. vstore &c, v3
S B
Scheduler r r r
…
Vector Assembly 5 S Bank conflict
m[0]=0, m[1]=1
r r
Active PEs Memory stall 0 = token/element #
r0 r0 r r r r r r r r r r r r r r r r r r r r r r r
1 0 2 1 3 2 4 3 0
2 M
1 M
M 5 M M 2 M
1 M 5 M M 2 M
1 M 5 M 2 M
1 M
M 5 M 2 M
1 M
M 5 M
Execute r r r r r r r r r r r r 0 r r r r r 1 r r r r r 2 r r r
S 3
C 4B S 3
C 4B S 3
C 4B S 0
3
C 4B S 3
C1
4B
r r r r r r r r r r r r r r r r r r r r
S B S B S B S B S B
…
r m[0]=0 à r
…
… r m[1]=1 à
…
…
r r r r r r
Fires as soonr r r r r r
S S inputs ready S op disabled àS op enabled àS
r r r r
r r r
v1[0] unchanged r r
v1[1] *= 5 r
…
Time: 1 2 3 4 5
Figure 4: An example execution on a S NAFU CGRA fabric. The DFG is extracted from vectorized C-code, compiled to a bitstream, and
then executed according to asynchronous dataflow firing.
CGRA generated by S NAFU. This kernel multiplies values Configuration Handles On-chip
signals network signals
at address &a by 5 for the elements where the mask m is variable timing
ce ow
cd ol
a
oun
oe r
t
n
opr
at
nc
in
Control
ip
nr
ie
set, sums the result, and stores it to address &c. S NAFU’s
ce
signals
compiler extracts the dataflow from the kernel source code
fe fcle fdo
n ar ne
ucore config
and generates a bitstream to configure the CGRA fabric. The Data buffer
scalar core configures the CGRA fabric and kicks off fabric Your config
Data buffer
execution using three new instructions (vcfg, vtfr, vfence), µcfg Bufferless
input Router
after which the CGRA runs autonomously in SIMD fashion Intermediate buffer(s)
over arbitrarily many input data values. The fabric executes
va dy
Configurable
z e
µcore
dolid
n
op
a
m
d
b
a
re
the kernel using asynchronous dataflow firing: number of inputs
1 In the first timestep, the two memory PEs (that load a[0] Standardized
and m[0]) are enabled and issue loads. The rest of the fabric Interface
FU-specific logic
is idle because it has no valid input values.
2 The load for a[0] completes, but m[0] cannot due to a bank
conflict. This causes a stall, which is handled transparently by Processing Element
S NAFU’s scheduling logic and bufferless NoC. Meanwhile, Figure 5: S NAFU provides a standardized interface that makes
the load of a[1] begins. integrating new types of PEs trivial. S NAFU handles variable-latency
3 As soon as the load for m[0] completes, the multiply logic, PE-specific configuration, and the sending and receiving of
operation can fire because both of its inputs have arrived. values from the on-chip network.
But m[0] == 0, meaning the multiply is disabled, so a[0]
and provides a “bring your own functional unit” interface,
passes through transparently. The load of a[1] completes,
allowing easy integration of custom FUs into a CGRA. For
and loads for a[2] and m[1] begin.
the application programmer, S NAFU is designed to efficiently
4 When the predicated multiply completes, its result is
support SIMD execution of vectorized RISC-V C-code, using
consumed by the fourth PE, which keeps a partial sum
a custom compiler that targets the generated CGRA.
of the products. The preceding PEs continue executing in
pipelined fashion, multiplying a[1] × 5 (since m[1] == 1)
A. Bring your own functional unit (BYOFU)
and loading a[3] and m[2].
5 Finally, a value arrives at the fifth PE, and is stored back S NAFU has a generic PE microarchitecture that exposes
to memory in c[0]. Execution continues in this fashion until a standard interface, enabling easy integration of custom
all elements of a and m have been processed and a final functional units (FUs) into the CGRA. If a custom FU
result has been stored back to memory... implements S NAFU’s interface, then S NAFU generates hardware
The next three sections describe S NAFU. Sec. IV describes the to automatically handle configuring the FU, tracking FU and
S NAFU ULP CGRA-generator. Sec. V describes how S NAFU overall CGRA progress, and moderating its communication
minimizes energy. And Sec. VI describes S NAFU -A RCH. with other PEs. There are few limitations on the sort of the
logic that S NAFU can integrate. S NAFU’s interface is designed
IV. D ESIGNING S NAFU TO MAXIMIZE FLEXIBILITY to support variable latency and currently supports up to four
S NAFU is designed to generate CGRAs that minimize energy, inputs, but could be easily extended for more. The PE can
maximize extensibility, and simplify programming. For the have any number of additional ports and contain any amount
architect, S NAFU automates synthesis from the top down of internal state.
5Fig. 5 shows the microarchitecture of a generic S NAFU so that it can update internal state (e.g., memory index for a
processing element, comprising two components: µcore and strided load), but the fallback value is passed through.
µcfg. The µcore handles progress tracking, predicated execution, Configuration services: The µcfg handles processing element
and communication. The standard FU interface (highlighted configuration, setting up a PE’s dataflow routes and providing
orange) connects the µcore to the custom FU logic. The µcfg custom FU configuration state. Router configuration maps
handles (re-)configuration of both the µcore and FUs. inputs (a, b, m, d) to a router port. The µcfg forwards custom
Communication: The µcore handles communication between FU configuration directly to the FU, which S NAFU assumes
the processing element and the NoC, decoupling the NoC handles its own internal configuration. The µcfg module
from the FU. The µcore is made up of an input router, contains a configuration cache that can hold up to six different
logic that tracks when operands are ready, and a few buffers configurations. The cached configurations reduce memory
for intermediate values. The input router handles incoming accesses and allow for fast switching between configurations.
connections, notifying the internal µcore logic of the availability This improves both energy-efficiency and performance. It also
of valid data and predicates. The intermediate buffers hold benefits applications with dataflow graphs too large to fit onto
output data produced by the FU. Before an FU (that produces the fabric. These applications split their dataflow graph into
output) fires, the µcore first allocates space in the intermediate multiple sub-graphs. The CGRA executes them one at a time,
buffers. Then, when the FU completes, its output data is written efficiently switching between them via the configuration cache.
to the allotted space, unless the predicate value is not set, in Note, however, that even with the configuration cache, each
which case a fallback value is passed through (see below). fabric configuration is intended to be re-used across many input
Finally, the buffer is freed when all consumers have finished values before switching, unlike prior CGRAs that multiplex
using the value. These intermediate buffers are the only data configurations cycle-by-cycle (Sec. II).
buffering in the fabric, outside of internal FU state. The NoC,
which forwards data to dependent PEs, is entirely bufferless. B. SNAFU’s PE standard library
The FU interface: S NAFU uses a standard FU interface for S NAFU includes a library of PEs that we developed using
interaction between a PE’s µcore and FU. The interface has the BYOFU custom FU interface. The library includes four
four control signals and several data signals. The four controls types of PEs: a basic ALU, multiplier, memory (load/store)
signals are op, ready, valid, and done; the µcore drives op unit, and scratchpad unit.
and the FU is responsible for driving the latter three. op tells Arithmetic PEs: There are two arithmetic PEs: the basic
the FU that input operands are ready to be consumed. ready ALU and the multiplier. The basic ALU performs bitwise
indicates that the FU can consume new operands. valid and operations, comparisons, additions, subtractions, and fixed-
done are related: valid says that the FU has data ready to point clip operations. The multiplier performs 32-bit signed
send over the network, and done says the FU has completed multiplication. Both units are equipped with the ability to
execution. The remaining signals are data: incoming operands accumulate partial results, like PE #4 (vredsum) in Fig. 4.
(a, b), predicate operands (m, d), and the FU’s output (z). Memory PEs: The memory PEs generate addresses and issue
The FU-µcore interface allows the µcore to handle variable- loads and stores to global memory. The PE operates in two
latency logic, making the FU’s outputs available only when different modes, supporting strided access and indirect access.
the FU completes an operation. The µcore raises back-pressure The memory PE also includes a “row buffer,” which eliminates
in the network when output from an FU is not ready and stalls many subword accesses on accesses to a recently-loaded word.
the FU (by keeping op low) when input operands are not ready Scratchpad PEs: A scratchpad holds intermediate values
or there are no unallocated intermediate buffers. When the FU produced by the CGRA. The scratchpad is especially useful for
asserts both valid and done, the µcore forwards the value holding data communicated between consecutive configurations
produced by the FU to dependent PEs via its NoC router. of a CGRA, e.g., when the entire dataflow graph is too large
Progress tracking and fabric control: The fabric has a top- for the CGRA. The PE connects to a 1 KB SRAM memory
level controller that interfaces with each µcore via three 1-bit that supports stride-one and indirect accesses. Indirect access
signals. The first enables the µcore to begin execution, the is used to implement permutation, allowing data to be written
second resets the µcore, and the third tells the controller when or read in a specified, permuted order.
the PE has finished processing all input. The µcore keeps
track of the progress of the FU by monitoring the done signal, C. Generating a CGRA fabric
counting how many elements the FU has processed. When Generating RTL: Given a collection of processing elements,
the number of completed elements matches the length of the S NAFU automatically generates a complete energy-minimal
computation, the µcore signals the controller that it is done. CGRA fabric. S NAFU ingests a high-level description of the
Predication: S NAFU supports conditional execution through CGRA topology and generates valid RTL. This high-level
built-in support for vector predication. The µcore delivers not description includes a list of the processing elements, their
only the predicate m, but also a fallback value d — for when the types, and an adjacency matrix that encodes the NoC topology.
predicate is false — to the FU. When the predicate is true, the With this high-level description, S NAFU generates an RTL
FU executes normally; when it is false, the FU is still triggered header file. The file is used to parameterize a general RTL
6description of a generic, energy-minimal CGRA fabric, which hardware makes compilation much easier: S NAFU supports
can then be fed through standard CAD tools. asynchronous dataflow firing and does not time-multiplex PEs
NoC and router topology: S NAFU generates a NoC using a or routes. Together, these properties mean that the compiler
parameterized bufferless router model. The router can have need not reason about operation timing, making the search
any input and output radix and gracefully handles network space much smaller and simplying its constraints. As a result,
back-pressure. Connections between inputs and outputs are S NAFU’s compiler can find an optimal solution in seconds even
configured statically for each configuration. Routers are mux- for the most complex kernels that we have evaluated.
based because modern CAD tools optimize muxes well. Current limitations: If a kernel is too large to fit onto the
Top-down synthesis streamlines CAD flow: Following RTL CGRA or there is resource mismatch between the kernel and
generation, S NAFU fabrics can be synthesized through standard the fabric, the tool relies on the programmer to manually
CAD tools from the top down without manual intervention. split the vectorized code into several smaller kernels that can
Top-down synthesis is important because S NAFU’s bufferless, be individually scheduled. This is a limitation of the current
multi-hop NoC introduces combinational loops that normally implementation, but not fundamental; a future version of the
require a labor-intensive, bottom-up approach to generate compiler will automate this process.
correct hardware. Industry CAD tools have difficulty analyzing V. D ESIGNING S NAFU TO MINIMIZE ENERGY
and breaking combinational loops (i.e., by adding buffers to
S NAFU’s design departs from prior CGRAs because it is de-
disable the loops). S NAFU leverages prior work on synthesizing
signed from the ground-up to minimize energy. This difference
FPGAs (which face the problem with combinational loops
is essential for emerging ULP applications (Sec. II), and it
in their bufferless NoCs) from the top down to automate
motivates several key features of S NAFU’s CGRA architecture.
this process [39, 43]. S NAFU partitions connections between
This section explores these differences and explains how they
routers and PEs and uses timing case analysis to eliminate
allow S NAFU to minimize energy.
inconsequential timing arcs. S NAFU is the first framework for
top-down synthesis of a CGRA, eliminating the manual effort A. Spatial vector-dataflow execution
of bottom-up synthesis.
Prior ULP systems: The state-of-the-art in ULP architecture
D. Compilation is M ANIC [23]. As discussed in Sec. II, M ANIC introduces
vector-dataflow execution, which amortizes instruction fetch,
The final component is a compiler that targets the gener- decode, and control (vector) and forwards intermediate values
ated CGRA fabric. Fig. 4 shows the compilation flow from between instructions (dataflow). M ANIC’s vector-dataflow im-
vectorized code to valid CGRA configuration bitstream. The plementation parks intermediate values in a small “forwarding
compiler first extracts the dataflow graph from the vectorized buffer,” instead of the large vector register file (VRF).
C code. S NAFU asks the system designer (not the application M ANIC reduces energy and adds negligible area, but its
programmer) to provide a mapping from RISC-V vector ISA savings are limited by two low-level effects that only become
instruction to a PE type, including the mapping of an operation’s apparent in a complete implementation. First, compiled SRAMs
inputs and output onto an FU’s inputs and output. This mapping are cheaper and scale better than suggested by high-level
lets S NAFU’s compiler seamlessly support new types of PEs. architectural models [57, 65]; i.e., M ANIC’s savings from
Integer linear program (ILP) scheduler: The compiler uses an reducing VRF accesses are smaller than estimated. Second,
integer linear program (ILP) formulation to schedule operations M ANIC multiplexes all instructions onto a shared execution
onto the PEs of a CGRA. The scheduler takes as input the pipeline, causing high switching activity in the pipeline logic
extracted dataflow graph, the abstract instruction→PE map, and and registers as control and data signals toggle cycle-to-cycle.
a description of the CGRA’s network topology. The scheduler’s Both effects limit M ANIC’s energy savings.
ILP constraint formulation builds on prior work on scheduling How SNAFU reduces energy: S NAFU reduces energy by imple-
code onto a CGRA [53]. The scheduler searches for subgraph menting spatial vector-dataflow execution. Like vector-dataflow,
isomorphisms between the extracted dataflow graph and the S NAFU’s CGRA amortizes a single fabric configuration across
CGRA topology, minimizing the distance between spatially many computations (vector), and routes intermediate values
scheduled operations. At the same time, the ILP adheres to directly between operations (dataflow). But S NAFU spatially
the mappings in the abstract instruction→PE map and does implements vector-dataflow: S NAFU buffers intermediate values
not map multiple dataflow nodes or edges to a single PE or locally in each PE (vs. M ANIC’s shared forwarding buffer)
route. To handle PEs that are shared across multiple fabric and each PE performs a single operation (vs. M ANIC’s shared
configurations (e.g., scratchpads holding intermediate data), pipeline). Note that this design is also a contrast with prior
programmers can annotate code with instruction affinity, which CGRAs, which share PEs among multiple operations to increase
maps a particular instruction to a particular PE. performance and utilization (Table I).
Scalability: Prior work has found scheduling onto a CGRA As a result, S NAFU reduces both effects that limit M ANIC’s
fabric to be extremely challenging and even intractable [18, 35, energy savings. We estimate that the reduction in switching
50, 74], limiting compiler scalability to small kernels. However, activity accounts for the majority of the 41% of energy savings
this is not the case for S NAFU’s compiler because S NAFU’s that S NAFU achieves vs. M ANIC. The downside is that S NAFU
7takes significantly more area than M ANIC. This tradeoff is r r r r r r r
SNAFU-A
worthwhile because ULP systems are tiny and most area is M M M M M M
Multi-hop, r r r r r r r
memory and I/O (see Sec. VIII). S NAFU’s leakage power bufferless NoC
S C B B C S
1KB
1KB
is negligible despite its larger area because we use a high- r r r r r r r
Control S B B B B S
1KB
1KB
threshold-voltage process. RV32
r r r r r r r
Scalar
S B B B B S
1KB
1KB
B. Asynchronous dataflow firing without tag-token matching Core Configurator
r r r r r r r
insn data stream
The rest of this section discusses how S NAFU differs from S C B B C S
1KB
1KB
r r r r r r r
prior CGRAs, starting with its dynamic dataflow firing. M M M M M M
Execution in prior CGRAs: Prior CGRAs have explored both r r r r r r r
static and dynamic strategies to assign operations to PEs and Main memory cgra memory interface
to schedule operations [75]. Static assignment and scheduling M = Load/store PE
is most energy-efficient, whereas fully dynamic designs require Bank Ctrl Bank Ctrl Bank Ctrl S = Scratchpad PE
expensive tag-matching hardware to associate operands with B = Basic ALU PE
their operation. A static design is feasible when all operation 32KB
SRAM
32KB
SRAM … SRAM 32KB
C = Multiplier PE
BANK BANK BANK
latencies are known and a compiler can find an efficient global
schedule. Static designs are thus common in CGRAs that do
not directly interact with a memory hierarchy [25, 33, 51]. 8 banks = 256KB total memory
How SNAFU reduces energy: S NAFU is designed to easily Figure 6: Architectural diagram of S NAFU -A RCH. S NAFU -A RCH
possesses a RISC-V scalar core tightly coupled with the S NAFU fabric.
integrate new FUs with unknown or variable latency. E.g.,
Both are attached to a unified 256 KB banked memory.
a memory PE may introduce variable latency due to bank
conflicts. A fully static design is thus not well-suited to S NAFU, pendent PEs and buffering them in large FIFOs, freeing a
but S NAFU cannot afford full tag-token matching either. producer PE to start its next operation as early as possible.
S NAFU’s solution is a hybrid CGRA with static PE as- If a dependent PE is not ready, the NoC or dependent PE
signment and dynamic scheduling. (“Ordered dataflow” in may buffer values. This approach maximizes parallelism, but
the taxonomy of prior work [75].) Each PE uses local, duplicates intermediate values unnecessarily.
asynchronous dataflow firing to tolerate variable latency. S NAFU How SNAFU reduces energy: S NAFU includes minimal in-
avoids tag-matching by enforcing that values arrive in-order. fabric buffering at the producer PE, with none in the NoC.
This design lets S NAFU integrate arbitrary FUs with little energy Buffering at the producer PE means each value is buffered
or area overhead, adding just ≈ 2% system energy to S NAFU - exactly once, and overwritten only when all dependent PEs
A RCH. The cost of this design is some loss in performance are finished using it. In S NAFU -A RCH, producer-side buffering
vs. a fully dynamic CGRA. Moreover, asynchronous firing saves ≈ 7% of system energy vs. consumer-side buffering. The
simplifies the compiler, as discussed above, because it is not cost is that a producer PE may stall if a dependent PE is not
responsible for operation timing. ready. S NAFU minimizes the number of buffers at each PE;
C. Statically routed, bufferless on-chip network using just four buffers per PE by default (Sec. VIII evaluates
S NAFU’s sensitivity to the number of buffers per PE).
NoCs in prior CGRAs: The on-chip network (NoC) can
consume a large fraction of energy in high-performance VI. S NAFU -A RCH : A C OMPLETE ULP S YSTEM W / CGRA
CGRAs, e.g., more than 25% of fabric energy [33, 51]. Buffers S NAFU -A RCH is a complete ULP system that includes a
in NoC routers are a major energy sink, and dynamic, packet- CGRA fabric generated by S NAFU integrated with a scalar
switched routers cause high switching activity. Prior ULP RISC-V core and memory.
CGRAs avoid this cost with highly restrictive NoCs that limit
flexibility [17, 34, 55]. A. Architectural overview
How SNAFU reduces energy: S NAFU includes a statically- Fig. 6 shows an overview of the architecture of S NAFU -
configured, bufferless, multi-hop on-chip network designed A RCH. There are three primary components: a RISC-V scalar
for high routability at minimal energy. Static circuit-switching core, a banked memory, and the S NAFU fabric. The S NAFU
eliminates expensive lookup tables and flow-control mecha- fabric is tightly coupled to the scalar core. It is a 6×6 mesh
nisms, and prior work showed that such static routing does possessing 12 memory PEs, 12 basic-ALU PEs, 8 scratchpad
not degrade performance [33]. The network is bufferless (a PE PEs, and 4 multiplier PEs. The RTL for the fabric is generated
buffers values it produces; see below), eliminating the NoC’s using S NAFU and the mesh topology shown. The memory PEs
primary energy sink (half of NoC energy or more [44]). As a connect to the banked memory, while the scratchpad PEs each
result, S NAFU’s NoC takes just ≈ 6% of system energy. connect to 1 KB outside the fabric.
The RISC-V scalar core implements the E, M, I, and C
D. Minimizing buffers in the fabric
extensions and issues control signals to the S NAFU fabric. The
Buffering of intermediate values in prior CGRAs: Prior banked memory has eight 32 KB memory banks (256 KB total).
CGRAs maximize performance by forwarding values to de- In total there are 15 ports to the banked memory: thirteen
8Instruction Purpose Memory control logic
vcfg Load a new fabric configuration and set Scalar core
vector length. Main memory
NoC incl. routers
vtfr Communicate scalar value to fabric.
vfence Start fabric execution and wait. Scratchpad units
Table II: New instructions to interface with CGRA. Memory units
Basic-ALU units
from the S NAFU fabric and two from the scalar core. The Multiplier units
twelve memory PEs account for the majority of the ports from
Figure 7: Layout of S NAFU -A RCH. Memory PEs are blue, scratchpad
the fabric. The final port from the fabric allows the S NAFU PEs are green, basic-ALU PEs are red, multiplier PEs are purple, the
configurator to load configuration bitstreams from memory. scalar core is yellow, and main-memory control logic is orange. The
Each bank of the main memory can execute a single memory remaining grey regions contain routers and wires.
request at a time; its bank controller arbitrates requests using
a round-robin policy to maintain fairness. Parameter Values
B. Example of SNAFU-ARCH in action Frequency 50 MHz
Main memory 256 KB
S NAFU -A RCH adds three instructions to the scalar core to Scalar register # 16
interface with the CGRA fabric, summarized in Table II. We Vector register # 16
Vector
explain how they work through the following example. Vector length 16/32/64
The S NAFU fabric operates in three states: idle, configuration, Window size (for M ANIC) 8
and execution. During the idle phase the scalar core is running
S NAFU -A RCH
Fabric dimensions 6×6
and the fabric is not. When the scalar core reaches a vcfg Memory PE # 12
instruction, the fabric transitions to the configuration state. The Basic-ALU PE # 12
Multiplier PE # 4
scalar core passes a vector length and a bitstream address (from Scratchpad PE # 8
the register file) to the fabric configurator (see Fig. 6). The
configurator checks to see if this configuration is still in the Table III: Microarchitectural parameters.
fabric’s configuration cache (Sec. IV-A). If it is, the configurator Cadence Xcelium RTL simulator [6]. We synthesized the design
broadcasts a control signal to all PEs and routers to load using Cadence Genus [2] and an industrial sub-28 nm, high-
the cached configuration; otherwise, it loads the configuration threshold voltage FinFET PDK with compiled memories. Next,
header from memory. The header tells the configurator which we placed and routed the design using Cadence Innovus [3];
routers and which PEs are active in the configuration. Then the Fig. 7 shows the layout. We also developed S NAFU’s compiler
configurator issues a series of loads to read in configuration that converts vectorized C-code to an optimal fabric config-
bits for the enabled PEs and routers. uration and injects the bitstream into the application binary.
Once this has completed, the configurator stalls until the Finally, we simulated full applications post-synthesis, annotated
scalar core either reaches a vtfr instruction or a vfence switching, and used Cadence Joules [4] to estimate power.
instruction. vtfr lets the scalar core pass a register value
Baselines: We compare S NAFU -A RCH against three baseline
to the fabric configurator, which then passes that value to a
systems: (i) a RISC-V scalar core with a standard five-stage
specific PE (encoded in the instruction). This allows PEs to be
pipeline, (ii) a vector baseline that implements the RISC-V V
further parameterized at runtime from the scalar core. vfence
vector extension, and (iii) M ANIC [23], the prior state-of-the-art
indicates that configuration is done, so the scalar core stalls and
in general-purpose ULP design. The scalar core is representative
the fabric transitions to execution. Execution proceeds until all
of typical ULP microcontrollers like the TI MSP430 [31]. Each
PEs signal that they have completed their work (Sec. IV-A).
baseline is implemented entirely in RTL using the same design
Finally, the scalar core resumes execution from the vfence,
flow. Table III shows their microarchitectural parameters. The
and the fabric transitions back into the idle state.
vector baseline and M ANIC both have a single vector lane,
VII. E XPERIMENTAL M ETHODOLOGY which minimizes energy at the cost of performance.
We implemented S NAFU -A RCH as well as three baselines Benchmarks: We evaluate S NAFU -A RCH, M ANIC, and the
entirely in RTL and synthesized each system using an industrial vector baseline across ten benchmarks on three different input
sub-28 nm FinFET process with compiled memories. We sizes, shown in Table IV. We use random inputs, generated
evaluated the systems using post-synthesis timing, power, and offline. For M ANIC and the vector baseline, each benchmark has
energy models. Additionally, we placed and routed S NAFU - been vectorized from a corresponding plain-C implementation.
A RCH (see Fig. 7) to validate top-down synthesis. For S NAFU -A RCH, these vectorized benchmarks are fed into
Software-hardware stack: We developed a complete software our compiler to produce CGRA-configuration bitstreams. In
and hardware stack for S NAFU. We implemented S NAFU - cases where the benchmarks contain a permutation, the kernel is
A RCH, its 256 KB banked memory, and its five-stage pipelined manually split and pieces are individually fed into our compiler.
RISC-V scalar core in RTL and verified correctness by running Metrics: We evaluate S NAFU -A RCH and the baselines primarily
full applications in simulation using both Verilator [66] and on their energy efficiency and secondarily on their performance.
9Memory Scalar Vec/CGRA Remaining
×106 ×106 ×105 ×106 ×106 ×106 ×106 ×105 ×105 ×106
1.0 1.4 1.8 3.0 2.5
3.5
1.0 3.5 3.0
4.0
4.0 1.2 1.5 2.5
0.8 3.0
3.0 2.0
2.5
Energy vs. Scalar
0.8 1.2
1.0
2.5 3.0 2.0
3.0 2.5
0.6 2.0 1.5
Cycles
0.8 1.0
2.0 0.6
2.0
1.5
2.0 1.5
2.0 0.6 0.8
0.4 1.5 1.5 1.0
0.4
1.0
0.5 1.0
1.0 1.0 0.4
1.0 1.0
0.2 0.2 0.5
0.5
0.5 0.2 0.2 0.5
0.5
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
Scalar
Vector
MANIC
SNAFU
FFT DWT Viterbi SMM DMM SCONV DCONV SMV DMV SORT AVG FFT DWT Viterbi SMM DMM SCONV DCONV SMV DMV SORT
(a) Energy (b) Execution time
Figure 8: Energy and execution time, normalized to the scalar baseline, across ten applications on large inputs. On average, S NAFU -A RCH
uses 81%, 57%, 41% less energy and is 9.9×, 3.2×, and 4.4× faster than the scalar design, vector baseline, and M ANIC, respectively.
Name Description Small Medium Large
ecution energy between memory, the scalar core, vector/CGRA,
FFT 2D Fast-fourier transform and remaining (other). S NAFU -A RCH outperforms all baselines
16×16 32×32 64×64
DWT 2D Discrete wavelet trnsfrm 16×16 32×32 64×64
on each benchmark. This is primarily because S NAFU -A RCH
Viterbi Viterbi decoder 256 1024 4096
Sort Radix sort
implements spatial vector-dataflow execution. Vector, M ANIC,
256 512 1024
SMM Sparse matrix-matrix and S NAFU -A RCH all benefit from vector execution (SIMD),
16×16 32×32 64×64
DMM Dense matrix-matrix 16×16 32×32 64×64
significantly improving energy-efficiency and performance
SMV Sparse matrix-dense vector 32×32 64×64 128×128
compared to the scalar baseline by eliminating much of the
DMV Dense matrix-dense vector 32×32 64×64 128×128
Sconv Sparse 2D convolution overhead of instruction fetch and decode. However, S NAFU -
16×16, 32×32, 64×64,
filter: A RCH benefits even more from vector execution because, once
3×3 5×5 5×5
Dconv Dense 2D convolution 16×16, 32×32, 64×64,
S NAFU -A RCH’s fabric is configured, it can be re-used across
filter: 3×3 5×5 5×5
an unlimited amount of data (unlike the limited vector length
Table IV: Benchmarks and their input sizes. in the vector baseline and M ANIC).
We measure the full execution of each benchmark after Moreover, only S NAFU -A RCH takes advantage of spatial
initializing the system, and we measure efficiency by the energy dataflow. The vector baseline writes all intermediate results to
to execute the complete benchmark normalized to either the the vector register file, which is quite costly. M ANIC eliminates
scalar baseline or S NAFU -A RCH. We measure performance by a majority of these VRF accesses (saving 27% energy compared
execution time (cycles) or speedup normalized to either the to the vector baseline) by buffering intermediate values in a less
scalar baseline or S NAFU -A RCH. expensive “forwarding buffer.” However, M ANIC shares a single
execution pipeline across all instructions, which significantly
VIII. E VALUATION increases switching activity. S NAFU -A RCH, on the other hand,
We now evaluate S NAFU -A RCH to show: (1) S NAFU -A RCH executes a dataflow graph spatially. Each PE only handles a
is significantly more energy-efficient than the state-of-the- single operation and routes are configured statically. This leads
art. (2) Secondarily, S NAFU -A RCH significantly improves to significantly less dynamic energy because intermediate values
performance over the state-of-the-art. (3) S NAFU -A RCH is are directly communicated between dependent operations and
an optimal design point across input, configuration cache, and there is minimal switching in PEs.
intermediate-buffer sizes. (4) S NAFU is easily extended with 2) SNAFU-ARCH also greatly improves performance: Fig. 8b
new PEs to improve efficiency. (5) Significant opportunities shows the execution time (in cycles) of all benchmarks and
remain to improve efficiency in the compiler. systems. Across the board, S NAFU -A RCH is faster — from
3.2× to 9.9× on average, depending on the baseline. S NAFU -
A. Main results A RCH achieves this high-performance by exploiting instruction-
Fig. 8 shows that S NAFU -A RCH is much more energy- level parallelism in each kernel, which is naturally achieved
efficient and performant vs. all baselines. The figure shows by S NAFU’s asynchronous dataflow-firing at each PE.
average energy and speedup of S NAFU -A RCH normalized to 3) SNAFU-ARCH is ultra-low-power and has a small footprint:
the scalar baseline. S NAFU -A RCH uses 81%, 57%, and 41% The S NAFU -A RCH fabric operates between 120 µW and
less energy than the scalar, vector, and M ANIC baselines, 324 µW, depending on the workload, achieving an estimated
respectively. S NAFU -A RCH is also highly performant; it is 305 MOPS/mW. This operating power domain is two to five
9.9×, 3.2×, and 4.4× faster than the respective baselines. orders-of-magnitude less than most prior CGRA designs.
1) SNAFU-ARCH saves significant energy: Fig. 8 shows Leakage power is also insignificant (Memory Scalar Vec/CGRA Remaining
Speedup vs. SNAFU
1.0
Energy vs. SNAFU
10
Speedup vs Scalar
2
Energy vs Scalar
2
1
0.5 5 1
0 0
MANIC
SNAFU
MANIC
SNAFU
MANIC
SNAFU
MANIC
SNAFU
MANIC
SNAFU
MANIC
SNAFU
MANIC
SNAFU
MANIC
SNAFU
unMANIC
unSNAFU
unMANIC
unSNAFU
unMANIC
unSNAFU
unMANIC
unSNAFU
unMANIC
unSNAFU
unMANIC
unSNAFU
unMANIC
unSNAFU
unMANIC
unSNAFU
0.0 0
S M L S M L
(a) Energy. (b) Speedup. DMM SCONV DCONV DMV DMM SCONV DCONV DMV
(a) Energy. (b) Speedup.
Figure 9: S NAFU -A RCH vs. the scalar Figure 10: Energy and speedup of M ANIC, unM ANIC (w/ loop unrolling), S NAFU -A RCH, and
design across three input sizes – small (S), unS NAFU -A RCH (w/ loop unrolling), normalized to S NAFU -A RCH. unS NAFU -A RCH uses 31%
medium (M) and large (L). less energy and is 2.2× faster S NAFU -A RCH; M ANIC benefits much less.
In addition, S NAFU -A RCH is tiny. The entire design in Fig. 7, Memory Scalar Vec/CGRA Remaining
including compiled memories, is substantially less than 1 mm2 . 1.0
Speedup vs. SNAFU
Energy vs. SNAFU
Note, however, that S NAFU -A RCH saves energy at the cost of 1.5
area: S NAFU -A RCH occupies 1.8× more area than M ANIC and
1.0
0.5
1.7× more than the vector baseline. Given S NAFU -A RCH’s
0.5
tiny size, we judge this to be a good tradeoff.
Benchmark analysis: S NAFU -A RCH is especially energy- 0.0 0.0
MANIC
SNAFU
MANIC
SNAFU
MANIC
SNAFU
MANIC
SNAFU
(no scratch)
(no scratch)
(no scratch)
(no scratch)
SNAFU
SNAFU
SNAFU
SNAFU
efficient on dense linear algebra kernels and sort. S NAFU -A RCH
uses on average 49% less energy on average for DMM, DMV, FFT DWT FFT DWT
and DConv vs. 35% less on average for SMM, SMV, and
(a) Energy. (b) Speedup.
SConv. This is because the dense linear algebra kernels take
Figure 11: Energy and speedup of M ANIC, S NAFU -A RCH w/ and
full advantage of coalescing in the memory PEs and generally w/out scratchpads, normalized to S NAFU -A RCH. Scratchpads improve
have fewer bank conflicts, reducing energy and increasing energy-efficiency by 34% and performance by 13%.
performance (5.8× vs. 3.8×).
Sort is another interesting benchmark because M ANIC barely scalar baseline. S NAFU -A RCH is 9.9×, 3.2×, 4.4× faster than
outperforms the vector baseline, while S NAFU -A RCH reduces the scalar baseline, vector baseline, and M ANIC on the large
energy by 72%. (The scalar baseline performs terribly due to input size and 5.4×, 2.4×, and 3.4× faster on the small input.
a lack of a good branch predictor.) This gap in energy can be SNAFU’s optimal parameterization: We considered designs
attributed to the unlimited vector length of S NAFU -A RCH: the with different configuration cache sizes (1, 2, 4, 6, and 8) and
vector length of both vector and M ANIC baselines is 64, but different numbers of intermediate buffers (1, 2, 4, and 8). For
the input size to Sort is 1024. S NAFU -A RCH is able to sort all applications except FFT, DWT, and Viterbi, configuration-
the entire vector with minimal re-configuration and buffering cache size makes little difference. FFT, DWT, and Viterbi
of intermediate values. realize an average 10% energy savings with a size of six
entries. This is because these applications have up to six phases
B. Sensitivity studies
of computation, and each phase requires a different fabric
We characterize S NAFU -A RCH by running applications configuration. Similarly, most applications are insensitive to
on three different input sizes. Further, we find the optimal the number of intermediate buffers. With too few buffers, PEs
configuration of S NAFU -A RCH by sweeping the size of the stall due to lack of buffer space. Two buffers is enough to
configuration cache and the number of intermediate buffers. eliminate most of these stalls, and four buffers is optimal.
Energy-efficiency and performance improve on larger work-
loads: Fig. 9a shows S NAFU -A RCH’s energy across three C. Case studies
different input sizes: small (S), medium (M), and large (L).
For most applications, S NAFU -A RCH’s benefits increase with We conduct two case studies (i) to show that there are
input size. (But S NAFU -A RCH is faster and more efficient at all opportunities to further improve performance and energy
input sizes.) As input size increases, S NAFU -A RCH generally efficiency with only software changes; and (ii) to demonstrate
widens the gap in energy-efficiency with the scalar baseline, the flexibility of S NAFU’s BYOFU approach.
from 67% to 81%. S NAFU -A RCH also improves vs. the vector Loop-unrolling leads to significantly improved energy and
baseline from 39% to 57% and vs. M ANIC from 37% to 41% performance: We show the potential of further compiler
(not shown). The primary reason for this improvement is that, optimizations through a case study on loop unrolling. Fig. 10
with larger input sizes, S NAFU -A RCH can more effectively shows the normalized energy and speedup of M ANIC and
amortize the overhead of (re)configuration. S NAFU -A RCH with and without loop unrolling on four different
This trend is even more pronounced in the performance data. applications. With loop unrolling, S NAFU -A RCH executes four
Fig. 9b shows the speedup of S NAFU -A RCH normalized to the iterations of an inner loop in parallel (vs. one iteration without
11Memory Scalar CGRA/Accel Remaining
5%
1.00 12%
1.00 1.00
14% 10%
Energy vs. SNAFU
Energy vs. SNAFU
Energy vs. SNAFU
14% 35% 44% 17%
20%
0.75 15%
3%
0.75 0.75 55% 70%
18% 23% 64% 28%
30%
0.50 0.50 61% 0.50
3% 47%
0.25 0.25 0.25
0.00 0.00 0.00
SNAFU
Bespoke
DMM
Tailored
Async
Accel
SNAFU
Bespoke
Tailored
BYOFU
Async
Accel
SNAFU
Bespoke
Tailored
BYOFU
FFT1D
FFT1D
FFT2D
SNAFU
SNAFU
SNAFU
SNAFU
SNAFU
Accel
SNAFU
SNAFU
SNAFU
Sort
Async
Dot
Sort
Dot
(a) DMM energy. (b) Sort energy. (c) FFT energy.
Figure 12: Quantifying the cost of S NAFU’s programmability on three benchmarks. Each subfigure shows, from left-to-right, the effect
of gradually removing S NAFU -A RCH’s programmability and increasing its specialization, culminating in a hand-coded ASIC. Overall,
S NAFU -A RCH’s energy is within 2.6× on average of the ASICs’, and can be easily specialized to narrow the gap at low upfront design cost.
loop unrolling). On average, with loop unrolling, S NAFU - to-end systems in the same technology and design flow using
A RCH’s energy efficiency improves by 85%, 71%, 62%, and an industrial PDK with compiled memories. Our results thus
33% vs. scalar, vector, M ANIC, and S NAFU -A RCH without avoid pitfalls of prior studies based on simulations, analytical
unrolling. The performance results are even more significant: models, or extrapolations from different technologies.
with loop unrolling, S NAFU -A RCH’s speedup improves to 19×, We find that, on average, S NAFU -A RCH uses 2.6× more
7.5×, 11×, and 2.2× vs. the same set of baselines. These energy and 2.1× more time than an ASIC implementation.
results make it clear that S NAFU -A RCH can effectively exploit Breaking down the sources of inefficiency in S NAFU -A RCH,
instruction-level parallelism and that there is an opportunity we find that S NAFU lets designers trade off programmability
for the compiler to further improve efficiency. and efficiency via simple, incremental design changes. S NAFU
SNAFU makes it easy to add new FUs: Initially, S NAFU - makes selective specialization easy, letting the architect focus
A RCH did not have scratchpad PEs. However, FFT and DWT their design effort where it yields the most efficiency gains.
produce permuted results that must be persisted between re- SNAFU is within 2.6× of ASIC energy: Fig. 12 shows the
configurations of the fabric. Without scratchpad units, these energy of DMM, Sort, and FFT on large inputs. The leftmost
values were being communicated through memory. bars in Fig. 12 represent S NAFU -A RCH and the rightmost
Leveraging S NAFU’s standard PE interface, we were able bars represent a fixed-function, statically scheduled ASIC
to quickly add scratchpad PEs to S NAFU -A RCH with minimal implementation of the same algorithm. S NAFU -A RCH uses
effort — we just made S NAFU aware of the new PE, without as little as 1.8× and on average 2.6× more energy than the
any changes to S NAFU’s framework. Fig. 11 shows the ASICs. To explain the gap, we now consider intermediate
normalized energy and speedup of S NAFU -A RCH with and designs that build up from the ASIC back to S NAFU -A RCH.
without scratchpads for FFT and DWT. Persisting intermediate SNAFU-ARCH, inner loops, & Amdahl’s Law: S NAFU maps
values to main memory is quite expensive: without scratchpads, only inner loops to its fabric and runs outer loops on the scalar
S NAFU -A RCH consumes 54% more energy and is 16% slower core, limiting its benefits to the fraction of dynamic execution
on average. The flexibility of S NAFU allowed us to easily spent in inner loops. To make a fair comparison, we built
optimize the S NAFU -A RCH fabric for FFT and DWT at ASICs for DMM and FFT that accelerate only the inner-loop
low effort, without affecting other benchmarks. The next of the kernel (D OT-ACCEL and FFT1D-ACCEL), just like
section explores the implications for programmability and S NAFU -A RCH. These designs add 33% energy to run outer
specialization. loops on the scalar core, reducing the energy gap to 2.2× (vs.
2.5× for these benchmarks previously). A future version of
IX. T HE C OST OF P ROGRAMMABILITY S NAFU could eliminate this extra scalar energy by mapping
With the mainstream acceptance of architectural special- outer loops to its fabric [75].
ization, the architecture community faces an ongoing debate Asynchronous dataflow firing adds minimal overhead: Next,
over the ideal form and degree of specialization. Some results we add asynchronous dataflow firing to the ASIC designs
suggest a need for drastic specialization to compete with (∗-A SYNC bars). Comparing A SYNC designs to the ASICs
ASICs [26, 64, 70]; whereas others argue that programmable shows that asynchronous dataflow firing adds little energy
designs can compete by adopting a non-von Neumann execution overhead, just 3% in DMM and Sort. The 30% overhead in FFT-
model [49, 52]. A SYNC is inessential and could be optimized away: S NAFU’s
We contribute to this debate by performing an apples-to- current implementation of asynchronous dataflow firing adds an
apples comparison of a programmable design (S NAFU -A RCH) unnecessary pipeline stage when reading scratchpad memories
against three hand-coded ASICs, demonstrating that the cost of in the ASIC designs.
programmability is low in the ULP domain. We compare end- Closing the gap with negligible design effort: Next, we
12consider variants of S NAFU -A RCH to break down the cost Finally, digging deeper, we can better understand the cost
of software programmability. S NAFU -B ESPOKE hardwires the of programmability as separate costs incurred at design time
fabric configuration, eliminating unused logic during synthesis (i.e., hardware implementation quality) and run time (i.e.,
(like prior work [10]), removing S NAFU -A RCH’s software overhead for running software). With current synthesis tools,
programmability. S NAFU -B ESPOKE uses 54% more energy software programmability itself is surprisingly cheap, but
than the A SYNC designs. The gap in energy with A SYNC can carries a hidden design-time cost: the gap between S NAFU
be attributed to S NAFU’s logic for predicated execution and the and S NAFU -B ESPOKE is just 27%, whereas the gap between
operation set that S NAFU implements, which is not well suited S NAFU -B ESPOKE and ASICs is 2.1×. Even when runtime re-
to every application. For instance, S ORT-ACCEL can select bits configurability is removed from a design, synthesis tools cannot
directly, whereas S NAFU must do a vshift and vand. produce circuits similar to a hand-coded ASIC because they
BYOFU makes it easy to specialize where it matters: S NAFU’s do not understand the intent of RTL. Barring a breakthrough
flexible, “bring your own functional unit” design (Sec. IV-A) in synthesis, this challenge will remain. S NAFU provides a
makes it easy to add missing operations to improve efficiency. path forward: BYOFU lets a designer specialize for critical
To illustrate this, Sort-B YOFU and FFT-B YOFU improve operations, enabling programmable designs to compete with
S NAFU -B ESPOKE’s efficiency by adding specialized PEs to ASICs at a fraction of the design effort and without forfeiting
the fabric. For Sort, we add a PE that fuses vshift and vand programmability.
operations. For FFT, we size scratchpads properly for their X. C ONCLUSIONS
data. In both cases, the energy savings are significant. S NAFU -
This paper presented S NAFU, a framework for generating
B ESPOKE uses 20% more energy than the B YOFU designs, and
ultra-low-power CGRAs. S NAFU maximizes flexibility while
the B YOFU designs come within 44% of the A SYNC ASIC
minimizing energy. It takes a bring your own functional unit
designs. These savings come with much lower design effort
approach, allowing easy integration of custom logic, and it
than a full ASIC, and we expect the gap would narrow further
minimizes energy by aggressively favoring efficiency over
if more B YOFU PEs were added to the fabric.
performance throughout the design. We used S NAFU to generate
The cost of software programmability is low: Next, S NAFU - S NAFU -A RCH, a complete ULP CGRA system that uses 41%
TAILORED specializes the CGRA to eliminate extraneous PEs, less energy and is 4.4× faster than the prior state-of-the-
routers, and NoC links, but is not hardwired like S NAFU - art general-purpose ULP system. Moreover, S NAFU -A RCH is
B ESPOKE or S NAFU -B YOFU — i.e., S NAFU-TAILORED is competitive with ASICs and can be incrementally specialized
where the design becomes programmable in software. S NAFU - to trade off efficiency and programmability.
TAILORED uses only 15% more energy than S NAFU -B ESPOKE,
illustrating that the cost of software programmability is low. XI. ACKNOWLEDGMENTS
The original S NAFU -A RCH design uses just 10% more We thank the anonymous reviewers for their helpful feedback.
energy than S NAFU -TAILORED. This gap includes the cost of This work was supported by NSF Award CCF-1815882, and
PEs, routers, and links that are not needed by every application, Graham Gobieski was supported by the Apple Scholars in
but may be used by some. This gap is also small, suggesting AI/ML PhD Fellowship.
that general-purpose programmability also has a low cost.
R EFERENCES
[1] “Cortex-m0.” [Online]. Available: https://developer.arm.com/ip-products/
The above comparisons yield three major takeaways. The processors/cortex-m/cortex-m0
[2] “Genus synthesis solution.” [Online]. Available: https://www.cadence.com/en_US/
big picture is that the total cost of SNAFU’s programmability home/tools/digital-design-and-signoff/synthesis/genus-synthesis-solution.html
is 2–3× in energy and time vs. a fully specialized ASIC. [3] “Innovus implementation system.” [Online]. Available:
https://www.cadence.com/en_US/home/tools/digital-design-and-signoff/soc-
While significant, this gap is much smaller than the 25× (or implementation-and-floorplanning/innovus-implementation-system.html
larger) gap found in some prior studies [26].2 Whether further [4] “Joules rtl power simulation.” [Online]. Available:
https://www.cadence.com/en_US/home/tools/digital-design-and-signoff/power-
specialization is worthwhile will depend on the application; analysis/joules-rtl-power-solution.html
for many applications, a 2–3× gap is good enough [63]. [5] “Nvidia turing gpu architecture.” [Online]. Available:
https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/
Moreover, for applications that benefit from more specializa- technologies/turing-architecture/NVIDIA-Turing-Architecture-Whitepaper.pdf
tion, SNAFU allows for selective specialization with incremen- [6] “Xcelium logic simulation.” [Online]. Available: https://www.cadence.com/
en_US/home/tools/system-design-and-verification/simulation-and-testbench-
tal design effort to trade off efficiency and programmability. verification/xcelium-simulator.html
Fig. 12 shows that by tailoring the fabric topology, hardwiring [7] R. Andri, L. Cavigelli, D. Rossi, and L. Benini, “Yodann: An ultra-low power
convolutional neural network accelerator based on binary weights,” in ISVLSI,
configuration state, or partially specializing PEs, designers 2016.
can get within 2× of ASIC efficiency at a small fraction of [8] K. Asanovic, J. Beck, B. Irissou, B. E. Kingsbury, and J. Wawrzynek, “T0: A
single-chip vector microprocessor with reconfigurable pipelines,” in ESSCIRC 22.
ASIC design effort. Designers can incrementally scale their [9] K. Bong, S. Choi, C. Kim, S. Kang, Y. Kim, and H.-J. Yoo, “14.6 a 0.62 mw
design effort to the degree of specialization appropriate for ultra-low-power convolutional-neural-network face-recognition processor and a cis
integrated with always-on haar-like face detector,” in ISSCC, 2017.
their application. [10] H. Cherupalli, H. Duwe, W. Ye, R. Kumar, and J. Sartori, “Bespoke processors
for applications with ultra-low area and power constraints,” in ISCA 44, 2017.
[11] S. Ciricescu, R. Essick, B. Lucas, P. May, K. Moat, J. Norris, M. Schuette, and
2 The smaller gap comes from comparing to a programmable design that
A. Saidi, “The reconfigurable streaming vector processor (rsvptm),” in ISCA 36,
exploits both vector and dataflow techniques to improve efficiency [49, 52]. 2003.
13[12] A. Colin, E. Ruppel, and B. Lucia, “A reconfigurable energy storage architecture [47] L. Nazhandali, B. Zhai, A. Olson, A. Reeves, M. Minuth, R. Helfand, S. Pant,
for energy-harvesting devices,” in ASPLOS 23, 2018. T. Austin, and D. Blaauw, “Energy optimization of subthreshold-voltage sensor
[13] Cray Computer, “U.S. Patent 6,665,774,” December 2003. network processors,” in ISCA 32, 2005.
[14] D. Culler, J. Hill, M. Horton, K. Pister, R. Szewczyk, and A. Wood, “Mica: The [48] R. S. Nikhil et al., “Executing a program on the mit tagged-token dataflow
commercialization of microsensor motes,” Sensor Technology and Design, April, architecture,” IEEE Transactions on computers, vol. 39, no. 3, 1990.
2002. [49] T. Nowatzki, V. Gangadhan, K. Sankaralingam, and G. Wright, “Pushing the limits
[15] W. J. Dally, J. Balfour, D. Black-Shaffer, J. Chen, R. C. Harting, V. Parikh, J. Park, of accelerator efficiency while retaining programmability,” in HPCA, March 2016,
and D. Sheffield, “Efficient embedded computing,” Computer, vol. 41, no. 7, 2008. pp. 27–39.
[16] W. J. Dally, Y. Turakhia, and S. Han, “Domain-specific hardware accelerators,” [50] T. Nowatzki, N. Ardalani, K. Sankaralingam, and J. Weng, “Hybrid optimiza-
Commun. ACM, vol. 63, no. 7, Jun. 2020. tion/heuristic instruction scheduling for programmable accelerator codesign,” in
[17] S. Das, D. Rossi, K. J. Martin, P. Coussy, and L. Benini, “A 142mops/mw PACT 27, 2018.
integrated programmable array accelerator for smart visual processing,” in ISCAS, [51] T. Nowatzki, V. Gangadhar, N. Ardalani, and K. Sankaralingam, “Stream-dataflow
2017. acceleration,” in ISCA 44, 2017.
[18] S. Dave, M. Balasubramanian, and A. Shrivastava, “Ramp: Resource-aware map- [52] T. Nowatzki, V. Gangadhar, K. Sankaralingam, and G. Wright, “Domain special-
ping for cgras,” in DAC 55, 2018. ization is generally unnecessary for accelerators,” IEEE Micro, vol. 37, no. 3,
[19] B. Denby and B. Lucia, “Orbital edge computing: Nanosatellite constellations as 2017.
a new class of computer system,” in ASPLOS 25, 2020. [53] T. Nowatzki, M. Sartin-Tarm, L. De Carli, K. Sankaralingam, C. Estan, and
[20] H. Desai and B. Lucia, “A power-aware heterogeneous architecture scaling model B. Robatmili, “A general constraint-centric scheduling framework for spatial
for energy-harvesting computers,” IEEE Computer Architecture Letters, vol. 19, architectures,” ACM SIGPLAN Notices, vol. 48, no. 6, 2013.
no. 1, 2020. [54] Nvidia, “Nividia jetson tx2,” 2019. [Online]. Available: https://developer.nvidia.
[21] M. Duric, O. Palomar, A. Smith, O. Unsal, A. Cristal, M. Valero, and D. Burger, com/embedded/develop/hardware
“Evx: Vector execution on low power edge cores,” in DATE, 2014. [55] N. Ozaki, Y. Yasuda, M. Izawa, Y. Saito, D. Ikebuchi, H. Amano, H. Nakamura,
K. Usami, M. Namiki, and M. Kondo, “Cool mega-arrays: Ultralow-power
[22] G. Gobieski, B. Lucia, and N. Beckmann, “Intelligence beyond the edge: Inference
reconfigurable accelerator chips,” IEEE Micro, vol. 31, no. 6, 2011.
on intermittent embedded systems,” in ASPLOS, 2019.
[56] A. Parashar, M. Pellauer, M. Adler, B. Ahsan, N. Crago, D. Lustig, V. Pavlov,
[23] G. Gobieski, A. Nagi, N. Serafin, M. M. Isgenc, N. Beckmann, and B. Lucia,
A. Zhai, M. Gambhir, A. Jaleel et al., “Triggered instructions: a control paradigm
“Manic: A vector-dataflow architecture for ultra-low-power embedded systems,”
for spatially-programmed architectures,” ACM SIGARCH Computer Architecture
in MICRO 52, 2019.
News, vol. 41, no. 3, 2013.
[24] S. C. Goldstein, H. Schmit, M. Budiu, S. Cadambi, M. Moe, and R. R. Taylor,
[57] M. Poremba, S. Mittal, D. Li, J. S. Vetter, and Y. Xie, “Destiny: A tool for modeling
“Piperench: A reconfigurable architecture and compiler,” Computer, vol. 33, no. 4,
emerging 3d nvm and edram caches,” in DATE, 2015.
2000.
[58] R. Prabhakar, Y. Zhang, D. Koeplinger, M. Feldman, T. Zhao, S. Hadjis, A. Pedram,
[25] V. Govindaraju, C.-H. Ho, T. Nowatzki, J. Chhugani, N. Satish, K. Sankaralingam, C. Kozyrakis, and K. Olukotun, “Plasticine: A reconfigurable architecture for
and C. Kim, “Dyser: Unifying functionality and parallelism specialization for parallel patterns,” in ISCA 44, 2017.
energy-efficient computing,” IEEE Micro, vol. 32, no. 5, 2012. [59] B. Reagen, P. Whatmough, R. Adolf, S. Rama, H. Lee, S. K. Lee, J. M. Hernández-
[26] R. Hameed, W. Qadeer, M. Wachs, O. Azizi, A. Solomatnikov, B. C. Lee, Lobato, G.-Y. Wei, and D. Brooks, “Minerva: Enabling low-power, highly-accurate
S. Richardson, C. Kozyrakis, and M. Horowitz, “Understanding sources of deep neural network accelerators,” in ISCA 43, 2016.
inefficiency in general-purpose chips,” in ACM SIGARCH Computer Architecture [60] Riscv, “riscv-v-spec,” Apr 2019. [Online]. Available: https://github.com/riscv/riscv-
News, vol. 38, no. 3, 2010. v-spec
[27] M. Hempstead, N. Tripathi, P. Mauro, G.-Y. Wei, and D. Brooks, “An ultra low [61] A. Rowe, M. E. Berges, G. Bhatia, E. Goldman, R. Rajkumar, J. H. Garrett, J. M.
power system architecture for sensor network applications,” in ISCA 32, 2005. Moura, and L. Soibelman, “Sensor andrew: Large-scale campus-wide sensing and
[28] J. Hester, L. Sitanayah, and J. Sorber, “Tragedy of the coulombs: Federating actuation,” IBM Journal of Research and Development, vol. 55, no. 1.2, 2011.
energy storage for tiny, intermittently-powered sensors,” in Proc. of the 13th ACM [62] K. Sankaralingam, R. Nagarajan, H. Liu, C. Kim, J. Huh, D. Burger, S. W.
Conference on Embedded Networked Sensor Systems, 2015. Keckler, and C. R. Moore, “Exploiting ilp, tlp, and dlp with the polymorphous
[29] J. Hester and J. Sorber, “Flicker: Rapid prototyping for the batteryless internet of trips architecture,” in ISCA 30, 2003.
things,” in SenSys 15, 2017. [63] M. Satyanarayanan, N. Beckmann, G. A. Lewis, and B. Lucia, “The role of edge
[30] M. Horowitz, “Computing’s energy problem (and what we can do about it),” in offload for hardware-accelerated mobile devices,” in HotMobile, 2021.
ISSCC, 2014. [64] Y. S. Shao, B. Reagen, G.-Y. Wei, and D. Brooks, “Aladdin: A pre-rtl, power-
[31] T. Instruments, “Msp430fr5994 sla,” 2017. [Online]. Available: http://www.ti. performance accelerator simulator enabling large design space exploration of
com/lit/ds/symlink/msp430fr5994.pdf customized architectures,” in ISCA 41, 2014.
[32] N. Jackson, “lab11/permamote,” Apr 2019. [Online]. Available: https://github. [65] P. Shivakumar and N. P. Jouppi, “CACTI 3.0: An Integrated Cache, Timing, Power,
com/lab11/permamote and Area Model,” Compaq Western Research Laboratory, Tech. Rep., February
[33] M. Karunaratne, A. K. Mohite, T. Mitra, and L.-S. Peh, “Hycube: A cgra with 2001.
reconfigurable single-cycle multi-hop interconnect,” in DAC, 2017. [66] W. Snyder, “Verilator and systemperl,” in North American SystemC Users’ Group,
[34] C. Kim, M. Chung, Y. Cho, M. Konijnenburg, S. Ryu, and J. Kim, “Ulp-srp: DAC, 2004.
Ultra low power samsung reconfigurable processor for biomedical applications,” [67] S. Swanson, K. Michelson, A. Schwerin, and M. Oskin, “Wavescalar,” in MICRO
in ICFPT, 2012. 36, 2003.
[35] M. Kou, J. Gu, S. Wei, H. Yao, and S. Yin, “Taem: fast transfer-aware effective [68] C. Tan, M. Karunaratne, T. Mitra, and L.-S. Peh, “Stitch: Fusible heterogeneous
loop mapping for heterogeneous resources on cgra,” in DAC 57, 2020. accelerators enmeshed with many-core architecture for wearables,” in ISCA 45,
[36] C. Kozyrakis and D. Patterson, “Overcoming the limitations of conventional vector 2018.
processors,” ACM SIGARCH Computer Architecture News, vol. 31, no. 2, 2003. [69] F. Tavares, “Kicksat 2,” May 2019. [Online]. Available: https://www.nasa.gov/
[37] R. Krashinsky, C. Batten, M. Hampton, S. Gerding, B. Pharris, J. Casper, and ames/kicksat
K. Asanovic, “The vector-thread architecture,” in ISCA 31, 2004. [70] M. B. Taylor, “Is dark silicon useful? harnessing the four horsemen of the coming
[38] J. Lee, C. Kim, S. Kang, D. Shin, S. Kim, and H.-J. Yoo, “Unpu: A 50.6 tops/w dark silicon apocalypse,” in DAC, 2012.
unified deep neural network accelerator with 1b-to-16b fully-variable weight bit- [71] D. Voitsechov and Y. Etsion, “Single-graph multiple flows: Energy efficient design
precision,” in ISSCC, 2018. alternative for gpgpus,” ACM SIGARCH computer architecture news, vol. 42, no. 3,
[39] A. Li, T.-J. Chang, and D. Wentzlaff, “Automated design of fpgas facilitated by 2014.
cycle-free routing,” in FPL 30, 2020. [72] D. Voitsechov, O. Port, and Y. Etsion, “Inter-thread communication in multi-
[40] T. Liu, C. M. Sadler, P. Zhang, and M. Martonosi, “Implementing software on threaded, reconfigurable coarse-grain arrays,” in MICRO 51, 2018.
resource-constrained mobile sensors: Experiences with impala and zebranet,” in [73] B. A. Warneke and K. S. Pister, “17.4 an ultra-low energy microcontroller for
MobiSys 2. New York, NY, USA: ACM, 2004. smart dust wireless sensor networks,” 2004.
[41] B. Lucia, V. Balaji, A. Colin, K. Maeng, and E. Ruppel, “Intermittent computing: [74] J. Weng, S. Liu, V. Dadu, Z. Wang, P. Shah, and T. Nowatzki, “Dsagen:
Challenges and opportunities,” in SNAPL 2, 2017. synthesizing programmable spatial accelerators,” in ISCA 47, 2020.
[42] M. Mishra, T. J. Callahan, T. Chelcea, G. Venkataramani, S. C. Goldstein, and [75] J. Weng, S. Liu, Z. Wang, V. Dadu, and T. Nowatzki, “A hybrid systolic-dataflow
M. Budiu, “Tartan: evaluating spatial computation for whole program execution,” architecture for inductive matrix algorithms,” in HPCA, 2020.
ACM SIGARCH Computer Architecture News, vol. 34, no. 5, 2006. [76] A. Wickramasinghe, D. Ranasinghe, and A. Sample, “Windware: Supporting
[43] P. Mohan, O. Atli, O. Kibar, M. Z. Vanaikar, L. Pileggi, and K. Mai, “Top-down ubiquitous computing with passive sensor enabled rfid,” in RFID, April 2014.
physical design of soft embeddedÂăfpgaÂăfabrics,” in FPGA. ACM, 2021. [77] H. Zhang, J. Gummeson, B. Ransford, and K. Fu, “Moo: A batteryless computa-
[44] T. Moscibroda and O. Mutlu, “A case for bufferless routing in on-chip networks,” tional rfid and sensing platform,” Department of Computer Science, University of
in ISCA 36, 2009. Massachusetts Amherst., Tech. Rep, 2011.
[45] S. Naderiparizi, M. Hessar, V. Talla, S. Gollakota, and J. R. Smith, “Towards
battery-free {HD} video streaming,” in NSDI 15, 2018.
[46] M. Nardello, H. Desai, D. Brunelli, and B. Lucia, “Camaroptera: A batteryless
long-range remote visual sensing system,” in ENSSys 7, 2019.
14You can also read
