Snowflake: An Efficient Hardware Accelerator for

Convolutional Neural Networks

Vinayak Gokhale∗ , Aliasger Zaidy∗ , Andre Xian Ming Chang∗ , Eugenio Culurciello†
∗ School
of Electrical and Computer Engineering
† Weldon
School of Biomedical Engineering
Purdue University, West Lafayette, IN 47907
Email: {vgokhale,azaidy,amingcha,euge}@purdue.edu

Abstract—Deep learning is becoming increasingly popular Z'ŝŶƉƵƚ

for a wide variety of applications including object detection,
classification, semantic segmentation and natural language pro-
cessing. Convolutional neural networks (CNNs) are a type of >ϭ
>Ϯ >ϯ >ϰ >ϱ
deep neural network that achieve high accuracy for these tasks.
CNNs are hierarchical mathematical models comprising billions ϭϬϬϬ

of operations to produce an output. The high computational

complexity combined with the inherent parallelism in these
models makes them an excellent target for custom accelerators. In
this work we present Snowflake, a scalable, efficient low-power
accelerator that is agnostic to CNN architectures. Our design
is able to achieve an average computational efficiency of 91%
which is significantly higher than comparable architectures. We
implemented Snowflake on a Xilinx Zynq XC7Z045 APSoC. On
this platform, Snowflake is capable of achieving 128 G-ops/s while
consuming 9.48 W of power. .Snowflake achieves a throughput
and energy efficiency of 98 frames per second and 10.3 frames
per joule, respectively, on AlexNet and 34 frames per second and
3.6 frames per joule on GoogLeNet.
I. I NTRODUCTION
Convolutional neural networks (CNNs) have emerged as
the model of choice for object detection, classification, seman-
tic segmentation and natural language processing tasks. CNNs
achieving high accuracy in these tasks have been published
in [1]–[3]. CNNs are hierarchical models named after the
eponymous convolution operator. The levels of hierarchy in
a CNN are called the layers of the network. The inputs and
outputs of CNN layers are usually three dimensional. Typical
CNNs use as input an image, with its red, green and blue
channels split into three separate two dimensional input feature
maps. Three convolutional filters, one per channel, perform
two dimensional convolution on the input maps to produce
three outputs. Finally, these outputs are combined by pixel-
wise addition into a single two dimensional output called an
output feature map. Multiple such filters are convolved with
the same input to produce multiple output maps. The output
of one layer becomes the input to the next.
Convolutional layers can be interspersed with some sort of
spatial pooling operation that downsamples the feature maps.
The most commonly used pooling operator is spatial max-
pooling. Max-pooling performs the max operation on a spatial
region within an input feature map and produces a single
output. Finally, a non-linear function is applied to the result.
The most common non-linear function used is the rectified
linear unit (ReLU). ReLU sets negative inputs to zero and
keeps positive inputs unchanged. An example of a complete
CNN nicknamed AlexNet [1] is shown in figure 1.
ϵϲ Ϯϱϲ ϯϴϰ ϯϴϰ Ϯϱϲ
ϰϬϵϲ ϰϬϵϲ
KƵƚƉƵƚŽĨĐŽŶǀŽůƵƚŝŽŶĂůůĂLJĞƌ
KƵƚƉƵƚŽĨŵĂdžͲƉŽŽůŝŶŐ
&ƵůůLJĐŽŶŶĞĐƚĞĚůĂLJĞƌ
Fig. 1: Shown here is a CNN with five convolutional layers
and three fully-connected layers. While not shown, all layers
(except max-pooling) are followed by a rectified linear unit.
While CNNs report high accuracy for object detection
and classification tasks, they also have high computational
complexity. This fact, combined with their recent success
has resulted in a large number of custom architectures that
take advantage of the inherent parallelism of the convolution
operator. However, the highly varied data access patterns in
CNNs make it difficult for custom architectures to achieve
high computational efficiency while processing a network. In
this context, we define computational efficiency as the ratio of
actual number of operations processed to the theoretical max-
imum number of operations the design can process, expressed
as a percentage. This translates to the ratio of actual FPS to
theoretical FPS for a given CNN. Most custom accelerators
are capable of achieving over 90% efficiency in some part
of the network’s computation but have lower efficiencies in
other parts. We discuss computational efficiency because it
is one of two factors influencing computational throughput,
the other being bandwidth. Certain CNN layers are entirely
bandwidth dependent and cannot be made compute bound
by changing data access patterns alone. For these layers, a
variety of compression techniques have been presented which
reduces their size significantly [4], [5]. However, network
compression techniques are orthogonal to the work presented
here. This is because compression techniques can be used with
most accelerator architectures by fetching compressed data
from memory and decompressing it before writing to on-chip
buffers. However, if the computations within a network do
not map efficiently to the compute resources available in the
design, computational efficiency will decrease. In this paper,
we present Snowflake, an efficient architecture that is able to

Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 10,2024 at 03:39:59 UTC from IEEE Xplore. Restrictions apply.
978-1-4673-6853-7/17/$31.00 ©2017 IEEE
 <t
