MaPU: A Novel Mathematical Computing Architecture

Donglin WangCASIA, Beijing, China

Shaolin Xie∗

CASIA, Beijing, ChinaZhiwei Zhang

CASIA, Beijing, China

Xueliang DuCASIA, Beijing, China

Lei Wang, Zijun LiuCASIA, Beijing, China

Xiao Lin, Jie HaoCASIA, Beijing, China

Leizu YinSpreadtrum Comm, Inc.

Tao WangHuawei Tech Co, Ltd.

Yongyong YangHuawei Tech Co, Ltd.

Chen Lin, Hong MaCASIA, Beijing, China

Zhonghua Pu,GuangxinDing

CASIA, Beijing, China

Wenqin Sun, FabiaoZhou

CASIA, Beijing, China

Weili Ren, Huijuan WangCASIA, Beijing, China

Mengchen Zhu, LipengYang

CASIA, Beijing, China

NuoZhou Xiao, Qian CuiCASIA, Beijing, China

Xingang WangCASIA, Beijing, China

Ruoshan GuoCASIA Beijing China

Xiaoqin WangCASIA Beijing China

ABSTRACTAs the feature size of the semiconductor process is scalingdown to 10nm and below, it is possible to assemble systemswith high performance processors that can theoretically pro-vide computational power of up to tens of PLOPS. However,the power consumption of these systems is also rocketing upto tens of millions watts, and the actual performance is onlyaround 60% of the theoretical performance. Today, powerefficiency and sustained performance have become the mainfoci of processor designers. Traditional computing architec-ture such as superscalar and GPGPU are proven to be powerinefficient, and there is a big gap between the actual and peakperformance. In this paper, we present the MaPU architec-ture, a novel architecture which is suitable for data-intensivecomputing with great power efficiency and sustained com-putation throughput. To achieve this goal, MaPU attemptsto optimize the application from a system perspective, in-cluding the hardware, algorithm and corresponding programmodel. It uses an innovative multi-granularity parallel mem-ory system with intrinsic shuffle ability, cascading pipelineswith wide SIMD data paths and a state-machine-based pro-gram model. When executing typical signal processing algo-rithms, a single MaPU core implemented with a 40nm pro-cess exhibits a sustained performance of 134 GLOPS while

∗Corresponding author; email: shaolin.xie@ia.ac.cn

consuming only 2.8 W in power, which increases the actualpower efficiency by an order of magnitude comparable withthe traditional CPU and GPGPU.

1. INTRODUCTIONToday, power efficiency is a key factor for mobile com-

puting. Great advances have been made to prolong batterylife and provide greater computing abilities[1][2]. However,power efficiency is not only an important factor in mobilecomputing, but also a key metric in supercomputing.

As Moore’s Law is still effective, tremendous transistorscan be used for building super processors like Intel’s XeonPhi co-processor and the Nvidia GPU. The Intel Xeon Phi7120p co-processor was built with 61 cores, providing a the-oretical peak performance of 2.4 TFLOPS. The latest NvidiaKepler GK210 provides a theoretical peak performance of4.37 TFLOPS. However, the peak power levels of these twochips are 300 W and 150 W, respectively, which means theirpower efficiency levels are only 8 GFLOPS/W and 29 GFLOPS/W,respectively. Furthermore, these figures represent their theo-retical power efficiency; their actual power efficiency is evenlower. As reported by Green500, which aims to provide aranking of the most energy-efficient supercomputers in theworld, the most power-efficient supercomputer is only 0.7GLOPS/W,

Although the power consumption of a single processor

978-1-4673-9211-2/16/$31.00 c©2016 IEEE

457

is not necessarily a disadvantage for indoor systems with asustained power supply, the aggregate power of those super-computers built with thousands of super processors wouldeventually limit the scale of the system given the increasingcost of deployment and maintenance involved. For exam-ple, the most powerful super computer Tianhe2 consumes 24MW(with a cooling system) and occupies 720 square metersof space. To build such a system, dedicated computer com-plex and power station are needed.

Another problem with today’s computing is the gap be-tween peak performance and sustained performance[3]. Onlya few improvements have been made today[4]. The actualperformance of the most two powerful supercomputers (rankedby Top500 in June 2015) is only 62% and 65% of the corre-sponding peak performance, respectively, even with a verystructured algorithm such as LINPACK applied. As theirsustained performance is much lower than their theoreticalperformance, the actual power efficiency of their processorsis less than the theoretical power efficiency.

Many factors contribute to the performance gap[3], al-though the most important one is that the compilers usuallyimplicitly use simplified models of processor architectureand do not take the detailed workings of each processor com-ponent into account, such as the memory hierarchy, SIMDinstruction extensions, and zero overhead circulations. It hasbeen reported that the mean usage for various GPU bench-marks is only 45%, and that the main sources of underuseare memory stalls, which are caused by memory access la-tency and inefficient access patterns [4]. As a result, mostprocessors rely heavily on hand-optimized libraries to boostactual performance in many applications, which makes thecompiler subsidiary in performance critical program.

Given the current abundance of chip transistors, many newarchitectures leverage various ASIC-based accelerators toincrease the power efficiency and narrow the performancegap. However, these architectures are inflexible and requiregreat effort to design a chip for specific applications. Weaimed to construct a programmable accelerator architecturefrom a system perspective that can provide performance andpower efficiency comparable with ASIC implementation andcan be tailored by the programmer to specific workloads.The intuitive strategy we adopt is to map the mathemati-cal representation of the computation kernel into massive re-configurable computing logics, and map the data into highlyreconfigurable memory systems. We call this architectureMaPU, which stands for Mathematical Processing Unit.

In this paper, we first discuss the considerations involvedin designing MaPU. We then introduce the instruction setarchitecture of MaPU in Section 2. The highlights of theMaPU architecture are presented in Section 3. To prove theadvantages of the MaPU architecture, a chip with four MaPUcores is designed, implemented and taped out with a 40-nmprocess. The structure, performance and power of this chipare fully analyzed in Section 4.

2. RETROSPECT AND OVERVIEW OF MAPUARCHITECTURE

It took us a long time to design with a feasible micro-architecture for MaPU. Traditional superscalar has proved tobe inherently power inefficient[5], and GPGPU is also power

hungry. As such, our work excluded both of those architec-tures. Strategies such as VLIW and SIMD were taken intoconsideration. The first proposed MaPU micro-architecturefeatured customized wide vector instructions in a RISC styleand an innovative multi-granularity parallel (MGP) memory.This method was discarded for its low efficiency. We thenproposed a micro-architecture that included massive com-puting units with hardwired state machines, in which eachcomputation kernel was represented by a state machine. Thismicro-architecture manifested high performance and powerefficiency. However, as we tried to support more kernels,the state machine became so complex that the circuit couldonly run at a much lower frequency. The micro-architecturethen evolved into the current one in which the state ma-chines were broken down into microcodes and became pro-grammable. This provided the possibility of supporting var-ious kernels with customized state machines.

