# Exploiting Partial Reconfiguration through PCIe for a Microphone Array Network Emulator

Authors: Bruno da Silva; An Braeken; Federico Domínguez; Abdellah Touhafi
Journal: International Journal of Reconfigurable Computing
 (2018)

---

## Abstract

The current Microelectromechanical Systems (MEMS) technology enables the deployment of relatively low-cost wireless sensor networks composed of MEMS microphone arrays for accurate sound source localization. However, the evaluation and the selection of the most accurate and power-efficient network’s topology are not trivial when considering dynamic MEMS microphone arrays. Although software simulators are usually considered, they consist of high-computational intensive tasks, which require hours to days to be completed. In this paper, we present an FPGA-based platform to emulate a network of microphone arrays. Our platform provides a controlled simulated acoustic environment, able to evaluate the impact of different network configurations such as the number of microphones per array, the network’s topology, or the used detection method. Data fusion techniques, combining the data collected by each node, are used in this platform. The platform is designed to exploit the FPGA’s partial reconfiguration feature to increase the flexibility of the network emulator as well as to increase performance thanks to the use of the PCI-express high-bandwidth interface. On the one hand, the network emulator presents a higher flexibility by partially reconfiguring the nodes’ architecture in runtime. On the other hand, a set of strategies and heuristics to properly use partial reconfiguration allows the acceleration of the emulation by exploiting the execution parallelism. Several experiments are presented to demonstrate some of the capabilities of our platform and the benefits of using partial reconfiguration.


---

## Body

## 1. Introduction

Wireless sensor networks (WSN) composed of microphone arrays are becoming popular [1, 2] thanks to the relatively low cost of Microelectromechanical Systems (MEMS) sensors. However, validation and verification of these networks, using simulations, are time consuming procedures. Furthermore, before the deployment of a WSN composed of microphone arrays, the network must be tested in adapted environments such as anechoic chambers to avoid undesired reflections, possible distortions, or acoustic artifacts. Simulators offer usually a solution since they quickly provide information about the capabilities of a network. For instance, they can be used to explore the effects of different node’s architectures, network topologies, or network synchronization strategies. However, simulation processes are computationally intensive tasks which usually require hours or days to complete. Due to the inherent parallelism that microphone arrays present, we believe that FPGAs can accelerate the simulation of such type of networks. Here we present an extended version of the microphone array network emulator (NE) presented in [3, 4], which mimics the node’s response, combines the response of the network’s nodes, and provides an estimation of the network’s response under a certain acoustic scenario. Therefore, instead of a pure software-based NE like the one presented in [1], the proposed NE uses an FPGA to accelerate the node’s computation by implementing exactly the same HDL code that is going to be deployed in the nodes of a real network. From one side, an improved version of the sound source locator proposed in [5] and accelerated in [6] is used as nodes of the network. From the other side, the NE uses partial reconfiguration (PR) to adapt the network topology and the node’s configuration to increase accuracy of the sound source location. As a result, the functionalities of our NE are distributed between the host and the FPGA, using a high-bandwidth PCI-express (PCIe) interface for the communication and PR.This paper extends the work and results presented in [3, 4]. On the one hand, this paper presents a more detailed description of the NE platform, by providing low-level details of the node’s architectures under evaluation and detailed use of PR through PCIe. On the other hand, the use of PR through PCIe is exploited to not only extend the capabilities of the NE but also accelerate the emulation of multiple network’s topologies. The main contributions of this work can be summarized as follows:(i)
A fully detailed architecture description of an FPGA-basedNE, providing low-level details of the platform and how the PR via PCIe is used to reconfigure the network’s characteristics.(ii)
Strategies and heuristics to exploit the use ofPR through PCIe to further accelerate the computations on the FPGA.This paper is organized as follows. The motivation of includingPR as part of our system is done in Section 2. Section 3 presents related work. The description of the NE architecture, the data fusion technique, and the PR is done in Section 4. How PR is used to expand the supported nodes’ configurations of the NE and how to accelerate executions of the emulator by using PR is described in Section 5. In Section 6, the proposed NE is used to evaluate certain network’s configurations. Finally, our conclusions are presented in Section 7.


## 2. Why Partial Reconfiguration?

P R is a unique feature of FPGAs which allows us to change the functionality of a part of the reconfigurable logic in runtime. This results not only in a better reuse of area but also in a potential increment of performance when properly applied. Streaming applications demanding multiple individual computations of similar tasks but with different configurations are the ideal candidates. Furthermore, the execution of streaming applications on FPGAs can exploit parallelism by means of pipelining.Reconfigurable resources are divided into static and dynamic parts when applyingPR. The resources for the communication interfaces or for the PR control are usually in the static part. The dynamic part supports PR at runtime to allocate different mutually exclusive functionalities, known as reconfigurable modules (RM). The reserved logic resources for the dynamic part are denoted as reconfigurable partitions (RP). Thus, each RP is dimensioned to provide enough logic resources to support several RMs.


### 2.1. Beyond the Available Resources

PR allows a higher level of resource reuse because functionality can be multiplexed in time on the reconfigurable logic. Such feature allows the allocation of different tasks in the sameRP. The only condition is that their associated RMs must be multiplexed in time by partially reconfiguring the RP.The benefit ofPR for efficient resources’ management has been exploited in different ways in recent years. For instance, the architecture presented in [7] supports 80 distinct hardware architectures, with different levels and precisions, of DCT computations. Other applications, instead, use PR to switch between applications’ modes in order to reduce the consumed FPGA resources and the overall power consumption. An example is presented in [8], where different image processing operations are switched in runtime to more power-efficient modes. The runtime management of the FPGA’s resources through PR allows self-adaptive or self-repairing systems such as the one presented in [9]. Further examples of how PR improves the resource utilization and increases the flexibility of the system are detailed in [10].


### 2.2. Performance Opportunities

P R has area and time cost. On the one hand, additional area is dedicated to support PR. On the other hand, the PR of a RP requires a certain amount of time, which is directly related to the size of the RP and the available BW to load the bitmap. Everything is slightly different when considering PR over PCIe. PR is usually exploited for small FPGAs or FPGA-based SoC. In such devices, the logic resources are very limited, which evidences the benefit of PR by multiplexing in time the available resources. An FPGA board with PCIe is typically a high-end FPGA offering a large amount of resources to support high-performance applications. Thus, the sizes of the RPs are usually larger to exploit the available resources and/or to allocate complex applications demanding many logic resources. As a consequence, the corresponding bitmaps of the RMs are bigger, consuming more external on-board memory. Fortunately, since PR over PCIe is supported, the bitmap files can be located on the host side and be loaded through PCIe. The use of a high-bandwidth interface such as PCIe not only allows the reduction of the PR’s area overhead but also provides new opportunities to the use of FPGAs as hardware accelerators. However, a proper placement and scheduling of the tasks to be executed on the FPGA is mandatory to compensate the remaining time overhead.


### 2.3. Our Approach

P R offers several benefits in the context of a microphone array network emulator. As mentioned above, the reuse of the logic resources increases the flexibility of the NE by modifying the functionalities in runtime. For instance, PR allows the evaluation of different node’s architectures in runtime as has been shown in [3, 4]. Thanks to PR, the area reuse not only increases the system’s flexibility but can be also used to increase performance when exploiting the level of parallelism of the tasks of the NE accelerated on the FPGA. Figure 1 depicts the main idea, where a RP is configured to support a scalable algorithm, which processes several inputs in parallel (e.g., a convolutional filter with several kernel sizes). The performance doubles thanks to partially reconfiguring the RP to support two instances of the algorithm while consuming the same area. Of course, the overall performance by using PR through PCIe only increases if the time overhead is reduced. As extension of the platform is presented in [3], we propose several heuristics to properly place and schedule the nodes’ configurations. The overall result is a flexible platform optimized to achieve the highest area and performance efficiency.Figure 1
The use orPR allows us to exploit the available resources for different algorithm’s configurations. For instance, when not all the input data need to be processed (dash arrows) the RP can be reconfigured to allocate more instances of the algorithm, doubling the throughput in this example.


## 2.1. Beyond the Available Resources

PR allows a higher level of resource reuse because functionality can be multiplexed in time on the reconfigurable logic. Such feature allows the allocation of different tasks in the sameRP. The only condition is that their associated RMs must be multiplexed in time by partially reconfiguring the RP.The benefit ofPR for efficient resources’ management has been exploited in different ways in recent years. For instance, the architecture presented in [7] supports 80 distinct hardware architectures, with different levels and precisions, of DCT computations. Other applications, instead, use PR to switch between applications’ modes in order to reduce the consumed FPGA resources and the overall power consumption. An example is presented in [8], where different image processing operations are switched in runtime to more power-efficient modes. The runtime management of the FPGA’s resources through PR allows self-adaptive or self-repairing systems such as the one presented in [9]. Further examples of how PR improves the resource utilization and increases the flexibility of the system are detailed in [10].


## 2.2. Performance Opportunities

P R has area and time cost. On the one hand, additional area is dedicated to support PR. On the other hand, the PR of a RP requires a certain amount of time, which is directly related to the size of the RP and the available BW to load the bitmap. Everything is slightly different when considering PR over PCIe. PR is usually exploited for small FPGAs or FPGA-based SoC. In such devices, the logic resources are very limited, which evidences the benefit of PR by multiplexing in time the available resources. An FPGA board with PCIe is typically a high-end FPGA offering a large amount of resources to support high-performance applications. Thus, the sizes of the RPs are usually larger to exploit the available resources and/or to allocate complex applications demanding many logic resources. As a consequence, the corresponding bitmaps of the RMs are bigger, consuming more external on-board memory. Fortunately, since PR over PCIe is supported, the bitmap files can be located on the host side and be loaded through PCIe. The use of a high-bandwidth interface such as PCIe not only allows the reduction of the PR’s area overhead but also provides new opportunities to the use of FPGAs as hardware accelerators. However, a proper placement and scheduling of the tasks to be executed on the FPGA is mandatory to compensate the remaining time overhead.


## 2.3. Our Approach

P R offers several benefits in the context of a microphone array network emulator. As mentioned above, the reuse of the logic resources increases the flexibility of the NE by modifying the functionalities in runtime. For instance, PR allows the evaluation of different node’s architectures in runtime as has been shown in [3, 4]. Thanks to PR, the area reuse not only increases the system’s flexibility but can be also used to increase performance when exploiting the level of parallelism of the tasks of the NE accelerated on the FPGA. Figure 1 depicts the main idea, where a RP is configured to support a scalable algorithm, which processes several inputs in parallel (e.g., a convolutional filter with several kernel sizes). The performance doubles thanks to partially reconfiguring the RP to support two instances of the algorithm while consuming the same area. Of course, the overall performance by using PR through PCIe only increases if the time overhead is reduced. As extension of the platform is presented in [3], we propose several heuristics to properly place and schedule the nodes’ configurations. The overall result is a flexible platform optimized to achieve the highest area and performance efficiency.Figure 1
The use orPR allows us to exploit the available resources for different algorithm’s configurations. For instance, when not all the input data need to be processed (dash arrows) the RP can be reconfigured to allocate more instances of the algorithm, doubling the throughput in this example.


## 3. Related Work

In this section, we provide an overview of similar previous work and explain the relations and differences compared to our work.FPGAs have been already used as emulators for WSN. The authors in [11] propose an FPGA-based WSN emulator for the design, simulation, and evaluation of WSNs. Similarly, the authors in [12] present an FPGA-based wide-band wireless channel emulator able to generate white Gaussian noise and multipath and Doppler fading effects. Both works are complementary to ours as we focus on a detailed emulation of a network node while simplifying the wireless communication aspect. Furthermore, the PR of our emulator provides a higher dynamism and flexibility, which is not exploited in the mentioned emulators.The use ofPR has been thoroughly explored and proposed during the last decades. From one side, the use of PR to change the configuration of a node in a network has been already considered. For example, a LUT-based PR is proposed in [13] as part of an adaptive beamformer and in [5] to obtain a dynamic angular resolution of their acoustic beamforming. Our NE, however, considers the complete reconfiguration of the node and not only a minor component. Thanks to this additional flexibility different architectures can be evaluated on the nodes.From the other side, the use ofPR induces certain area and time overhead. Specially critical is the time overhead, which must be overcome in order to achieve high performance. Several authors have proposed strategies to mitigate the impact of this overhead. The approach proposed in [14] minimizes the total reconfiguration time when distributing the tasks onto the target architecture, through a proper placement and scheduling. Despite the authors exploiting task’s similarities, they do not use such characteristic to further exploit the RP resources. The optimal placement and scheduling are an NP-problem which is usually solved as an Integer-Linear Programming (ILP) problem. Thus, the authors in [15] present their ILP model together with an heuristic to exploit PR techniques such asmodule reuse to reduce the number of reconfigurations. However, their approach does not consider the use of PR to increment the resource sharing of the RPs. Our approach, instead, not only considers themodule reuse during execution time but also takes advantage of task’s similarities to share logic resources of RPs. A more similar work to the one presented here is presented in [16]. The authors propose the resource sharing of RPs by merging tasks of streaming applications thanks to identifying similarities between tasks. Although our approach addresses similar applications, our strategy prioritizes the maximum area reuse of RPs while reducing the number of reconfigurations on a PCIe-based FPGA. Despite the fact that none of the mentioned works uses PCIe, PR through PCIe has been already targeted in [17, 18]. Our proposed NE presents a more complex application which benefits from the current state-of-the-art technology [19]. As far as we are aware, the presented NE is one of the first applications using the recently introduced Xilinx MCAP [20] to partially reconfiguring the FPGA through PCIe.


