dataesr/scientific-paragraphs-categorization huggingface dataset:
The Two-Dimensional Fast Fourier Transform (2D-FFT) algorithm is used for the study of many modern systems applied for security and biometrics. The adoption of this algorithm, which is a compute intensive task, is limited due to its hardware design complexity. The first objective of this paper is to underline the effect of the hardware/ software co-design (Hw/Sw co-design) for the reduction of the processing time and power consumption. Secondly, we propose an innovative architecture for the 2D-FFT algorithm tested on Zynq Soc, which requires less processing time and memory compared to the traditional algorithm. Three implementations (one software and two Hw/Sw co-designs) of the 2D-FFT algorithm using the Zynq SoC are presented in this paper. The first is based on ARM processor. A speedup of 29x is obtained compared to the original implementation thanks to many optimizations.
The use of embedded systems such as Graphics Processing Units (GPUs)  [4] , a combination of Hw/Sw Co-Design, and Field Programmable Gate Arrays (FPGAs)  [7]  are expected to solve these challenges. In this work, we have used the Zynq SoC FPGA-based platform, which presents better performance in terms of energy efficiency compared to GPUs  [4]. Zynq SoC FPGAs are a good candidate for computer vision system development for their ability to exploit parallelism. Additionally, the design flow of current FPGAs synthesis tools supports high-level abstraction languages (C/C++) as input descriptions, in contrast to hardware description languages (HDL: Verilog and VHDL). High-level synthesis (HLS) is used to simplify the design process by transforming the algorithmic description into hardware while satisfying the design constraints.
Given the importance of using the 2D-FFT algorithm in many applications, it could be interesting to propose a different implementation of this algorithm. In this paper, three implementations (one software and two Hw/Sw co-designs) of the 2D-FFT algorithm using the Zynq SoC are proposed. The first is based on ARM Cortex-A9 processor to perform the software implementation using OpenCV functions. The second is based on a hybrid platform combining an ARM Cortex-A9 processor with an FPGA to perform a Hw/Sw co-design implementation. The Hw/Sw co-design implementation provides less processing time and less power, which is the first contribution of this paper. The second contribution is an innovative architecture for the 2D-FFT algorithm using the Zynq SoC. It requires less processing time and less dedicated hardware blocks (DSP, LUT, and FF) compared to the traditional algorithm.
The butterfly architecture used and the number of inputs and outputs are the main difference between these architectures  [8]. In this work, four architectures have been assessed in order to select the best one. These architectures include Radix-4 Burst I/O, Radix-2 Burst I/O, Pipelined Streaming I/O, and Radix-2 Lite Burst I/O. Vivado HLS tool is used to generate the hardware description (at RTL level) from software-coded functions and targeting Zynq SoC. This description serves to exchange data between the software part and the hardware part. Many optimizations are introduced in order to develop suitable hardware implementation. The contributions of this paper are as follows: • Proposing a Hw/Sw co-design solution of the 2D-FFT algorithm, which provides less processing time, and less power consumption using the Zynq SoC.
• Innovative architecture for the 2D-FFT algorithm tested on Zynq Soc that requires less processing time, memory, and less number of computational blocks compared to the traditional algorithm. • A comparative study between four existing architectures to select the best one. • Study the impact of directives on resource usage and performance. The rest of the paper is organized as follows: Section 2, presents the different applications of the 2D-FFT algorithm and platforms used for these implementations. Section 3 describes our innovative architecture for the 2D-FFT algorithm using the Zynq SoC. Section 4 describes the software implementation based on ARM Cortex-A9 processor. Section 5 presents the Hw/Sw co-design solution using the Zynq SoC and the different optimizations for both 2D-FFT algorithms performed on ARM Cortex-A9 processor and the FPGA.
However, this accelerator requires a thorough knowledge of hardware description languages (HDL) such as VHDL and Verilog. These languages are used to describe and synthesize at the Register-Transfer Level (RTL) levels. Today, high-level synthesis tools (HLS) is used to synthesize hardware description (RTL) from a high-level language such as C/C ++ and SystemC. In addition, HLS tools can not directly transform high-level language into RTL levels. As a result, it needs to be optimized and restructured to be suitable and synthesizable for a specific hardware platform. Vivado HLS reduces design time and makes complex algorithms much easier than to use HDL. However, Vivado HLS does not support the compilation of all C/C ++ command structures. So, Xilinx provides many popular libraries and model templates for programming users.
The hls_fft. h and ap_fixed. h libraries are used to implement our proposed FFT IP core. The float data type is used for the default implementation of FFT IP core. Then, to reduce the processing time and the resources number, it is better to transfer the input data to fixed-point data. Once compiled into HDL, modules on Vivado HLS produces an FFT IP core, which can be instantiated and simulated with other software such as Matlab, ISE. Besides, this FFT IP core subject to various optimizations in order to improve performance and reduce memory requirements. The design process using Vivado HLS is shown in Fig. 1.
Software implementation of the 2D-FFT algorithm The OpenCV library provides an implementation for many interesting applications dedicated to software platforms. In addition, the 2D-FFT algorithm applied to image reconstruction can be used for the validation of the software implementation based on ARM Cortex 9 processor using the Zynq device. A SIMD architecture integrated into the ARM Cortex 9 processor is used to accelerate the execution. The 2D-FFT algorithm provided by the OpenCV library applied on the input frames stored in the DDR memory. The data transfer between the ARM Cortex 9 processor and the DDR memory is controlled with a Video Direct Memory Access (VDMA) core based on the High Performance (AXI HP) port of the Zynq SoC  [24]. Finally, the output result is forwarded to the VGA output.
The software implementation of the 2D-FFT algorithm is configured to forward direction. We should notice that for a single high-resolution frame 1920 × 1080, this implementation requires 229 ms, which is inefficient for real-time applications. Two pre-processing steps are introduced to reduce the computation time of the 2D-FFT algorithm based on OpenCV functions: grayscale conversion and resizing. Fig. 3  shows the design of the software implementation based on ARM Cortex 9 processor.
Hw/sw Co-Design implementation of the 2D-FFT algorithms This section presents 2D-FFT algorithm implementation tested on hybrid processing units: ARM Cortex-A9 processor and FPGA. The advantage of the Zynq SoC from Xilinx is the ability to generate any algorithm written with High-Level Language: C, C++, and SystemC. Some other tools can generate RTL description using python language. The HLS tool is used to reduce design time and greatly facilitate the deployment of complex algorithms in the FPGA. However, the functions written with C/C++ can be optimized and specified based on many directives in order to enhance the performance and reduce the processing time using the HLS tools. The Zynq SoC can automatically manage the exchange of data between the software part and the hardware part. Traditional and optimized RC algorithms will be accelerated on FPGA.
The Hw/Sw co-design implementation of the optimized RC algorithm is accelerated by integrating the grayscale conversion function and the 2D-FFT algorithm into the FPGA. The hardware acceleration of the gray-scale conversion function and 2D-FFT algorithm achieve a speedup of 10. 62x and 72. 59x, respectively, compared to the software implementation based on the ARM Cortex 9 processor. The hardware implementation based on FPGA means higher performance than software implementation. This higher performance presents the interest of a high-level synthesis using Zynq SoC. In addition, the software implementation of the 2D-FFT function can take advantage of the SIMD engine. The results of the test bench obtained with HLS will be compared to the MATLAB implementation of each step of the optimized RC algorithm to verify that the Hw/Sw co-design implementation works correctly.
A similar implementation of the 2D-FFT algorithm has been introduced in Matlab. Due to the simplicity and benefits of implementing multidimensional arrays, the implementation with Matlab was much shorter and easier in terms of development time. Note that the optimized RC algorithm has been computed is a pipeline which processes the input frame as a continuous stream of pixel values. When calculating PSNR between the results of the MATLAB implementation with the proposed architecture using Vivado HLS must be the same. Therefore, it is proven that the hardware implementation of the optimized RC algorithm works correctly. To compute the PSNR, we use an image of 256 × 256 pixels. The optimized RC algorithm has been introduced. The (X fl (k)) is the 2D-FFT exact with a floating-point arithmetic obtained by Matlab 64-bit precision.
The (X fx (k)) is obtained with the proposed architecture. Table  6  shows the comparison between PSNR obtained by the hardware implementation and the MATLAB implementation. The PSNR is defined by: PSNR (db) = 10 log 10 ( ∑ k ⃒ ⃒ X fk (k) ⃒ ⃒ 2 ) ( ∑ k ⃒ ⃒ X fl (k) ⃒ ⃒ 2 - ∑ k ⃒ ⃒ X fx (k) ⃒ ⃒ 2 ) (4) The original and reconstructed images obtained using the Hw/Sw codesign implementation for the optimized RC algorithm based on a hybrid platform combining an ARM Cortex 9 processor and an FPGA using Zynq SoC are shown in Fig. 11. It can be seen that the PSNR value between the Hw/Sw co-designs for the optimized RC algorithm using Zynq SoC and the 2D-FFT algorithm using Matlab is greater than 36 dB and ∞ when compared the inverse 2D-FFT.
Discussion In this work, three implementations (one software and two Hw/Sw co-designs) are used to assess the performance of the 2D-FFT algorithm: software implementation based on ARM Cortex-A9 processor and two Hw/Sw Co-design implementations based on a hybrid platform combining an ARM processor and FPGA circuit. Many optimizations are used to improve the evaluation for each implementation. The software implementation based on ARM Cortex-A9 processor provides advantages in terms of flexibility of the programmability based on the wellknown OpenCV libraries. However, the HW/SW co-design flow of the traditional or optimized RC algorithms needs an intermediate evaluation of sub-program, which would be very fastidious in terms of programmability. Then, we should mention that numerous directives have been used to get parallel processing.
Conclusion This work presents three implementations (one software and two Hw/Sw co-designs) of the 2D-FFT algorithm introduced by Cooley and Tukey. All of them have been implemented on ARM Cortex-A9 processor and FPGA using the Zynq SoC. The design was realized using the Vivado HLS. To begin, a software implementation of the 2D-FFT algorithm is introduced on ARM Cortex-A9 processor. After that, a Hw/Sw co-design solution of the traditional 2D-FFT algorithm is introduced on a hybrid platform combining an Cortex-A9 processor with an FPGA. The traditional 2D-FFT algorithm uses more resources and more processing time due to the transpose operation. Therefore, to respect real-time execution and memory consumption constraints, an optimized architecture for the 2D-FFT algorithm using the Zynq SoC is proposed on FPGA.
The spectrometer will be placed downstream the collision zone to analyze the charge state of the slow ion beam. To measure absolute cross-sections of elementary electronic processes, coincidence measurements between slow and fast ion charge states after the collision zone are mandatory. The ion spectrometer must be charge dispersive for multicharged ions with keV/u energies, and must be able to count several charge states at once. We have chosen a full electrostatic system for which we present here the first tests performed at the ARIBE (French acronym for Accelerator for Research with Low Energy Ions) facility  [3]  in Caen, France. In this paper, we first discuss the design of the spectrometer with its associated detection system. Second, we present selected experimental results and their comparison with simulations made using the SIMION software  [4].
Equations Parameter Definition In these equations, it is assumed that all occupants start evacuation simultaneously from the centre of the room, movement flow of occupants does not include any discontinuity due to personal decisions  [27]. No disabilities have been considered and all occupants are assumed to be moving at a similar pace  [27]. There is some software for evacuation simulation such as EvacSim  [28] , EVACNET  [29] , Social Distances  [30] , Pathfinder  [31] , Exodus  [32]  that are time-consuming  [33, 34]. These software packages are computationally expensive, which will be discussed in detail in Section 1. 3. 4. They are not opensource, which means it is required to set subjective parameters manually for every simulation in these software packages  [33, 34]. Implementing optimisation requires several iterations, and every iteration needs to set subjective parameters manually (e.
Furthermore, there are some software packages based on zone modelling such as CFAST  [42, 44]. They have some drawbacks that limit their applicability in some situations, their inability to import BIM and limitations in the number and shapes of rooms of buildings  [44]. The review of the literature shows that zone modelling and field modelling have some advantages and disadvantages. Zone modelling has a lower computation time than field modelling while it has lower accuracy. Nevertheless, a simplified and compatible smoke propagation modelling method that is based on zone modelling should be utilised for the optimisation approach, that is developed in the proposed framework in this paper. 𝑧𝑧 𝑙𝑙 = 0. 166𝑄𝑄 𝑐𝑐 2/.
Application of BIM and Graph Theory in Fire Safety BIM is a process in which all building elements are modelled as 3D object-oriented elements with corresponding information for all stages of the life cycle of the building  [10]. BIM has promising features for fire safety, e. g. , determining paths and identifying unsafe paths for evacuation at design, operation, and maintenance phases  [7] , analysing the impact of gaps caused by dimensional and geometric variations on the smoke propagation  [51, 52]. Sun and Turkan  [8]  examines occupants' evacuation during the fire for the purpose of safe paths for occupants and determining unsafe zones in the building design. They propose BIM, agent-based modelling and FDS software integrated into a simulation. Abolghasemzadeh  [16]  investigates the occupant's behaviour confronting dynamic conditions of evacuation during the fire and proposes a microscopic simulation through integrating BIM and agent-based modelling.
The software packages that are used for evacuation and smoke propagation validation are Pathfinder  [31]  and CFAST  [44]  respectively. These two software packages were validated and used in past research  [90] [91] [92] [93]. Thus, they can be used for validation in this study. In the proposed framework, a large number of fire scenarios are simulated due to the requirement of the optimisation phase. A sample scenario for the first case project of this paper is defined. The scenario is for each of the two modules and the results are compared with other applicable software. On the other hand, the validation of the hospital building case project is deemed to be not feasible due to the limitations of the zone modelling smoke software in the number and shape of rooms. Therefore, the residential building is considered to validate the results.
Evacuation Validation The evacuation simulation is conducted using the Pathfinder software for the considered number of occupants in the residential building  [31]. The computation time of the Pathfinder to accomplish the calculations of one evacuation scenario is about 70 s. Considering 576,000 evacuation simulation calculations, it takes about 11,200 h for the residential building evacuation simulation to be completed by the Pathfinder software. This emphasises the necessity of developing a fast macroscopic evacuation modelling that is compatible with the proposed framework. It appeared that the developed method in this study only needs 1. 6 h a complete optimisation of the residential building case project with six budget limits. Figure  18  presents the comparison between the results of the Pathfinder software and the developed evacuation module for each story of the residential building case project.
Smoke Propagation Validation Software that uses field modelling like FDS  [43]  requires a considerable amount of time for simulation of smoke propagation. For the residential case projects, it takes about 4883 s for one simulation to be accomplished. Assuming 576,000 smoke simulations, it takes about 781,280 h for the residential building smoke simulation to be completed by the FDS software. The total required time for complete optimisation of the residential building case project using the developed method is about 1. 6 h, as indicated earlier. The CFAST software  [44] , which is based on zone modelling, is faster than FDS. However, the identified limitations during the review of literature necessitate developing a compatible smoke propagation module for the proposed framework. The CFAST software is selected for the validation of the results of the smoke propagation module.
Our SSBFT implementation of ♦P mute. As mentioned, Algorithm 4 is our SSBFT recycling mechanism for BAMP n,t [FC, t < n/3, ♦P mute , BML], which requires the implementation of ♦P mute (Definition 6. 2). We present our ♦P mute 's implementation (Algorithm 5) and its interface with Algorithm 4, see the boxed code lines. Algorithm 5's line numbers continue the ones of Algorithm 4. Specifically, Algorithm 4 lets p i restart the local state of the muteness detector via a call to invoc i () (line 51). It uses rtComp i ( j) (line 61) for taking into account the completion of a roundtrip between p i and p j. Related solutions. In the context of self-stabilizing Byzantine-free (crash-prone) systems, Blanchard et al. [37]  designed a solution for crash-tolerant systems, rather than BFT one. They implemented perfect failure detectors, specifically class P , by allowing node p i to suspect any node p j ∈ P when p i is able to complete roundtrips with other nodes in P but not with p j , where is a predefined constant.
Then, a correlation, for instance, with MDO resource performances may be needed to solve the issue. Using this hierarchical scheme permits to leverage of time-scale decomposition at different levels of the proposed system, hence limiting the interference among different feedback-based decisions. Moreover, using local data processing and decisions, we (a) minimize the exchange of (big) data between components (e. g. , aggressive feature selection) to keep management scalable, and (b) significantly reduce the reaction time of data-driven management decisions that could be handled locally. Similar in spirit to ZSM, all the entities involved in the management and orchestration process are using the cross domain fabrics and cross slice fabrics to expose and consume APIs. Here we distinguish between the external interfaces used by the closed control loop to collaborate aiming at assisting IDMO, DMOs and ISMs to derive decisions to handle network slices' LCM, and the interfaces between IDMOs and DMOs which are mainly used for orchestrating and managing sub-slices resources.
) as well as from the VNFs and PNFs composing a network slice. Note that MS may use a DB to store the collected monitoring data for future analysis. It can be used for instance to understand the long term evolution of a system. MS periodically transmits monitoring information to AE that processes the data and provides the required analysis output to the DE. The latter, using a pre-deployed policy or automatic decision mechanisms, decides on the LCM action to apply; in the case of a VNF a LCM action is to scale up or down the resources (e. g. , CPU) or migrate the VNF to another NFVI. These actions are enforced by the DE using interfaces with the components managing the network slices (i. e. , IDMO, DMOs, and ISM). AE and DE are highly driven by AI/ML techniques aiming at learning appropriate LCM decisions to consider, according to the state of the infrastructure, the state of network slice components (obtained from AE), and depending on the technological domain where each slice component is deployed (e.
The main functions of AE are: (i) identify performance degradation of a network slice; (ii) optimize the performance of a network slice or the DMO resources; (iii) react to security threats. To this aim, AE subscribes for data types to which it is interested in using the control API exposed by the MS. The data type will be determined according to the logic of the LCM application execution. Then, AE starts receiving the stream of data or uses a request/response mechanism, depending on the purpose of the analysis. AE may adapt the monitoring data rate or stop the precedent request and request for other related monitoring information. AE heavily relies on AI/ML to complete an inference task locally, extract features, and analyse these features and send alerts and notifications to DE. AEs can collaborate to build distributed learning (based on federated learning) models to realize the analysis and notify the DE accordingly.
C. IDMO IDMO is equivalent to the 3GPP Network Slice Management Function (NSMF)  [10]  and exposes the Northbound API (NBI) for the OSS/BSS or Consumer Service Management Function (CSMF). IDMO is in charge of the LCM of end-to-end network slices. It has full-scope slice management and orchestration decision capabilities and takes global actions for network-wide, cross-slice, and cross-domain optimizations. The tenant or the slice owner interacts with the OSS/BSS or CSMF to define the network slice to deploy using an already Blueprint to generate a Network Slice Template (NST) that includes attributes and meta-data on the network slice (ex. the start date and end date, slice owner, type of slice, etc. ), and information on each sub-slice composing the network slice. For instance, in the case of computing resource (i.
A typical SLA between slice n tenant and the network slice provider would consist on imposing an upper-bound γ n on the probability that a slice resource usage exceeds an interval [α n , β n ], which translates into learning the AE local resource prediction model under empirical cumulative density function (ECDF) and complementary CDF (ECCDF) constraints which are solved via proxy-Lagrangian two-player game  [13]. Since the local MSs datasets are not exhaustive, the local AEs participate in a federated learning (FL) task to improve their prediction, where only their slice n models weights and achieved SLA violation rates {σ k,n } K k=1 are reported to the endto-end AE and DE, respectively, which are both located at IDMO. At each FL round, the end-to-end AE averages the received weights and broadcasts the result to the decentralized AEs to update their local models.