As an accelerator framework, MaPU is made up of threemain components: the microcode pipeline, MGP memoryand scalar pipeline, as shown in Figure 1.

Scalar Register File

Scalar FU

Microcode Fetch

Microcode Memory

FU2

FU5

FU6

FU7

FU8

FU1

FU9

FU0

FU3

FU4

Multi-Granularity Parallel Memory

System(MGP)

CSU

Microcode Controller Microcode

Pipeline

Bus Interface

Bus Interface

Bus Interface

Scalar Pipeline

Figure 1: MaPU Architecture Framework

The scalar pipeline is subsidiary and can be a simple RISCcore or a VLIW DSP core. It is used to communicate withthe system on chip (SoC) and controlling the microcode pipeline.The Communication and Synchronization Unit (CSU) in thescalar pipeline includes a DMA controller used to transporthigh dimensional data to and from the SoC and some con-trol registers that can be read/written by other SoC mastersto control or check the status of the MaPU core.

Although MaPU is an accelerator architecture, we includethis scalar pipeline to facilitate the interaction between theMaPU cores and SoC. For example, the scalar pipeline in-cludes exclusive load/store operation pairs to support multi-thread primitives such as atomic addition, spin lock and fork/join.Therefore, it would be easier to develop a MaPU runtime li-brary to support a multi-core program framework such asOpenMPI, OpenMP and OpenCL.

2.1 Microcode pipelineThe microcode pipeline is the key component of the MaPU

architecture. The functional unit (FU) can be an ALU, MACor any other module with special functions. Superscalarcomponents such as register rename logics and instructionissue windows are power inefficient[5]. To eliminate thepower consumed by control logics, the FUs in MaPU arecontrolled by microcodes in VLIW style. There is a highly

2

458

2

structured forwarding matrix between FUs, and its routing iscontrolled dynamically by microcodes. In this way, the FUscan cascade into a complete data path which resembles thedata flow of the algorithm. Data dependence and routing arehandled by the program to further simplify the control logic.

This micro-architecture, which consists of massive FUswith a structured forwarding matrix, manifests high perfor-mance and power efficiency but leaves all of the complexityto the programmers. This is plausible because computationkernels are usually simple and structured, such as the FFTand matrix multiply algorithms. A library that includes com-mon routines would decrease the complexity for program-mers.

The microcode pipeline has many features in commonwith coarse grain reconfigurable architecture(CGRA), butwith two enhancements. First, all of the FUs and forward-ing matrix in MaPU operate in the SIMD manner and havethe same bit width, which is supposed to be wide. WiderSIMD can amortize the power overhead of instruction fetchand dispatch, bringing more benefits in terms of energy effi-ciency. Second, the microcode pipeline has a highly coupledforwarding matrix instead of dedicated routing units. Withthis forwarding matrix, FUs can cascade into a compact datapath that resembles the data flow of the algorithm. There-fore, it can provide performance and power efficiency com-parable with that of ASIC. Furthermore, as each FU has adedicated path to and from other specific FUs, programmersdo not have to consider the data routing congestion problem,making instruction scheduling much simpler than CGRA.These benefits comes at the cost of extra wires, which oc-cupy a considerable chip area. In fact, some implementationhas to divide the forwarding matrix into two stages to de-crease the connecting wires between FUs, and only part ofthe FUs maybe connected depending on the characteristicsof the applications .

FU0 FU1 FU2 FU3 FU4 … … Control

Repeat:

Loop:

Microcode for each functional Unit

Microcode controlling next PC address

Figure 2: Microcode line Format

There are N microcodes issued in a clock period for animplementation with N FUs. These microcodes issued atthe same time are called microcode lines, which are storedin the microcode memory and can be updated at runtime.This coding schema is simple and effective. However, formost kernels, only a few FUs are working simultaneouslymost of the time; thus, there are NOPs in most microcodelines. A compression strategy can be used to increase thecode density in the future.

The microcode line format is illustrated in Figure 2. Eachmicrocode for FU has two parts: "Operation” and "ResultDestination.” "Operation” tells the FU what should be done,

and "Result Destination” tells the forwarding logic how toroute the result. At the end of the line is the microcode forthe controller, which takes charge of the microcode fetch anddispatch. There are two types of microcodes for the con-troller: repeat and loop. These two types of microcodes in-struct the controller to repeat or loop to a specific microcodeline at certain times. The MaPU architecture incorporatesthese two special microcodes to support the widespread nestedloop structure in kernel applications.

2.2 Multi-granularity parallel (MGP) mem-ory

As mentioned in previous work [4], memory access pat-terns are an important source for processor’s underuse. How-ever, computation kernels are always structured, and theirmemory access patterns can be classified into a few cate-gories. Therefore, it is highly possible to normalize thesepatterns with a strict data model and special designed mem-ory system.

The MGP memory system serves as a soft managed localmemory system and is designed with an intrinsic data shuf-fle ability, supporting various access patterns. Providing arow- and column-major layout simultaneously for matriceswith common data types, this memory architecture makesthe time-consuming matrix transposition unnecessary. Withthe MaPU data model, matrices in the MGP memory systemcan be treated as normal and transposed forms at the sametime. We explore this feature in more details in Section 3.1.

3. ARCHITECTURE HIGHLIGHTS

3.1 MGP memory systemThe MGP memory system supports various access pat-

terns, especially the simultaneous row- and column-majorlayout for matrices with common data types. Before describ-ing the structure of the MGP memory system, some basicconcepts should be explained.

• Physical bank: On-chip SRAM that can be accessedwith multiple bytes in parallel,which can be generatedfrom a memory compiler or customized.

• Logic bank: a group of physical banks, on which theaddress resolution is based.

• Granularity parameter: the parameter controls whichphysical banks should be grouped into a logic bank andhow the inputted address is resolved.

3.1.1 Basic structure of the MGP memory systemThe MGP memory system provides W bytes of parallel

access and N bytes of capacity and has three interfaces: oneread/write address, a granularity parameter(G) and data forreading or writing. The MGP memory system has the fol-lowing constraints.

• W should be an integer to the power of 2, and N=2kW,where k must be a natural number.

• G should be an integers to the power of 2, ranging from1 to W. That is, G=2k, where 0 ≤ k ≤ log2W .

3

459

3