## 4. Network Emulator Description

The main purpose of theNE (Figure 2) is to mimic the functionality of a network composed of microphone array nodes and to evaluate the network’s response for certain acoustic scenarios. This network increases the accuracy of the sound source location by combining the response of each node. This information is used as an early estimation about how the network would react in real-world scenarios and allows a fast design space exploration in order to target priorities like overall power consumption or the accuracy of the sound source localization. Our NE is flexible enough to support multiple network topologies, different sound source detection methods, or a variable number of nodes and sound sources.Figure 2
Distribution of theNE’s components. The PR of the nodes and the data communication between the host and the FPGA are done via PCIe. A middleware abstracts the application from the heuristics for the merging and scheduling of the nodes’ configurations, the host-FPGA communication, and the PR control. The dark blue boxes represent the components involved in the PR.Figure3 summarizes the execution steps of the NE. One or multiple sound sources are generated for a target scenario composed of a variable number of nodes. Each execution consists of several iterations to compute all the necessary nodes on the available RPs. The data collected from the nodes, thepolar steering response maps, are fused and used to estimate the position of the sound sources. An evaluation of the error is done by considering the estimated position where the sound source is located and the known position of the sound source. Then, based on the target strategy under evaluation, the network is readjusted by partially reconfiguring the nodes with different configurations. The overall network power consumption and the accuracy of the sound source location are examples of potential strategies.Figure 3
Execution steps of theNE. The sound sources are generated and processed by the nodes. The nodes of the network are reconfigured based on the error obtained after the evaluation of the data fusion.


### 4.1. Distributed Functionality

TheNE is built using the node’s architecture described in the previous section. Thanks to the scalability and flexibility of the architecture, each node of the network can present a different configuration. The network is designed to preserve this flexibility in order to adapt its response for the variances in the acoustic environment. Therefore, the NE must support multiple node’s possible configurations [6]. Some configurations are supported thanks to control signals, to disable certain microphones, or through PR, especially when evaluating the use of different architectures. Further details regarding the supported node’s configurations are provided in Section 4.4.Figure2 depicts the main components of the NE, which are distributed between the host and the FPGA.


#### 4.1.1. Host

The host contains the sound source generator, the data fusion of the polar maps, and the evaluation of the data fusion. A graphical user interface (Figure4) abstracts the user from these computations and from the host-FPGA communication and PR. The graphical user interface consists of a front-end generated in Matlab that communicates with the FPGA back-end through amiddleware. The front-end is capable of simulating a sound field with multiple sound sources and nodes. Each sound source can have different frequency bands and each node can have different array configurations and calculation methods. Multiple sound sources are converted to PDM format in order to be compatible with the expected input data format of the node. The front-end is also capable of generating probability maps with thepolar steering response map produced by the nodes on the FPGA.Figure 4
The data fusion front-end is capable of simulating a sound field with multiple sound sources (green diamond) and multiple nodes (pink circles). The front-end generates PDM signals for each microphone in each node that are then sent to the FPGA back-end. The FPGA generates the corresponding polar steering response map (a) which is then fed to the data fusion algorithm to generate a probability map (b) and estimate the localization error.
(a)
Fetchingpolar steering response map from the FPGA (b)
Fusing the data to locate the sound sourceThe front-end uses data fusion to locate sound sources. Data fusion techniques combine the information gathered by different sensors measuring the same process to enhance the understanding of that process. In the context of this article, data fusion is performed by aggregating and combining the acoustic directivity information, represented as apolar steering response map, gathered by each node to produce a probability map of the location of the observed sound sources in a two-dimensional field. This technique is originally presented in [1] and has been used to validate the capacity of their microphone array design to locate sound sources (Figure 5).Figure 5
Our data fusion technique combines the polar steering response map produced by each node to generate a probability map that estimates the location of the observed sound sources. As more nodes are used, the localization accuracy is improved. This technique has been adapted from [1].
(a)
One node (b)
Two nodes (c)
Four nodesBased on the data fusion results, the front-end calculates three error parameters: the localization error (in meters), the number of undetected sound sources, and the number of phantom sound sources.The front-end allows us to create a network of nodes and to validate our architecture with a permutation of different scenarios: array architecture, detection method, sound spectrum, and sound source positions.Finally, amiddleware abstracts the application from the acceleration on the FPGA by managing the nodes’ configurations, the FPGA’s PR, and the host-FPGA communication. Further details about the heuristics for the placement and schedule of the nodes are detailed in Section 5.


#### 4.1.2. PCIe Communication

The communication between the host and the FPGA uses the Xilinx PCIe DMA driver available in [21]. This driver enables the interaction of the software running on the host with the DMA endpoint IP via PCIe.


#### 4.1.3. FPGA

On the FPGA side, theNE uses the IP core DMA subsystem for PCIe [22]. This IP core provides support for different types of reconfiguration through PCIe, such as Tandem, Tandem with Field Updates, and PR. In our case, the IP core DMA subsystem for PCIe with PR support is used. The DMA capability of this core is configured to act like an AXI4 bridge, operating at 125 MHz and with an AXI4 stream interface of 256 bitwidth. The HDL code of each node is encapsulated in an AXI4-Stream Wrapper in order to be compatible with AXI4-Stream. This AXI4-Stream Wrapper interfaces an input AXI4-Stream FIFO, both integrated in a Node Emulator entity. The NE is composed of 4 Node Emulators operating at 62.5 MHz and with a 64-bits AXI4-Stream interface each. Finally, the output AXI4-streams of the Node Emulators are combined in a 256-bits AXI4-Stream to interface the PCIe DMA Subsystem IP core.


### 4.2. Node Description

The original architecture proposed in [5] has been improved in [6] by rearranging the detection method (DM) in a modular fashion and by reducing the control management. The filter stage has been also modified to operate uninterruptedly during the beamed orientation transition. The implementation of the node’s architecture on the FPGA (Figure 6) is done in VHDL and designed to process in stream fashion. Moreover, the nodes of the NE are composed of several cascaded stages operating in pipeline for a fast sound source location.Figure 6
Node’s design emulated in theNE using P-SRP detection method. Each node is composed of a MEMS microphone array, a filter stage, a beamforming stage, and a detection stage.


#### 4.2.1. Microphone Array

The audio data is acquired by the microphone arrays and expressed as a multiplexed pulse density modulation (PDM). The microphone array is composed of four concentric subarrays of 4, 8, 16, and 24 digital MEMS microphones [23] mounted on a 20-cm circular printed board (Figure 7). Each subarray is dynamically activated or deactivated in order to facilitate the capture of spatial acoustic information using a beamforming technique. The distributed geometry of the subarrays allows the adaptation of the sensor to different sound sources. Therefore, the computational demand is adapted to the surrounding acoustic field, making the sensor array more power efficient if only a necessary number of subarrays are active. The emulation of the microphone array is partially done at the host side by the sound generator. The sound wave corresponding to the sound sources is generated in a PDM format for each microphone based on the node to be emulated and the position of the microphone in the node. The frequency band of the audio sources ranges from 100 Hz up to 15 kHz. In order to respect the technical specifications of the ADMP521 MEMS microphones, the generated audio signals are oversampled at 2 MHz.Figure 7
Sound source localization device composed of 4 digital MEMS microphone subarrays.


#### 4.2.2. Filter Stage

The single-bit PDM signal needs to be filtered to remove the high-frequency noise and to be downsampled to retrieve the audio signal in a Pulse-Code Modulation (PCM) format. The removal of the undesired high-frequency noise and the downsampling are done at the filter stage. Thus, each microphone signal has one cascade of filters to downsample and to remove the high-frequency noise. The first filter is a4th order low pass Cascaded Integrated-Comb (CIC) decimator filter with a decimation factor of 16. This type of filter only involves additions and subtractions [24], which significantly reduces the resource consumption. The CIC filter is followed by a 32-bits running average block to reduce the microphone DC offset and by a 15th order serial low pass FIR filter with a cut-off frequency of 12 kHz and a decimation factor of 4 completes the filter chain. The serial design of the FIR filter drastically reduces the resource consumption but limits the maximum order of the filter, which must be equal to the decimation factor of the CIC filter. The data representation is a signed 32-bits fixed point representation with 16 bits as fractional part. The filter’s coefficients are represented with 16 bits. However, the bitwidth is higher in the filter to keep the proper data resolution due to some internal filter operations, but the interfilter data representation is set to constant by applying the proper adjustment at the output of each filter.


#### 4.2.3. Beamforming Stage

Beamforming techniques focus the array to a specific orientation by amplifying the sound coming from the predefined direction, while suppressing the sound coming from other directions. Therefore, the directional variations of the surrounding sound field are measured by continuously steering the focus direction in a 360° sweep. Our Delay-and-Sum based beamformer is applied to 64 orientations, which represents an angular resolution of 5.625 degrees.The filtered signal of each microphone is delayed by a specific amount of time determined by the focus direction, the position vector of the microphone, and the speed of sound. All possible delays are precomputed, grouped based on the supported beamed orientations, and stored in block RAMs (BRAM) during the compilation time. Therefore, the 32-bits filtered audio of each microphone is delayed based on the precomputed values and grouped following their subarray structure to support a variable number of active microphones. Thus, instead of implementing one simple beamforming operation of 52 microphones, there are four beamforming operations in parallel for the 4, 8, 16, and 24 microphones. Only the beamforming block linked to an active subarray is enabled, while the disabled beamformers are set to zero.


#### 4.2.4. Detection Stage

Thepolar steering response maps are obtained at this stage. The output data is normalized based on the maximum output value for each complete loop. The normalized outputs need to be represented with at least 16 bits to avoid errors due to the data representation.We distinguish here 2 differentDMs. Both methods, already proposed in [3], can be available by partially reconfiguring the node’s architecture based on the active subarrays.Polar Steered Response Power. The original architecture in [1] proposed the Delay-and-Sum beamforming technique. This technique uses the added beamformed values to calculate the output power of the signal per orientation in the time domain. The computation of this output power for different beamed orientations defines thePolar Steered Response Power (P-SRP). The P-SRP informs in which direction the sound source is located since the maximum power is obtained when the focus corresponds to the location of a sound source.Cross-Correlation. The cross-correlation (CC) method is based on the cross-correlated pairs of microphones. Thus, the time-differences-of-arrival (TDoA) is the lag associated with the maximum measured correlation. The P-SRP method is more robust to reverberation and noise effects [25] since it considers all available information. Nevertheless, we propose the alternative implementation of CC where all the global information is used and the difference between beamed orientations is amplified. Once the audio is beamformed, the audio data of all microphones are cross-correlated with each other and accumulated. Thus, once the audio data is properly delayed, the maximum of the positive values determines the location of a sound source. This CC method, however, demands a high number of multiplications because all possible pairs of microphones need to be correlated. The total number of multiplications (Mam) depends on the number of active microphones (Nam) and is expressed as follows:(1)Mam=Nam·Nam-12.Unfortunately,Mam drastically increases when increasing the number of active microphones. For instance, Mam=6 when only the inner subarray, composed of 4 microphones, is active. Furthermore, Mam increases from 66 to 1326 when activating the first two inner subarrays (12 microphones) or all subarrays (52 microphones), respectively. This fact has a significant impact in the resource consumption, since not only a large number of DSPs are consumed but also the LUTs are used to keep the fixed point precision. Each multiplication extends the 32-bit fixed point data representation to 64 bits, which is adjusted to 32 bits again before the next multiplication in the multiplication tree [3].TheCC method promises better accuracy when using a lower number of microphones. The theoretical implementation needs 66 multiplications in order to reach all possible combinations of the 12 active microphones. However, in order to save resources while maintaining the maximum flexibility, the implementation under evaluation only considers the combinations between the microphones of a subarray and not the combinations between the microphones of different subarrays. Therefore, the number of multiplications is reduced to 32, with 6 and 28 multiplications for the 4 microphones of the inner subarray and the 8 microphones of the second subarray, respectively. Because this modular CC promises higher accuracy, it is an interesting candidate to replace the P-SRP method when a low number of microphones is active. The analysed CC method in our experiments only considers the use of the two inner subarrays.


### 4.3. Accuracy

The effective dynamic range of the floating point data representation provides a high accuracy at the cost of a high resource consumption and a performance cost, which discourages the use of floating point operations in the node’s architecture. The alternative fixed point data representation, however, induces undesired errors [26, 27]. The most sensitive blocks of the node’s architecture are located in the filter and the detection stages. A variable fixed point representation is applied at each node’s stage to minimize the errors induced by this type of data representation. The internal operations in the filters are scaled in order to provide enough bits for the data representation. However, in order to reduce the overall resource consumption, the output of each block is rescaled to signed 32-bit fixed point representation with 16 bits of fractional part. The evaluation of the impact in the accuracy of the node’s response has been performed for each supported frequency by comparing the results with our reference model programmed in Matlab which mimics the node’s architecture and is already used in [3–6]. As a result, the fixed point data representation at each stage of the node’s architecture guarantees an average relative error of 2.42×10-5, compared to floating point data representation.