E
<ĞƌŶĞůdƌĂĐĞ 9HF 
<, <tΎE
0DS7UDFH 9HF 
<tΎE
Fig. 2: A trace is a contiguous two dimensional region of the
input operand volumes that is part of the computation of an
output pixel. Traces are accessed from on-chip buffers at the
granularity of 256-bit blocks called vectors.
achieve an efficiency of 91% on AlexNet and GoogLeNet, two
CNNs with significantly varied data access patterns and layer
sizes.
II. R ELATED W ORK
Most recent accelerators comprise a collection of process-
ing elements (PEs) and some scratchpad memory. Eyeriss is
an ASIC implementation that contains a 12 × 14 grid of PEs
and 108 KB of scratchpad memory [5]. Eyeriss achieves a
maximum efficiency of 92% on AlexNet layer 1, 80% on
layer 2 and 93% on layers 3-5. However, AlexNet layer 2
has 50% more computation than the next largest layer (layer
3) and represents 33% of the entire workload. The Origami
architecture comprises multiple grids of 49 multipliers and
adders. Origami is able to achieve an efficiency of 74%
[6]. The design proposed by Qiu, et al. is able to achieve
an efficiency of 80.3% [7]. By comparison, Snowflake is
able to achieve 91% efficiency when processing AlexNet and
GoogLeNet.
III. DATA O RGANIZATION
Snowflake organizes computation into traces. A trace is de-
fined as a contiguous region of memory that must be accessed
as part of the computation necessary to produce a single output
pixel. An example of a trace is shown in figure 2. Usually,
an output pixel requires multiple traces to be processed and
accumulated. The length of a trace depends on the size of
the kernel and the number of input channels in that layer. For
example, a layer with 256 input maps and 3 × 3 kernels would
require 3 traces, each of length 256 × 3 = 768, to produce one
dž
LJ nj
dž͕LJ͕nj
Ϭ͕Ϭ͕Ϭ Ϭ͕Ϭ͕ϭ Ϭ͕Ϭ͕Ϯ
dž D
D D
nj
LJ Ϭ͕Ϭ͕Ϭ
Ϭ͕Ϭ͕Ϭ Ϭ͕Ϭ͕ϭ Ϭ͕Ϭ͕Ϯ
dž͕LJ͕nj
(a) In cooperative mode, illustrated here, the mth word of the vector
is sent to the mth MAC within the vMAC
Fig. 3: An illustration of how computation maps to MAC units in independent and cooperative modes.
Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 10,2024 at 03:39:59 UTC from IEEE Xplore. Restrictions apply.
9HF  ͙ 9HF 0
output. Splitting computation into traces allows us to hide the
^ƵďĚŝǀŝĚĞĚŝŶƚŽDǀĞĐƚŽƌƐ latency associated with branches, loads, stores and other non-
compute instructions. This is because computation of a trace
requires a single instruction that usually takes several cycles to
9HF  ͙ 9HF 0
^ƵďĚŝǀŝĚĞĚŝŶƚŽDǀĞĐƚŽƌƐ
process. Data that is part of a trace is accessed from on-chip
buffers at 256-bit granularity. These smaller blocks of data are
called vectors. Snowflake uses 16-bit fixed point words. As
a result, each vector contains 16 words. The choice for 16-
bit words was made because for CNNs there is insignificant
loss in accuracy between networks using 16-bit fixed point and
32-bit floating point [8].
The 16 words of a vector are split up among a group of 16
multiply-accumulate (MAC) units called a vector MAC unit
(vMAC). This splits up the computation of a single output
among several MAC units. A separate adder, one per vMAC,
performs reduction on the partial sums stored in the internal
accumulate register of each MAC, to produce an output pixel.
Since multiple MAC units work together to produce an output,
this method of mapping is called the cooperative mode of
computation. The cooperative mode is illustrated in figure 3a.
The benefits of this type of mapping are twofold. First, it
maximizes MAC utilization. In a 2D systolic grid, maximum
utilization can only be achieved if the size of the grid is equal
to or an integer multiple of the kernel size. In Snowflake, MAC
utilization is 100% any time the number of input maps is an
integer multiple of 16. This is usually the case for all but the
first layer of a CNN [1]–[3]. The second benefit of this type
of mapping is that it reduces the on-chip SRAM required per
MAC. Each MAC requires maps and kernels to process a layer.
Maps can be shared across MACs to some extent. In that case,
however, they require different kernels. For large networks, the
size of a single kernel can be large. For example, the size of
a single kernel in AlexNet’s layer 3 is 6.75 KB. Using our
mapping, this can be split up across 16 MAC units instead of
one, resulting in lower amount of SRAM necessary per MAC.
The cooperative mode does not work for layers that contain
input maps that are not a multiple of 16. For that scenario, the
data organization changes slightly. Maps are still stored depth-
first. However, the weights are stored in a kernel-first order.
Consider the case of AlexNet layer 1 [1] with 64 kernels, each
of which is 3 × 11 × 11. These will be stored such that the first
element in the weights array is the first pixel of the first red
kernel’s first row. This is illustrated in figure 3b. The second
element will be the first pixel of the second red kernel’s first
row. Similarly, the sixteenth pixel will be the first pixel of the
dž dž͕LJ͕nj͕Ŷ
ϯ
͙ LJ ͙ Ϭ͕Ϭ͕Ϭ͕Ϭ Ϭ͕Ϭ͕Ϭ͕ϭ Ϭ͕Ϭ͕Ϭ͕Ϯ ͙ Ϭ͕Ϭ͕Ϭ͕ϭϱ
Ϭ͕Ϭ͕ϭϱ
͙ D D D D
D
dž ϯ
Ϭ͕Ϭ͕ϭ Ϭ͕Ϭ͕Ϯ ͙ Ϭ͕ϱ͕Ϭ
͙ Ϭ͕Ϭ͕ϭϱ
LJ
dž͕LJ͕nj
(b) In independent mode, the mth word of the maps vector is
broadcast to all MACs.
 >ͬ^d