• W physical banks, labeled from 0 to W-1, are required.Each bank can read/write W bytes in parallel and hasN/W-byte capacity.

When accessed, this memory system operates accordingto the following procedures to decode the address.

1. Logic bank formation: Physical banks cascade andgroup into logic banks according to parameter G. Gconsecutive physical banks labeled with i*G to (i+1)*G-1 cascade into a logic bank i, where 0 ≤ i < W

G .

2. Address mapping: Physical banks in a logic bank areaddressed in sequence, starting from zero. All of thelogic banks have the same address space. As the sizeof each physical memory bank is N/W and there are Gphysical banks in a logic bank, the address of the logicbank ranges from 0 to G*N/W-1.

3. Data access: When reading/writing, each logic bankaccesses only G bytes of the whole W bytes. The ac-cess address is the address inputted into the MGP mem-ory system. Each physical memory bank uses a maskto control this partial access.

Figure 3: MGP memory example that provides W=4bytes of parallel access and with a total capacity of N=64bytes. (a)G=1, address=0, one physical memory bank isgrouped into a logic bank and each logic bank accesses 1byte. (b)G=2, address=0, two physical banks are groupedinto a logic bank and each logic bank accesses 2 bytes.(c)G=4, address=0, four physical banks are grouped intoa logic bank and each logic bank accesses 4 bytes

Figure 3 shows an MGP memory system in which W=4,N=64. With a granularity parameter G, the memory systemcan support log2W+1 types of access patterns. The layoutof physical memories is controlled dynamically by granu-larity parameter G. When G=W, the MGP memory systemhas only one logic bank and all of the physical banks are ad-dressed in sequence. In this case, the memory system fallsinto an ordinary memory system with W bytes accessing theinterface. When combined with carefully designed data lay-outs, the MGP memory system can provide interesting fea-tures such as simultaneous parallel access for matrix rows

and columns. In fact, when writing data into memory withone G value and then reading them with a different G value,we shuffle the data implicitly. Different pairs of G representdifferent shuffle patterns, which makes this MGP memorysystem versatile in handling high dimensional data.

In fact, the MGP memory system is the most distinguish-ing feature of MaPU and other designs may certainly benefitfrom it. Other reconfigurable architectures focus mainly oncomputing fabric, ignoring or compensating for the perfor-mance and power penalties caused by an inefficient memorysystem. MGP memory tries to address the root cause of theproblem. It is not like the scatter/gather-enabled memory inconventional vector processors. In such a scatter/gather op-eration, multiple addresses are sent to memory banks, andaccess conflicts are unavoidable and can lead to pipelinestall, affecting the performance and increasing the complex-ity of pipeline control in turn. MGP memory in MaPU is amathematically structured, conflict-free and vectorized sys-tem. Most vector accessing patterns can be mapped into theMGP memory system, such as accessing a matrix row orcolumn with the same data layout, and reading and writingFFT data for any stage of butterfly diagram. More of the ap-plications that may benefit from MPG memory are exploredlater.

0 5 10 151 6 11 162 73 8

9 14 1920 21 22

23 24

0 1 2 3 45 6 7 8 9

12 13 1415 16 1710 11

18 1920 21 22 23 24

036

147

258

0 12

3 456

7 8

Figure 4: Matrix initial layout when (a): the element’s bitwidth is the same as that of the addressable units and (b)the element’s bit width is twice as that of the addressableunits. The bit width W in this example is 4 bytes. Both(a) and (b) show only the initial layout of the matrix. Theactual layout is controlled by granularity parameter Gwhen this memory is read/written.

3.1.2 Matrix layout in the MGP memory systemAn matrix can be accessed in parallel in row or column or-

der simultaneously only if it is initialized in a specific layoutin the MGP memory system. Figure 4 shows two matricesin with the initial layout can be accessed in either row orcolumn order. Keep in mind that figure 4 shows only thelayout in which the matrices should be initialized. The datalayout will change according to the provided G parameterwhen accessed.

For matrices with elements whose bit widths are the same

4

460

4

as those of the addressable units, the following procedureswould produce the initial layout.

• Set granularity parameter G=1.

• Put the ith row in logic bank i%W. Rows in the samelogic bank should be consecutive.

These procedures generate the initial layout for a 5x5 ma-trix in an MPG memory system with W=4, as shown in Fig-ure 4(a). Providing this data layout, the matrix can be ac-cessed in row order with G=W and accessed in column orderwith G=1. When G=1 and address=0, column elements (0, 5,10, 15) are accessed in parallel. When G=W and address=0,row elements (0, 1, 2, 3) are accessed in parallel.

In fact, a formal expression for the address offset of eachrow during the initialization procedure and the address offsetof each element for the read/write process after initializationcan be derived for general cases. Matrices with elementswhose bit width is M times those of the addressable units,where M is an integer to the power of 2, should be initializedas follows ( providing the capacity of the memory system isN, and the dimension of the matrix is PxQ).

• Set the granularity parameter G=W. (In this case, thereis only one logic bank.)

• The address offset of the ith row is A(i) = [i%(WM )](NM

W )+

( iMW )QM.

Table 1: Address offset for matrix elements (i, j), whichoccupy M memory units. The matrix size is PxQ. Thememory width is W and the total capacity is N.

Access Mode G Address Offset

Row major W (i%WM )NM

W +( iMW )QM+W ( jM

W )Column major M M j+( i

W )QM

When masters access the matrix in the MGP memory sys-tem, they access consecutive W bytes as a whole by row orby column. The address offset for accessing elements (i, j)can be calculated as shown in Table 1. Here, "%"representsthe modulo operation, and all the of divisions operate withno remainder. As masters can only access W bytes as whole,Table 1 shows only the accessing address for these W bytes.The address computation is complicated, but the stride ofthe address is regular. Thus, it is plausible to transverse thewhole matrix with simple address generation hardware.

3.2 High dimension data modelAs mentioned previously, the MGP memory system is ver-

satile in handling high dimensional data, but its address com-putation is complicated and addresses are always not consec-utive. To describe and access high dimensional data in theMGP memory system, a much more expressive data modelother than vectors is required.

Figure 5 shows the basic parameters needed for each di-mension: the base address(KB); the address stride(KS), whichis the address difference between two consecutive elements;and the total number of elements (KI). Figure 6 shows thetwo-dimensional data described by these parameters.

Figure 5: Parameters to describe the dimensions of data

Dimension 1

KB0=1

KB1=1

KS0=3

KS1=8

KI0=3

KI1=4

Dimension 2

Figure 6: Example of high dimensional data description:A4x3 matrix distributed in a 4x8 space.