### 4.4. Design Space Exploration

Table1 summarizes the most relevant parameters that can be evaluated in our platform. Some parameters are related to the node’s architecture while others are relevant at the network perspective. Although the node’s parameters like the impact of the number of orientations or the sensing time have been discussed in [6] from the performance point of view, the NE allows the evaluation of the network’s configurations. For instance, different data fusion techniques or network topologies for a lower network’s power consumption can be evaluated. Moreover, the error induced by the data desynchronization from the nodes can be estimated. Notice that, due to the distribution of the functionality, the node’s parameters affect the FPGA design while the network’s parameters affect the code running on the host. Therefore, in order to focus on how PR can be exploited by our platform, only a couple of node’s parameters are considered for the design space exploration.Table 1
The proposed platform enables the exploration of multiple node’s and network’s configurations.
Perspective Evaluation Node (FPGA) Detection method Number of active microphones Number of orientations Sensing time  Network (host) Data Fusion techniques Power efficiency topology Data desynchronizationThe node’s architecture permits the modification ofNam in runtime (Figure 6) to adapt the node’s response to the dynamic behavior of acoustic environments. However, Nam has a significant impact in the area consumption and in the node’s power consumption as detailed in [6]. This fact makes Nam an interesting parameter to be evaluated from a network point of view because while a lower Nam leads to a lower node’s power consumption, a lower accuracy is the price to pay. Further details about the node’s architecture, demanded hardware resources, and the impact of the supported configurations are detailed in [6].Although different node’s configurations are supported in runtime, this does not occur with theDMs, since only one of the proposed DMs can be allocated on the FPGA. As a consequence, the switch between the proposed DMs is only possible when using PR. Nevertheless, the evaluation of the DMs is fully supported in our NE for the two inner subarrays. Both parameters are used to evaluate networks composed of nodes with variable values of Nam and DMs (Table 2). The experimental results are presented in Section 6.Table 2
The experimental results detailed in Section6 are obtained by evaluating different node’s configurations.
Parameter Definition Range DM Detection method [P-SRP, CC] N a m Number of active microphones [ 4 ,  12 ,  28 ,  52 ]


## 4.1. Distributed Functionality

TheNE is built using the node’s architecture described in the previous section. Thanks to the scalability and flexibility of the architecture, each node of the network can present a different configuration. The network is designed to preserve this flexibility in order to adapt its response for the variances in the acoustic environment. Therefore, the NE must support multiple node’s possible configurations [6]. Some configurations are supported thanks to control signals, to disable certain microphones, or through PR, especially when evaluating the use of different architectures. Further details regarding the supported node’s configurations are provided in Section 4.4.Figure2 depicts the main components of the NE, which are distributed between the host and the FPGA.


### 4.1.1. Host

The host contains the sound source generator, the data fusion of the polar maps, and the evaluation of the data fusion. A graphical user interface (Figure4) abstracts the user from these computations and from the host-FPGA communication and PR. The graphical user interface consists of a front-end generated in Matlab that communicates with the FPGA back-end through amiddleware. The front-end is capable of simulating a sound field with multiple sound sources and nodes. Each sound source can have different frequency bands and each node can have different array configurations and calculation methods. Multiple sound sources are converted to PDM format in order to be compatible with the expected input data format of the node. The front-end is also capable of generating probability maps with thepolar steering response map produced by the nodes on the FPGA.Figure 4
The data fusion front-end is capable of simulating a sound field with multiple sound sources (green diamond) and multiple nodes (pink circles). The front-end generates PDM signals for each microphone in each node that are then sent to the FPGA back-end. The FPGA generates the corresponding polar steering response map (a) which is then fed to the data fusion algorithm to generate a probability map (b) and estimate the localization error.
(a)
Fetchingpolar steering response map from the FPGA (b)
Fusing the data to locate the sound sourceThe front-end uses data fusion to locate sound sources. Data fusion techniques combine the information gathered by different sensors measuring the same process to enhance the understanding of that process. In the context of this article, data fusion is performed by aggregating and combining the acoustic directivity information, represented as apolar steering response map, gathered by each node to produce a probability map of the location of the observed sound sources in a two-dimensional field. This technique is originally presented in [1] and has been used to validate the capacity of their microphone array design to locate sound sources (Figure 5).Figure 5
Our data fusion technique combines the polar steering response map produced by each node to generate a probability map that estimates the location of the observed sound sources. As more nodes are used, the localization accuracy is improved. This technique has been adapted from [1].
(a)
One node (b)
Two nodes (c)
Four nodesBased on the data fusion results, the front-end calculates three error parameters: the localization error (in meters), the number of undetected sound sources, and the number of phantom sound sources.The front-end allows us to create a network of nodes and to validate our architecture with a permutation of different scenarios: array architecture, detection method, sound spectrum, and sound source positions.Finally, amiddleware abstracts the application from the acceleration on the FPGA by managing the nodes’ configurations, the FPGA’s PR, and the host-FPGA communication. Further details about the heuristics for the placement and schedule of the nodes are detailed in Section 5.


### 4.1.2. PCIe Communication

The communication between the host and the FPGA uses the Xilinx PCIe DMA driver available in [21]. This driver enables the interaction of the software running on the host with the DMA endpoint IP via PCIe.


### 4.1.3. FPGA

On the FPGA side, theNE uses the IP core DMA subsystem for PCIe [22]. This IP core provides support for different types of reconfiguration through PCIe, such as Tandem, Tandem with Field Updates, and PR. In our case, the IP core DMA subsystem for PCIe with PR support is used. The DMA capability of this core is configured to act like an AXI4 bridge, operating at 125 MHz and with an AXI4 stream interface of 256 bitwidth. The HDL code of each node is encapsulated in an AXI4-Stream Wrapper in order to be compatible with AXI4-Stream. This AXI4-Stream Wrapper interfaces an input AXI4-Stream FIFO, both integrated in a Node Emulator entity. The NE is composed of 4 Node Emulators operating at 62.5 MHz and with a 64-bits AXI4-Stream interface each. Finally, the output AXI4-streams of the Node Emulators are combined in a 256-bits AXI4-Stream to interface the PCIe DMA Subsystem IP core.


## 4.1.1. Host

The host contains the sound source generator, the data fusion of the polar maps, and the evaluation of the data fusion. A graphical user interface (Figure4) abstracts the user from these computations and from the host-FPGA communication and PR. The graphical user interface consists of a front-end generated in Matlab that communicates with the FPGA back-end through amiddleware. The front-end is capable of simulating a sound field with multiple sound sources and nodes. Each sound source can have different frequency bands and each node can have different array configurations and calculation methods. Multiple sound sources are converted to PDM format in order to be compatible with the expected input data format of the node. The front-end is also capable of generating probability maps with thepolar steering response map produced by the nodes on the FPGA.Figure 4
The data fusion front-end is capable of simulating a sound field with multiple sound sources (green diamond) and multiple nodes (pink circles). The front-end generates PDM signals for each microphone in each node that are then sent to the FPGA back-end. The FPGA generates the corresponding polar steering response map (a) which is then fed to the data fusion algorithm to generate a probability map (b) and estimate the localization error.
(a)
Fetchingpolar steering response map from the FPGA (b)
Fusing the data to locate the sound sourceThe front-end uses data fusion to locate sound sources. Data fusion techniques combine the information gathered by different sensors measuring the same process to enhance the understanding of that process. In the context of this article, data fusion is performed by aggregating and combining the acoustic directivity information, represented as apolar steering response map, gathered by each node to produce a probability map of the location of the observed sound sources in a two-dimensional field. This technique is originally presented in [1] and has been used to validate the capacity of their microphone array design to locate sound sources (Figure 5).Figure 5
Our data fusion technique combines the polar steering response map produced by each node to generate a probability map that estimates the location of the observed sound sources. As more nodes are used, the localization accuracy is improved. This technique has been adapted from [1].
(a)
One node (b)
Two nodes (c)
Four nodesBased on the data fusion results, the front-end calculates three error parameters: the localization error (in meters), the number of undetected sound sources, and the number of phantom sound sources.The front-end allows us to create a network of nodes and to validate our architecture with a permutation of different scenarios: array architecture, detection method, sound spectrum, and sound source positions.Finally, amiddleware abstracts the application from the acceleration on the FPGA by managing the nodes’ configurations, the FPGA’s PR, and the host-FPGA communication. Further details about the heuristics for the placement and schedule of the nodes are detailed in Section 5.


## 4.1.2. PCIe Communication

The communication between the host and the FPGA uses the Xilinx PCIe DMA driver available in [21]. This driver enables the interaction of the software running on the host with the DMA endpoint IP via PCIe.


## 4.1.3. FPGA

On the FPGA side, theNE uses the IP core DMA subsystem for PCIe [22]. This IP core provides support for different types of reconfiguration through PCIe, such as Tandem, Tandem with Field Updates, and PR. In our case, the IP core DMA subsystem for PCIe with PR support is used. The DMA capability of this core is configured to act like an AXI4 bridge, operating at 125 MHz and with an AXI4 stream interface of 256 bitwidth. The HDL code of each node is encapsulated in an AXI4-Stream Wrapper in order to be compatible with AXI4-Stream. This AXI4-Stream Wrapper interfaces an input AXI4-Stream FIFO, both integrated in a Node Emulator entity. The NE is composed of 4 Node Emulators operating at 62.5 MHz and with a 64-bits AXI4-Stream interface each. Finally, the output AXI4-streams of the Node Emulators are combined in a 256-bits AXI4-Stream to interface the PCIe DMA Subsystem IP core.


## 4.2. Node Description

The original architecture proposed in [5] has been improved in [6] by rearranging the detection method (DM) in a modular fashion and by reducing the control management. The filter stage has been also modified to operate uninterruptedly during the beamed orientation transition. The implementation of the node’s architecture on the FPGA (Figure 6) is done in VHDL and designed to process in stream fashion. Moreover, the nodes of the NE are composed of several cascaded stages operating in pipeline for a fast sound source location.Figure 6
Node’s design emulated in theNE using P-SRP detection method. Each node is composed of a MEMS microphone array, a filter stage, a beamforming stage, and a detection stage.


### 4.2.1. Microphone Array

The audio data is acquired by the microphone arrays and expressed as a multiplexed pulse density modulation (PDM). The microphone array is composed of four concentric subarrays of 4, 8, 16, and 24 digital MEMS microphones [23] mounted on a 20-cm circular printed board (Figure 7). Each subarray is dynamically activated or deactivated in order to facilitate the capture of spatial acoustic information using a beamforming technique. The distributed geometry of the subarrays allows the adaptation of the sensor to different sound sources. Therefore, the computational demand is adapted to the surrounding acoustic field, making the sensor array more power efficient if only a necessary number of subarrays are active. The emulation of the microphone array is partially done at the host side by the sound generator. The sound wave corresponding to the sound sources is generated in a PDM format for each microphone based on the node to be emulated and the position of the microphone in the node. The frequency band of the audio sources ranges from 100 Hz up to 15 kHz. In order to respect the technical specifications of the ADMP521 MEMS microphones, the generated audio signals are oversampled at 2 MHz.Figure 7
Sound source localization device composed of 4 digital MEMS microphone subarrays.


### 4.2.2. Filter Stage

The single-bit PDM signal needs to be filtered to remove the high-frequency noise and to be downsampled to retrieve the audio signal in a Pulse-Code Modulation (PCM) format. The removal of the undesired high-frequency noise and the downsampling are done at the filter stage. Thus, each microphone signal has one cascade of filters to downsample and to remove the high-frequency noise. The first filter is a4th order low pass Cascaded Integrated-Comb (CIC) decimator filter with a decimation factor of 16. This type of filter only involves additions and subtractions [24], which significantly reduces the resource consumption. The CIC filter is followed by a 32-bits running average block to reduce the microphone DC offset and by a 15th order serial low pass FIR filter with a cut-off frequency of 12 kHz and a decimation factor of 4 completes the filter chain. The serial design of the FIR filter drastically reduces the resource consumption but limits the maximum order of the filter, which must be equal to the decimation factor of the CIC filter. The data representation is a signed 32-bits fixed point representation with 16 bits as fractional part. The filter’s coefficients are represented with 16 bits. However, the bitwidth is higher in the filter to keep the proper data resolution due to some internal filter operations, but the interfilter data representation is set to constant by applying the proper adjustment at the output of each filter.


### 4.2.3. Beamforming Stage

Beamforming techniques focus the array to a specific orientation by amplifying the sound coming from the predefined direction, while suppressing the sound coming from other directions. Therefore, the directional variations of the surrounding sound field are measured by continuously steering the focus direction in a 360° sweep. Our Delay-and-Sum based beamformer is applied to 64 orientations, which represents an angular resolution of 5.625 degrees.The filtered signal of each microphone is delayed by a specific amount of time determined by the focus direction, the position vector of the microphone, and the speed of sound. All possible delays are precomputed, grouped based on the supported beamed orientations, and stored in block RAMs (BRAM) during the compilation time. Therefore, the 32-bits filtered audio of each microphone is delayed based on the precomputed values and grouped following their subarray structure to support a variable number of active microphones. Thus, instead of implementing one simple beamforming operation of 52 microphones, there are four beamforming operations in parallel for the 4, 8, 16, and 24 microphones. Only the beamforming block linked to an active subarray is enabled, while the disabled beamformers are set to zero.


