Satyajit Das

Kevin J M Martin

Davide Rossi

Philippe Coussy

Luca Benini

An Energy-Efficient Integrated Programmable Array Accelerator and Compilation flow for Near-Sensor Ultra-low Power Processing

Keywords: CGRA, compilation, control flow, CDFG, ultralow power accelerator, computer architecture

In this paper we give a fresh look to Coarse Grained Reconfigurable Arrays (CGRAs) as ultra-low power accelerators for near-sensor processing. We present a general-purpose Integrated Programmable-Array accelerator (IPA) exploiting a novel architecture, execution model, and compilation flow for application mapping that can handle kernels containing complex control flow, without the significant energy overhead incurred by state of the art predication approaches. To optimize the performance and energy efficiency, we explore the IPA architecture with special focus on shared memory access, with the help of the flexible compilation flow presented in this paper. We achieve a maximum energy gain of 2×, and performance gain of 1.33× and 1.8× compared with state of the art partial and full predication techniques, respectively. The proposed accelerator achieves an average energy efficiency of 1617 MOPS/mW operating at 100MHz, 0.6V in 28nm UTBB FD-SOI technology, over a wide range of near-sensor processing kernels, leading to an improvement up to 18×, with an average of 9.23× (as well as a speed-up up to 20.3×, with an average of 9.7×) compared to a core specialized for ultra-low power near-sensor processing.

I. INTRODUCTION

D UE to the increasing complexity of near-sensor data analytics algorithms, low power embedded applications such as Wireless Sensor Networks (WSN), Internet of Things (IoT), and wearable sensors combine the requirement of high performance and extreme energy efficiency in a mW power envelope [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF]. While traditional ultra-low power sensor processing circuits rely on hardwired Application Specific Integrated Circuit (ASIC) architectures [START_REF] Dehyadegari | Architecture support for tightly-coupled multi-core clusters with shared-memory hw accelerators[END_REF], near-threshold parallel computing is emerging as a promising solution [START_REF] Rossi | A 60 GOPS/W, -1.8 V to 0.9 V body bias ULP cluster in 28 nm UTBB fd-soi technology[END_REF]. Even though this approach provides maximum flexibility, a dominating majority of the power consumed during processing is linked to the typical overheads of instruction processors [START_REF] Gautschi | Near-Threshold RISC-V Core With DSP Extensions for Scalable IoT Endpoint Devices[END_REF], such as instruction fetching and decoding, control and data-path pipeline overheads (up to 40%), load/store overhead (up to 30%). In this work, we make significant step forward in parallel near-threshold computing toward the goal of achieving the energy efficiency of application-specific data-paths, by exploiting the Coarse Grain Reconfigurable Array (CGRA) architectural template, and revisiting it to fit within an ultralow power (mW) power envelope.

CGRAs have been intensely investigated in the past for applications with power consumption profiles ranging from mobile (hundreds of mW) [START_REF] Sutter | Coarse-Grained Reconfigurable Array Architectures[END_REF] to high performance (hundreds of W) [START_REF] Madhu | Compiling HPC Kernels for the REDEFINE CGRA[END_REF]. In this paper, we focus on a CGRA architecture in the mW range (and below). Very few CGRA architectures have been pushed in this ultra-low power mission profile [START_REF] Masuyama | A 297mops/0.4 mw ultra low power coarse-grained reconfigurable accelerator CMA-SOTB-2[END_REF] [48] [START_REF] Donohoe | Reconfigurable data path processor[END_REF]. Our CGRA is designed to work as an accelerator of an ultra-low power PULP processor cluster [START_REF] Rossi | A 60 GOPS/W, -1.8 V to 0.9 V body bias ULP cluster in 28 nm UTBB fd-soi technology[END_REF], sharing L1 memory with the processors. Hence, another major challenge in this context is achieving efficient L1 memory sharing [START_REF] Rossi | A 60 GOPS/W, -1.8 V to 0.9 V body bias ULP cluster in 28 nm UTBB fd-soi technology[END_REF]. To reduce memory access contention, it is necessary to have enough banks in the shared memory. On the other hand, the number of ports into the multi-banked shared-L1 memory logarithmic interconnect must be tightly constrained to avoid significant area and power overheads [START_REF] Rahimi | A fully-synthesizable single-cycle interconnection network for shared-l1 processor clusters[END_REF].

To cope with the ultra-low power profile and memory sharing challenges we build upon the Integrate Programmable-Array accelerator (IPA) concept proposed in [START_REF] Das | A 142 mops/mw integrated programmable array accelerator for smart visual processing[END_REF] involving a multi-bank Tightly Coupled Data Memory (TCDM) coupled with a flexible and configurable memory hierarchy for data storage. As shown in Fig. 1, from an architectural viewpoint, point-to-point data communication between processing elements (PEs) during kernel execution, represents a key advantage over energy-hungry data sharing over shared memory that is required when using a traditional processorcluster architecture for parallel processing. The IPA cluster performs a lower number of memory operations on the sample program presented in the Fig. 1(c), which in turn gives and energy improvement of 1.3× over the clustered multi-core architecture, which performs data sharing through the TCDM. In this comparison, we even ignore the barrier synchronization overheads in the many-core cluster for the sake of simplicity.

The IPA approach allows to significantly reduce the pressure on L1 memory, and hence the complexity of the interconnect between the PEs and the memory banks, since it requires a smaller number of banks to achieve low contention [START_REF] Rossi | A 60 GOPS/W, -1.8 V to 0.9 V body bias ULP cluster in 28 nm UTBB fd-soi technology[END_REF]. On the other hand, as opposed to clustered multi-core architectures, where data-exchange among cores is managed through

B[0] B[1] C[0] C[1] B[0] B[1] C[0] C[1]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * Load Load S to re Store L o ad L o a d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + Load Load 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

* M O V M O V
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [START_REF] Chen | Graph minor approach for application mapping on cgras[END_REF] for CGRAs deal only with the straight-line code sequence (basic block) of the innermost loop of a kernel. In case of conditional present in the innermost loop, the compilers use predication [START_REF] Rakossy | Design and synthesis of reconfigurable controlflow structures for cgra[END_REF] techniques to convert the control flows into data flow structures. Indeed, these compilers can only generate code to execute a single loop, as a set of pipelined stages is repeatedly executed up to a certain number (loop boundary / number of pipelined stages) specified by the compiler. In case of nested loops, only the innermost loop is accelerated using a CGRA, leaving the outer loops for the host processor. However, this approach requires several offloads by the host, which implies additional memory-mapped I/O operations for synchronization and communication with the CGRA. Hence, it causes significant overhead, especially when the innermost loop has a very small number of iterations, which is a typical scenario for nearsensor processing applications [START_REF] Song | Unroll-and-jam for imperfectly-nested loops in dsp applications[END_REF].

+ Load Load A[0] A[1] Load Load A[0] A[1] (c) (d)
On the other hand, large CGRA architectures for high performance computing have frequently resorted to predication techniques to expose parallelism across control dependencies, such as conditionals [START_REF] Rakossy | Design and synthesis of reconfigurable controlflow structures for cgra[END_REF] [START_REF] Chang | Mapping control intensive kernels onto coarsegrained reconfigurable array architecture[END_REF]. Unfortunately, predication leads to waste of resources and it is hard to justify in an extremely power and area constrained scenario [START_REF] Yin | Acceleration of nested conditionals on cgras via trigger scheme[END_REF]. In this paper, we address the above challenges by proposing a novel compilation flow tailored for our ultra-low power IPA architecture. This flow enables the execution of multiple loops and conditionals starting from ANSI C code, relying on the energy efficient register allocation approach presented in [START_REF] Das | Efficient mapping of CDFG onto coarse-grained reconfigurable array architectures[END_REF].

In a nutshell, this paper contributes to the two critical aspects of energy-efficient application mapping onto CGRAs. First, we carry out an architectural exploration, based on the IPA proposed in [START_REF] Das | A 142 mops/mw integrated programmable array accelerator for smart visual processing[END_REF], for optimizing performance and energy efficiency. The IPA features full support for conditional operations, exploits the internal registers of the PEs for intermediate data exchange and relies on a multi-bank TCDM only for accesses to input/output buffers, significantly improving energy efficiency. Second, we describe a complete compilation flow to map kernels with multiple loop nests and conditionals onto the IPA. The flow helps releasing the host processor from performing the computation of the outer loops, significantly improving performance of the IPA. It also achieves high energy efficiency by minimizing the number of memory operations exploiting the features of the architecture.