With this data model, the matrix described in Table 1 canbe configured according to the access modes. All of the baseaddresses of the dimensions are the same as the start addressof the matrix.

When accessed by row, the matrix in the MGP memorysystem can be seen as three-dimensional data. The first di-mension is the elements in a row. As the memory systemaccesses W bytes for a time, the address stride of the dimen-sion is W and the number of elements is QM/W. The seconddimension is the rows between the logic banks, whose ad-dress stride is the size of the logic banks, i.e., NM/W. Thenumber of elements is the number of logic banks, i.e., W/M.The third dimension is the row in the same logic bank, whoseaddress stride is the memory units occupied by a row, i.e.,QM, and the number of elements is PM/W.

When accessed by column, the first dimension is the el-ements in a column, whose address stride is the memoryunits occupied by a row, i.e., QM. The number of elementsis PM/W. The second dimension is the column of the matrix,whose address stride is M, and the total number of elementsis Q.

Table 2 shows the KS and KI configurations of these twoaccess modes.

Table 2: Parameters for a matrix whose size is PxQ. Eachelement occupies M memory units. The memory width isW and the total capacity is N.

Access Mode G KS0 KI0 KS1 KI1 KS2 KI2

Row major W W QMW

NMW

WM QM PM

WColumn major M QM PM

W M Q

In the MaPU architecture, the number of dimensions thatthe chip can support depends on implementations. These

5

461

5

parameters are set by the scalar pipeline. Their values arestored in registers of FUs that take charge of the load/storeoperation. During operation, data are accessed in sequentialgroups where low dimensions are accessed first, followedby the high dimensions. The addresses of these groups arecalculated automatically, like those in DMA operations, ex-cept that the time required to access the data is controlled bymicrocode.

3.3 Cascading pipeline with state-machine-basedprogram model

FUs in the microcode pipeline can cascade into the datapath that suites the algorithms, like the data path in the ASICcontrolled by the state machine. Different storage elementssuch as pipeline registers and caches have different accesstime and energy consumptions for each operation. This cas-cading structure can dramatically decrease data movementbetween register files and memory, thus decreasing the over-all consumed energy. Moreover, keeping the dataflow cen-tralized in FUs and forwarding paths increases the overallcomputation efficiency, as the FUs and forwarding logics arealways running at a higher frequency then caches and mem-ories.

Figure 7 shows this concept for the FFT and matrix mul-tiply algorithms.

Figure 7: Dataflow mapping in MaPU architecture,which can change dynamically through microcode se-quences.

The mapping between the dataflow and data path is repre-sented by a microcode sequence that defines the operationsof the FUs at every clock cycle. As these microcodes arestored in memory and can be updated at runtime, this map-ping can be also updated dynamically.

As hardware does not handle dependency between mi-crocodes, programmer should write the microcodes carefullyto make sure that the result will not come too early or toolate. This involves a great number of effort. MaPU imple-ments a-state-machine based program model to simplify thistask. Programmers only need to describe the state machineof each FU and the time when these state machines should

start. The compiler can then transform these state machinesinto microcode lines that can be emitted simultaneously.

First, the programmer establishes a state-machine-basedprogram description. Sub-state machines for each node areconstructed using the MaPU instruction set, and the top statemachine is then constructed according to the time delay, i.e.,data dependence. Next, according to the micro-architecturefeature of MaPU, the compiler transforms each state ma-chine into an intermediate expression that conveys the se-quential, cyclic or repeated structure of the basic block. Thecompiler then merges the different state machines by ab-stracting their same attributes to generate combinational statemachines and the microcode lines. Finally, the compiler im-plements grammatical structure, resource conflict and datadependence detection to ensure that the microcode lines sat-isfy the MaPU instruction set constraints.

Figure 8 shows the concept of this program model.

S

E

E

S

E

E

S

E

E

S

E

E

SSS SS

State Machine of Each Functional Unit

Figure 8: Illustration of state-machine-based programmodel.

The state machine of each FU is described by microcodesthat the FU supports and microcodes for loop control. Thefollowing code snippet shows an example state machine of aload/store unit.

.hmacro FU1SM//loop to label 1, loop count is stored in KI12 register

LPTO(1f)@(KI12);//load data to Register file and calculate next load address

BIU0.DM(A++, K++)->M[0];NOP; //idle for one cycle

BIU0.DM(A++,K++)->M[0];NOP; //idle for one cycle

1:.endhmicro

The following code snippet shows the top state machine ofthe algorithm.

.hmacro MainSMFU1SM; //start FU1 state machine at cycle 0

REPEAT@(6); // wait six cycles

FU2SM || FU3SM; //start FU2 and FU3 state machine at cycle 7

REPEAT@(6); // wait six cycles

FU4SM; //start FU4 state machine at cycle 13

.endhmicro

6

462

6

4. THE FIRST MAPU CHIPTo prove the advantages of the MaPU architecture, we de-

sign, implement and tape out a chip with four cores that im-plement MaPU the instruction set architecture.

4.1 SoC architectureFigure 9 shows a simplified diagram of this chip. The

Local Memory

Local Memory

Local Memory

Local Memory

Hig

h Sp

eed

Net

wor

kDDR 3

Controller 0 PCIe 0 RapidIO 0DDR 3

Controller 1PCIe 1RapidIO 1

Cortex-A8 ShareMemory

High Speed Network

High Speed Network

Ethernet DDR3Controller GPU CODEC

GPIO

UART

External Bus Interface

I2C/SPI

IIS

Timer

Watch Dog

Interrupt

JTAG

Reset

L2 B

us

L1 Bus

L2 B

us

4x 4x 4x 4x

Figure 9: Simplified SoC structure

MaPU cores in this chip are called APE, which stands forAlgebraic Processing Engine. In addition to the for MaPUcores, there are other subsidiary components like the Cortex-A8 core and IPs. This chip also includes some high-speedIOs like DDR3 Controller, PCIe and RapidIO, and someother low-speed interfaces. All of these components are con-nected by a three-level bus matrix. This chip is implementedwith a TSMC 40-nm low-power process. Figure 10 showsthe final layout. The total area is 363.468mm2.

Figure 11 shows the APE structure. The microcode pipelinein APE runs at 1 GHz an the other components run at 500MHz.There are 10 FUs in each APE, as listed below. Each FU canhandle 512 bits of data in the SIMD manner.

• IALU: for integer computation, with an SIMD abilityfor 8-, 16- and 32-bit data types.

• FALU: for IEEE 754 single and double precision float-ing point computation.

• IMAC: for integer multiply accumulation,with an SIMDability for 8-, 16- and 32-bit data types.

• FMAC: for IEEE 754 single and double precision float-ing point multiply accumulation.