### 4.2.4. Detection Stage

Thepolar steering response maps are obtained at this stage. The output data is normalized based on the maximum output value for each complete loop. The normalized outputs need to be represented with at least 16 bits to avoid errors due to the data representation.We distinguish here 2 differentDMs. Both methods, already proposed in [3], can be available by partially reconfiguring the node’s architecture based on the active subarrays.Polar Steered Response Power. The original architecture in [1] proposed the Delay-and-Sum beamforming technique. This technique uses the added beamformed values to calculate the output power of the signal per orientation in the time domain. The computation of this output power for different beamed orientations defines thePolar Steered Response Power (P-SRP). The P-SRP informs in which direction the sound source is located since the maximum power is obtained when the focus corresponds to the location of a sound source.Cross-Correlation. The cross-correlation (CC) method is based on the cross-correlated pairs of microphones. Thus, the time-differences-of-arrival (TDoA) is the lag associated with the maximum measured correlation. The P-SRP method is more robust to reverberation and noise effects [25] since it considers all available information. Nevertheless, we propose the alternative implementation of CC where all the global information is used and the difference between beamed orientations is amplified. Once the audio is beamformed, the audio data of all microphones are cross-correlated with each other and accumulated. Thus, once the audio data is properly delayed, the maximum of the positive values determines the location of a sound source. This CC method, however, demands a high number of multiplications because all possible pairs of microphones need to be correlated. The total number of multiplications (Mam) depends on the number of active microphones (Nam) and is expressed as follows:(1)Mam=Nam·Nam-12.Unfortunately,Mam drastically increases when increasing the number of active microphones. For instance, Mam=6 when only the inner subarray, composed of 4 microphones, is active. Furthermore, Mam increases from 66 to 1326 when activating the first two inner subarrays (12 microphones) or all subarrays (52 microphones), respectively. This fact has a significant impact in the resource consumption, since not only a large number of DSPs are consumed but also the LUTs are used to keep the fixed point precision. Each multiplication extends the 32-bit fixed point data representation to 64 bits, which is adjusted to 32 bits again before the next multiplication in the multiplication tree [3].TheCC method promises better accuracy when using a lower number of microphones. The theoretical implementation needs 66 multiplications in order to reach all possible combinations of the 12 active microphones. However, in order to save resources while maintaining the maximum flexibility, the implementation under evaluation only considers the combinations between the microphones of a subarray and not the combinations between the microphones of different subarrays. Therefore, the number of multiplications is reduced to 32, with 6 and 28 multiplications for the 4 microphones of the inner subarray and the 8 microphones of the second subarray, respectively. Because this modular CC promises higher accuracy, it is an interesting candidate to replace the P-SRP method when a low number of microphones is active. The analysed CC method in our experiments only considers the use of the two inner subarrays.


## 4.2.1. Microphone Array

The audio data is acquired by the microphone arrays and expressed as a multiplexed pulse density modulation (PDM). The microphone array is composed of four concentric subarrays of 4, 8, 16, and 24 digital MEMS microphones [23] mounted on a 20-cm circular printed board (Figure 7). Each subarray is dynamically activated or deactivated in order to facilitate the capture of spatial acoustic information using a beamforming technique. The distributed geometry of the subarrays allows the adaptation of the sensor to different sound sources. Therefore, the computational demand is adapted to the surrounding acoustic field, making the sensor array more power efficient if only a necessary number of subarrays are active. The emulation of the microphone array is partially done at the host side by the sound generator. The sound wave corresponding to the sound sources is generated in a PDM format for each microphone based on the node to be emulated and the position of the microphone in the node. The frequency band of the audio sources ranges from 100 Hz up to 15 kHz. In order to respect the technical specifications of the ADMP521 MEMS microphones, the generated audio signals are oversampled at 2 MHz.Figure 7
Sound source localization device composed of 4 digital MEMS microphone subarrays.


## 4.2.2. Filter Stage

The single-bit PDM signal needs to be filtered to remove the high-frequency noise and to be downsampled to retrieve the audio signal in a Pulse-Code Modulation (PCM) format. The removal of the undesired high-frequency noise and the downsampling are done at the filter stage. Thus, each microphone signal has one cascade of filters to downsample and to remove the high-frequency noise. The first filter is a4th order low pass Cascaded Integrated-Comb (CIC) decimator filter with a decimation factor of 16. This type of filter only involves additions and subtractions [24], which significantly reduces the resource consumption. The CIC filter is followed by a 32-bits running average block to reduce the microphone DC offset and by a 15th order serial low pass FIR filter with a cut-off frequency of 12 kHz and a decimation factor of 4 completes the filter chain. The serial design of the FIR filter drastically reduces the resource consumption but limits the maximum order of the filter, which must be equal to the decimation factor of the CIC filter. The data representation is a signed 32-bits fixed point representation with 16 bits as fractional part. The filter’s coefficients are represented with 16 bits. However, the bitwidth is higher in the filter to keep the proper data resolution due to some internal filter operations, but the interfilter data representation is set to constant by applying the proper adjustment at the output of each filter.


## 4.2.3. Beamforming Stage

Beamforming techniques focus the array to a specific orientation by amplifying the sound coming from the predefined direction, while suppressing the sound coming from other directions. Therefore, the directional variations of the surrounding sound field are measured by continuously steering the focus direction in a 360° sweep. Our Delay-and-Sum based beamformer is applied to 64 orientations, which represents an angular resolution of 5.625 degrees.The filtered signal of each microphone is delayed by a specific amount of time determined by the focus direction, the position vector of the microphone, and the speed of sound. All possible delays are precomputed, grouped based on the supported beamed orientations, and stored in block RAMs (BRAM) during the compilation time. Therefore, the 32-bits filtered audio of each microphone is delayed based on the precomputed values and grouped following their subarray structure to support a variable number of active microphones. Thus, instead of implementing one simple beamforming operation of 52 microphones, there are four beamforming operations in parallel for the 4, 8, 16, and 24 microphones. Only the beamforming block linked to an active subarray is enabled, while the disabled beamformers are set to zero.


## 4.2.4. Detection Stage

Thepolar steering response maps are obtained at this stage. The output data is normalized based on the maximum output value for each complete loop. The normalized outputs need to be represented with at least 16 bits to avoid errors due to the data representation.We distinguish here 2 differentDMs. Both methods, already proposed in [3], can be available by partially reconfiguring the node’s architecture based on the active subarrays.Polar Steered Response Power. The original architecture in [1] proposed the Delay-and-Sum beamforming technique. This technique uses the added beamformed values to calculate the output power of the signal per orientation in the time domain. The computation of this output power for different beamed orientations defines thePolar Steered Response Power (P-SRP). The P-SRP informs in which direction the sound source is located since the maximum power is obtained when the focus corresponds to the location of a sound source.Cross-Correlation. The cross-correlation (CC) method is based on the cross-correlated pairs of microphones. Thus, the time-differences-of-arrival (TDoA) is the lag associated with the maximum measured correlation. The P-SRP method is more robust to reverberation and noise effects [25] since it considers all available information. Nevertheless, we propose the alternative implementation of CC where all the global information is used and the difference between beamed orientations is amplified. Once the audio is beamformed, the audio data of all microphones are cross-correlated with each other and accumulated. Thus, once the audio data is properly delayed, the maximum of the positive values determines the location of a sound source. This CC method, however, demands a high number of multiplications because all possible pairs of microphones need to be correlated. The total number of multiplications (Mam) depends on the number of active microphones (Nam) and is expressed as follows:(1)Mam=Nam·Nam-12.Unfortunately,Mam drastically increases when increasing the number of active microphones. For instance, Mam=6 when only the inner subarray, composed of 4 microphones, is active. Furthermore, Mam increases from 66 to 1326 when activating the first two inner subarrays (12 microphones) or all subarrays (52 microphones), respectively. This fact has a significant impact in the resource consumption, since not only a large number of DSPs are consumed but also the LUTs are used to keep the fixed point precision. Each multiplication extends the 32-bit fixed point data representation to 64 bits, which is adjusted to 32 bits again before the next multiplication in the multiplication tree [3].TheCC method promises better accuracy when using a lower number of microphones. The theoretical implementation needs 66 multiplications in order to reach all possible combinations of the 12 active microphones. However, in order to save resources while maintaining the maximum flexibility, the implementation under evaluation only considers the combinations between the microphones of a subarray and not the combinations between the microphones of different subarrays. Therefore, the number of multiplications is reduced to 32, with 6 and 28 multiplications for the 4 microphones of the inner subarray and the 8 microphones of the second subarray, respectively. Because this modular CC promises higher accuracy, it is an interesting candidate to replace the P-SRP method when a low number of microphones is active. The analysed CC method in our experiments only considers the use of the two inner subarrays.


## 4.3. Accuracy

The effective dynamic range of the floating point data representation provides a high accuracy at the cost of a high resource consumption and a performance cost, which discourages the use of floating point operations in the node’s architecture. The alternative fixed point data representation, however, induces undesired errors [26, 27]. The most sensitive blocks of the node’s architecture are located in the filter and the detection stages. A variable fixed point representation is applied at each node’s stage to minimize the errors induced by this type of data representation. The internal operations in the filters are scaled in order to provide enough bits for the data representation. However, in order to reduce the overall resource consumption, the output of each block is rescaled to signed 32-bit fixed point representation with 16 bits of fractional part. The evaluation of the impact in the accuracy of the node’s response has been performed for each supported frequency by comparing the results with our reference model programmed in Matlab which mimics the node’s architecture and is already used in [3–6]. As a result, the fixed point data representation at each stage of the node’s architecture guarantees an average relative error of 2.42×10-5, compared to floating point data representation.


## 4.4. Design Space Exploration

Table1 summarizes the most relevant parameters that can be evaluated in our platform. Some parameters are related to the node’s architecture while others are relevant at the network perspective. Although the node’s parameters like the impact of the number of orientations or the sensing time have been discussed in [6] from the performance point of view, the NE allows the evaluation of the network’s configurations. For instance, different data fusion techniques or network topologies for a lower network’s power consumption can be evaluated. Moreover, the error induced by the data desynchronization from the nodes can be estimated. Notice that, due to the distribution of the functionality, the node’s parameters affect the FPGA design while the network’s parameters affect the code running on the host. Therefore, in order to focus on how PR can be exploited by our platform, only a couple of node’s parameters are considered for the design space exploration.Table 1
The proposed platform enables the exploration of multiple node’s and network’s configurations.
Perspective Evaluation Node (FPGA) Detection method Number of active microphones Number of orientations Sensing time  Network (host) Data Fusion techniques Power efficiency topology Data desynchronizationThe node’s architecture permits the modification ofNam in runtime (Figure 6) to adapt the node’s response to the dynamic behavior of acoustic environments. However, Nam has a significant impact in the area consumption and in the node’s power consumption as detailed in [6]. This fact makes Nam an interesting parameter to be evaluated from a network point of view because while a lower Nam leads to a lower node’s power consumption, a lower accuracy is the price to pay. Further details about the node’s architecture, demanded hardware resources, and the impact of the supported configurations are detailed in [6].Although different node’s configurations are supported in runtime, this does not occur with theDMs, since only one of the proposed DMs can be allocated on the FPGA. As a consequence, the switch between the proposed DMs is only possible when using PR. Nevertheless, the evaluation of the DMs is fully supported in our NE for the two inner subarrays. Both parameters are used to evaluate networks composed of nodes with variable values of Nam and DMs (Table 2). The experimental results are presented in Section 6.Table 2
The experimental results detailed in Section6 are obtained by evaluating different node’s configurations.
Parameter Definition Range DM Detection method [P-SRP, CC] N a m Number of active microphones [ 4 ,  12 ,  28 ,  52 ]


## 5. Strategies for Exploiting Partial Reconfiguration

Themiddleware, located in the host side, is not only in charge of the host-FPGA communication through PCIe but also controlling and to optimizing the PR. This layer abstracts the front-end from the back-end configuration. While the user only needs to configure the topology of the network, the nodes’ configuration, and the sound sources, themiddleware optimizes the execution of the NE by merging and scheduling the nodes in the available PRs. Thus, the user does not need any knowledge about the RPs configurations or in what RP a particular node is emulated.One execution of theNE consists of the emulation of a certain number of nodes under an acoustic context. Themiddleware distributes the nodes between the available RPs. Several iterations are needed in case the number of nodes to be emulated (nnode) is higher than the number of RPs (nRP). Thus, the number of iterations (niter) is defined as(2)niter=nnodenRP.Thanks to the independence of the nodes, there are no data dependencies. This fact simplifies themiddleware decisions. Thus, themiddleware uses some heuristics to optimize the merging of compatible node’s configurations in order to exploit the available resources in one RP and also optimizes the scheduling of the computation of the merged node’s configurations. As a result, themiddleware not only allows the abstraction of the user about the NE internal configuration but also exploits PR to increase performance.


### 5.1. Increasing Network Capabilities