To quantify the efficiency of IPA architecture and compilation flow, we compare the performance and energy consumption with the state of the art predication methods running on the IPA. Experimental results on a benchmark set of control intensive kernels show that the register allocation approach achieves a maximum of 1.33× (with minimum of 1.04× and average of 1.13×) and 1.8× (with minimum of 1.37× and average of 1.59×) performance gain compared to partial predication and full predication techniques. For what concerns shared-L1 memory access optimization, our exploration shows that a banking factor of 0.5 (i.e. 8 LSUs, 4 TCDM banks) provides the optimal configuration in terms of performance and energy for a IPA configuration with 4x4 PEs. Moreover, the IPA features a very regular control and data-path structure, which is suitable for fine-grained power management. We exploit this architectural regularity to design a fine-grained clock gating mechanism, which turns into an average 2× energy efficiency boost with respect to the non-clock-gated IPA. Results show that the IPA achieves a maximum speed up of 20.3×, with an average of 9.7× compared to one or1k processor [START_REF] Gautschi | Tailoring instruction-set extensions for an ultra-low power tightly-coupled cluster of openrisc cores[END_REF] 1 , with an area ratio of just 1.6×. The average energy efficiency achieved by the IPA operating at 0.6V is 1617 MOPS/mW, which is up to 18× and on average 9.23× better than what is achieved by the processor.

The rest of this paper is organized as follows. In Section II, the background and related work are discussed. In section III, the target architecture, memory hierarchy and the execution model are described. Section IV focuses on presenting the full compilation flow, with the support of required definitions, and models. Section V presents the implementation and experimental results. Finally, the paper is concluded in Section VI.

II. BACKGROUND AND RELATED WORK

Much research has been done to evaluate the performance, power, and cost of CGRAs [START_REF] Sutter | Coarse-Grained Reconfigurable Array Architectures[END_REF]. In this paper, we focus on the energy efficiency aspects of both architecture and compiler.

A. Architecture

While targeting low power execution, data and context management is of utmost importance. Integration of CGRAs as accelerators with the data and instruction memory has seen several solutions over the past years [START_REF] Sutter | Coarse-Grained Reconfigurable Array Architectures[END_REF].

In many low-power targeted CGRAs [3][39][48] [START_REF] Kim | Ulpsrp: Ultra low-power samsung reconfigurable processor for biomedical applications[END_REF], memory operations are managed by the host processor. Among these architectures, Ultra-Low-Power Samsung Reconfigurable Processor (ULP-SRP) and Cool Mega Array (CMA) operate in ultra-low-power (up to 3 mW) range. In these architectures, PEs can only access the data once prearranged in the shared register file by the processor. For an energy efficient implementation, the main challenge for these designs is to balance the performance of the data distribution managed by the CPU, and the computation in the PE array. However, in several cases, the computational performance of the PE array is compromised by the CPU, due to large synchronization overheads. For example, in ADRES [START_REF] Bouwens | Architectural exploration of the adres coarse-grained reconfigurable array[END_REF] the power overhead of the VLIW processor used to handle the data memory access is up to 20%. In CMA [START_REF] Ozaki | Cool megaarray: A highly energy efficient reconfigurable accelerator[END_REF] the host CPU feeds the data into the PEs through a shared fetch register (FR) file. This is very inefficient in terms of flexibility.

The key feature of this architecture is the possibility to apply independent DVFS [START_REF] Su | Body bias control for a coarse grained reconfigurable accelerator implemented with silicon on thin box technology[END_REF] or body biasing [START_REF] Masuyama | A 297mops/0.4 mw ultra low power coarse-grained reconfigurable accelerator CMA-SOTB-2[END_REF] to balance array and controlling processor parameters to adjust performance and bandwidth requirements of the applications. The highest reported energy efficiency for CMA is 743 MOPS/mW on 8bit kernels, not considering the overhead of the controlling processor, which is not reported. With respect to this work, which only deals with DFG described with a customized language, we target 32-bit data and application kernels described in C language, which are mapped onto the array using an endto-end C-to-CGRA compilation flow.

In architectures such as, MorphoSys [START_REF] Singh | Morphosys: an integrated reconfigurable system for dataparallel and computation-intensive applications[END_REF], RSPA [START_REF] Kim | Resource sharing and pipelining in coarse-grained reconfigurable architecture for domainspecific optimization[END_REF], Smart-Cell [START_REF] Liang | Smartcell: An energy efficient coarse-grained reconfigurable architecture for stream-based applications[END_REF], PipeRench [START_REF] Goldstein | Piperench: A reconfigurable architecture and compiler[END_REF], SIMD-CGRA [START_REF] Duch | Heal-wear: An ultra-low power heterogeneous system for bio-signal analysis[END_REF], load-store operations are managed explicitly by the PEs. Data elements in these architectures are stored in a shared memory with one memory port per PE row. The main disadvantages of such data access architecture are: (a) lots of contention between the PEs on the same row to access the memory banks, and (b) expensive data exchange between rows through complex interconnect networks within the array. With respect to these architectures, our approach minimizes contention by exploiting a multi-banked shared memory with word-level interleaving. In this way data-exchange among tiles can be performed either through the much simpler point-to-point communication infrastructure or fully flexible shared TCDM.

NASA's Reconfigurable Data-Path Processor (RDPP) [START_REF] Donohoe | Reconfigurable data path processor[END_REF], and Field Programmable Processor Array (FPPA) [START_REF] Donohoe | Field programmable processor array: Reconfigurable computing for space[END_REF] are targeted for low-power stream data processing for spacecrafts. These architectures rely on control switching [START_REF] Donohoe | Reconfigurable data path processor[END_REF] of data streams, and synchronous data flow computational model avoiding investment on memories and control. On the contrary, the IPA is tailored to achieve energy-efficient near sensor processing of data with workloads very different from the stream data processing.

Table I summarizes an overview of the jobs managed by CGRA and the host processor for different architectural approaches. Acceleration of the kernels involves memory operations, innermost loop computation, outer loop computation, offload and synchronization with the CPU. As shown in the table, IPA manages to execute both the innermost and outer loops, and the memory operations of a kernel imposing least communication and memory operation overhead while synchronizing with the CPU execution.

With respect to these state of the art reconfigurable ar-rays and array of processors, this paper introduces a highly energy efficient, general-purpose IPA accelerator where PEs have random access to the local memory, and execute full control and data flow of kernels on the array starting from a generic ANSI C representation of applications [START_REF] Das | Efficient mapping of CDFG onto coarse-grained reconfigurable array architectures[END_REF]. This paper also focuses on the architectural exploration of the proposed IPA accelerator [START_REF] Das | A 142 mops/mw integrated programmable array accelerator for smart visual processing[END_REF], with the goal to determine the optimal configuration of number of LSUs and number of banks for the shared L1 memory. Moreover, we employ a fine-grained power management architecture to eliminate dynamic power consumption of idle tiles during kernels execution which provides 2× improvement of energy efficiency, on average. The globally synchronized execution model, low cost but fullflexible programmability, tightly coupled data memory organization, and fine-grained power management architecture define the suitability of the proposed architecture as an accelerator for ultra-low power embedded computing platforms.

B. Compilation

To map the loops, state of the art compilers for CGRA mostly rely on software pipelining [19] [37] [40]. This approach can manage to map the innermost loop body in a pipelined manner. On the other hand, for the outer loops, CPU must initiate each iteration in the CGRA, which causes significant overhead in the synchronization between the CGRA and CPU execution. Liu et al in [START_REF] Liu | Polyhedral model based mapping optimization of loop nests for cgras[END_REF] pinpointed this issue and proposed to map maximum of two levels of loops using polyhedral transformation on the loops. However, this approach is not generic as it cannot scale to an arbitrary number of loops. Some approaches [START_REF] Liu | Automatic nested loop acceleration on fpgas using soft CGRA overlay[END_REF] [27] use loop unrolling for the kernels. The basic assumption for these implementations is that the innermost loops trip count is not large. Hence, the solutions end up doing partial unroll of the innermost loops. The outer loops remain to be executed by the host processor. As most of the proposed compilers handle innermost loop of

√ √ × × Full predication [1] √ √ × × State based full predication [21] √ √ × × Dual issue single execution [20] √ × × × TLIA [32] √ √ √ × Software pipelining [37] × × √ × Loop unrolling [27] × × √ NA Register allocation [8] √ √ √ √
the kernels, they mostly bank upon the partial predication [START_REF] Chang | Mapping control intensive kernels onto coarsegrained reconfigurable array architecture[END_REF] and full predication [1] techniques to map the conditionals inside the loop body.

