dataesr/scientific-paragraphs-categorization huggingface dataset:
The first factor is the similarity of classes, and the second is the number of well-classified images. Regarding the first factor, it is necessary to explore the use of deep learning for fine-grained image classification techniques, given that it is easy for CNNs to differentiate a horse from a car but the complexity increases when considering the classification of similar images. Concerning the second factor, it is easier to obtain high levels of accuracy if we have large and well-classified datasets. Although we used data augmentation techniques in order to improve validation accuracy, having a large dataset could be very important for obtaining a robust and more general prediction model. We believe false positives could be avoided with larger and better-tagged datasets. In our case, the main cause of false positives and negatives were borderline cases-images with which even retinal specialists have low interobserver agreement.
AI can detect DR, AMD, or suspected glaucoma perfectly, but we have to see what would happen-and who is responsible in the event the algorithm fails-when the system evaluates an image with uncommon findings, such as dystrophies, tumors, or minor infections. In our opinion, this problem could be solved with bigger datasets that include rare diseases. In the end, the more we teach the AI system, the more it learns. Meanwhile, AI could be used to ameliorate the cost-effectiveness of using hybrid systems supervised by a medical expert, raising doctor's performance beyond unaided human-only abilities, also would be desirable for furthers investigations evaluate AIassisted interpretation in other non-retinal specialist personnel such as general ophthalmologists or primary care physicians. Deep learning opens an exciting chapter for the future.
The reduction of atmospheric greenhouse gas emissions is a major challenge. In this context, each natural or industrial release such as methane (CH 4 ), carbon dioxide (CO 2 ) has to be monitored, localized and quantified. IFP Energies nouvelles (IFPEN) is developing a mobile measurement system called Flair car whose purpose is the detection of different abnormal gas emissions. Flair car system incorporates various gas sensors, including a weather station and GPS (Global Positioning System) module, mounted on a plugin hybrid electric vehicle. This enables the real-time monitoring and the recording of geo-time-stamped gas concentration measurements. Flair map corresponds to the on board real-time visualization software. Flair map development required two important challenges : a quick and agile software modification capability together with a realtime display of measurements on maps.
In order to meet these two challenges, we adopted a software rapid-prototyping approach based on the xDash tool. In this paper, our proposed real-time data visualisation approach is first introduced. Then, the rapidprototyping development methodology which resulted in the Flair map software is described. Finally, two main operational usages of Flair map are illustrated. The first involves real-time visualization aboard the car of the maps representing data acquisition from gas concentration sensors. The second shows the a-posteriori analysis of measurement campaigns for the purpose of methane anomalies study.
INTRODUCTION In the context of global warming and for geological gas storages, IFPEN develops several monitoring devices allowing the detection of anomalous gas. In this context, the main challenges are the ability to detect very small variations in gas concentrations and locate their leaks accurately in the field. The Flair car equipment corresponds to the mobile monitoring version. Flair car system is a plugin hybrid electric vehicle (PHEV) that incorporates various gas sensors, such as UV spectroscopy (Elements'atmo) and IR laser spectrometry (Picarro G2210-i). A weather station (AIRMAR) records GPS positions, temperature, barometric pressure and wind direction (corrected from car motion). To exploit all this equipment, a real-time visualization software, called Flair map, was needed. Two software challenges had to be handled : a quick and agile software modification capability together with a real-time display of measurements on maps.
Handling real-time aspects with GIS (Geographic Information Systems) have been investigated in  (Xu et al. , 2013)  in application for indoor fire detection, in  (Jeon et al. , 2019)  for marine surveillance, and in  (Oliveira et al. , 2018)  for dronebased geo-referencing, but for different visualization goals, with different software methodologies and tools than those used in our work. One technical problematic in our application was that major data acquisition and control software tools, especially those used in our context, do not include real-time capable geovisualization features. Thus, the first software challenge in the Flair project was to extend the measurement and control system, based on the LabVIEW platform  (Jeffrey, 2006) , with real-time map display capabilities. This was performed by coupling LabVIEW and xDash  (Ben Gaid et al.
, 2020)  tools. Another originality of our approach comes from the use of a synchronous/reactive abstraction for the data acquisition, processing and graphical display, including geo-spatial visualization description. As the Flair system requires strong software agility, a synchronous dataflow block-diagram based approach was undertaken, thanks to the use of the xDash tool. This approach is largely used in cyber-physical systems  (Broman et al. , 2012 ) modelling (Derler et al. , 2012) , simulation and rapid-prototyping  (Grzegorz et al. , 2008)  tools like Simulink  (Karris, 2008)  or LabVIEW, but these tools do not have geo-spatial visualization features. In this paper, we first describe our approach for the real-time geospatial data visualization and the underlying xDash tool. Then, we introduce the Flair car measurement system.
Synchronous programming philosophy Synchronous programming languages  (Benveniste et al. , 1994)  were developed for safely programming the control algorithms of reactive systems. In these systems, there is basic "sensecompute-act" sequence that have to be repeated. Synchronous programming languages relies on a fundamental idealization : the synchronous abstraction. In this abstraction, timing events are abstracted in logical ticks, and computations in one tick are assumed to be instantaneous. They have interesting theoretical properties, allowing their programs to be formally validated. In our application, we have to handle an analogous periodic "sense-compute-display" sequence. The execution engine of the used xDash tool, relies on these principles.
The xDash execution engine The xDash execution engine implements a synchronous/reactive scheduling algorithm. Computation modules, called datasources, are the nodes of a direct acyclic graph (DAG) where edges are data dependencies. This allow users to express computations to perform as block diagrams whose execution follows synchronous principles. Datasources produce JSON (JavaScript Object Notation) variables that are kept into a common workspace of xDash. The graph is executed on the web-browser and data (or operations) flow as JSON variables. In fact, JSON is simple and versatile: it can handle simulation run results, CSV(Comma-Separated Values) information, geographic information (like GeoJSON), and, even web-services results. Datasources in xDash are stateless and can be periodic or not.
xDash visualization components xDash widgets are based on various open source JavaScript libraries for scientific visualization. First use-cases with xDash involved mobility-related APIs (Application Programming Interfaces) validation needs. Thus several web-based mapping libraries were evaluated. We finally selected Leaflet. js (Crickard III. , 2014)  library for several reasons. Leaflet. js has several advantages. First, a clean and well-designed object model. Also, a complete and simple documentation. Finally a wide range of available plugins shared by an active community. For specific Flair map project requirements, quick real-time rendering was a supplementary pre-requisite. Leaflet. js successfully fulfilled this requirement.
The AIRMAR weather station records temperature, barometric pressure, wind velocity and wind direction (corrected from car motion). Flair map corresponds to the real-time viewing software on board the PHEV. Detection of abnormal gases in the ambient air corresponds to very small in gas concentrations. One important aspect of real-time analysis is the ability to change live the min and max range of displayed points colour map, using the double-slider widget. The wind direction and speed guide the driver to find gas leaks. Real-time visualization is useful for optimizing gas sampling. Indeed, in the case of diffusive leaks from the ground (recorded from the Flair car sniffer rake), real-time visualization makes it possible to precisely locate the sampling area. The three maps below in Figure  7  show the simultaneous recordings of methane (CH 4 ), ethane (C 2 H 6 ) and the relationship between these two molecules (C2 / C1) near the gas injection wells.
These maps show exactly where the wellhead is leaking. The C2 / C1 ratio equal to 5% corresponds to the ratio found in natural gas. Thanks to the real-time visualization (Flair map), soil and gas samples taken in this area have confirmed the diffuse leak from the well. In the context of field campaigns, the possibility of modifying the xDash project by any user was very helpful, in particular for correcting few bugs on the field. One field example was the need to correct sign error in the NMEA (National Marine Electronics Association) 0183 conversion to JSON from GPS module.
Post-analysis of measurements LabVIEW records the field measurement in several CSV files. This paper presented the Flair map software and its application for methane leaks detection. The building of the Flair map application using xDash was detailed. The underlying methodology is general and can be applied to other geo-spatial data acquisition projects. The benefits of using rapidprototyping methodology were also illustrated. As collected data size increases, the need for a database is increasing. Future version will rely on a Warp10 (www. warp10. io) database system for data storage. Plume modelling based on data recorded by the Flair car is now under study and will soon be added to the post-analysis software.
[20] proposes a layer conscious memory management framework for FPGA-based CNN hardware accelerators. Recently, software-hardware co-design gains more and more attention. [21] proposes REQ-YOLO, a resource-aware, systematic weight quantization framework for object detection, considering both algorithm and hardware resource aspects in object detection. [22] and  [23]  raise a novel and practical bi-directional codesign approach, including a bottom-up DNN model design strategy together with a top-down flow for DNN accelerator design. It enables a joint optimization of both DNN models and their deployment configurations on FPGAs. Also,  [23]  builds an automatic co-design flow, including an Auto-DNN engine to perform a hardware-oriented DNN model search, as well as an Auto-HLS engine to generate synthesizable C code of the FPGA accelerator for explored DNNs.
[38] raises a method for accurate power control and monitoring on ZYNQ device,  [39]  investigates the viability of physical power gating FPGA devices that incorporate a hardened processor in a different power domain, but they only implemented several computing units such as fp32mult, IIR, DCT, etc. , rather than an accelerator. In order to solve these problems, we propose a DVFS framework with high scaling range and resolution as well as low scaling time in this paper. What's more, we combine the DVFS framework with high-level synthesis tool, SDSoC, making it possible to build a system with DVFS support in a complete software development flow.
The proposed DVS framework is coarse-grained because modern FPGAs do not support multiple voltages in different domains. The power supply of all the slices is connected together. Therefore it is impossible to implement the module-level DVS method on current FPGA devices up till now. In this section, we will introduce how the DVS and DFS are implemented in hardware and then discuss how to access them in Linux OS. The framework supports a series of Zynq 7000 and Zynq UltraScale+ series FPGA boards including ZC702, ZC706, ZCU102, etc at the moment. To be specific, we use ZCU104 as an example in this paper.
Dynamic Frequency Scaling The Zynq 7000 and Zynq UltraScale+ series FPGA mainly has two kinds of clock sources, FCLK on the PS and MMCM on the PL. The FCLK has the advantage of low area overhead and existing driver in Linux. However, it can only provide limited frequency points. Therefore, we choose MMCM as the clock generator in our design since it is armed with a larger range and higher resolution. As shown in Fig. 2 , the As shown in Fig. 4 , there are two IRPS5401s on the ZCU104 board, both of which are connected to PCA9548, which is an I2C 1-to-8 bus switch external to the device. Then PCA9548 is connected to PS I2C controller via MIO. IRPS5401 can control and monitor up to ten voltage rails on board, including VCC12 and VCCINT. The former is the power input and the latter is PL side supply voltage.
This gives us the possibility to scale the accelerator's voltage and frequency and monitor the power consumption of each power rail in real time. There are two alternatives to communicate with the PMIC internally, as both the PL and the PS banks have access to the PMIC. The hardware method is to implement an AXI I2C controller in PL, while the software method connects the MIO pins directly to the PS. We choose the second method in that software method does not have any area overhead and can take advantage of the mature I2C driver embedded in the linux kernel. IV. SYSTEM ARCHITECTURE Fig. 8  shows the topology details of the convolutional FINN BNN as used in this work which has a model size of 187 Kbytes. Fig. 7  shows the BNN hardware and the Elongate IP architecture in the Zynq Ultrascale ZC9 device used in the ZCU102 board.
The next sections will discuss how this performance can be extended and made energy proportional with the Elongate framework. Energy efficiency is measured by monitoring the PL power in both devices at 37800 FPS/Watt in the zc9 compared with 3260 FPS/Watt in the Z7020. Fig. 7  shows that a single compute unit (BNNZU0) has been instrumented with the Elongate detectors and it communicates with the Elongate control logic shown before in Fig. 5. This means that this compute unit sets the operating point for itself and for the other 3 compute units. The timing analysis data obtained during Elongate integration is used to choose the compute unit with the longest critical paths for instrumentation.
As shown in Fig. 3 , the configuration information and the reset signal are sent to the MMCM via an AXI4-Lite interface and then saved in the register map. MMCM retrieves the configuration from the register map and resets to desired frequency accordingly. Fig. 4  shows the driver for DFS. The clock generator is mapped to a device firstly so that it can be accessed in Linux userspace, then M, D, and O are calculated according to the target frequency. The clock input of the MMCM is connected to the FCLK on the PS, and the FCLK is set to 100MHz. As shown in Eq. 1, the M can be the fractional number that is a multiple of 0. 25. Thus we can divide the target frequency by 4. 0. As shown in Eq. 1, the output frequency is F CLKIN × M ÷ D ÷ O = 100 ×F÷ 4. 0 ÷5 ÷5 = F(MHz) and the resolution is 1MHz.
Besides, IRPS5401 can also monitor the power consumption of each power rail and feedback the information through PMBus. There are two alternatives to communicate with the PMIC internally, as both the PL and the PS banks have access to the PMIC. The hardware method is to implement an AXI I2C controller in PL, while the software method connects the MIO pins directly to the PS. We choose the software method because it not only does not have any area overhead but also can take advantage of the mature I2C driver embedded in the Linux kernel. Fig. 7  demonstrates the driver for DVS. Since the PMBus protocol is compatible with the I2C protocol at the physical level, we can leverage the integrated I2C driver in Linux to communicate with the PMIC. The output voltage can be modified by writing PMBus commands to the PMIC in a fixed order according to the PMBus protocol.
Because of the low speed of I2C and more commands to transfer, the voltage scaling takes about 2ms each time. On the other hand, the power consumption can also be accessed in Linux in a similar way in which the PMIC is configured. In summary, at the hardware level, the proposed DVFS framework takes advantage of the MMCM module on modern FPGAs, as well as the PMBus compliant power supply system. In the software level, we internally, as both the PL and the PS banks have access to the PMIC. The hardware method is to implement an AXI I2C controller in PL, while the software method connects the MIO pins directly to the PS. We choose the second method in that software method does not have any area overhead and can take advantage of the mature I2C driver embedded in the linux kernel. IV. SYSTEM ARCHITECTURE Fig.
A. Power Scaling In this section we focus on the power of the FPGA fabric (i. e. , PL) that is supplied by the VCCINT power rail. Other power rails include VCCAUX that powers the clock managers and the IOs among other blocks and the VCCBRAM use with the BlockRAMs. The power drawn from these additional power rails is considerably lower than VCCINT. In addition, the processing side of the device where the ARM processor   adapt the provided memory map and I2C drivers in Linux to control the DVFS module, making it easier to use. We take ZCU104 as an example in this paper, however, the DVFS framework can be easily ported to Zynq 7000 devices or even non-Zynq FPGA devices as long as the board is equipped with a configurable PMIC. For the non-Zynq FPGA devices, we can inherit the drivers for Zynq devices if a MicroBlaze, a RISC Harvard architecture soft processor provided by Xilinx, is adapted as the DVFS module controller and running Linux on it.
System Architecture Fig. 1  shows the topology details of the system. It is implemented on the latest Zynq UltraScale+ device that integrates processing system (PS) and programmable logic (PL). The PS is a Quad-Core A53 processor running at 1. 2GHz. It provides three M_AXI buses and six S_AXI buses for high throughput data transfer between the PL and the PS. What's more, the PS is also embedded with common interfaces for various peripherals, such as I2C, USB, Ethernet, Display Port, etc. The I2C interface is connected to the power management IC on the FPGA board via MIO. Two high-performance M_AXIs are enabled in this design, one of them is connected to the DFS module, and the other one is connected to the SkyNet accelerator. The PS is running Linux OS and is responsible for loading images and sends control signals such as target frequency of the DFS module and the configuration parameters for the SkyNet accelerator.
SDSoC Support To build an ARM + FPGA system with DVFS support in the traditional design flow, designers should first add the DVFS module in PL, then prepare the drivers for controlling DVFS module in Linux. After the DVFS function is ready, the accelerators are added to the system and connected with the DVFS modules, which is quite exhausting. What's more, preparing testbench that is able to cover a sufficient number of test cases is also time-consuming. To solve this problem, we combine the DVFS framework with Xilinx's latest tool for developing ARM + FPGA system in C/C++/OpenCL, SDSoC, to further enhance the efficiency of system development. The starting point of an SDSoC-based design is an SDSoC hardware platform, where all the hardware components such as DDR and DVFS modules are defined.
Then the boot loaders and target operating systems are built to bring-up the hardware platform. After that, the drivers for the DVS and the DFS module are embedded in the operating system. The bootloaders, target operating system, and the drivers together are called SDSoC software platform, and the hardware platform and software platform together are called SDSoC platform. With this platform, users can develop an embedded system with hardware accelerators in a total software design flow. The user's C/C++/OpenCL code will be translated into Verilog/VHDL code and package the Verilog/VHDL into IPs by SDSoC compiler. After that, SDSoC will connect the accelerator to the PS and the DFS module automatically and then generate the bitstream. Using this platform, we can focus on the accelerator design rather than paying attention to the DVFS module.
Experimental Setup The SkyNet is written in High-Level Synthesis (HLS) C++ and then synthesized in SDSoC 2019. 1. The Quad Cortex-A53 cores in ZCU104 is running Ubuntu18. 04 modified by Xilinx. We test the system using the sample dataset of DAC-SDC2019 that is composed of 1000 images and corresponding ground truth. We record the total time and energy consumption for processing all the images and calculated the average IoU under different voltage & frequency combinations. We sweep the VCCINT from 680mV to 840mV at the step size of 20mV and sweep the frequency from 200MHz to 400MHz at the step size of 1MHz. Table. 1 gives the resource consumption of the original SkyNet and SkyNet with DVFS.
Energy Analysis In the previous section, we only considered the power of the PL part to make the result look more obvious, but considering the actual edge computing scenario, we should also take the power consumption of CPU into account. For example, when the data arrives, the CPU wakes up and processes the images, and then the CPU immediately enters the sleep state. Although the power of the PL side goes up as the frequency increases, it is also considered that the time for processing each picture as the frequency increases is also reduced. In such a scenario, the computational time reduction caused by the frequency increase may bring energy savings in the CPU part. Fig. 11  gives the relationship between the total energy consumption for processing all the 1000 images in the sample dataset and voltage/frequency obtained by our DVFS framework.
As shown in Fig. 11 , at each voltage point, the total energy consumption goes down as the frequency increases. The reason is that when the accelerator's frequency runs at a low frequency, the dynamic power decreases but the static power remains. What's more, although the PS side's power consumption decreases as the operating frequency of accelerator decreases because the data throughput is reduced, the difference can be neglected compared to the total power of the PS. At the meantime, at each frequency point, the energy consumption performs a linear relationship with voltage. The highest energy consumption is 518. 8J achieved at 200MHz/840mV while the least energy consumption is 354. 1J achieved at 371MHz/840mV. About 32% of energy can be saved with our DVFS framework. It should be noted that all the data mentioned above is given under strict constraint that the result should be 100% correct.
Accuracy Analysis All the results presented so far have used the neural network at full accuracy, that is 71. 9% Intersection over Union (IoU) on the whole sample dataset. As previously mentioned, it is possible to relax this constraint and let errors affect the user logic. As shown in Fig. 12 , there is a threshold frequency at 371MHz, above which there may be errors in the final results and the accuracy will change. However, the IoU does not go from 71. 9% sharply to zero, but goes through four different stages, namely jitter period, slow decent period, quick decent period and zero period. In the first period, the IoU jitter around 71. 9% within +1/-1% until 382MHz. In the second period, the IoU goes down gradually from 383MHz to 386MHz (70. 8% to 68. 5%). Only until the quick decent period (387MHz to 388MHz), we can see a sharp decrease in IoU.