The dynamism required to reduce the estimation error under unpredictable acoustic scenarios is enhanced thanks toPR. A clear example occurs when minimizing the overall network power consumption while offering accurate sound sources location. The overall power consumption and the accuracy are directly related to the Nam. Thus, a trade-off is needed in order to get the highest accurate estimation with the minimum power consumption. PR has a role when considering alternative architectures to enhance the quality of results. That is the case of the CC method, which is only applicable for a lower number of microphones where it promises better accuracy. In that case, PR allows the dynamic modification of the network configuration in runtime to satisfy power constraints. Such evaluation in the NE would not be possible without PR. Otherwise, the platform had to be completely reprogrammed and a reboot would be needed in order to let the operating system identify the reconfigured PCIe device. Our experimental results in Section 6 cover this example.


### 5.2. Heuristics to Increase Performance

Figure8 shows the heuristics used by themiddleware to increase performance. PR can only be exploited for higher performance by properly placing and scheduling the nodes to be accelerated. Furthermore, we propose the use of PR to exploit the configurations’ compatibilities in order to better use the available resources.Figure 8
Our approach consists of several heuristics to optimize the area reuse and to improve performance by reducingPR. Firstly, the nodes’ configurations are classified and sorted based on their compatible RMs. Secondly, the increment of the area reuse is possible by merging similar nodes’ configurations to increase the overall LP. Finally, an optimized scheduler minimizes the PR by properly allocating the nodes.An existing cost table (CT), like Table 3, is used to decide at each step of the heuristics. Such table is elaborated at design time and contains information about the relative area cost of the configurations, related to the most area demanding configuration, and information about configurations’ compatibilities. From one side, the relative area cost reflects the configuration’s level of parallelism (LP), which is used to merge compatible node’s configurations. In fact, LP is the inverse of the relative area cost since it represents the number of nodes with a certain configuration that can be executed in parallel per RP. From the other side, the configurations’ compatibilities relate a certain configuration with its supported RMs. Thanks to the flexible architecture of the nodes, the number of active microphones varies from 4 to 52 MICs. Their activation is in runtime through control signals and does not require any type of PR. As a consequence, certain RMs support multiple node’s configurations depending on the dedicated logic resources. Thus, the RM52 not only supports 52 microphones but also 28, 12, or 4. Such flexibility is used to reduce the number of PR in order to achieve higher performance. A summary of the abbreviations used for the NE description is done in Table 4.Table 3
Cost table of the node’s configurations for the second experiment with the NE. The time values are expressed in seconds.
Configuration Time cost Area cost Compatibility 52 Mics 1.0834 ± 0.0029 1 RM52 28 Mics 1.0753 ± 0.0024 1/2 RM52,RM28 12 Mics 1.0679 ± 0.0023 1/4 RM52,RM28,RM12 4 Mics 1.0677 ± 0.0023 1/4 RM52,RM28,RM12Table 4
Abbreviations used for the description of the NE and the presented heuristics.
Parameter Definition R P Reconfigurable partition R M Reconfigurable module C T Cost table L P Level of parallelism. Inverse of the area cost P - S R P Polar steered response power C C Cross-correlation D M Detection method N a m Number of active microphones M a m Number of multiplications n n o d e Number of nodes’ configurations per execution n i t e r Number of iterations needed by one execution n R P Number of RPs n R C Number of PR N Initial nodes’ configuration list N I Sorted and classified nodes’ configuration list N M Merged nodes’ configuration list N T Temporal nodes’ configuration list N S Scheduled nodes’ configuration list S t e m p Temporal set of RP’s configurations S n o d e [ i ] Set of RP’s configurations on iterationi


#### 5.2.1. Classification

The nodes are classified based on an existingCT like Table 3. This classification identifies the compatible RMs and the LP that can be achieved based on their type. Algorithm 1 details the operations involved during the nodes’ classification. N is composed of multiple nodes’ configurations, which can be optimally parallelized and scheduled to minimize the execution time. The relative area cost of each node is used as reference to sort the nodes’ list in decreasing order. Lately, the nodes’ list is evaluated to identify the compatible RMs per configuration.Algorithm 1:Classification of nodes.
input: Nodes’ configuration list N, CT output: Sorted and classified node list NI (1) begin (2)   NI← Sort nodes based on their area cost (N, CT); (3)   NI← Find Compatible RM (NI, CT); (4) end


#### 5.2.2. Merging

The merging of the nodes’ configurations consists of grouping the maximum number of compatible configurations in oneRP in order to exploit the otherwise unused resources. For instance, in case NI=[52,52,52,28,28,12,12,12,12] the nodes with Nam=28 and Nam=12 can be computed in parallel in RPs configured with RM28 and RM12, respectively (Table 3). Since the RMs are associated with the nodes’ configurations after the merging heuristic, NM for the previous example results in NM=[RM52,RM52,RM52,RM28,RM12]. Notice that niter is reduced in one unit thanks to this merging (2). In fact, the reduction of niter is the main objective of this heuristic.Algorithm2 shows how nodes are merged based on their LP to place in each RP as many nodes as possible. This merging intends to reduce niter and, potentially, the overall execution time. Algorithm 2 starts scanning the list of configurations in increasing relative area cost order. There are three possibilities:(i)
If the configuration consumes a completeRP, which occurs when its cost equals 1, the configuration cannot share any RP. Thus, this configuration is allocated to the largest compatible RM in order to maximize the reuse of this RP. Otherwise, if the demanded relative area cost of the configuration is lower, it can be evaluated for sharing a RP.(ii)
In case the addition of the configuration’s cost and the accumulated area cost of the already allocated nodes is higher than oneRP, this RP is locked. Firstly, the grouped configurations are moved to the configurations’ list NM since they cannot longer share the resources of one RP. Secondly, the new unassigned node’s configuration is assigned to the smallest compatible RM to limit the sharing to the most constrained situation.(iii)
In case area cost of the configuration allows the addition of this node’s configuration to the existing configurations’ group, the accumulated area cost (which represents the percentage of occupancy of theRP) is incremented by the maximum area cost of new node’s configuration. In this way, the area cost of the largest node’s configuration dominates and thus unfeasible situations are avoided.Algorithm 2:Merging of the nodes’ configurations.
input: Nodes’ configuration list NI output: Merged configuration list NM (1) begin (2)   NM←∅; (3)   NT←∅; (4)   fori∈NIdo (5)     ifAreaCost(i) =1then (6)       NT←config(i); (7)       AccAreaCost(NT) ← AreaCost(config(i)); (8)       CompatibleRMs(NT) ← SmallestRM(NT,config(i)); (9)       NM← InsertIn(NM,NT); (10)     end (11)     else (12)       if AreaCost(i) + AccAreaCost(NT) >1then (13)         NM← InsertIn(NM,NT); (14)         NT←config(i); (15)         AccAreaCost(NT) ← AreaCost(config(i)); (16)         CompatibleRMs(NT) ← SmallestRM(NT,config(i)); (17)       end (18)       else (19)         NT← InsertIn(NT,config(i)); (20)         AccAreaCost(NT) ← AccAreaCost(NT) + max(AreaCost(config(i)),AccAreaCost(NT)); (21)        end (22)      end (23)   end (24) endAs a result, the configurations are categorized in the compatibleRMs which maximize the area reuse and potentially increment the overall performance by decreasing niter.


#### 5.2.3. Scheduling

Once the nodes have been merged, they need to be properly scheduled in order to minimize the number of reconfigurations (nRC). The strategy consists in maximizing the reuse of the RP’s previous configurations between iterations of one execution.Algorithm3 details how the merged configurations in NM are scheduled based on the configuration of the RPs in each iteration. The RP’s configuration of the previous iteration is used as initial RP’s configuration of the iteration under scheduling. Thus, the list NM is traverse looking for the same RM loaded in the target RP. If found, the node’s configuration is assigned to that RP at that particular iteration. The process continues for the next RP until all the available nRP are assigned. If there is no compatible node’s configuration with the available RPs at a certain iteration, it could be possible that either all the nodes have been allocated or PR is needed. Based on the number of unallocated nodes, it is possible to distinguish how to proceed. On the one hand, if PR is needed, the most frequent configuration of the unallocated nodes is selected. This configuration is obtained through the calculation of a histogram and maximizes the potential reuse of this configuration over the remaining iterations. On the other hand, the remaining unassigned RPs keep their configuration from the previous iteration to avoid additional and unnecessary PR if there are no more unallocated nodes. The process continues this way until no compatible tasks are available. The PR of some RPs is then mandatory to compute the remaining tasks. Finally, it might be possible that the computation of some RPs is not required. This occurs when nRP/nnode is not an integer number. In that case, the RPs maintain their configuration from the previous iteration to avoid additional and unnecessary PR.Algorithm 3:Scheduling of the merged nodes.
input: Merged configuration list NM output: Scheduled configuration set Snode (1) begin (2)    NS←∅; (3)    Stemp←∅; (4)    Snode[0]← InitialRPsConfig; (5)    fori∈niterdo (6)      Stemp←Snode[i-1]; (7)      forj∈nRPdo (8)        fork∈ Size(NM)do (9)          ifConfig(Stemp(j)) = Config(NM(k))then (10)            Snode[i]← InsertConfigInRP(NM(k),j); (11)            Snode[i]← MarkAsConfigured(); (12)            NM← RemoveConfigfromList(NM, k); (13)            break; (14)          end (15)        end (16)      end (17)      ifNofElements(Snode[i]) <nRPthen (18)        forj∈ NotConfigured(Snode[i])do (19)          ifNofElements(NM) > 0then (20)            HM← CalcHistogram(NM); (21)            idxnode← FindMostFreqConfig(HM); (22)            Snode[i]← InsertConfigInRP(NM(idxnode),j); (23)            Snode[i]← MarkAsConfigured(); (24)            NM← RemoveConfigfromList(NM, idxnode); (25)          end (26)          else (27)            Snode[i]← Config(Snode[i-1]); (28)            Snode[i]← MarkAsConfigured(); (29)          end (30)        end (31)      end (32)    end (33) endFor the sake of understanding, the scheduling heuristic is applied to the previous example. We assume some initial RPs’ conditions and the previous values ofNM: (3)InitalRPsConfig=RM28,RM52,RM12,RM52,NM=RM52,RM52,RM52,RM28,RM12.The scheduling heuristic distributes the elements of NM between the required niter based on the previous iterations RPs’ configurations. Therefore, the execution order to minimize nRC results as follows: (4)Snode1=RM28,RM52,RM12,RM52,Snode2=-,RM52,-,- where − represents an unused RP in one particular iteration. Thanks to both heuristics, niter has been reduced to 2 iterations, multiple configurations are computed in parallel, and there is no need for PR.


### 5.3. Partial Reconfiguration over PCIe

Despite the minimization ofPR between iterations due to our scheduler, PR might be unavoidable due to the initial configuration of the RPs and the list of nodes to be executed. Our PR uses the Media Configuration Access Port (MCAP) [19], which is a new configuration interface available for UltraScale devices, that provides a dedicated connection to the ICAP from one specific PCIe block per device. This interface is integrated into the PCIe hard block and provides access to the FPGA configuration logic through the PCIe hard block when enabled. The bitstream loading across the PCIe to configure the RPs of the NE is detailed in [20]. The detailed process is only applicable for UltraScale architectures since these architectures need clearing bitstreams in order to prepare the RP for the new configuration. Consequently, each new reconfiguration of one RP of the NE requires a clearing operation before being reconfigured. Otherwise, the subsequent RM cannot be initialized [19]. It demands a knowledge of what RM is configured at each RP. This task is done at the host side by the middleware, which monitors the status of the nodes and applies the proper clearing reconfiguration before each PR of a node.


#### 5.3.1. Cost Table

TheCT of the NE shown in Table 3 has been partially defined at design time. It lists the different node’s configurations to be executed on the FPGA, their relative area cost, and the compatibility between the defined RMs. The current CT considers 4 different configurations of the nodes based on the active microphones and using the P-SRP method. Thus, the microphones of all subarrays are active when Nam=52, which is the most area demanding configuration. Thanks to the flexibility of the nodes, Nam can be modified at runtime without the need of PR. Therefore, the largest configuration is able to support all considered node’s configurations. To exploit the unused resources of a RP when considering low area-demanding node’s configurations (Nam < 12), several node’s configurations are placed in parallel per RP. For instance, when Nam=12 up to 4 instances can be placed in a RP dimensioned for the Nam=52 node’s configuration. Here is where PR has a role for performance acceleration. Of course, such acceleration is determined by the overhead due to partially reconfiguring a RP and the time cost of each configuration. The time cost shown in Table 3 is the averaged execution time experimentally measured after 100 executions.


#### 5.3.2. Defining Reconfigurable Partitions