Partial predication maps instructions of both if-part and elsepart on different PEs. If both the if-part and the else-part update the same variable, the result is computed by selecting the output from the path that must have been executed based on the evaluation of the branch condition. This technique increases the utilization of the PEs, at the cost of higher energy consumption due to execution of both paths in a conditional. Unlike partial predication, in full predication all instructions are predicated. Instructions on each path of a control flow, which are sequentially configured onto PEs, will be executed if the predicate value of the instruction is similar with the flag in the PEs. Hence, the instructions in the false path do not get executed. The sequential arrangement of the paths degrades the latency and energy efficiency of this technique.

Full predication is upgraded in state based full predication [START_REF] Han | State-based full predication for low power coarse-grained reconfigurable architecture[END_REF]. This scheme prevents the wasted instruction issues from false conditional path by introducing sleep and awake mechanisms, but fails to improve performance. Dual issue scheme [START_REF] Han | Acceleration of control flow on cgra using advanced predicated execution[END_REF] targets energy efficiency by issuing two instructions to a PE simultaneously, one from the if-path, another from the else-path. In this mechanism, the latency remains similar to that of the partial predication with improved energy efficiency. However, this approach is too restrictive, as far as imbalanced and nested conditionals are concerned. To map nested, imbalanced conditionals and single loop onto CGRA, the triggered long instruction set architecture (TLIA) is presented in [START_REF] Liu | Tlia: Efficient reconfigurable architecture for control-intensive kernels with triggeredlong-instructions[END_REF]. This approach merges all the conditionals present in kernels into triggered instructions, and creates instruction pool for each triggered instruction. As the depth of the nested conditionals increases the performance of this approach decreases. As far as the loop nests are concerned, the TLIA approach reaches bottleneck to accommodate the large set of triggered instructions into the limited set of PEs.

The compilation flow we propose, uses the register allocation approach [START_REF] Das | Efficient mapping of CDFG onto coarse-grained reconfigurable array architectures[END_REF] to map CDFGs onto the CGRA. This allows to map both loops and conditionals of any depth. In our case, the only limitation in the mapping of kernels onto the CGRA is given by the size of instruction memory of the PEs, and not by the structure of the application (i.e. number of loops, and branches). Also, one can increase the size of code segment to be executed in the CGRA as much as possible, minimizing the control and synchronization overheads with the core, which is not negligible in the other approaches. Table II presents a comprehensive comparison between several techniques to manage control flow in the kernels. Software pipelining and loop unrolling are mostly used for the mapping of the innermost loop, while branches inside the loop are managed by one of the described predication techniques. Hence, the existing compilers use combined solutions for branches and innermost loop mapping. This requires exhaustive exploration to find out the most suitable combination for the target architecture and application domain. On the contrary, our proposed compilation flow can handle both conditionals and loops efficiently. In this section, we present the Integrated Programmable-Array Accelerator (IPA) architecture, supporting standalone execution of complete control and data flow applications.

#0 Bank #1 Bank #2 Bank #n-1 Bank #0 Bank #1 Bank #2 Bank #n-1 ... TCDM . Bank #0 Bank #1 Bank #2 Bank #n-1 ... TCDM .

IPA Controller

A. Integrated Programmable-Array Accelerator (IPA)

IPA is the integration of a PE Array (PEA) and a tightly coupled data memory (TCDM) through a low-latency logarithmic interconnect. An IPA controller loads the context into the PEs from a pre-loaded Global Context Memory (GCM). Fig. 2 shows the organization of the IPA.

The PEA consists of a parametric number of PEs connected with a 2-dimensional tours network. The PE Array follows the multiple instruction, multiple data (MIMD) model of computation. All PEs operate on different set of instructions. A bus based interconnect network is implemented to load instructions and constants (i.e. context) from the GCM into the PEs, whereas the torus network is used during execution phase for low power data communication between the PEs. The details of the load context protocol are discussed in [START_REF] Das | A 142 mops/mw integrated programmable array accelerator for smart visual processing[END_REF]. Targeting low power execution, the instruction set architecture [START_REF] Das | A 142 mops/mw integrated programmable array accelerator for smart visual processing[END_REF] was designed from scratch resulting 20-bit long instruction. We took the advantage of the visibility of the micro-architecture to the compiler and moved the immediate data to constant register file in the PEs (discussed later) which eases the compression of the instruction, imposing low pressure on the decoder. Fig. 3 describes the components of a PE. The Load Store Unit (LSU) is optional for the PEs (the optimal number of LSU is a parameter studied in this paper). Two operands (IN0 and IN1) define the inputs of each PE. The input sources are the neighbouring PEs and the register file. A 32-bit ALU and a 16-bit × 16-bit → 32-bit multiplier are employed in this block. The Constant Register File (CRF) stores the immediate values of the instructions, while the Regular Register File (RRF) and Output Register (OPR) store the temporary variables. The Controller fetches the instructions from the Instruction Register File (IRF). If the decoded instruction is a jump, the target address of the jump is stored in the Jump Register (JR). The cjump (conditional jump) instruction contains two target addresses. The true path is evaluated in the JR by the Boolean "OR" of the Condition Register (CR) bits of the PEs. The TCDM acts as L1 memory for the IPA. Featuring a number of ports equal to the number of memory banks, the TCDM provides concurrent access to different memory locations. The TCDM is interfaced with the LSUs of the PE array through a low latency, logarithmic interconnect [START_REF] Rahimi | A fully-synthesizable single-cycle interconnection network for shared-l1 processor clusters[END_REF], implementing a word level interleaving scheme to minimize access contention.

B. Power Management Unit (PMU)

To reduce dynamic power consumption in idle mode, each PE contains a tiny Power Management Unit (PMU) which clock gates the PEs when idle. An idle condition for a PE arises from three situations: (i) Unused PE: when a PE is not used during mapping; (ii) Load Store stall: In case of TCDM banking conflict the PMU generates a global stall, which is broadcast to all the PEs. Until the global stall is resolved, all the PEs are clock gated by their corresponding PMUs. LSUs are placed in the global clock region (Fig. 3) to avoid deadlocks; (iii) Multiple NOP operations: a NOP instruction contains the number of successive NOPs. When a NOP instruction is fetched, the decoder loads this number into a counter within the PMU. The clockgate en remains low until the count reaches zero. The counter gets halted when it encounters a global stall and resumes the count after the stall is resolved, synchronizing the execution flow among PEs.

Due to the fine-grained nature of the power management, more aggressive power gating is not implemented, since it imposes large area penalty without remarkable benefits. The leakage power of each tile is so small that it does not change notably the energy efficiency when rest of the system is active.

C. Overview of the execution model

After compiling a kernel (see section IV), the compiler generates the assembly and the addresses for the input and output data in the local shared memory. The assembler takes the assembly and the Instruction Set Architecture (ISA) of the IPA, to generate the context (i.e. the program to be stored into the IRF) for each PE, which is pre-loaded in the GCM. The context contains instructions and constants for each PE in the array. Prior to the execution start, the context is loaded into the int example(int a [START_REF] Campi | RTL-to-layout implementation of an embedded coarse grained architecture for dynamically reconfigurable computing in systems-on-chip[END_REF] respectively. Also, the IPA achieves 28× performance gain compared to that of the CPU while executing the sample program. The decrease in the number of instructions in the IPA in this specific example is mainly due to the much lower number of memory operations and the fact that the small loop can be completely unrolled without code size blown-up.

IV. COMPILATION FLOW

The compilation generates a mapping of the program for the corresponding PEA. This section presents the models adopted for the architecture and the application and the full compilation flow to map control and data flow onto the PEA. We also discuss the register allocation approach to exploit the register files of the PEs while preserving control-carried dependencies.

A. Architecture, application model and homomorphism

The compiler takes two inputs. The first is the PEA model, and the second is the ANSI-C code of the application. The PEA is modelled by a bipartite directed graph with two types of nodes: operators and registers. Timing is implicitly represented by connections between registers and operators, which is referred to as the time extended model of the PEA [START_REF] Hamzeh | Regimap: registeraware application mapping on coarse-grained reconfigurable architectures (cgras)[END_REF]. Two types of operator nodes are defined for the PEAs. The first type is the computing operator (functional unit (FU) nodes in Fig. 5(a)) that represents the physical implementation of an arithmetic and logical operation (+, ×, -, OR, AND) and/or memory access (e.g. load/store). The second type of operator is the memorization operator (circular nodes in Fig. 5(b)). It is associated with the output register and represents the operation of keeping a value in a local register explicitly. (d) The transformed CDFG of (b) for systematic load store based approach (e) A possible mapping of (d) onto the PEA over 7 cycles using systematic load store based approach we discuss the full compilation flow for CDFG mapping.

B. The compilation flow step by step

Fig. 7 shows a schematic representation of the compilation flow for mapping CDFGs onto the PEA. A CDFG mapping is a set of DFG mappings that are compatible with each other. To be compatible, the DFGs must access the data that remain in the PEs (see symbol variables (see definition IV.1)) in the same location. This is ensured by the register allocation approach.

To map the basic blocks, we rely on the highly scalable and efficient mapping approach for DFGs described in [START_REF] Das | A scalable design approach to efficiently map applications on CGRAs[END_REF]. The compilation flow proposed in this paper, extends the DFG mapping to accommodate the register allocation approach to map a full CDFG onto the PE array. As presented in Fig. 7, the full compilation flow is composed of six interdependent stages: BB selection, backtracking, update constraints, scheduling and placement, graph transformation and a stochastic pruning. These tasks are described in detail in the next sub-sections. 1) Scheduling and placement: The proposed approach uses a backward traversal [START_REF] Peyret | Efficient application mapping on cgras based on backward simultaneous scheduling/binding and dynamic graph transformations[END_REF] list scheduling algorithm to schedule the DFG of each basic block. It relies on a heuristic in which the schedulable operations are listed by priority order. In backward traversal, a node is schedulable if and only if all its children are already scheduled. The priority of nodes depends on their mobility [START_REF] Paulin | Force-directed scheduling for the behavioral synthesis of asics[END_REF]. It is possible to process memorization nodes and conventional nodes differently. Also, when several nodes have the same mobility, their respective number of successors is used as a second priority criterion. The higher is the number of successors, the higher the priority is. Indeed, a node with a higher number of successors is more difficult to map due to the routing constraint coming from the limited amount of connections between tiles. Thus, scheduling these nodes at first usually allows to decrease the application's latency [START_REF] Peyret | Efficient application mapping on cgras based on backward simultaneous scheduling/binding and dynamic graph transformations[END_REF]. As soon as the highest priority node has been defined, the compiler tries to find a placement in the PE array model. If a placement solution exists, the node is scheduled else the graph is transformed.