• BIU0,BIU1,BIU2: for load/store operation. Calcu-lates next data address automatically and supports dataaccess with four dimensions.

• MReg: 128x512bit matrix register file with slide win-dow and auto index features.

APE0APE2

APE1 APE3

SRIO

0

SRIO

1

PCIe0 PCIe1

Cortex-A8 IP1 IP0

Phy0 Phy1

GMAC

DD

R3

Con

trol

ler

0

DD

R3

Con

trol

ler

1

BusMatrix

DDR3 Controller

DDD

RD

DR

DD

RD

DR

DDD3

C3

C3

C3

Con

DR

DR

D3

C3

Cnt

rolle

r 1

tttntlll

rollllle

r1111

tttllllll

1113

CD

R3

C1

tll

1

APE0

APE1

DDDDDDDDDDDDDDDD

APE3

Figure 10: Final layout of the chip

Microcode Fetch

Microcode Memory

SHU0

IALU

IMAC

FALU

FMAC

SHU1

Mreg

BIU0

BIU1

BIU2

CSU

Microcode Controller Microcode

PipelineAXI

Interface

AXI Interface

AXI Interface

Scalar Pipeline

DM0DM1

DM2DM3

DM4DM5

SCU SEQ

SYNAGU

J R

Figure 11: APE structure

• SHU0, SHU1: shuffle unit that can extract specificbytes in the source register and write them into the des-tination register in any order.

Some special function units are designed to explore datalocality. Therefore, data flow can be concentrated inside themicrocode pipeline and decrease the load/store operations.For example, SHU can perform cascading shift operations,in which two 512-bit registers are connected and shifted for1, 2 or 4 bytes circularly, just like the sliding window inthe finite impulse response (FIR) algorithm. Combined withlarge matrix register files, the coefficients and input datumneed to load only once in the whole FIR process.

The bus, forwarding matrix and memory system are also512 bits wide. To decrease the scale of the forwarding ma-trix, not all of the FUs are connected. For example, theFMAC result can not be forwarded to the IALU and IMAC.The microcode syntax embodies these constraints. There aresix data memories in total, each of which is an MGP memorysystem, with a 2M bit capacity. The microcode line includes

7

463

7

14 microcodes, each of which is assigned to an FU except forMReg, which requires 4 microcodes. The microcode line is328 bits wide, and the microcode memory (MIM) can hold2,000 microcode lines. To accelerate the turbo decoding pro-cess, we add a dedicated turbo co-processor in APE.

The scalar pipeline is a 32-bit VLIW DSP core that con-tains four FUs :

• SCU: for 32-bit integers and IEEE 754 single precisionfloating point computation.

• AGU: for load/store and register file transfer.

• SYN: for microcode pipeline configuration and con-trol.

• SEQ: for the jump, loop and function call.

These four FUs can run in parallel and the scalar pipelinecan issue four instructions at one cycle. Figure 12 shows thefinal layout of APE. The total area is 36 mm2.

Mul

ti-gr

anul

arity

pa

ralle

l Mem

ory

syst

em

Load/Store &Forwarding

logics

Mul

ti-gr

anul

arity

pa

ralle

l Mem

ory

syst

em

Mic

roco

de

Mem

ory

Scalar Pipeline

SHU0/SHU1

Mem

ory Bus &

Microcode Controller

FMA

C

IMAC MReg

FALUU IALU

FMA

C

IMAC MReg

FALUU IALU

FMA

C

IMAC MReg

FALUU IALU

FMA

C

IMAC MReg

FALUU IALU

FMA

C

IMACMReg

FALUFIALU

FMA

C

IMACMReg

FALUFIALU

FMA

C

IMACMReg

FALUFIALU

FMA

C

IMACMReg

FALUFIALU

Turbo Decoder Turbo Decoder

Mic

roco

de

Mem

ory

Figure 12: Final layout of APE. FMAC, IMAC, FALU,IALU and MReg are distributed in eight blocks, each ofwhich can handle 64 bits of data. The microcode pipelineruns at 1 GHz an the other components run at 500MHzin typical cases.

The tool chain of APE is based mainly on an open sourceframework, as shown in Table 3.

4.2 PerformanceBefore taping out the chip, we simulate many typical sig-

nal processing algorithms in APE with the final RTL andcompare the performance with that of the TI C66x core, acommercial DSP with a similar process node and computa-tion resource. We suppose that APE runs at 1 GHz and thatthe C66x core runs at 1.25Hz. We obtain the performance of

Table 3: MaPU tool chainsTool Name Open Source FrameworkCompiler for microcode pipeline Ragel & Bison & LLVMCompiler for scalar pipeline Clang & LLVMAssembler/Disassembler Ragel & Bison & LLVMLinker Binutils GoldDebugger for scalar pipeline GDBSimulator Gem5Emulator OpenOCD

the C66x core by running an algorithm in Code ComposerStudio (CCSv5) with the official optimized DSP library andimage processing library (DSPLIB and IMGLIB).

Table 4: Complex SP FFT performance ( TimeUnit: us )length 128 256 512 1024 2048 4096C66x 0.65 1.18 2.82 5.49 13.09 26.00APE 0.56 0.88 1.41 2.63 4.75 9.79

Table 4 shows the execution time of a complex single pre-cision floating point FFT algorithm of varying lengths. Ta-ble 5 shows the execution time of a complex 16-bit fixedpoint FFT algorithm. The specific FFT algorithm used hereis cached-fft [6]. In this algorithm, butterflies are dividedinto groups. Each group contains multiple butterflies andstages that can be computed independently without interact-ing with the data in other groups. Thus, a group of butter-flies can be loaded and computed thoroughly without writingback to memory. Figure 13 (a) shows a dataflow diagramof a butterfly group within a complex single floating pointFFT. Figure 13 (b) shows the corresponding data path of theFUs. Although the butterfly in a group can be computed in-dependently, the datum must be shuffled between groups indifferent epochs. This is done naturally using MGP mem-ory. The result of a group is stored back to memory with oneG value after computation and then loaded back to the mi-crocode pipeline with a different G value. The loaded datacan be computed directly without any shuffle operation. Asdifferent pairs of G values are used for the FFT with differentdata types, the memory access pattern matches the data pathperfectly. As result, the overall performance is boosted andthe power is reduced. The original work was implementedwith a dedicated co-processor. In this paper, the algorithm isre-implemented with only microcodes.

The average speedups of APE vs. the C66x core for the SPFFT algorithm are 2.00x and 1.89x, respectively, for a fixedpoint FFT. In fact, we can further improve the performanceof APE through microcode optimization. For example, theexecution time for a 4,096-point 16-bit FFT can be reducedfrom 4.80 us to 4.10 us after further microcode optimization,an improvement of almost 15%. From this example, we cansee that MaPU has a huge performance potential with cus-tomized state machines.