Figure9 depicts the 4 RPs available on the NE. The sizes of the RPs are determined by the nodes’ configuration sizes and the dedicated I/O channels. Firstly, the RPs’ size must be large enough to support different node’s architectures based on Nam or DM as detailed in Table 2. Nevertheless, the RPs have a fixed dimension independent of the node’s parameter under evaluation since hierarchical PR is not supported [28]. Thus, our RPs are designed to fit the most demanding resource node’s configuration, which is T52Mics based on Table 3. Secondly, the 64-bit dedicated AXI4-Stream interface also limits the maximum LP per RP. Due to the characteristics of the node emulation, each normalized output needs to be represented with at least 16 bits. This fact is limited to 16, the number of nodes that can be simultaneously allocated on the FPGA. Finally, notice that the RPs better adjust the available resources to the most area demanding node’s configuration with respect to [3, 4].Figure 9
FPGA floorplanning when all nodes have their subarrays active. The four reconfigurable partitions of theNE are framed into white boxes.Figure10 depicts the list of supported RMs based on the experiments presented in Section 6. Notice that each RP supports the same number of RMs. For instance, there are 4 different RMs based on the number of active subarrays when using the P-SRP method. Table 5 details the dimensions of the RPs and their percentage of occupancy when configured with RM52. Their values slightly vary since not all RPs have exactly the same size, containing a different number and type of slices.Table 5
Resource consumption of the static and dimensions of theRPs, including their highest percentage of occupancy.
Resources Available Static RP 0 RP 1 RP 2 RP 3 Slice registers 663360 18413 93600 (51.42%) 102400 (46.97%) 103200 (46.64%) 102400 (47.00%) Slice LUTs 331680 16209 46800 (78.81%) 51200 (72.05%) 51600 (71.50%) 51200 (72.07%) LUT-FF Pairs 331680 7026 46800 (50.97%) 51200 (47.39%) 51600 (46.01%) 51200 (47.24%) BRAM 1080 47 170 (28.24%) 170 (28.24%) 170 (28.24%) 170 (28.24%) DSPs 2760 0 460 (24.35%) 460 (24.35%) 460 (24.35%) 460 (24.35%)  Bitmap size   4,762 MB 4,762 MB 4,764 MB 4,762 MB Clearing time - - 0.0826 ± 0.0047 s 0.0836 ± 0.0044 s 0.0848 ± 0.0031 s 0.0836 ± 0.0040 s Reconfig. time   1.0908 ± 0.0042 s 1.0988 ± 0.0056 s 1.0947 ± 0.0050 s 1.0945 ± 0.0054 sFigure 10
List of bitmap files required for the experiments evaluatingDM and the use of PR for acceleration detailed in Section 6.


#### 5.3.3. Partial Reconfiguration Overhead

The reconfiguration time perRP, including the cleaning operation and the PR, rounds to 1.09 s. It represents a relatively slow PR when considering the PCIe theoretical bandwidth and the size of the RP bitstream files, which rounds to 4.762 MB. Nevertheless, the time values have been experimentally obtained at the MCAP driver side.


## 5.1. Increasing Network Capabilities

The dynamism required to reduce the estimation error under unpredictable acoustic scenarios is enhanced thanks toPR. A clear example occurs when minimizing the overall network power consumption while offering accurate sound sources location. The overall power consumption and the accuracy are directly related to the Nam. Thus, a trade-off is needed in order to get the highest accurate estimation with the minimum power consumption. PR has a role when considering alternative architectures to enhance the quality of results. That is the case of the CC method, which is only applicable for a lower number of microphones where it promises better accuracy. In that case, PR allows the dynamic modification of the network configuration in runtime to satisfy power constraints. Such evaluation in the NE would not be possible without PR. Otherwise, the platform had to be completely reprogrammed and a reboot would be needed in order to let the operating system identify the reconfigured PCIe device. Our experimental results in Section 6 cover this example.


## 5.2. Heuristics to Increase Performance

Figure8 shows the heuristics used by themiddleware to increase performance. PR can only be exploited for higher performance by properly placing and scheduling the nodes to be accelerated. Furthermore, we propose the use of PR to exploit the configurations’ compatibilities in order to better use the available resources.Figure 8
Our approach consists of several heuristics to optimize the area reuse and to improve performance by reducingPR. Firstly, the nodes’ configurations are classified and sorted based on their compatible RMs. Secondly, the increment of the area reuse is possible by merging similar nodes’ configurations to increase the overall LP. Finally, an optimized scheduler minimizes the PR by properly allocating the nodes.An existing cost table (CT), like Table 3, is used to decide at each step of the heuristics. Such table is elaborated at design time and contains information about the relative area cost of the configurations, related to the most area demanding configuration, and information about configurations’ compatibilities. From one side, the relative area cost reflects the configuration’s level of parallelism (LP), which is used to merge compatible node’s configurations. In fact, LP is the inverse of the relative area cost since it represents the number of nodes with a certain configuration that can be executed in parallel per RP. From the other side, the configurations’ compatibilities relate a certain configuration with its supported RMs. Thanks to the flexible architecture of the nodes, the number of active microphones varies from 4 to 52 MICs. Their activation is in runtime through control signals and does not require any type of PR. As a consequence, certain RMs support multiple node’s configurations depending on the dedicated logic resources. Thus, the RM52 not only supports 52 microphones but also 28, 12, or 4. Such flexibility is used to reduce the number of PR in order to achieve higher performance. A summary of the abbreviations used for the NE description is done in Table 4.Table 3
Cost table of the node’s configurations for the second experiment with the NE. The time values are expressed in seconds.
Configuration Time cost Area cost Compatibility 52 Mics 1.0834 ± 0.0029 1 RM52 28 Mics 1.0753 ± 0.0024 1/2 RM52,RM28 12 Mics 1.0679 ± 0.0023 1/4 RM52,RM28,RM12 4 Mics 1.0677 ± 0.0023 1/4 RM52,RM28,RM12Table 4
Abbreviations used for the description of the NE and the presented heuristics.
Parameter Definition R P Reconfigurable partition R M Reconfigurable module C T Cost table L P Level of parallelism. Inverse of the area cost P - S R P Polar steered response power C C Cross-correlation D M Detection method N a m Number of active microphones M a m Number of multiplications n n o d e Number of nodes’ configurations per execution n i t e r Number of iterations needed by one execution n R P Number of RPs n R C Number of PR N Initial nodes’ configuration list N I Sorted and classified nodes’ configuration list N M Merged nodes’ configuration list N T Temporal nodes’ configuration list N S Scheduled nodes’ configuration list S t e m p Temporal set of RP’s configurations S n o d e [ i ] Set of RP’s configurations on iterationi


### 5.2.1. Classification

The nodes are classified based on an existingCT like Table 3. This classification identifies the compatible RMs and the LP that can be achieved based on their type. Algorithm 1 details the operations involved during the nodes’ classification. N is composed of multiple nodes’ configurations, which can be optimally parallelized and scheduled to minimize the execution time. The relative area cost of each node is used as reference to sort the nodes’ list in decreasing order. Lately, the nodes’ list is evaluated to identify the compatible RMs per configuration.Algorithm 1:Classification of nodes.
input: Nodes’ configuration list N, CT output: Sorted and classified node list NI (1) begin (2)   NI← Sort nodes based on their area cost (N, CT); (3)   NI← Find Compatible RM (NI, CT); (4) end


### 5.2.2. Merging

The merging of the nodes’ configurations consists of grouping the maximum number of compatible configurations in oneRP in order to exploit the otherwise unused resources. For instance, in case NI=[52,52,52,28,28,12,12,12,12] the nodes with Nam=28 and Nam=12 can be computed in parallel in RPs configured with RM28 and RM12, respectively (Table 3). Since the RMs are associated with the nodes’ configurations after the merging heuristic, NM for the previous example results in NM=[RM52,RM52,RM52,RM28,RM12]. Notice that niter is reduced in one unit thanks to this merging (2). In fact, the reduction of niter is the main objective of this heuristic.Algorithm2 shows how nodes are merged based on their LP to place in each RP as many nodes as possible. This merging intends to reduce niter and, potentially, the overall execution time. Algorithm 2 starts scanning the list of configurations in increasing relative area cost order. There are three possibilities:(i)
If the configuration consumes a completeRP, which occurs when its cost equals 1, the configuration cannot share any RP. Thus, this configuration is allocated to the largest compatible RM in order to maximize the reuse of this RP. Otherwise, if the demanded relative area cost of the configuration is lower, it can be evaluated for sharing a RP.(ii)
In case the addition of the configuration’s cost and the accumulated area cost of the already allocated nodes is higher than oneRP, this RP is locked. Firstly, the grouped configurations are moved to the configurations’ list NM since they cannot longer share the resources of one RP. Secondly, the new unassigned node’s configuration is assigned to the smallest compatible RM to limit the sharing to the most constrained situation.(iii)
In case area cost of the configuration allows the addition of this node’s configuration to the existing configurations’ group, the accumulated area cost (which represents the percentage of occupancy of theRP) is incremented by the maximum area cost of new node’s configuration. In this way, the area cost of the largest node’s configuration dominates and thus unfeasible situations are avoided.Algorithm 2:Merging of the nodes’ configurations.
input: Nodes’ configuration list NI output: Merged configuration list NM (1) begin (2)   NM←∅; (3)   NT←∅; (4)   fori∈NIdo (5)     ifAreaCost(i) =1then (6)       NT←config(i); (7)       AccAreaCost(NT) ← AreaCost(config(i)); (8)       CompatibleRMs(NT) ← SmallestRM(NT,config(i)); (9)       NM← InsertIn(NM,NT); (10)     end (11)     else (12)       if AreaCost(i) + AccAreaCost(NT) >1then (13)         NM← InsertIn(NM,NT); (14)         NT←config(i); (15)         AccAreaCost(NT) ← AreaCost(config(i)); (16)         CompatibleRMs(NT) ← SmallestRM(NT,config(i)); (17)       end (18)       else (19)         NT← InsertIn(NT,config(i)); (20)         AccAreaCost(NT) ← AccAreaCost(NT) + max(AreaCost(config(i)),AccAreaCost(NT)); (21)        end (22)      end (23)   end (24) endAs a result, the configurations are categorized in the compatibleRMs which maximize the area reuse and potentially increment the overall performance by decreasing niter.


### 5.2.3. Scheduling

Once the nodes have been merged, they need to be properly scheduled in order to minimize the number of reconfigurations (nRC). The strategy consists in maximizing the reuse of the RP’s previous configurations between iterations of one execution.Algorithm3 details how the merged configurations in NM are scheduled based on the configuration of the RPs in each iteration. The RP’s configuration of the previous iteration is used as initial RP’s configuration of the iteration under scheduling. Thus, the list NM is traverse looking for the same RM loaded in the target RP. If found, the node’s configuration is assigned to that RP at that particular iteration. The process continues for the next RP until all the available nRP are assigned. If there is no compatible node’s configuration with the available RPs at a certain iteration, it could be possible that either all the nodes have been allocated or PR is needed. Based on the number of unallocated nodes, it is possible to distinguish how to proceed. On the one hand, if PR is needed, the most frequent configuration of the unallocated nodes is selected. This configuration is obtained through the calculation of a histogram and maximizes the potential reuse of this configuration over the remaining iterations. On the other hand, the remaining unassigned RPs keep their configuration from the previous iteration to avoid additional and unnecessary PR if there are no more unallocated nodes. The process continues this way until no compatible tasks are available. The PR of some RPs is then mandatory to compute the remaining tasks. Finally, it might be possible that the computation of some RPs is not required. This occurs when nRP/nnode is not an integer number. In that case, the RPs maintain their configuration from the previous iteration to avoid additional and unnecessary PR.Algorithm 3:Scheduling of the merged nodes.
input: Merged configuration list NM output: Scheduled configuration set Snode (1) begin (2)    NS←∅; (3)    Stemp←∅; (4)    Snode[0]← InitialRPsConfig; (5)    fori∈niterdo (6)      Stemp←Snode[i-1]; (7)      forj∈nRPdo (8)        fork∈ Size(NM)do (9)          ifConfig(Stemp(j)) = Config(NM(k))then (10)            Snode[i]← InsertConfigInRP(NM(k),j); (11)            Snode[i]← MarkAsConfigured(); (12)            NM← RemoveConfigfromList(NM, k); (13)            break; (14)          end (15)        end (16)      end (17)      ifNofElements(Snode[i]) <nRPthen (18)        forj∈ NotConfigured(Snode[i])do (19)          ifNofElements(NM) > 0then (20)            HM← CalcHistogram(NM); (21)            idxnode← FindMostFreqConfig(HM); (22)            Snode[i]← InsertConfigInRP(NM(idxnode),j); (23)            Snode[i]← MarkAsConfigured(); (24)            NM← RemoveConfigfromList(NM, idxnode); (25)          end (26)          else (27)            Snode[i]← Config(Snode[i-1]); (28)            Snode[i]← MarkAsConfigured(); (29)          end (30)        end (31)      end (32)    end (33) endFor the sake of understanding, the scheduling heuristic is applied to the previous example. We assume some initial RPs’ conditions and the previous values ofNM: (3)InitalRPsConfig=RM28,RM52,RM12,RM52,NM=RM52,RM52,RM52,RM28,RM12.The scheduling heuristic distributes the elements of NM between the required niter based on the previous iterations RPs’ configurations. Therefore, the execution order to minimize nRC results as follows: (4)Snode1=RM28,RM52,RM12,RM52,Snode2=-,RM52,-,- where − represents an unused RP in one particular iteration. Thanks to both heuristics, niter has been reduced to 2 iterations, multiple configurations are computed in parallel, and there is no need for PR.


## 5.2.1. Classification