The proposed placement uses an incremental version of Levi's algorithm [START_REF] Levi | A note on the derivation of maximal common subgraphs of two directed or undirected graphs[END_REF]. The proposed algorithm adds the newly scheduled operation node and its associated data node to the sub-graph composed of already scheduled and placed nodes. Only the previous set of solutions that have been kept, location constraints (RLC (see definition IV.3) and TLC (see definition IV.2)) are used to find every possibility to add this couple of nodes without considering the non-yet scheduled nodes. If no solution is found, there is absolutely no possibility to bind this couple in all the previous partial solutions because Levi's algorithm provides a complete exploration of the solution space. In that case, graph transformation is required.

2) Graph transformation: DFG is transformed dynamically when no binding solution is found. The three graph transformations are used in our compilation flow (Fig. 8).

• Operation splitting duplicates an operation node by keeping its same inputs and distributing output edges to reduce the number of successors of the original operation node. • Memorization routing adds a memorization node and its associated data node to delay one operation and to keep data dependencies • Assignment routing adds an assignment node (mov operation node) to increase the physical distance between the source and the sink of symbol variables by one. Due to TLC or RLC, when the physical distance between the source and sink of the symbol variable becomes more than one, the compiler dynamically adds one mov operation node to the DFG. 3) Stochastic pruning: The exactness of the placement approach leads to very large number of partial mappings. And it grows exponentially if not pruned. Hence, we use the stochastic pruning approach described in [START_REF] Das | A scalable design approach to efficiently map applications on CGRAs[END_REF].

4) Basic block selection: Once all the nodes of the basic block have been scheduled and bound, the compiler selects one mapping among the several mappings generated, and selects the next basic block to be mapped. As discussed previously, the data integrity must be maintained over several basic block mappings. The data mapping problem for CDFG mapping is now described before detailing the basic block selection step.

4.a: Definition and problem formulation

Data in an application is separated into two categories. (i) The standard input and output data (mostly the array inputs and outputs) are mapped as memory operands. The inputs and outputs are allotted by load-store operations. In our sample program in Fig. 6, m, n are the input arrays and p is the output array, which are managed by load and store operations. (ii) The internal variables of a program are mapped onto the registers of the processing elements, and managed by the register allocation based approach [START_REF] Das | Efficient mapping of CDFG onto coarse-grained reconfigurable array architectures[END_REF]. Following, we introduce several definitions concerning register allocation approach: Definition IV.1. [Symbol Variables and location constraints] In compilation, the recurring variables (repeatedly written and read) are managed in local register files of the PEs to avoid multiple access of local memory. The recurring variables which have occurrences in multiple basic blocks need special attention since the integrity of these variables must be kept intact throughout the mapping process for different basic blocks. These variables are defined as Symbol variables. The register locations for the symbol variables are referred to as location constraints. For instance, variable c in the CDFG (Fig. 6) is written in BB 3, and read in BB 4, BB 5 and BB 6. The register location for c must be same for all the mappings of these basic blocks. Similarly, X1, X2, X3, X4, X5, i, a and b must be location constrained. In the rest of the paper, the locations for such symbol variables are denoted with an overline, as variable name.

Depending on the order of the basic blocks mapped (i.e. traversing the CDFG), some location constrains may be reused in the mapping process or may be kept reserved for later use. These two types of location constraints are now detailed.

Definition IV.2. [Target Location Constraints (TLC)]

We consider a scenario scenario 1, where BB 6 is mapped first, BB 3 is mapped next and so on. While mapping BB 6, variables c and X5 are placed at c and X5. While mapping BB 3, c and X5 which are already mapped in BB 6, must be considered because c will be used to map c in BB 3. In other words, the placement of the variables in the registers must be respected. Also, a, b, X1 and X2 must not reuse X5. Otherwise, X5 will have wrong value when executing BB 6. Let's consider scenario 2 with another order of basic blocks mapped, like first BB 3 and then BB 6 and so on. In this order of mapping, it is necessary to pass c and X5 from BB 3 to BB 6 mapping. To keep c and X5 alive in BB 6 both c and X5 must be used in mapping of BB 6. The placement or binding information which are passed from the mapping of one basic block to the mapping of the other basic block is referred to as constraint (e.g. scenario 1: c and X5 passed from BB 6 to BB 3). The location constraints related to the data that are used within a basic block mapping phase (e.g. scenario 1: c in BB 3 mapping) are referred to as target location constraints (TLC).

Definition IV.3. [Reserved Location Constraints (RLC)] As

we have seen in the previous examples, some of the location constraints must be reserved in the mapping of basic blocks for the sake of data integrity. To keep the symbol variables alive, it is necessary to exclude the memory elements from placement. Accordingly, these resources will not override while mapping the basic block (e.g. scenario 1: X5 in BB 3 mapping). These are referred to as reserved location constraints (RLC).

4.b: Selection approach

If the number of RLC and TLC is high, mapping becomes complex. As TLC will force to use resources, and RLC will force to exclude resources from placement. Hence, the primary goal for our compiler is to minimize the number of TLCs and RLCs by choosing an efficient traversal of the CDFG.

The basic solution to deal with the symbol variables is to introduce memory operations. The symbol variables are stored in the memory where they are written and are loaded from the memory when read. In the rest of the paper this basic solution is referred to as systematic load-store based approach. This method is presented in the Fig. 5(d). For the symbol variable c in the CDFG shown in Fig. 5(c), it stores variable c in the memory in BB 3, and loads in BB 4, BB 5 and BB 6. Fig. 5 refers to the mapping of the transformed CDFG in this approach. This basic solution reduces the complexity of the mapping as there are no constraints to be dealt with while mapping the basic block. However, it requires a huge memory bandwidth, significantly reducing the energy efficiency of the system. As the compilation is built on register allocation approach, the symbol variables are stored in the register files when they are produced, and retrieved from the registers when used as operands. While doing so, the effects of the constraints in mapping are unavoidable. RLC restrict the use of some resources, and TLC force to reuse some resources. If there is only a single TLC in a basic block mapping, it becomes easier to start mapping from the known place. But several TLC and RLC complicates the mapping. Forced and blocked placements by these constraints induce extra routing effort (dynamically transforming the graph in compilation).

As the selection of the basic blocks during the mapping is important, we compare the number of TLC and RLC for several CDFG traversal in this section. Table III presents the comparison between the number of different constraints in the forward and backward CDFG traversal for Breadth First Search (BFS) and Depth First Search (DFS) strategies. As the trend is similar for other kernels we present the results for sobel and seperable 2D filter only. The numbers show that DFS strategy generates a lower number of RLC than the BFS in both forward and backward traversal. The number of RLC for sobel filter is much higher in BFS due to several sequential loops present in the kernel. The numbers of TLC are similar in both the strategies for different traversal mechanisms. Also for the different search strategies forward and backward traversal perform similarly. The DFS strategy is thus used.