We implement other typical algorithms with the same FFTstrategies, in which the data path resembles the dataflow andMGP memory provides the matched access patterns. Table 6summarizes the average speedups of APE vs. C66x for thesealgorithms. These algorithms have different data types and

8

464

8

MR2

BIU0/2 BIU1

MReg

SHU1 SHU0

FMACFALU

BIU0/2

DM0/4 DM1

DM0/4

MR0MR1

(a) FFT butterfly diagram, each cross indicates a butterfly

(b) Cascading pipeline for FFT, multiple stages of butterfly are computed before write the

result back to memory

Dat

a re

ad fr

om m

emor

y

Dat

a w

rite

to m

emor

y

Figure 13: FFT dataflow diagram and data path map-ping in APE.

Table 5: 16-bit complex fixed point FFT performance (TimeUnit: us )

length 256 512 1,024 2,048 4,096C66x 0.60 1.33 2.59 5.91 12.03APE 0.56 0.79 1.50 2.41 4.80

dataflow. However, given the cascading pipeline and intrin-sic shuffle abilities of MGP memory, all of them are mappedsuccessfully in APE, and their performance is quite impres-sive. APE has hundreds of speedups for table lookups dueto its SHU units, which can handle 64 parallel queries for atable with 256 records within 5 cycles. Taking the frequencyof both processors into consideration, APE has more advan-tages in terms of architecture as it runs at a lower frequencybut performs better.

4.3 Power efficiencyBefore taping out the chip, we estimate the power of APE

using Prime Time with various algorithms. The switchingactivity is generated through the final post-simulation withthe final netlist and SDF annotation. We also test the powerof APE when the chip returns from fab. As in the SoC, thereare dedicated power domains and clock gates for AP. As wecan turn on the power supply and clock for each APE sep-arately, the power of each APE can be measured preciselyby the power increase when it is invoked. Table 7 shows thepower data of the typical algorithm. The data types of eachalgorithm are the same in Table 6.

All of the used micro-benchmarks are held in on-chip mem-ory, but the overall amount of power consumed by memoryis small. The number of DMs in APE is designed for scal-ability. For benchmarks that exceed the size of DM, three

Table 6: APE vs. C66x core: Actual performance com-parison

Algorithm Speedup Data Types

Cplx SP FFT 2.00 Complex single floating pointCplx FP FFT 1.89 Complex 16-bit fixed pointMatrix mul 4.77 Real single floating point2D filter 6.94 Real 8-bit fixed pointSP FIR 6.55 Real single floating pointTable lookup 161.00 table with 8bit address, 256 recordsMatrix Trans 6.29 16bit matrix

Table 7: Estimated and Tested Power of APE at 1GHz(PowerUnit : Watt)

Algorithm Est Tested Diff Size

Cplx SP FFT 2.81 2.95 -5% 1,024Cplx FP FFT 2.63 2.85 -8% 1,024Matrix Mul 3.05 3.10 -2% 65*66, 66*67 matrix2D Filter 4.13 4.15 -1% 508*508, 5*5 templateFIR 2.19 2.20 -1% 4,096, 128 coefficientsTable lookup 2.75 2.95 -7% 4,096 queriesMatrix Trans 2.28 2.45 -7% 512*256 matrixIdle 1.51 1.55 -2% While APE stand by

of the six DMs can be used for computation buffers, and theother three DMs can be used for DMA transfers. The aggre-gated power of all of the MGP memories (six DMs in Figure13) for benchmarks in Table 7 (in order, except for Idle) are8%, 6%, 3%, 3%, 2%, 3% and 15%, respectively. The 15%is for matrix transpose, which consists entirely of memoryread/write operations. Taking DMA transfers into consider-ation, the energy efficiency will degrade slightly but remainalmost the same as the presented result.

We can see clearly from the table that the power consump-tion of most of the algorithms is below 3 W and that thestandby power of APE is as high as 1.55 W. Preliminaryanalysis indicated that the clock network contributed mostof the idle power, which will require improvement in future.It is also can be seen from Table 7 that the estimated andmeasured power are almost the same. This indicates that ourpower evaluating method is effective and our module basedpower analysis discussed later is highly reasonable.

To compute the actual dynamic power efficiency of APE,we collect detailed instructions statistics. Table 8 shows thenumber of microcodes issued when APE runs different al-gorithms. The data type and size are the same as in Table7.

Based on the microcode statistics in Figure 8, we knowhow many data operations are needed to complete an algo-rithm. We obtain the actual GFLOPS or GOPS of APE fordifferent algorithms by dividing the number of operationswith corresponding execution times. The corresponding ac-tual GFLOPS/W and GOPS/W are computed by dividingGFLOPS or GOPS with the power, as show in Figures 14and 15.

The computation operations include IALU, IMAC, FALU,FMAC and SHU0, SHU1(each MAC instruction is consid-ered as two operations) and the total operations includescomputation, register file read/write and load/store opera-tions.

Figure 14 shows that the maximum actual computationperformance of APE for floating point application is 64.33GFLOPS with the SP FIR algorithm. The maximum actualcomputation performance for the fixed point is 255.21 GOPSwith an 8-bit 2D filter application.

When taking power into account, the maximum actual to-tal power efficiency of APE for floating point application is45.69 GFLOPS/W with the SP FFT algorithm. The max-imum actual total power efficiency across all of the algo-rithms is 103.49 GOPS/W with a 2D filter application, asshown in Figure 15.

Table 9 summarizes the energy efficiency of several pro-

9

465

9

Table 8: Microcode statistics for different algorithmsAlgorithm MR0 MR1 MR2 MR3 SHU0 SHU1 IALU IMAC FALU FMAC BIU0 BIU1 BIU2

Cplx SP FFT 1,908 1,841 1,888 12 1,878 1,836 0 0 1,771 1,847 807 746 832Cplx FP FFT 942 930 897 10 894 894 0 885 0 0 255 193 288Matrix mul 29,478 0 0 1,650 29,478 0 0 0 12,854 29,476 1,650 488 7,4512D filter 20,336 20,336 0 0 105,740 105,740 0 105,737 0 0 8,703 20,344 7,599FIR 2,048 2,049 0 0 34,817 34,817 0 0 1,792 34,817 265 2,048 511Table lookup 258 192 128 0 257 0 320 0 0 0 4 64 64Matrix tran 0 0 0 4,098 0 0 0 0 0 0 4,099 0 4,096