The nodes are classified based on an existingCT like Table 3. This classification identifies the compatible RMs and the LP that can be achieved based on their type. Algorithm 1 details the operations involved during the nodes’ classification. N is composed of multiple nodes’ configurations, which can be optimally parallelized and scheduled to minimize the execution time. The relative area cost of each node is used as reference to sort the nodes’ list in decreasing order. Lately, the nodes’ list is evaluated to identify the compatible RMs per configuration.Algorithm 1:Classification of nodes.
input: Nodes’ configuration list N, CT output: Sorted and classified node list NI (1) begin (2)   NI← Sort nodes based on their area cost (N, CT); (3)   NI← Find Compatible RM (NI, CT); (4) end


## 5.2.2. Merging

The merging of the nodes’ configurations consists of grouping the maximum number of compatible configurations in oneRP in order to exploit the otherwise unused resources. For instance, in case NI=[52,52,52,28,28,12,12,12,12] the nodes with Nam=28 and Nam=12 can be computed in parallel in RPs configured with RM28 and RM12, respectively (Table 3). Since the RMs are associated with the nodes’ configurations after the merging heuristic, NM for the previous example results in NM=[RM52,RM52,RM52,RM28,RM12]. Notice that niter is reduced in one unit thanks to this merging (2). In fact, the reduction of niter is the main objective of this heuristic.Algorithm2 shows how nodes are merged based on their LP to place in each RP as many nodes as possible. This merging intends to reduce niter and, potentially, the overall execution time. Algorithm 2 starts scanning the list of configurations in increasing relative area cost order. There are three possibilities:(i)
If the configuration consumes a completeRP, which occurs when its cost equals 1, the configuration cannot share any RP. Thus, this configuration is allocated to the largest compatible RM in order to maximize the reuse of this RP. Otherwise, if the demanded relative area cost of the configuration is lower, it can be evaluated for sharing a RP.(ii)
In case the addition of the configuration’s cost and the accumulated area cost of the already allocated nodes is higher than oneRP, this RP is locked. Firstly, the grouped configurations are moved to the configurations’ list NM since they cannot longer share the resources of one RP. Secondly, the new unassigned node’s configuration is assigned to the smallest compatible RM to limit the sharing to the most constrained situation.(iii)
In case area cost of the configuration allows the addition of this node’s configuration to the existing configurations’ group, the accumulated area cost (which represents the percentage of occupancy of theRP) is incremented by the maximum area cost of new node’s configuration. In this way, the area cost of the largest node’s configuration dominates and thus unfeasible situations are avoided.Algorithm 2:Merging of the nodes’ configurations.
input: Nodes’ configuration list NI output: Merged configuration list NM (1) begin (2)   NM←∅; (3)   NT←∅; (4)   fori∈NIdo (5)     ifAreaCost(i) =1then (6)       NT←config(i); (7)       AccAreaCost(NT) ← AreaCost(config(i)); (8)       CompatibleRMs(NT) ← SmallestRM(NT,config(i)); (9)       NM← InsertIn(NM,NT); (10)     end (11)     else (12)       if AreaCost(i) + AccAreaCost(NT) >1then (13)         NM← InsertIn(NM,NT); (14)         NT←config(i); (15)         AccAreaCost(NT) ← AreaCost(config(i)); (16)         CompatibleRMs(NT) ← SmallestRM(NT,config(i)); (17)       end (18)       else (19)         NT← InsertIn(NT,config(i)); (20)         AccAreaCost(NT) ← AccAreaCost(NT) + max(AreaCost(config(i)),AccAreaCost(NT)); (21)        end (22)      end (23)   end (24) endAs a result, the configurations are categorized in the compatibleRMs which maximize the area reuse and potentially increment the overall performance by decreasing niter.


## 5.2.3. Scheduling

Once the nodes have been merged, they need to be properly scheduled in order to minimize the number of reconfigurations (nRC). The strategy consists in maximizing the reuse of the RP’s previous configurations between iterations of one execution.Algorithm3 details how the merged configurations in NM are scheduled based on the configuration of the RPs in each iteration. The RP’s configuration of the previous iteration is used as initial RP’s configuration of the iteration under scheduling. Thus, the list NM is traverse looking for the same RM loaded in the target RP. If found, the node’s configuration is assigned to that RP at that particular iteration. The process continues for the next RP until all the available nRP are assigned. If there is no compatible node’s configuration with the available RPs at a certain iteration, it could be possible that either all the nodes have been allocated or PR is needed. Based on the number of unallocated nodes, it is possible to distinguish how to proceed. On the one hand, if PR is needed, the most frequent configuration of the unallocated nodes is selected. This configuration is obtained through the calculation of a histogram and maximizes the potential reuse of this configuration over the remaining iterations. On the other hand, the remaining unassigned RPs keep their configuration from the previous iteration to avoid additional and unnecessary PR if there are no more unallocated nodes. The process continues this way until no compatible tasks are available. The PR of some RPs is then mandatory to compute the remaining tasks. Finally, it might be possible that the computation of some RPs is not required. This occurs when nRP/nnode is not an integer number. In that case, the RPs maintain their configuration from the previous iteration to avoid additional and unnecessary PR.Algorithm 3:Scheduling of the merged nodes.
input: Merged configuration list NM output: Scheduled configuration set Snode (1) begin (2)    NS←∅; (3)    Stemp←∅; (4)    Snode[0]← InitialRPsConfig; (5)    fori∈niterdo (6)      Stemp←Snode[i-1]; (7)      forj∈nRPdo (8)        fork∈ Size(NM)do (9)          ifConfig(Stemp(j)) = Config(NM(k))then (10)            Snode[i]← InsertConfigInRP(NM(k),j); (11)            Snode[i]← MarkAsConfigured(); (12)            NM← RemoveConfigfromList(NM, k); (13)            break; (14)          end (15)        end (16)      end (17)      ifNofElements(Snode[i]) <nRPthen (18)        forj∈ NotConfigured(Snode[i])do (19)          ifNofElements(NM) > 0then (20)            HM← CalcHistogram(NM); (21)            idxnode← FindMostFreqConfig(HM); (22)            Snode[i]← InsertConfigInRP(NM(idxnode),j); (23)            Snode[i]← MarkAsConfigured(); (24)            NM← RemoveConfigfromList(NM, idxnode); (25)          end (26)          else (27)            Snode[i]← Config(Snode[i-1]); (28)            Snode[i]← MarkAsConfigured(); (29)          end (30)        end (31)      end (32)    end (33) endFor the sake of understanding, the scheduling heuristic is applied to the previous example. We assume some initial RPs’ conditions and the previous values ofNM: (3)InitalRPsConfig=RM28,RM52,RM12,RM52,NM=RM52,RM52,RM52,RM28,RM12.The scheduling heuristic distributes the elements of NM between the required niter based on the previous iterations RPs’ configurations. Therefore, the execution order to minimize nRC results as follows: (4)Snode1=RM28,RM52,RM12,RM52,Snode2=-,RM52,-,- where − represents an unused RP in one particular iteration. Thanks to both heuristics, niter has been reduced to 2 iterations, multiple configurations are computed in parallel, and there is no need for PR.


## 5.3. Partial Reconfiguration over PCIe

Despite the minimization ofPR between iterations due to our scheduler, PR might be unavoidable due to the initial configuration of the RPs and the list of nodes to be executed. Our PR uses the Media Configuration Access Port (MCAP) [19], which is a new configuration interface available for UltraScale devices, that provides a dedicated connection to the ICAP from one specific PCIe block per device. This interface is integrated into the PCIe hard block and provides access to the FPGA configuration logic through the PCIe hard block when enabled. The bitstream loading across the PCIe to configure the RPs of the NE is detailed in [20]. The detailed process is only applicable for UltraScale architectures since these architectures need clearing bitstreams in order to prepare the RP for the new configuration. Consequently, each new reconfiguration of one RP of the NE requires a clearing operation before being reconfigured. Otherwise, the subsequent RM cannot be initialized [19]. It demands a knowledge of what RM is configured at each RP. This task is done at the host side by the middleware, which monitors the status of the nodes and applies the proper clearing reconfiguration before each PR of a node.


### 5.3.1. Cost Table

TheCT of the NE shown in Table 3 has been partially defined at design time. It lists the different node’s configurations to be executed on the FPGA, their relative area cost, and the compatibility between the defined RMs. The current CT considers 4 different configurations of the nodes based on the active microphones and using the P-SRP method. Thus, the microphones of all subarrays are active when Nam=52, which is the most area demanding configuration. Thanks to the flexibility of the nodes, Nam can be modified at runtime without the need of PR. Therefore, the largest configuration is able to support all considered node’s configurations. To exploit the unused resources of a RP when considering low area-demanding node’s configurations (Nam < 12), several node’s configurations are placed in parallel per RP. For instance, when Nam=12 up to 4 instances can be placed in a RP dimensioned for the Nam=52 node’s configuration. Here is where PR has a role for performance acceleration. Of course, such acceleration is determined by the overhead due to partially reconfiguring a RP and the time cost of each configuration. The time cost shown in Table 3 is the averaged execution time experimentally measured after 100 executions.


### 5.3.2. Defining Reconfigurable Partitions

Figure9 depicts the 4 RPs available on the NE. The sizes of the RPs are determined by the nodes’ configuration sizes and the dedicated I/O channels. Firstly, the RPs’ size must be large enough to support different node’s architectures based on Nam or DM as detailed in Table 2. Nevertheless, the RPs have a fixed dimension independent of the node’s parameter under evaluation since hierarchical PR is not supported [28]. Thus, our RPs are designed to fit the most demanding resource node’s configuration, which is T52Mics based on Table 3. Secondly, the 64-bit dedicated AXI4-Stream interface also limits the maximum LP per RP. Due to the characteristics of the node emulation, each normalized output needs to be represented with at least 16 bits. This fact is limited to 16, the number of nodes that can be simultaneously allocated on the FPGA. Finally, notice that the RPs better adjust the available resources to the most area demanding node’s configuration with respect to [3, 4].Figure 9
FPGA floorplanning when all nodes have their subarrays active. The four reconfigurable partitions of theNE are framed into white boxes.Figure10 depicts the list of supported RMs based on the experiments presented in Section 6. Notice that each RP supports the same number of RMs. For instance, there are 4 different RMs based on the number of active subarrays when using the P-SRP method. Table 5 details the dimensions of the RPs and their percentage of occupancy when configured with RM52. Their values slightly vary since not all RPs have exactly the same size, containing a different number and type of slices.Table 5
Resource consumption of the static and dimensions of theRPs, including their highest percentage of occupancy.
Resources Available Static RP 0 RP 1 RP 2 RP 3 Slice registers 663360 18413 93600 (51.42%) 102400 (46.97%) 103200 (46.64%) 102400 (47.00%) Slice LUTs 331680 16209 46800 (78.81%) 51200 (72.05%) 51600 (71.50%) 51200 (72.07%) LUT-FF Pairs 331680 7026 46800 (50.97%) 51200 (47.39%) 51600 (46.01%) 51200 (47.24%) BRAM 1080 47 170 (28.24%) 170 (28.24%) 170 (28.24%) 170 (28.24%) DSPs 2760 0 460 (24.35%) 460 (24.35%) 460 (24.35%) 460 (24.35%)  Bitmap size   4,762 MB 4,762 MB 4,764 MB 4,762 MB Clearing time - - 0.0826 ± 0.0047 s 0.0836 ± 0.0044 s 0.0848 ± 0.0031 s 0.0836 ± 0.0040 s Reconfig. time   1.0908 ± 0.0042 s 1.0988 ± 0.0056 s 1.0947 ± 0.0050 s 1.0945 ± 0.0054 sFigure 10
List of bitmap files required for the experiments evaluatingDM and the use of PR for acceleration detailed in Section 6.


### 5.3.3. Partial Reconfiguration Overhead

The reconfiguration time perRP, including the cleaning operation and the PR, rounds to 1.09 s. It represents a relatively slow PR when considering the PCIe theoretical bandwidth and the size of the RP bitstream files, which rounds to 4.762 MB. Nevertheless, the time values have been experimentally obtained at the MCAP driver side.


## 5.3.1. Cost Table

TheCT of the NE shown in Table 3 has been partially defined at design time. It lists the different node’s configurations to be executed on the FPGA, their relative area cost, and the compatibility between the defined RMs. The current CT considers 4 different configurations of the nodes based on the active microphones and using the P-SRP method. Thus, the microphones of all subarrays are active when Nam=52, which is the most area demanding configuration. Thanks to the flexibility of the nodes, Nam can be modified at runtime without the need of PR. Therefore, the largest configuration is able to support all considered node’s configurations. To exploit the unused resources of a RP when considering low area-demanding node’s configurations (Nam < 12), several node’s configurations are placed in parallel per RP. For instance, when Nam=12 up to 4 instances can be placed in a RP dimensioned for the Nam=52 node’s configuration. Here is where PR has a role for performance acceleration. Of course, such acceleration is determined by the overhead due to partially reconfiguring a RP and the time cost of each configuration. The time cost shown in Table 3 is the averaged execution time experimentally measured after 100 executions.


## 5.3.2. Defining Reconfigurable Partitions