5) Backtracking: For a basic block to be mapped (except the first one), this stage selects the first map out of several mappings generated for the last basic block mapped. The selected map updates the constraints for the current basic block mapping. If the compiler is unable to find a mapping solution for the basic block due to the constraints, this stage selects the second map from previous basic block to update the constraints and restart mapping of the new basic block. The process continues up to the first basic block mapped until a valid mapping is found for the current basic block. 6) Update Constraints: In this stage, the compiler creates and updates a constraint database. This database is used in the placement algorithm, to place the data nodes and corresponding operation nodes according to the TLC and RLC. When mapping a current basic block, new variables cannot be placed in RLCs, while TLCs are used to map the symbol variables. If the symbol variables in the current basic block mapping are not present in the constraint database, then the variables are mapped using available resources, and the respective placements are used to update the constraint database prior to mapping of the next basic block. Once all the basic blocks are mapped the compiler generates the assembly containing a single map for the whole CDFG.

C. Assembler

Assembler holds the key to differentiate from the PEA model used in the compiler and the actual hardware implementation. The assembler takes the ASCII text assembly generated by the compiler and the instruction set architecture (ISA) and produces machine code, which can then be used to configure the PEs in the hardware. The ISA provides the added hardware information to the PEA model used in the compiler. As an example, the PEs in the IPA use an added constant register file (CRF) for storing the constants. The introduction of the CRF in the PEA model minimizes the instruction length by storing the immediates of the instruction into the internal registers, giving a low power solution. That is how the assembler separates the model used in the compiler from the actual implementation of the hardware. One can define their own PEA model and derive an architecture from that for actual implementation. Thus, the compiler can be used for a wide range of PEA variations.

V. EXPERIMENTAL RESULTS

This section analyses the implementation results, providing performance, area, and energy consumption on several signal processing kernels. We carry out experiments to show the efficiency of the register allocation approach compared to the state of the art predication techniques, considering a wide range of control dominated kernels. An architectural exploration is also performed to find the optimal configuration in terms of number of load-store units and TCDM banks for an IPA with 4x4 PE array. Performance, area and energy efficiency are also compared with that of the or1k CPU [START_REF] Lampret | Openrisc 1000 architecture manual[END_REF].

A. Implementation Results

This section describes the implementation results for the IPA accelerator, providing a comparison with the or1k CPU. Both the designs were synthesized with Synopsys design compiler 2014.09-SP4 using STMicroelectronics 28nm UTBB FD-SOI technology libraries. Synopsys PrimePower 2013.12-SP3 was used for timing and power analysis at the supply of 0.6V, 25 • C temperature, in typical process conditions. The cycle information was achieved simulating the RTL with Mentor Questa Sim-64 10.5c. The code-sizes (instructions and constants) of all the kernels used in the experiments are presented in Table IV. In the following, the exploration considers a 4×4 array with 16 PEs, each one including 20×32bit instruction register file, a 32×8-bit regular register file and 32×16-bit constant register file, as shown in Table V. For area comparison, the CPU includes 32kB of data memory, 4kB of instruction memory, and 1 kB of instruction cache, which is equivalent to the design parameters of the IPA. The cost of the IRF is considered both in size and power. Thanks to the simpler architecture and tiny processing elements, at the target operating voltage of 0.6V, the IPA runs at 100 MHz while or1k can only reach 45MHz in the same operating point.

Fig. 9 shows the area of the whole array and memory with different numbers of TCDM banks, where the total amount of memory is kept constant at 32kB. As the area of LSUs is negligible if compared to the overall system area, we show the area results for the worst-case scenario with maximum number of LSUs present in the PE array (i.e. 16). As shown in Fig. 9, in the minimal configuration with 4 TCDM banks, the IPA area is dominated by that of the array (60%) and by the local data storage (35%), while the remaining 5% is consumed by the interconnect. Increasing the number of TCDM banks imposes a significant area overhead on the size of the interconnect. Also, the area of the TCDM increases as well due to the higher area/bit of small SRAM cuts necessary to implement 32kB of memory with several banks. Hence, it is fundamental to properly balance the number of LSUs and TCDM banks with the bandwidth requirements of applications.

B. Comparison of the proposed compilation approach with state of the art predication techniques

To evaluate the efficiency of the register allocation approach to handle the control flow we compare the execution of six control intensive kernels compared to the state of the art partial and full predication techniques. The results, presented in Table VI, show that the register based approach achieves a maximum of 1.33× (with minimum of 1.04× and average of 1.13×) and 1.8× (with minimum of 1.37× and average of 1.59×) performance gain compared to partial predication and full predication techniques. The maximum gain achieved over existing methods are highlighted in bold in the table. The smaller number of executed instructions allows the register allocation approach to outperform the partial and full predication techniques by an average of 1.54× (with min 1.35×, max 2×) and 1.71× (with min 1.44×, max 2×) respectively in terms of energy efficiency. The table also presents a comparison with respect to or1k CPU and C64 DSP processor [START_REF] Instruments | Tms320c64x/c64x+ dsp cpu and instruction set reference guide[END_REF] from TI. The register allocation approach achieves a maximum of 3.94×, 15.8× performance gain and 7.52×, 32.77× energy gain over or1k and C64 processor, respectively. Due to the abundance of branches in these kernels, the DSP processor performs worst. Finally, we compare with the basic systematic load-store (SLS) based approach for control mapping. It is depicted from the Table VI that the register allocation approach performs an average of 1.16× (with max of 1.46×, min of 1.05×) better than the SLS based approach, while gaining an average of 1.31× energy efficiency with a maximum gain of 2× and minimum gain of 1.07×.

C. Architectural Exploration

This section provides an extensive comparison with respect to the CPU computational model and an evaluation of the performance of the IPA while varying the number of LSUs and TCDM banks, a critical parameter for data-hungry accelerators. To carry out the exploration, we selected 7 compute intensive signal processing kernels featuring a high bandwidth towards the TCDM.

1) Performance: Generally speaking, the IPA performs well when significant parallelism can be extracted from a kernel. This concept is well shown in Fig. 10, which compares the performance of the IPA with that of the or1k processor on a matrix multiplication when growing the size of the matrices from 2×2 to 32×32. It is possible to note that the increase of the kernel size increases the average utilization of the PEs as well, which in turn helps to enhance performance. It also demonstrates that the initial configuration time, which is dominant for small kernel size is well amortized for larger kernels, further contributing to improve performance. 11 presents the total execution time (clock cycles) of seven compute-intensive kernels. The execution time is normalized with respect to that of or1k processor, where the kernels are compiled with -O3 optimization flag. The IPA outperforms the CPU by up to 20.3×, with an average speed-up of 9.7×. A quantitative performance comparison with respect to the CPU is presented in Table VII. The table presents the configuration and execution cycles in the IPA for different kernels. It also presents the average utilization of PEs over the total execution period and total number of instructions executed in the IPA. The instruction count includes the instructions that are replicated on all the active PEs for keeping the PE in synch across conditionals and jumps. It also includes NOPs that are used when some PEs are stalled due to manipulation of index variables. However, during NOP execution PEs are clock gated and do not consume dynamic power. The IPA achieves a maximum of 18× and an average of 9.23× energy gain over the CPU.

To establish the impact of the memory bandwidth over performance and energy efficiency, we vary the number of LSUs in the PE array from 4 to 16 and the number of TCDM banks from 4 to 32. The number of LSUs defines the available bandwidth from the TCDM to the array, while increasing the number of TCDM banks reduces the banking conflict probability, improving performance. To perform the exploration without any bias towards configurations, the innermost loops of the kernels are unrolled to get a maximum of 16 load-store operations in one cycle (as the highest number of LSUs considered is 16, in the exploration). In Fig. 11, each configuration is represented as a 2-dimensional number, where the first one represents the number of LSUs, and the second one represents the number of TCDM banks.