,WϬ
>ͬ^d
,Wϭ ŝƐƉĂƚĐŚ >h
ĂƚĂŝƐƚƌŝďƵƚŝŽŶEĞƚǁŽƌŬ
>ͬ^d
,WϮ
>ͬ^d ĞĐŽĚĞ ZĞŐ͘&ŝůĞ
,Wϯ
&ĞƚĐŚ
/Ψ
ŽŶƚƌŽůŽƌĞ
Fig. 4: An overview of the Snowflake architecture. The four major components of Snowflake - the memory interface, the data
distribution network, the control core and the compute core - are shown in the figure.
sixteenth red kernel’s first row. The seventeenth pixel will hold
the first pixel of the first green kernel’s first row. In this type
of mapping, each MAC unit produces an output pixel. Since
each MAC unit works independently of others, this type of
mapping is called the independent mode of computation. The
cooperative mode is used any time the number of input maps
is a multiple of 16 while the independent mode is used for all
other cases.
IV. A RCHITECTURE
The Snowflake coprocessor has four components - the
memory interface, the data distribution network, the control
core and the compute core. An overview of the system is
shown in figure 4.
1) Control Core: The control core is designed as a simple
RISC-style, five stage pipeline. It contains a 4 KB direct-
mapped instruction cache, an instruction decoder, a two-ported
register file and an ALU containing a multiplier, an adder and
a comparator. The traditional instruction decode stage is split
into two parts, with the second being the dispatch stage. The
dispatch stage is responsible for preventing read access to a
buffer that is also the destination for a load instruction. By do-
ing this, it prevents the vMACs from accessing a buffer before
data from memory has completed writing to it. The control
core is responsible for supplying compute instructions to the
compute core. These compute instructions are in the form of
traces described in section III. Each trace instruction contains
the trace length, the mode of computation (independent or
cooperative) and the addresses of the maps and weights buffers
where the first element of the trace resides. Other instructions
are loads, stores, ALU operations that increment the trace start
addresses and branches. Branch instructions are followed by
four branch delay slots. Most loops can make full use of these
slots. The latencies associated with non-trace instructions can
usually be hidden because a single trace instruction keeps the
vMACs occupied for several cycles.
2) Compute Core: The compute core contains the vMACs,
the maps and weights buffers and comparators to perform
Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 10,2024 at 03:39:59 UTC from IEEE Xplore. Restrictions apply.
ŽŵƉƵƚĞ
hŶŝƚ tΨ tΨ tΨ tΨ
ŽŵƉƵƚĞ
hŶŝƚ sĞĐƚŽƌ sĞĐƚŽƌ sĞĐƚŽƌ sĞĐƚŽƌ DĂdž
͘ D D D D ƉŽŽů
͘
͘
ŽŵƉƵƚĞ DΨ
hŶŝƚ
ŽŵƉƵƚĞŽƌĞ
the maxpool and ReLU operations. Four vMACs and four
comparators are grouped together to form one compute unit
(CU). Each CU also contains a reduction adder, a 128 KB
maps buffer and a 32 KB weights buffer. The compute core
contains four CUs which contain a total of 256 MAC units,
512 KB of maps buffer and 128 KB of weights buffer. The 4
CUs together provide a maximum throughput of 128 G-ops/s.
3) Data Distribution Network: The data distribution net-
work (DDN) is responsible for forwarding data returned from
memory to the correct on-chip buffers and forwarding results
produced by the coprocessor back to memory. The bus from
memory contains 64-bit words while Snowflake vectors are
256 bits wide. As a result, the DDN packs four memory words
into a single vector. When receiving data from memory that is
destined for the instruction cache, the DDN unpacks a 64-bit
memory word into two 32-bit instructions.
4) Memory Interface: The memory interface contains four
load-store units. Each unit is capable of sustaining 1 GB/s in
full-duplex. The load units supply data to the DDN. Each
memory word is accompanied by its physical memory address,
the buffer address at which the word is to be written and a
destination ID. The destination ID is used by the DDN to
forward data to the correct buffer. The memory address is
necessary to write to the instruction cache. Finally, a single
bit last signal is included which signals the dispatch stage of
the control core to unlock read access to the corresponding
buffer so that any trace instructions that are being held back
can proceed.
V. R ESULTS
A. System Specifications
We implemented Snowflake on a Xilinx Zynq XC7Z045
APSoC device. We used the ZC706 platform which has the
Zynq device and 1 GB of DDR3 memory. This Zynq device
has 2 ARM cores running at 800 MHz and a Kintex-7 FPGA.
The implemented Snowflake system had 4 CUs, each with 64
MAC units, a 128 KB maps buffer, 32 KB weights buffer and
 TABLE I: A comparison of computational efficiency with other FPGA accelerators.