Figure 14: Actual Performance of APE for different al-gorithms. The units are GFLOPS for floating point ap-plication and GOPS for fixed point application.

Table 9: Estimated performance of current proces-sors[7].

Processor Process GFLOPS GLOPS/WCore i7 960 45nm 96 1.2Nvidia GTX280 65nm 410 2.6Cell 65nm SOI 200 5.0Nvidia GTX480 40nm 940 5.4Stratix IV FPGA 40nm 200 7.0TI C66x DSP 40nm 74 7.4Xeon Phi 7210D 22nm 2,225 8.2Tesla K40(+CPU) 28nm 3,800 10.0Tegra K1 28nm 290 26.0MaPU Core 40nm 134 45.7

cessors, as presented in [7]. From this table and the datapresented in [4], we can see that the peak energy efficiencyof GPGPU and processors are below 10 GFLOPS/W. Theactual maximum energy efficiency of APE is around 40-50GLFOPS/W, a 4x to 5x improvement for the floating pointapplications and a 10x improvement for the fixed point ap-plications.

4.4 DiscussionIn addition to the instruction statistics in Table 8, we gather

the power data for each individual module through detailedsimulation. With the microcode count and power, we can es-timate the average dynamic energy consumed per microcode,as presented in Table 10. Table 7 shows the estimated andtested power from real chip are very close, thus the powerstatistics here that based on simulation are highly reliable.

Figure 15: Actual power efficiency tested from real chip.The units are GFLOPS/W for floating point applicationand GOPS/W for fixed point application.

The result is calculated as follows:

(Running Power− Idle Power)∗TimeInstruction Count

(1)

The average load/store energy includes the load/store unit,data bus and memory. Table 10 clearly shows that the regis-ter file access is mostly energy efficiency. The energy con-sumed by most of the computation FU is almost half that ofthe load/store unit, except for IMAC, which requires furtherimprovement.

Figure 16: Microcode composition for different algo-rithms. MReg access includes microcodes for MR0-MR3; computation includes microcodes for SHU, IALU,IMAC, FMAC and FALU; load/store includes mi-crocodes for BIU0-BIU2.

10

466

10

Table 10: Dynamic energy consumed per microcodeAlgorithm Energy Per Microcode ( Unit : pJ, 512 bit)Register R/W 133.25Load/Store 609.20FALU 345.65IALU 335.18FMAC 387.23IMAC 788.77SHU 213.04

As the energy consumed by FUs is much less than thatconsumed by load/store operations, it is reasonable to keepdata moving between FUs through cascading pipelines asmuch as possible. Figure 16 shows microcode compositionsfor different algorithms. Using the MGP memory systemand cascading pipelines, typical algorithms can be mappedinto structured data paths in which the operations mainlycomprise register file access and computation operations, whichconsume much less energy than the load/store operations.

Figure 17 further shows the average usage and average en-ergy consumption for different components when APE runsalgorithms in Table 7, except for matrix transpose. A trendcan be seen in Figure 17: the register file access opera-tion consumes much less energy than the load/store opera-tions but is used much more, and the computation units areused much more than the file registration and memory units.As such, the energy-efficient FUs are used much more fre-quently than the energy-inefficient FUs.

This is an important factor that contributes to the remark-able energy efficiency of MaPU. Power efficiency benefitsfrom two aspects. The first aspect is the novel micro archi-tecture. MaPU consists of massive FUs but simple controllogic. As in ASIC, most of the energy is consumed by FUsthat do the real computations, and energy-hungry operationssuch as memory access are minimized through MPG mem-ory systems. Therefore, it is possible to achieve high powerefficiency in MaPU. In particular, instruction fetching anddispatching logic consume only 0.18% power, and FUs con-sume up to 53% power in the FFT benchmark.

The second aspect is the elaborately optimized algorithmof MaPU. To achieve outstanding power efficiency, data lo-cality should be explored at the algorithm level and statemachines should be constructed in a manner that central-izes data movements in the FUs and forwarding matrix. Fig-ure 17 indicates that benchmarks have been mapped mostlyinto the computation and register file access operations. Aspower-consuming load/store operations are only a small partof the overall operations, power consumption is reduced over-all.

Great efforts have been made to optimize the micro bench-marks presented in this paper. Although the state-machine-based program model has simplified the optimization pro-cess, it would take about one month to implement a kernelon MaPU for those familiar with the micro-architecture. Wedevelop an informal flow to facilitate the optimization pro-cess. We would like to explore this flow more thoroughly inthe near future and hope to develop a more convenient andhigh-level program mode based on the one adopted in thispaper.

Figure 17: Average usage and energy consumption of dif-ferent components

5. RELATED WORKIn general, MaPU can be classified into CGRA and vec-

tor processors. One principle under MaPU involves mappingthe computation graph into a reconfigurable fabric while map-ping the data accessing pattern into an MGP memory sys-tem. The computation mapping of MaPU is similar to DySER[8].However, MaPU uses a crossbar-based forwarding logic ratherthan a switching network. Furthermore, the reconfigurationfabric and computation sub-region in DySER is more like aninstruction extension to the scalar pipeline. The reconfigura-tion fabric and microcode pipeline in MaPU is a standaloneprocessor core that can execute kernel algorithms such asmatrix multiply and 2D filter algorithms. MaPU is not likeGARP [9]and SGMF[10]. GARP uses fine-grained reconfig-urable arrays to construct FUs such as adders and shifters ina way that resembles FPGA. MaPU uses FUs to map high-level algorithms. At the same time, MaPU has no threadconcept and thus no data dependence handling logic. This isdifferent from SGMF[10].

The power efficiency of computer architecture has becomemore and more important in recent years. Voltage and fre-quency adjustments and clock gating are two main techniquesused to decrease the power of previous processors[11]. How-ever, although chips are integrating far more transistors thanbefore, their total power is still strictly constrained. Onlya few parts of the chip can be lighted, which leads to theidea of using so-called dark silicon [12]. In this new designregime, heterogeneous architectures have been proposed inwhich some general-purpose cores are augmented by manyother cores and accelerators of different micro-architectures[13].GreenDroid[14] is such an aggressive dark silicon proces-sor with great power efficiency. Although the dedicated co-processor c-core in this chip can be reconfigured after man-ufacture, its compatibility with algorithm updates presents aconcern for programmers.

Some other customized processors that aim at power ef-ficiency are less aggressive. Most of them focus mainly onimproving data path computation, such as by adding a vec-tor processing unit[7][1], adding chained FUs[7] and addingspecialized instructions[2][15]. Although improvements havebeen made through these techniques, they are limited bytheir memory access efficiency.

11

467

11