Results show that, as opposed to tightly coupled clusters of processors which require a banking factor of 2 (i.e. number of TCDM banks is twice the number of cores) [START_REF] Rossi | A 60 GOPS/W, -1.8 V to 0.9 V body bias ULP cluster in 28 nm UTBB fd-soi technology[END_REF], IPA performance is almost insensitive to the number of TCDM banks, and a configuration with a banking factor of 0.5 is sufficient to minimize the impact of contention on the shared memory banks for most applications. Indeed, while the typical processor execution requires several load/store operations for variables exceeding the size of the register file, direct CDFG 2) Energy Efficiency: Fig. 12 shows the average power consumption breakdown for various configurations of the IPA. As expected, the PE array is the most dominant power consumer for all the configurations. The configurations with 4 TCDM banks achieve the best power advantages in each group, as increasing the number of banks increases the interconnect complexity, causing timing pressure on the array, which increases the sizing of the cells, hence power consumption. Fig. 13 shows the average energy efficiency (MOPS/mW) for different configurations. Million Operations Per Second (MOPS) only considers the active PEs during execution, since a PE may be idle due to TCDM bank access conflicts, consecutive NOPs, or not mapped (not used in the application execution). Executions with high number of active PEs/cycle achieve large MOPS. As depicted in Fig. 13, for different number of LSUs in the PE array, the configuration with 4 TCDM banks achieves the best energy efficiency, since this is the least number of banks in each configuration, it of the non clock gated design. Due to the regular architecture of the PE array, fine grained power management is much more suitable to implement than a processor. Moreover, thanks to the efficient execution of CDFG on the array, the smaller energy required to execute an instruction in the IPA with respect to a CPU (5.6E-07 µJ vs 3.49E-06 µJ), and the effectiveness of the fine-grained power management the IPA outperforms the or1k CPU's energy efficiency by up to 18× (Table VII). The energy per instruction execution in the IPA is much less than that of the CPU due to its simple instruction set architecture. Also, the lower number of memory operations executed in the IPA helps reducing on the average energy consumption.

D. Comparison with low-power CGRA architectures

Table VIII shows a comparison with existing CGRAs. For some papers, energy efficiency figures could not be extracted, so 'NA' is put in the corresponding cell. The energy efficiency figures are provided both in the original manufacturing technology node and scaled to the 28nm technology, according to the power scaling factor C * V 2 . C and V represent the effective capacitance (approximated with the channel length of the technology) and the supply voltage of the designs, normalized to the nominal parameters of the 28nm technology node. It should be noted that this simplified scaling factor penalizes our design, since deep-submicron technologies such as 28nm, where the load capacitance of gates is typically dominated by wires require much more buffering than mature technology nodes, which penalizes energy efficiency. Nevertheless, IPA provides leading-edge energy efficiency, surpassing by more than one order of magnitude other architectures featuring a C based mapping flow. The driving factors for this gain are (a) architectural simplicity with less complex interconnect network, (b) low power instruction processing, (c) lowest possible number of memory operations in application execution, (d) fine grained power management architecture. Compared to ultra-low power targets (that fit in a power envelope of 3mW), the IPA presents a better energy efficiency than [START_REF] Lopes | Evaluation of cgra architecture for real-time processing of biological signals on wearable devices[END_REF] and [START_REF] Masuyama | A 297mops/0.4 mw ultra low power coarse-grained reconfigurable accelerator CMA-SOTB-2[END_REF] for which information could be extracted from the papers. One distinguishing characteristic of the proposed accelerator is the flexible execution model capable of implementing CDFG on the array without the need of a host processor, coupled with a fully automated mapping flow that starts from a plain ANSI C description of the application. Moreover, the memory architecture, based on a shared multi-banked TCDM enables easy integration within ultra-low-power tightly coupled clusters of processors, while fine-grained power management allows improving energy efficiency by up to 2×. The average power consumption of the IPA is 0.49mW, which is compatible with the ultra-low power target.

VI. CONCLUSION

This work presents an ultra-low power coarse reconfigurable array accelerator for near-sensor processing. The proposed Integrated Programmable-Array (IPA) is a 2-D array of NxN processing elements (a 4x4 configuration is used in this paper), and leverages a multi-banked tightly coupled data memory for data storage, to ease the integration in clustered multi-core architectures. We present a compilation flow targeting the mapping of both control and data flow portions of kernels onto the array of processing elements, aimed at reducing the pressure on the shared data memory, along with an architectural exploration of the memory architecture parameters. The results of the exploration show that a configuration of the IPA with 8 load-store units and 4 TCDM banks achieves the optimal performance/energy tradeoff featuring an average speed-up of 9.7× (max 20.3×, min 4.9×) compared to a general-purpose processor. With respect to state of the art partial and full predication techniques, the proposed compilation flow improves performance by 1.54× on average (min 1.35×, max 2×) and energy efficiency by 1.71× on average (min 1.44×, max 2×). Thanks to the optimized architecture and mapping flow, the proposed accelerator achieves an average energy efficiency of 1617 MOPS/mW over a wide range of sensor signal processing kernels, surpassing other CGRA architectures featuring a C based mapping flow by more than one order of magnitude.

Figure 2 :

 2 Figure 2: Integrated Programmable-Array Accelerator

Figure 3 :

 3 Figure 3: Components of the PE

Figure 4 :

 4 Figure 4: (a) Sample program (b) Execution in CPU (c) Example PEA (d) Execution in IPA (e) Execution metrics in CPU and IPA