Figure9 depicts the 4 RPs available on the NE. The sizes of the RPs are determined by the nodes’ configuration sizes and the dedicated I/O channels. Firstly, the RPs’ size must be large enough to support different node’s architectures based on Nam or DM as detailed in Table 2. Nevertheless, the RPs have a fixed dimension independent of the node’s parameter under evaluation since hierarchical PR is not supported [28]. Thus, our RPs are designed to fit the most demanding resource node’s configuration, which is T52Mics based on Table 3. Secondly, the 64-bit dedicated AXI4-Stream interface also limits the maximum LP per RP. Due to the characteristics of the node emulation, each normalized output needs to be represented with at least 16 bits. This fact is limited to 16, the number of nodes that can be simultaneously allocated on the FPGA. Finally, notice that the RPs better adjust the available resources to the most area demanding node’s configuration with respect to [3, 4].Figure 9
FPGA floorplanning when all nodes have their subarrays active. The four reconfigurable partitions of theNE are framed into white boxes.Figure10 depicts the list of supported RMs based on the experiments presented in Section 6. Notice that each RP supports the same number of RMs. For instance, there are 4 different RMs based on the number of active subarrays when using the P-SRP method. Table 5 details the dimensions of the RPs and their percentage of occupancy when configured with RM52. Their values slightly vary since not all RPs have exactly the same size, containing a different number and type of slices.Table 5
Resource consumption of the static and dimensions of theRPs, including their highest percentage of occupancy.
Resources Available Static RP 0 RP 1 RP 2 RP 3 Slice registers 663360 18413 93600 (51.42%) 102400 (46.97%) 103200 (46.64%) 102400 (47.00%) Slice LUTs 331680 16209 46800 (78.81%) 51200 (72.05%) 51600 (71.50%) 51200 (72.07%) LUT-FF Pairs 331680 7026 46800 (50.97%) 51200 (47.39%) 51600 (46.01%) 51200 (47.24%) BRAM 1080 47 170 (28.24%) 170 (28.24%) 170 (28.24%) 170 (28.24%) DSPs 2760 0 460 (24.35%) 460 (24.35%) 460 (24.35%) 460 (24.35%)  Bitmap size   4,762 MB 4,762 MB 4,764 MB 4,762 MB Clearing time - - 0.0826 ± 0.0047 s 0.0836 ± 0.0044 s 0.0848 ± 0.0031 s 0.0836 ± 0.0040 s Reconfig. time   1.0908 ± 0.0042 s 1.0988 ± 0.0056 s 1.0947 ± 0.0050 s 1.0945 ± 0.0054 sFigure 10
List of bitmap files required for the experiments evaluatingDM and the use of PR for acceleration detailed in Section 6.


## 5.3.3. Partial Reconfiguration Overhead

The reconfiguration time perRP, including the cleaning operation and the PR, rounds to 1.09 s. It represents a relatively slow PR when considering the PCIe theoretical bandwidth and the size of the RP bitstream files, which rounds to 4.762 MB. Nevertheless, the time values have been experimentally obtained at the MCAP driver side.


## 6. Experimental Results

A couple of experiments are detailed in this section to demonstrate some of the capabilities of theNE and the benefits of PR. The sound field simulation used in the front-end has been optimized for a two-dimensional open field where sound attenuation, caused by propagation, has been assumed to be negligible. All the experiments demand a PR involving one or more RMs. The first experiment demonstrates how PR is used to evaluate different DMs for several node’s configurations and sound source profiles. The main purpose is to show how the capabilities of the NE are extended thanks to PR. Thus, different DMs can be evaluated in runtime, which could not be possible without PR. Our strategies and heuristics are evaluated in the second experiment, which exemplifies how the use of PR can lead to a significant performance improvement. The increment in performance comes from the better resource exploitation. As a result, NE executions are accelerated when the network is composed of a minimum number of nodes.All the supported node’s configurations (Table2) are implemented and stored in the host side. As a result, the bitmaps required to run the experiments detailed in this section (Figure 10) are loaded to the NE by using PR through PCIe when needed. Because no bitmap compression technique has been applied, all the bitmaps associated with one RP have the same size (Table 5). The bitmaps are grouped based on the experiment where they are used. However, some bitmaps like RP_RM12_PSRP are used in both experiments. Finally, a static bitmap file contains the static logic and the initial RMs’ configuration.The FPGA card used for the implementation of theNE is a Xilinx Kintex Ultrascale from Alpha Data (ADM-PCIE-KU3), whose available resources are detailed in Table 5. It provides a Gen3 PCIe connection, supporting up to two PCIe x8 controllers. Vivado 2016.4 has been used to develop the PCIe DMA Subsystem and the PR through design flow. The system has been implemented in an Ubuntu 14.04.1 machine that uses C/C++ code, bash scripts, and Matlab 2016b.


### 6.1. Impact of the Detection Methods

ThePR feature of the NE provides the capability of evaluating different node’s configurations. The following experiment intends to demonstrate how the PR allows the comparison of two different DMs from the network point of view.Figure11 shows the average error in the estimation of the sound source when applying data fusion of 4 nodes using the two inner subarrays. The values have been obtained for a random position of a standalone sound source at 3 different frequencies (4, 8, and 10 kHz). The RMs are partially reconfigured to switch between both methods. The evaluation also considers the permutations of all possible combinations of the two inner subarrays. Thus, the top left error value corresponds to the 4 nodes with only the inner subarray active while the top right corresponds to all the nodes with two inner subarrays active. The results show that the CC method does not offer a significant improvement compared to the P-SRP method. Despite offering a lower estimation error, its implementation in a distributed network of microphone arrays is not completely justified considering the additional resource consumption due to the required multiplications. Nevertheless, further experiments must be done with different sound source frequencies, with real measurements and in an anechoic room before discarding completely the CC method.Figure 11
The localization error, using one sound source and four nodes at three different frequencies, improved as the total number of microphones in the network increased. Both methods, P-SRP and CC, performed equivalently.


### 6.2. Partial Reconfiguration for Higher Performance

The use ofPR to increment performance is evaluated through multiple executions with nnode and random Nam per node. All the experimental results explained here have been obtained after 10000 executions of up to 100 random nodes per execution. Only the P-SRP method is considered in this experiment. The only difference in the node’s configuration is Nam, which directly affects the node’s resource consumption. Therefore, the performance increases thanks to an increment in the number of node’s configurations executed in one iteration, which is done by allocating on each RP multiple node’s configurations with small Nam.Figure12 depicts the required niter based on the nnode with and without merging nodes. niter is, by default, expressed in (2). This value can be decreased thanks to exploiting the unused resources per RP. Thus, the merging of nodes to share resources of one RP leads to a lower niter needed per execution. Since niter determines the execution time, the merging of the nodes is expected to directly benefit the performance. Both graphs present a stepped shape because at least nRP nodes are executed per iteration.Figure 12
Theniter is reduced by merging nodes.Figure13 depicts the average execution time (left figure) and the overall speedup (right figure). The nonheuristic strategy(None) is used as reference. This strategy does not need to partially reconfigure the RP and, therefore, does not benefit from the use of the heuristics. Each RP is configured with the same RM52 in order to support all the node’s configurations under evaluation. Consequently, the None strategy time-multiplexed the nodes in the available RPs without any merging or scheduling. The other two strategies under evaluation consider the proposed heuristic for merging of the node’s configurations as standalone(Merge) and combined with the proposed heuristic for scheduling(Merge+Schedule). Both strategies have a random initial configuration of the RPs, which are randomly asserted after each execution when using PR. This is the expected behavior of the NE since the final configuration of the RPs after one execution is unknown in advance, at least not before the execution of the heuristics.Figure 13
Average execution time and speedup for different strategies.The results depicted in Figure13 reflect that although a lower niter obtained by merging the node’s configuration in the same RP should lead to a higher performance, the PR time overhead decreases the overall performance. Moreover, the use of PR without a proper scheduling induces performance decrements, which is reflected in Figure 13. Although the merging of nodes increases the parallelism and diminishes niter, the PR overhead dominates when the nodes are not properly scheduled. Executions demanding a low nnode are specially sensitive to this overhead, because the PR time overhead represents a large percentage of the overall execution time. As a consequence, the proper scheduling of the nodes is not beneficial unless a certain nnode must be computed per execution. The rightmost figure in Figure 13 represents the overall speedup when only merging or also scheduling. Both graphs are saw waves for the same reason the graphs in Figure 12 present a stepped shape. Because several nodes’ configurations are computed in parallel, niter remains constant while incrementing nnode. Thus, the speedup increases when increasing nnode computed in the same amount of time, but suddenly decreases when an additional iteration must be computed. The proper merging and scheduling of the nodes’ configurations are only beneficial in average when nnode is higher than 45.


## 6.1. Impact of the Detection Methods

ThePR feature of the NE provides the capability of evaluating different node’s configurations. The following experiment intends to demonstrate how the PR allows the comparison of two different DMs from the network point of view.Figure11 shows the average error in the estimation of the sound source when applying data fusion of 4 nodes using the two inner subarrays. The values have been obtained for a random position of a standalone sound source at 3 different frequencies (4, 8, and 10 kHz). The RMs are partially reconfigured to switch between both methods. The evaluation also considers the permutations of all possible combinations of the two inner subarrays. Thus, the top left error value corresponds to the 4 nodes with only the inner subarray active while the top right corresponds to all the nodes with two inner subarrays active. The results show that the CC method does not offer a significant improvement compared to the P-SRP method. Despite offering a lower estimation error, its implementation in a distributed network of microphone arrays is not completely justified considering the additional resource consumption due to the required multiplications. Nevertheless, further experiments must be done with different sound source frequencies, with real measurements and in an anechoic room before discarding completely the CC method.Figure 11
The localization error, using one sound source and four nodes at three different frequencies, improved as the total number of microphones in the network increased. Both methods, P-SRP and CC, performed equivalently.


## 6.2. Partial Reconfiguration for Higher Performance

The use ofPR to increment performance is evaluated through multiple executions with nnode and random Nam per node. All the experimental results explained here have been obtained after 10000 executions of up to 100 random nodes per execution. Only the P-SRP method is considered in this experiment. The only difference in the node’s configuration is Nam, which directly affects the node’s resource consumption. Therefore, the performance increases thanks to an increment in the number of node’s configurations executed in one iteration, which is done by allocating on each RP multiple node’s configurations with small Nam.Figure12 depicts the required niter based on the nnode with and without merging nodes. niter is, by default, expressed in (2). This value can be decreased thanks to exploiting the unused resources per RP. Thus, the merging of nodes to share resources of one RP leads to a lower niter needed per execution. Since niter determines the execution time, the merging of the nodes is expected to directly benefit the performance. Both graphs present a stepped shape because at least nRP nodes are executed per iteration.Figure 12
Theniter is reduced by merging nodes.Figure13 depicts the average execution time (left figure) and the overall speedup (right figure). The nonheuristic strategy(None) is used as reference. This strategy does not need to partially reconfigure the RP and, therefore, does not benefit from the use of the heuristics. Each RP is configured with the same RM52 in order to support all the node’s configurations under evaluation. Consequently, the None strategy time-multiplexed the nodes in the available RPs without any merging or scheduling. The other two strategies under evaluation consider the proposed heuristic for merging of the node’s configurations as standalone(Merge) and combined with the proposed heuristic for scheduling(Merge+Schedule). Both strategies have a random initial configuration of the RPs, which are randomly asserted after each execution when using PR. This is the expected behavior of the NE since the final configuration of the RPs after one execution is unknown in advance, at least not before the execution of the heuristics.Figure 13
Average execution time and speedup for different strategies.The results depicted in Figure13 reflect that although a lower niter obtained by merging the node’s configuration in the same RP should lead to a higher performance, the PR time overhead decreases the overall performance. Moreover, the use of PR without a proper scheduling induces performance decrements, which is reflected in Figure 13. Although the merging of nodes increases the parallelism and diminishes niter, the PR overhead dominates when the nodes are not properly scheduled. Executions demanding a low nnode are specially sensitive to this overhead, because the PR time overhead represents a large percentage of the overall execution time. As a consequence, the proper scheduling of the nodes is not beneficial unless a certain nnode must be computed per execution. The rightmost figure in Figure 13 represents the overall speedup when only merging or also scheduling. Both graphs are saw waves for the same reason the graphs in Figure 12 present a stepped shape. Because several nodes’ configurations are computed in parallel, niter remains constant while incrementing nnode. Thus, the speedup increases when increasing nnode computed in the same amount of time, but suddenly decreases when an additional iteration must be computed. The proper merging and scheduling of the nodes’ configurations are only beneficial in average when nnode is higher than 45.


## 7. Conclusion

The presentedNE has shown the capacity to evaluate different WSN configurations thanks to its ability to mimic the node’s response to several sound sources. The use of PR through PCIe not only allows us to obtain a flexible NE capable of exploring multiple configuration scenarios in runtime but also allows us to accelerate the NE’s execution by exploiting the available resources and the inherent parallelism of the node’s emulation. We believe our approach for the NE not only provides an interesting case study of how PR can be used to increment performance but can also be extended for other streaming applications such as video processing, where similar convolutional filters must be applied to different image sources. Nevertheless, it will also be interesting to explore other strategies like bitstream compression in order to further reduce the PR time cost. Finally, in the current version of our emulator, the user is able to select the node and its configuration at every moment. Although the current version of the emulator is managed by the user, we consider that certain level of intelligence can be added in the control automation to determine, in real-time, the best strategies to evolve the network configuration to obtain the lowest power consumption with the lowest estimation error.



---

*Source: 3214679-2018-05-02.xml*