Transport triggered architecture possesses many advan-tages including modularity, flexibility and scalability. Itslow-power potential is exploited in [16] but mainly focuseson compiler optimization and the reduction of register fileaccess.

As clock distribution networks consume around 20-50%of the total power in a synchronous circuit[17], an asyn-chronous circuit is considered an alternative to build low-power processors[18]. However, asynchronous circuits aredifficult to design, and related EDA tools are far from matureand may only be successful in special chips such as neuro-morphic processors [19].

6. CONCLUSIONThe novel MaPU architecture is presented in this paper.

With an MGP memory system, cascading pipeline and state-machine-based program model, this architecture possessesgreat performance and energy potential for computation in-tensive applications. A chip with four MaPU cores is de-signed, implemented and taped out following a TSMC 40-nm low-power process. The performance and power of thechip are fully analyzed and compared with other processors.Although the implementation of the first MaPU chip can befurther improved, the results indicate that MaPU processorscan provide a performance/power efficiency improvement10 times higher than the traditional CPU and GPGPU.

The first MaPU chip presented here is only an example ofthe MaPU architecture. Designers can easily implement thisarchitecture in specific domains through customized FUs.

Great efforts are needed in programming MaPU. Althougha low-level state-machine-based programming model has beenproposed, we hope to develop a more efficient model at ahigh level. Furthermore, we are also trying to implementa heterogeneous computing framework such as OpenCL onMaPU, which would hide all of the hardware complexity andprovide efficient runtimes and libraries designed for specificdomains. In addition, we are now working hard to constructrelevant wiki pages and make detailed documentation andtools available to the open source community.

7. ACKNOWLEDGEMENTThis work is supported by the Strategic Priority Research

Program of Chinese Academy of Sciences (under Grant XDA-06010402).

8. REFERENCES[1] B. Barry, C. Brick, F. Connor, D. Donohoe, D. Moloney,

R. Richmond, M. O’Riordan, and V. Toma, “Always-on visionprocessing unit for mobile applications,” IEEE Micro, no. 2,pp. 56–66, 2015.

[2] L. Codrescu, W. Anderson, S. Venkumanhanti, M. Zeng, E. Plondke,C. Koob, A. Ingle, C. Tabony, and R. Maule, “Hexagon dsp: Anarchitecture optimized for mobile multimedia and communications,”Micro, IEEE, vol. 34, no. 2, pp. 34–43, 2014.

[3] D. Parello, O. Temam, and J. M. Verdun, “On increasing architectureawareness in program optimizations to bridge the gap between peakand sustained processor performance - matrix-multiply revisited,” inSC Conference, pp. 31–31, 2002.

[4] A. Sethia, G. Dasika, T. Mudge, and S. Mahlke, “A customizedprocessor for energy efficient scientific computing,” Computers,IEEE Transactions on, vol. 61, no. 12, pp. 1711–1723, 2012.

[5] V. V. Zyuban and P. M. Kogge, “Inherently lower-powerhigh-performance superscalar architectures,” Computers, IEEETransactions on, vol. 50, no. 3, pp. 268–285, 2001.

[6] B. M. Baas, “A low-power, high-performance, 1024-point fftprocessor,” Solid-State Circuits, IEEE Journal of, vol. 34, no. 3,pp. 380–387, 1999.

[7] M. H. Ionica and D. Gregg, “The movidius myriad architecture’spotential for scientific computing,” Micro, IEEE, vol. 35, no. 1,pp. 6–14, 2015.

[8] V. Govindaraju, C.-H. Ho, and K. Sankaralingam, “Dynamicallyspecialized datapaths for energy efficient computing,” in HighPerformance Computer Architecture (HPCA), 2011 IEEE 17thInternational Symposium on, pp. 503–514, Feb 2011.

[9] J. Hauser and J. Wawrzynek, “Garp: a mips processor with areconfigurable coprocessor,” in Field-Programmable CustomComputing Machines, 1997. Proceedings., The 5th Annual IEEESymposium on, pp. 12–21, Apr 1997.

[10] D. Voitsechov and Y. Etsion, “Single-graph multiple flows: Energyefficient design alternative for gpgpus,” in Computer Architecture(ISCA), 2014 ACM/IEEE 41st International Symposium on,pp. 205–216, June 2014.

[11] S. Kaxiras and M. Martonosi, “Computer architecture techniques forpower-efficiency,” Synthesis Lectures on Computer Architecture,vol. 3, no. 1, pp. 1–207, 2008.

[12] M. B. Taylor, “A landscape of the new dark silicon design regime,”Micro, IEEE, vol. 33, no. 5, pp. 8–19, 2013.

[13] M. Själander, M. Martonosi, and S. Kaxiras, “Power-efficientcomputer architectures: Recent advances,” Synthesis Lectures onComputer Architecture, vol. 9, no. 3, pp. 1–96, 2014.

[14] N. Goulding-Hotta, J. Sampson, S. Swanson, M. B. Taylor,G. Venkatesh, S. Garcia, J. Auricchio, P.-C. Huang, M. Arora,S. Nath, V. Bhatt, J. Babb, S. Swanson, and M. B. Taylor, “Thegreendroid mobile application processor: An architecture forsilicon’s dark future,” IEEE Micro, no. 2, pp. 86–95, 2011.

[15] S. Z. Gilani, N. S. Kim, and M. J. Schulte, “Power-efficientcomputing for compute-intensive gpgpu applications,” in HighPerformance Computer Architecture (HPCA2013), 2013 IEEE 19thInternational Symposium on, pp. 330–341, IEEE, 2013.

[16] Y. He, D. She, B. Mesman, and H. Corporaal, “Move-pro: a lowpower and high code density tta architecture,” in EmbeddedComputer Systems (SAMOS), 2011 International Conference on,pp. 294–301, IEEE, 2011.

[17] F. H. Asgari and M. Sachdev, “A low-power reduced swing globalclocking methodology,” Very Large Scale Integration (VLSI)Systems, IEEE Transactions on, vol. 12, no. 5, pp. 538–545, 2004.

[18] M. Laurence, “Introduction to octasic asynchronous processortechnology,” in Asynchronous Circuits and Systems (ASYNC), 201218th IEEE International Symposium on, pp. 113–117, IEEE, 2012.

[19] J.-s. Seo, B. Brezzo, Y. Liu, B. D. Parker, S. K. Esser, R. K. Montoye,B. Rajendran, J. Tierno, L. Chang, D. S. Modha, and D. J Friedman,“A 45nm cmos neuromorphic chip with a scalable architecture forlearning in networks of spiking neurons,” in Custom IntegratedCircuits Conference (CICC), 2011 IEEE, pp. 1–4, IEEE, 2011.

12

468

12