Fig. 5 (Figure 5 :

 55 Figure 5: (a) A 2×1 PEA with 3 registers in RF and one output register (b) CDFG model (c) A possible mapping of (b) onto the PEA over 4 cycles using register allocation based approach. (d) The transformed CDFG of (b) for systematic load store based approach (e) A possible mapping of (d) onto the PEA over 7 cycles using systematic load store based approach

Figure 6 :Figure 7 :

 67 Figure 6: Sample program and corresponding CDFG

Figure 8 :

 8 Figure 8: Graph transformation

Figure 9 :

 9 Figure 9: Synthesized area of IPA for different number of TCDM banks

Figure 10 :

 10 Figure 10: Performance of IPA executing matrix multiplication of different size

Figure 11 :

 11 Figure 11: Latency performance in different configurations ([#LSUs][#TCDM Banks])

Figure 12 :

 12 Figure 12: Average power breakdown in different configurations ([#LSUs][#TCDM Banks])

Figure 13 :

 13 Figure 13: Average energy efficiency for different configurations ([#LSUs][#TCDM Banks])

Table I :

 I Comparison between different architectural approaches

					IPA
					This
					paper
	Memory ops	CPU	CGRA	CPU	CGRA
	Innermost loop	CGRA	CGRA	CGRA	CGRA
	Outer loop	CPU	CPU	CGRA	CGRA
	Offload + Sync	CPU	CPU	CPU	CPU
	Overhead

Table II :

 II Comparison between different approaches to manage control flow in CGRA

	Techniques	Conditionals Balanced Imbalanced	Loops Single Nested
	Partial
	predication [5]

Table III :

 III Comparison of RLC and TLC numbers between different CDFG traversal

			Forward Traversal			Backward Traversal
	Kernels	Breadth First Search	DepthFirst Search	Breadth First Search	DepthFirst Search
		# RLC	# TLC	# RLC	# TLC	# RLC	# TLC	# RLC	# TLC
	Seperable 2D Filter	22	35	17	35	22	35	17	35
	sobel Filter	64	85	35	85	69	85	35	85

Table IV :

 IV Code size and the maximum depth of loop nests for the different kernels in the IPA

	Kernels	FIR	MatM	Conv	Sep Filter	Non Sep Filter	FFT	DC Filter	cordic	sobel	gcd	sad	deblock	manh-dist
	Code size (KB)	0.568	0.704	0.704	0.720	0.784	0.696	1.16	0.496	0.336	1.448	0.600	2.016	0.624
	Max depth loop nests	2	3	3	3	4	2	2	1	1	1	2	3	2

Table V :

 V Specifications of memories used in the IPA

		Name			Type	Size
		Global context memory	SRAM	8KB
		TCDM			SRAM	32KB
		Instruction Register File (IRF)	Registers	0.08KB
		Regular register file (RRF)	Registers	0.032KB
		Constant register fie(CRF)	Registers	0.128KB
					4banks	8banks	100000 16banks
		350000			IPA controller	50000 INTERCONNECT
		300000			GLOBAL CONTEXT MEMORY PE ARRAY IPA controller	TCDM CPU including memory
		250000			TCDM
	µm2	200000			GLOBAL CONTEXT
	in				MEMORY
	area	150000			INTERCONNECT
		100000			PE ARRAY
		50000
					CPU including memory
		0
		4banks	8banks	16banks	32banks

Table VI :

 VI Performance comparison between the register allocation approach and the state of the art approaches

	Kernels	# Loops	# Condi tionals	reg based	SLS based [9][43]	Performance (cycles) partial [5] full [1]	CPU	C64 DSP	reg based	SLS based [9][43]	Energy (µJ) partial [5] full [1]	CPU	C64 DSP
	cordic	1	2	328	408	396	542	513	286	0.001	0.002	0.002	0.002	0.004	0.002
	sobel	4	11	179 617	262 282	188 253	245 583	454 028	669 794	0.736	1.102	1	1.058	3.531	5.656
	gcd	1	1	55 312	58 596	73 747	92 852	67 545	92 184	0.227	0.246	0.392	0.4	0.525	0.778
	sad	2	1	15 962	16 824	16 573	28 776	62 932	252 193	0.065	0.071	0.088	0.124	0.489	2.13
	deblocking	5	7	472 258	495 081	518 722	727 243	834 683	1 310 220	1.936	2.079	2.754	3.134	6.492	11.064
	manh-dist	1	1	6 288	6 826	6 738	9 522	15 394	55 317	0.026	0.029	0.036	0.041	0.12	0.467
			max gain		1.46×	1.33×	1.8×	3.94×	15.8×		2×	2×	2×	7.52× 32.77×

Table VII :

 VII Overall instructions executed and energy consumption in IPA vs CPU

	Kernels				FIR	MatM (16×16)	Convolution	SepFilter	NonSepFilter	FFT	DC Filter
		Configuration cycles	71		88	88	90	98	87	145
		Execution cycles	6 071		11 940	56 241	827 685	1 852 382	8 076	4 748
	IPA	Total number of instructions executed	44 294		110 946	531 815	7 349 843	17 486 486	76 310	28 868
		Active PEs/cycle (%)	46.1		58.5	59.2	55.5	59	59.7	39.5
		Energy (µJ)		0.022		0.043	0.202	2.98	6.669	0.032	0.017
		Energy (µJ) in non-clock-gated IPA	0.047		0.077	0.479	7.152	11.704	0.063	0.045
	CPU	Execution cycles Energy (µJ)	37 677 0.132		96 256 0.337	616 805 2.159	5 982 730 20.94	9 084 101 31.794	164 480 0.576	50 085 0.175
		Speed-up			6.21x		8.06x	10.97x	7.23x	4.9x	20.3x	10.55x
		Energy-gain		6x		7.84x	10.69x	7.03x	4.77x	18x	10.29x
				[4][4] [4][8] [4][16] [4][32] [8][4] [8][8] [8][16] [8][32] [16][4] [16][8] [16][16] [16][32]
				0.25
		to cpu		0.2
		Cycles normalized	performance	0.05 0.1 0.15
				0
				FIR		MatM	Convolution	SepFilter	NonSepFilter	FFT	DC Filter

Table VIII :

 VIII Comparison with the state of the art low power targets PEs perform 8-bit operations, hence energy efficiency is normalized to equivalent 32-bit operations, does not include the power of controlling processor

	Ref	Arch	Maps	Source	Access local memory	Tech [nm]	Supply voltage	Area [mm 2 ]	Power [mW]	Freq [MHz]	Area eff [MOPS /mm 2 ]	Energy eff [MOPS /mW]	Energy [MOPS/mW] eff scaled to 28nm	Perf [MOPS]
						Low power targets
	[25]	TCPA	CDFG	Customized	VLIW	90	1.0V	15	12.48	200	106	112.00	360	1587
	[46]	Layers	CDFG	NA	PE	65	1.0	0.35	44.45	488	2786	21.94	72	975
	[29]	SmartCell	CDFG	Customized	PE	130	1.0V	8.2	160	100	13.04	37.8	176	6048
	[18]	PipeRench	DFG	Customized	PE	180	1.8V	55.5	675	120	NA	NA	NA	NA
	[41]	SYSCORE	CDFG	NA	PE	90	1.0V	5.73	18.5	100	NA	NA	NA	NA
	[3]	ADRES	DFG	ANSI C	VLIW	90	1.0V	15	80	100	94	17.51	56	1409
	[4]	XPP	CDFG	ANSI C	PE	90	1.0V	42	93	150	310	10.00	32	13000
	[53]	AsAP	CDFG	ANSI C	PE	180	1.8V	23.76	84	116	40	11.00	229	942
	[48]	MUCCRA-3	DFG	Customized	VLIW	65	1.2V	8.82	11	41.4	NA	NA	NA	NA
						Ultra-low power targets
	[33]	Lopes et al	DFG	NA	PE	90	1.0V	0.45	3.47	100	222	28.8	92.6	100
	[36]	CMA	DFG	Customized	µC	65	0.5V	25	1.6	85	3	186 a	430 a	74 a
	[15]	SIMD-CGRA	DFG	ANSI C	PE	65	0.9	0.59	NA	1	NA	NA	NA	NA
	[23]	ULP-SRP	DFG	ANSI C	VLIW	40	0.5V	NA	0.21	7	NA	NA	NA	NA
	This paper	IPA	CDFG	ANSI C	PE	28	0.6V	0.25	0.49	100	3036	1617	1617	759

a

This processor is optimized for low power execution in the context of near threshold near-sensor processing

Note that the context loading and setup cost are accounted for in the experimental results.

ACKNOWLEDGEMENTS

This work was funded by the ERC MultiTherman Project (ERC-AdG-291125), and by the OPRECOMP Project funded from the European Unions Horizon 2020 Research and Innovation Programme under grant agreement No. 732631. We also thank STMicroelectronics for granting access to the FDSOI 28nm technology libraries.


P Pajusco

F Gallée

N Malhouroux

R Burghelea

Massive Antenna Array for Space-Time Channel Sounding

Keywords: antenna array, channel sounding, direction of arrival, massive MIMO. I

In this paper, a prototype of a dual-polarized array antenna is presented. This array was designed in the framework of a collaborative project on spatial modulation schemes. It will be used for the project testbed and for space-time channel measurements. This array features several novelties, including a slant uniform planar structure, a scalable design with integrated switching circuitry, a reference antenna and a camera. The array has been successfully used with a wideband channel sounder to provide real-time radio photos.

INTRODUCTION

Wideband channel models should be realistic and should include all physical effects of the propagation channel, e.g. transmitter (TX) and receiver (RX) spatial spreading, temporal spreading, depolarization, etc. This is especially important in the context of advanced transmission schemes, such as massive MIMO or spatial modulation. System performance can be investigated using various massive MIMO testbeds, most of which are recapped in the first tables of [START_REF] Harris | LOS Throughput Measurements in Real-Time with a 128-Antenna Massive MIMO Testbed[END_REF] and [START_REF] Vieira | A flexible 100-antenna testbed for Massive MIMO[END_REF]. The number of antennas ranges from 32 to 128. Such testbeds are quite complex due to large number of transceivers. Alternatively, spatial modulation [START_REF] Renzo | Spatial modulation for generalized MIMO: Challenges, opportunities, and implementation[END_REF] is a promising modulation scheme but deeper investigation is needed. It involves carrying the symbol information by choosing a specific antenna of a massive array. Consequently, only a single transmitter is needed to simplify the communication system. However, the array is a bit more complex because it has to include the RF switch circuitry. Such antenna arrays can also be used in propagation channel measurement.

For accurate MIMO channel modeling, it is important to estimate path directions in azimuth and elevation, along with the amplitude and polarization of waves on both sides of the link. The characteristics of the array play a major role in the final performance irrespective of the algorithm used (e.g. casual beam former or advanced high-resolution techniques) [START_REF] Rusek | Scaling Up MIMO: Opportunities and Challenges with Very Large Arrays[END_REF], [START_REF] Choi | Exploiting the preferred domain of FDD massive MIMO systems with uniform planar arrays[END_REF]. In this paper, the design of a massive antenna array is presented which would be further used in the spatial modulation testbed as well as MIMO channel measurements.

The first section introduces the design of the antenna array. The real prototype is discussed in the second section. Finally, two examples of use are provided: one in an anechoic chamber for validation purpose and one in indoor environment for realtime radio photo demonstration.

II.

ANTENNA ARRAY DESIGN a) Introduction Various antenna solutions based on the switching approach have been proposed with different configurations and in different frequency bands. For MIMO channel modeling, the knowledge of the polarization state is also important. For instance, dual-polarization patch antennas are used in a Uniform Planar Array (UPA) [START_REF] Tang | Clustering in 3D MIMO Channel: Measurement-Based Results and Improvements[END_REF] and a Uniform Circular Array (UCA) [START_REF] Müller | Design of a circular antenna array for MIMO channel sounding application at 2.53 GHz[END_REF].

Our challenge was to design an easy-to-use, flexible, portable antenna array. The main idea was to co-integrate the antennas, feeding network and switching matrix. The main specifications are recapped hereafter:

• Flexible number of antennas b) Array geometry In order to steer the beam in both azimuth and elevation, a planar array can be used as the simplest solution. Compared to a circular or spherical array, this geometry limits the array field of view to about ±60°. However, this is representative of a base station in a 120° sector cellular configuration. For the ease of prototyping, printed technology was chosen for the array elements. To maximize the field of view of each element, slot radiating elements were selected in contrast to patch radiating elements.

UPA is defined by a rectangular shape with uniform spacing of λ/2. An example with 25 vertical slot antennas is shown in Fig. 1a. We propose to introduce Slant Uniform Planar Array (SUPA). An example of 25 SUPA elements is depicted in Fig. 1b. With the same element number and spacing between them, this structure is wider along both the x and y axes. If we consider only the Uniform Linear Array (ULA) for y=0, the beam resolution in the horizontal plane is improved. For y≠0, the different horizontal ULAs are smaller and the beam resolution is lower. If all elements are fed, this acts as a window effect and reduces side lobes. These properties are illustrated in Fig. 2 for two different beam steering angles. Compared to classic UPA, SUPA makes it possible to reduce side lobes with the same beamwidth. It is also possible to improve the angular resolution in the horizontal plane. Based on these improved characteristics, the SUPA geometry was chosen. Horizontal slot radiating antennas were interleaved to get a dual-polarized array. According to [START_REF] Harris | LOS Throughput Measurements in Real-Time with a 128-Antenna Massive MIMO Testbed[END_REF][START_REF] Vieira | A flexible 100-antenna testbed for Massive MIMO[END_REF], the number of antennas varies from 32 to 128. In spatial modulation, the number of antennas is also important because it represents the spatial state number of the modulation. To anticipate future application needs, we designed a structure which makes it possible to easily increase the number of antennas. For that purpose, a small array was designed as a LEGO™ brick, and the structure is depicted in 3a. This brick can be combined to obtain an arbitrary number of elements as depicted in 3b-c.

d) Elementary module

The elementary brick is an array of 16 slot antennas (8 in vertical polarization and 8 in horizontal polarization) with a uniform spacing of λ/2 (Fig. 4a). The motivation behind the choice of the slot is the requirement of a low-directivity elementary antenna allowing scanning or beamforming over a wider angle. The main constraint is to ensure a similar phase shift for each antenna. The adopted solution is to distribute the switch matrix on several levels by using an SP4T switch (Fig. 4b). For a simple RF circuit, a phase shift of 180° is introduced due to the position of the slot antenna excitation. This will be corrected by the system calibration. The DC power supply and the control of the switches are distributed on a PCB behind the antenna PCB (Fig. 5). The PCB in question is located at λ/4 of the antenna PCB to act like a reflector of the slot antenna. To simplify post-processing, the radiation patterns of all the slots should be similar. However, the radiation is disturbed by the adjacent slots due to the coupling effect. Electromagnetic simulation showed that a minimum of two slots on each side is required to avoid border effects. For this reason, two rows of dummy slots were added. Absorptive switches were chosen to reduce the fringing field effect.

III. ANTENNA PROTOTYPE

The frequency band chosen is 3.6-3.8 GHz corresponding to an LTE allocated frequency band. This prototype, depicted in Fig. 6, was built with four elementary modules, e.g. 64 switched slot radiating elements (32 for horizontal polarization and 32 for vertical polarization). The first layer, in red, is composed of one SP4T switch to select the module. The second layer, in orange, is composed using four SP4T switches and the third layer, in yellow, with sixteen SP4T switches.

For accurate direction of arrival estimation, the 64 slot antennas' radiation patterns were characterized in 3D thanks to the SG 32 equipment from MVG Company. The antenna array being tested is depicted in Fig. 7. This measurement includes phase calibration of the integrated switch matrix. Environment configuration is very important in propagation channel measurements, especially in the case of dynamic scenarios. Thus, it is really convenient to get a continuous view of the environment seen by the antenna. For that purpose, a wide angle camera was included in the antenna array. The SP360 from Kodak™ was selected because it offers a wide enough field of view (+/-120° in azimuth and elevation). Moreover, the MJPEG live stream is easy to get and included in real time for channel sounder application.

IV. DIRECTION OF ARRIVAL ASSESSMENT

a) Direction of arrival estimation A traditional method of beamforming was used [START_REF] Gao; Edfors | Massive MIMO Performance Evaluation Based on Measured Propagation Data[END_REF]. While this method suffers from poor angular resolution, it does offer linear, robust behavior. This method is also faster (no search values, no iterative process) than high-resolution techniques. The principle is recapped briefly in case of a narrow band signal. The different received signals are stored in the vector [ ] To improve sidelobe levels, a 2D weighting window may be applied, but it will also increase the beamwidth. The computation of direction of arrival in 2D is obtained simply by beaming in the different directions.

b) Validation in an anechoic environment Validation was carried out in an anechoic chamber using a VNA and Matlab™ for post-processing. The TX antenna was a path antenna. The measurement set-up is detailed in Fig. 8. To validate the measurements of the direction of arrival, the TX antenna was located at various distances and angles from the RX. Fig. 9 presents two configurations of the TX antenna (TA and TB). Fig. 10 shows the DoA (Direction of arrival) estimate from the method described in section IIIa for position TA. The blue ellipse represents the E field trajectory, i.e. it provides information on the polarization state in the direction of the maximum. In this case, the polarization is nearly vertical (XPD>20dB), which is in accordance with the patch orientation. Table I compares the estimated direction (beamforming method) and the geometrical measured direction in the azimuth and elevation planes. Both positions present a good agreement between the actual LOS direction and the estimated direction from the beamforming method.

Radio channel

VNA

Radio feeder

Radio feeder

USB

Ethernet

Analysis and storage

c) Real-time radio-photo application

The slant uniform planar array was used with Telecom Bretagne's real-time MIMO wideband channel sounder. This equipment is depicted in Fig. 11. The transmitter is composed of an arbitrary wave form generator and a patch antenna, and the channel sounder is based on a real-time SDR platform. Antenna switching is performed by the FPGA, and real-time acquisition is performed in C++. Finally, DoA estimation and video merging are performed in Python. In this example, the antenna array prototype was used in LOS condition. The user holds the patch antenna. Fig. 12 and Fig. 13 represent the radiophoto for two configurations. In Fig. 12, the user holds the patch horizontally in front of the array. As a result, the polarization of the received path is nearly horizontal, as represented by the horizontal ellipse. In Fig. 13, the user location is far from the array boresight and, additionally, the antenna is oriented towards the opposite wall. The array is able to identify both the direct and the reflected paths. A short video of this test is available on [9].

V. CONCLUSION AND FUTURE WORK

The design of a dual-polarized array antenna was presented in this paper. A slant uniform array structure was proposed to improve side lobe levels. The proposed concept makes it possible to design an array with a scalable antenna beamwidth, depending on the number of antennas. The concept was evaluated by building a 64-element prototype in the LTE frequency bands. Calibration and validation were performed in an anechoic chamber. Finally, the array was successfully used with a channel sounder to estimate in real time the polarization and direction of arrival in LOS configuration. Results were shown on radiophoto.

Future work will use the antenna array in indoor and outdoor environments to get new channel measurements in different settings and contribute to the improvement of massive MIMO propagation modeling. High resolution algorithms will be also implemented to increase the DoA estimate accuracy.

  a) 5×5 UPA b) 25 SUPA Fig. 1 : Array geometry a) Beam angle phi = 0° b) Beam angle phi = 30° Fig. 2 : Beam characteristics of the UPA and SUPA c) Scalable design Massive MIMO systems use a large number of antennas.