Eyeriss [5] Origami [6] Zhang, et al. [9] Caffeine [10] Qiu, et al. [7] This work
Platform ASIC 65nm CMOS ASIC 65nm CMOS Virtex-7 VX485T Ultrascale KU060 Zynq XC7Z045 Zynq XC7Z045
Clock (MHz) 200 250 100 200 150 250
Precision 16-bit fixed 12-bit fixed 32-bit float 16-bit fixed 16-bit fixed 16-bit fixed
MAC units 168 196 448 1058 780 256
Performance (G-ops/s) 46.1 145.0 61.6 310.0 187.8 116.5
Theoretical max (G-ops/s) 67.2 196.0 89.6 423.2 234 128.0
Power (W) 0.28 0.45 18.61 25.00 9.63 9.48
Energy Eff. (G-ops/J) 164.64 322.2 3.3 12.4 19.5 12.3
Computational Eff. 68.6% 74.0% 68.8% 73.3% 80.3% 91%

four comparators. The entire system was clocked at 250 MHz.
At these specifications, the ZC706 platform consumes 9.48 W.
This system is capable of a theoretical maximum throughput
of 128 G-ops/s.
B. Performance Comparison
We benchmarked both AlexNet [1] and GoogLeNet [2] on
this system and achieved an average efficiency of 91% on
both networks. Snowflake is able to achieve 98 frames per
second on AlexNet and 34 frames per second on GoogLeNet.
Our benchmarks do not take the models’ large fully con-
nected layers into account because, as mentioned in section
I, these layers add very little computational complexity and
are bandwidth limited. Compression techniques can reduce
their size significantly, increasing throughput. We compare the
efficiency of our design with other works in literature in table
I. In the table, an op is defined as a multiplication or an
addition. As opposed to the other works, [5] does not explicitly
state performance. As such, it was computed by taking the
ratio of number of ops to latency. Snowflake’s efficiency of
91% is 10.7 percentage points more than [7], which is the
next most computationally efficient system. [5] and [6] are
ASIC implementations which explains their higher energy
efficiency. However, they are 22.4 and 17 percentage points
lower, respectively, in terms of computational efficiency than
Snowflake. [7], [10] are FPGA implementations that are 10.7
and 17.7 percentage points lower in computational efficiency,
respectively, than Snowflake. While [7] achieves 1.6× more
throughput, it also uses 3× more MAC units. Similarly, the
design in [10] is 2.7× faster but uses 4× more MAC units.
Our simulations show that scaling our design up to 768 MAC
units would result in a system with a throughput of 349 G-
ops/s. Such a system would be 1.9× faster than [7] and 1.1×
faster than [10] while using fewer MAC units than either.
Snowflake’s high computational efficiency is attributed to the
efficient mapping of compute in CNNs to the vMACs in our
design using the independent and cooperative computation
modes. In terms of computational throughput, the current
system can process both AlexNet and GoogLeNet in real time.
VI. F UTURE W ORK AND C ONCLUSION
We presented an efficient implementation of a CNN copro-
cessor. Our design, titled Snowflake, is capable of achieving a
maximum throughput of 128 G-ops/s on CNN workloads while
using 256 MAC units clocked at 250 MHz. Snowflake is able to
process AlexNet at 98 frames per second and GoogLeNet at 34
frames per second while consuming 9.48 W. This demonstrates
the real time processing capabilities of our design on multiple
modern deep CNNs. We plan on exploiting Snowflake’s high
computational efficiency and scaling our design up to 768
MAC units on the current Zynq device and further on larger
FPGAs.
ACKNOWLEDGMENT
This work was partly supported by Office of Naval Re-
search (ONR) grants N000141210167, N000141512791 and
MURI N000141010278.
R EFERENCES
[1] A. Krizhevsky, “One weird trick for parallelizing convolutional neural
networks,” CoRR, vol. abs/1404.5997, 2014. [Online]. Available:
http://arxiv.org/abs/1404.5997
[2] C. Szegedy, W. Liu, Y. Jia, P. Sermanet, S. Reed, D. Anguelov, D. Erhan,
V. Vanhoucke, and A. Rabinovich, “Going deeper with convolutions,”
in The IEEE Conference on Computer Vision and Pattern Recognition
(CVPR), June 2015.
[3] K. He, X. Zhang, S. Ren, and J. Sun, “Deep residual learning
for image recognition,” CoRR, vol. abs/1512.03385, 2015. [Online].
Available: http://arxiv.org/abs/1512.03385
[4] S. Han, H. Mao, and W. J. Dally, “Deep compression: Compressing
deep neural networks with pruning, trained quantization and huffman
coding,” International Conference on Learning Representations (ICLR),
2016.
[5] Y.-H. Chen, T. Krishna, J. Emer, and V. Sze, “Eyeriss: An energy-
efficient reconfigurable accelerator for deep convolutional neural net-
works,” in IEEE International Solid-State Circuits Conference, ISSCC
2016, Digest of Technical Papers, 2016, pp. 262–263.
[6] L. Cavigelli, D. Gschwend, C. Mayer, S. Willi, B. Muheim,
and L. Benini, “Origami: A convolutional network accelerator,” in
Proceedings of the 25th Edition on Great Lakes Symposium on VLSI,
ser. GLSVLSI ’15. New York, NY, USA: ACM, 2015, pp. 199–204.
[Online]. Available: http://doi.acm.org/10.1145/2742060.2743766
[7] J. Qiu, J. Wang, S. Yao, K. Guo, B. Li, E. Zhou, J. Yu, T. Tang, N. Xu,
S. Song, Y. Wang, and H. Yang, “Going deeper with embedded fpga
platform for convolutional neural network,” in Proceedings of the 2016
ACM/SIGDA International Symposium on Field-Programmable Gate
Arrays, ser. FPGA ’16. New York, NY, USA: ACM, 2016, pp. 26–35.
[Online]. Available: http://doi.acm.org/10.1145/2847263.2847265
[8] S. Gupta, A. Agrawal, K. Gopalakrishnan, and P. Narayanan, “Deep
learning with limited numerical precision.” in ICML, 2015, pp. 1737–
1746.
[9] C. Zhang, P. Li, G. Sun, Y. Guan, B. Xiao, and J. Cong,
“Optimizing fpga-based accelerator design for deep convolutional
neural networks,” in Proceedings of the 2015 ACM/SIGDA International
Symposium on Field-Programmable Gate Arrays, ser. FPGA ’15.
New York, NY, USA: ACM, 2015, pp. 161–170. [Online]. Available:
http://doi.acm.org/10.1145/2684746.2689060
[10] C. Zhang, Z. Fang, P. Zhou, P. Pan, and J. Cong, “Caffeine: Towards
uniformed representation and acceleration for deep convolutional
neural networks,” in Proceedings of the 35th International
Conference on Computer-Aided Design, ser. ICCAD ’16. New
York, NY, USA: ACM, 2016, pp. 12:1–12:8. [Online]. Available:
http://doi.acm.org/10.1145/2966986.2967011

Authorized licensed use limited to: NORTHWESTERN POLYTECHNICAL UNIVERSITY. Downloaded on April 10,2024 at 03:39:59 UTC from IEEE Xplore. Restrictions apply.