Fig. 5 :

 5 Fig. 5 : The final elementary module e) Module Assembly The flexible geometry antenna is simply built from the association of several elementary bricks as shown in the Fig. 3.To simplify post-processing, the radiation patterns of all the slots should be similar. However, the radiation is disturbed by the adjacent slots due to the coupling effect. Electromagnetic simulation showed that a minimum of two slots on each side is required to avoid border effects. For this reason, two rows of dummy slots were added. Absorptive switches were chosen to reduce the fringing field effect.

  Fig. 7 : 3D radiation pattern calibration

  represents the received signal on the i th antenna. The antenna array response in direction ( , ) θ ϕ is defined by the vector is the far field gain of the i th antenna. The weighting vector( , ) w θ ϕ to steer in direction ( , )

Fig. 8 :Fig. 10 :

 810 Fig. 8 : Equipment set-up

  Fig. 11 : Wideband channel sounder measurement setup

Fig. 13 :

 13 Fig. 13 : real-time radio photo (LOS + reflected path)

TABLE I .

 I

	Position		TA	TB
	Beamforming	Azimuth Elevation	18° 89°	28° 100°
	Geometrical	Azimuth Elevation	21.7° 90°	33° 103.9°

ACKNOWLEDGMENT

The authors wish to thank the MVG Company for access to the SG 32 facilities. They also acknowledge the financial support of the "Agence National de la Recherche" who funded the "spatial modulation" collaborative project in which this work was partly done.