dataesr/scientific-paragraphs-categorization huggingface dataset:
In the regions where the observed polarization is below the MDP99 (minimum detectable polarization at 99% confidence), the direction of polarization is not constrained (NC). Facilities: IXPE, Chandra. Software: ixpeobssim  (Baldini et al. 2022) , CIAO  (Fruscione et al. 2006) , XSPEC  (Arnaud 1996). applied the previously described rejection algorithm to these background observations to ensure consistency with the Tycho observation, and then summed the Stokes parameters of each background region. This allows for each source to have a uniform background extraction region that is not contaminated by either border effects, or polarization from the source. We found that the background is consistent with no polarization ( i. e. , the normalized Stokes parameters are compatible with having a value of within the uncertainty) with an MDP99 of 3.
J. Vink & D. Prokhorov  are supported by funding from the  European Unionʼs   Horizon 2020 research and innovation program  under grant agreement No. 101004131  (SHARP). P. S. acknowledges support from  NASA  contract  NAS8-03060. P. Z. acknowledges the support from  NWO   Veni Fellowship  grant No. 639. 041. 647  and  NSFC  grant No. 12273010  C. -Y. N. and Y. J. Y. are supported by a  GRF  grant of the  Hong Kong Government  under  HKU 17305419. We thank the anonymous reviewer for their useful comments and suggestions.
The reconfigurable feature of FPGAs (Field-Programmable Gate Arrays) has made them a very attractive solution for implementing adaptive systems-on-chip. However, this implies additional design tasks to handle system reconfiguration and control, which increases design complexity. To address this issue, this paper proposes a model-driven design flow that guides the designer through the description of the different elements of a reconfigurable system. It is based on highlevel modeling using an extended version of the MARTE (Modeling and Analysis of Real-Time and Embedded systems) UML (Unified Modeling Language) profile. Both centralized and decentralized reconfiguration decision-making solutions are possible with the proposed flow, allowing it to adapt to various reconfigurable systems constraints.
Model-Driven Engineering (MDE) can be a solution to reduce design complexity. UML (Unified Modeling Language)  [2]  is commonly used in this approach for system modeling. The graphical nature of this language facilitates system understanding, editing, and reuse. UML profiles are a way to apply this language, originally used for software modeling, to other domains such as embedded systems. A UML profile is a set of extensions of the basic UML elements, which we call stereotypes. These stereotypes are used to describe different features of a given domain. There are several standard UML profiles for embedded systems, such as SysML (System Modeling Language) and MARTE (Modeling and Analysis of Real-Time and Embedded systems)  [2]. One of the advantages of using MDE is that it allows for generating a system implementation code from high-level models.
To allow this feature, MDE approaches often use a deployment phase that links the components of high-level models to low-level implementations through IPs (Intellectual Properties). All the necessary code for IP communication and system implementation is then generated automatically from high-level models. Furthermore, the code of some high-level components, with non-existent implementing IPs, can be generated from the UML descriptions of their behaviors, such as UML state machines. This can be the case with the reconfiguration controller, for instance. The main issue of the deployment phase of most MDE methodologies in the literature is that the deployed hardware IPs are tightly linked to the implementation technology, which makes both high-level models and actual IPs hardly reusable for various technologies.
Related Work SoCs are composite and complex systems that can include several hardware and software IPs and various processors for software tasks. Thanks to their reconfigurability, FPGA devices extend the concept of SoCs, making them able to adapt to various changes in user preferences, application requirements, and standards  [4]. However, this implies additional design tasks to handle system reconfiguration and control, which increases design complexity  [5]. To address this issue, several approaches have been proposed based on MDE tools. In the literature, many works have proposed high-level modeling to reduce the design complexity of DPR SoCs. In this context, several works used MDE to automatically generate the code necessary for the system implementation from high-level models, thus reducing design complexity and time-to-market.
For example, the authors in  [6]  presented a development framework based on UML/MARTE models for dynamically configurable systems design. In this framework, an XML-based tool was used to generate a VHDL and SystemC code from high-level models. In addition, the work in  [7]  proposed a design methodology based on UML/MARTE to deal with DPR designs. In this work, Xilinx concepts were included in the high-level models, which limits its flexibility. In  [8] , the authors proposed a UML/MARTE framework aimed at designing and synthesizing a formal controller managing dynamic reconfiguration. The UML/MARTE description of the formal controller was transformed into a BZR language in  [9]  to build a correct-byconstruction executable controller; the controller code is generated in C language and can then be added to a reconfigurable FPGA design to be executed by the processor.
The IP-XACT standard, offering an XML description of the system IPs independently of the used language, is a good solution to face the SoCs design reuse challenge. Some works proposed the integration of IP-XACT and UML in MDE-based design since they are complementary tools for the information they deliver  [10]. Indeed, IP-XACT is a standard for IP exchange and also a great solution that promotes IP reuse. In the literature, the exploitation of both specifications has been used in a variety of works to generate IP-XACT design files from MARTE models. This approach was proposed in the context of static SoC designs  [11]  as well as for reconfigurable ones. In  [12, 13] , the authors proposed an approach that has some similarities with ours. This approach is based on the transformation of MARTE models into IP-XACT descriptions to automatically generate reconfigurable systems code.
The proposed model-driven design platform was implemented using the Eclipse framework using plugins for high-level modeling, model-to-model transformations, and model-to-text transformations. After realizing the high-level modeling (the first four steps), the designer launches the transformation process, which generates all the system code (in VHDL and C languages). It also generates tool-specific scripts and a tool-specific design file. The designer can then launch the FPGA design tool (such as Vivado for Xilinx FPGAs), and execute the generated tool-specific scripts, which automates synthesis, implementation, and bitstreams generation. During the design exploration step (step 6), designers verify, using FPGA design tools, if the generated system respects the functional and non-functional constraints and requirements specified at the beginning of the design flow.
If not, high-level models can be edited, and code can be regenerated automatically. A list of the software and hardware systems used in this work is available in Appendix B. Thanks to the concern separation of the first four steps, the used models can be easily modified and reused for different system specifications or to target different FPGA platforms. In this section, the design flow is described through the used UML/MARTE concepts and the extensions we propose for the MARTE profile. The application of these concepts and extensions is presented in Section 5 with a watermarking case study.
Architecture Design and Task Allocation At this stage, the static and reconfigurable parts of the system are modeled using UML/MARTE components, ports, and connectors. To model the reconfigurable part of the architecture, we extended the MARTE profile through the <<ReconfigurableHwCom-ponent>> stereotype, which inherits from the <<HwComponent>> MARTE stereotype as shown in Figure  2. Using this new stereotype, we can distinguish components that will be implemented statically from those that will be reconfigurable. This stage also specifies which tasks will be implemented in software by the processor(s) and which tasks will be implemented in hardware using the FPGA logic. Task allocation on processors or static hardware components is performed using the <<allocate>> MARTE stereotype. As for reconfigurable tasks, we propose to use the <<mode>> and <<configuration>> concepts of MARTE together with the <<allocate>> stereotype.
Depending on the system requirements, reconfiguration control can be either centralized or decentralized, in which This stage also specifies which tasks will be implemented in software by the processor(s) and which tasks will be implemented in hardware using the FPGA logic. Task allocation on processors or static hardware components is performed using the <<allocate>> MARTE stereotype. As for reconfigurable tasks, we propose to use the <<mode>> and <<configuration>> concepts of MARTE together with the <<allocate>> stereotype. Depending on the system requirements, reconfiguration control can be either centralized or decentralized, in which case each reconfigurable region is handled by a separate module. In both cases, state machines are used for reconfiguration decision-making, where each state (<<Mode>>) represents a different configuration of one or several reconfigurable regions.
Deployment At this stage, the implementation details of the application tasks and the architecture components are specified through IPs. To be used in the deployment model, IPs have to be already packaged according to the IP-XACT standard and then transformed into MARTE components and stored in a MARTE components library. Figure  4  describes the extensions we propose to the MARTE profile for the deployment modeling. The <<IP>> stereotype can be applied to MARTE components representing either software IPs to be executed by the processor or hardware IPs to be implemented on the FPGA logic. Designers specify the language of the IP, its type (software or hardware), and its VLNV (vendor, library, name, and version) identifier. This identifier references a unique IP-XACT component in the library, which is used when transforming the whole high-level system into an IP-XACT global design.
Once the software and hardware IPs are specified in the deployment model, model transformations are used to become closer to the implementation code as detailed in the next section. An IP-XACT design file describing the whole architecture is generated from the deployed architecture model and is based on a set of transformation rules: Every instance of a MARTE component having the <<IP>> stereotype is transformed into a "component instance" according to the IP-XACT standard. Connections between the MARTE components in the deployed architecture are then transformed into either IP-XACT interconnections, ad-HocConnections, or hierConnections depending on the type of the connected ports (single port or bus interface) and the levels of hierarchy between the connected components.
Generation of the Reconfiguration Control Code This step corresponds to the generation of the code necessary for reconfiguration decision-making and reconfiguration launching. It consists in translating MARTE <<mode-Behaviors>> (state machines) into code for reconfiguration decision-making together with the necessary code to launch reconfiguration. For this, we propose two methods. The first one is purely software-based where decision-making and reconfiguration launching is performed by a processor. The second one is mixed, where MARTE <<modeBehaviors>> are translated into VHDL state machines. These machines are coordinated by the processor which handles also reconfiguration launching. This step will be detailed later in the case study section.
Generation of Tool-Specific Scripts and Project Skeleton At this step, the proposed platform creates a project skeleton in which it copies: (1) the hardware and software IPs codes specified at the deployment phase of the high-level modeling, (2) the generated tool-specific design file, (3) the generated hardware code for reconfiguration control, and (4) the generated code for the processor. Tcl scripts are also generated at this phase so the synthesis and implementation flow can be run automatically to obtain bitstreams ready to be loaded onto the target FPGA. The generated scripts handle the following steps: (1) importing the generated design file, (2) launching Synthesis for the static part of the system and reconfigurable modules, and (3) loading the Synthesis results in the floor planning tool.
System Constraints and Requirements Specification As the first step of high-level modeling, the designer specifies the requirements and constraints of the system. To model constraints linked to non-functional properties, we used the <<nfpConstraint>> MARTE stereotype as presented in Figure  7. To determine the requirements imposed by a video watermarking application and architecture, we carried out a study to extract the PSNR  [25]  values expected in video watermarking applications. The power consumption and frequency constraint were defined regarding a previous implementation using the motion estimator module proposed in  [26]. This implementation was an adaptive non-DPR (non-Partial Dynamic Reconfiguration) one. The system contained, at the same time, hardware modules implementing both the GS and the 4SS algorithms.
As mentioned above, the motion estimator used will implement either the GS or the 4SS algorithm at a given time. The operation of one algorithm or the other depends on the video motion speed. Each PE is implemented in a reconfigurable region. As shown in Figure  10 , the estimator module contains an estimator core that implements the nine PEs that will be reconfigured with either the GS or the 4SS algorithm at runtime according to the video motion speed. To indicate that the estimator core will be implemented in a reconfigurable region, we added the <<reconfigurableHwComponent>> stereotype to the MARTE profile. The estimator core has as inputs the current and the reference pixels and provides as results the horizontal and the vertical components of motion vectors (MH_final and MV_final). The estimator module also contains an adaptation component that we added so that reconfiguration decision-making (using a state machine) is completed in the hardware and then communicated to the processor to launch reconfigurations.
The operation of one algorithm or the other depends on the video motion speed. Each PE is implemented in a reconfigurable region. As shown in Figure  10 , the estimator module contains an estimator core that implements the nine PEs that will be reconfigured with either the GS or the 4SS algorithm at runtime according to the video motion speed. To indicate that the estimator core will be implemented in a reconfigurable region, we added the <<reconfigurableHw-Component>> stereotype to the MARTE profile. The estimator core has as inputs the current and the reference pixels and provides as results the horizontal and the vertical components of motion vectors (MH_final and MV_final). The estimator module also contains an adaptation component that we added so that reconfiguration decision-making (using a state machine) is completed in the hardware and then communicated to the processor to launch reconfigurations.
Allocation of the Static Tasks In this step, the task allocation of the processor and static hardware components is achieved using the <<allocate>> MARTE stereotype. As shown in Figure  11 , in our example, the processor manages the reading and saving of data. The rest of the application tasks are implemented in the hardware and are allocated to the corresponding hardware components of the architecture, except for the estimator module since it is a reconfigurable module. After describing the static and reconfigurable parts of the architecture, the allocation of the application tasks on the architecture component is modeled. The allocation in the MARTE profile consists in attaching each abstract component of the application to its execution support in the architecture. The designer performs two types of allocation.
The decentralized control would have many advantages in this case, such as decomposing the control design complexity between controllers, providing easier access to local data for decision-making, and enabling easier placement and routing of distributed controllers compared to a centralized hardware controller. In our case study, we modeled one state machine that represents the behavior of all reconfigurable regions using the <<modeBehavior>> and <<mode>> MARTE stereotypes as shown in Figure  12. The reconfigurations conditions are attached to the state machine transitions. The «ModeTransition» of the MARTE profile makes it possible to determine the transition from a source mode to a target mode. Since we decided to implement reconfiguration decision-making in the hardware, this state machine is linked to the adaptation module contained in the global estimator component as described earlier.
The SAD thresholds used in this work are threshold1 = 600 and threshold2 = 400. These thresholds were extracted from the work in  [27] , which is based on a study of different video sequences of 300 frames. MARTE configuration used to model one of the possible configurations (modes) of the reconfigurable estimator, which is the GS mode. Therefore, the GS version of the estimator task of the application is allocated to the estimator core module contained in the "Estima-torModule" of the architecture. As we mentioned earlier, in both centralized and decentralized reconfiguration decision-making, a global controller is required to guarantee that reconfiguration decisions respect the global system requirements. In this case study, this task is performed by the In this case study, the reconfigurable region performs two modes of the same application task.
Therefore, it is necessary to indicate the version of the task to be allocated to a region for each configuration of the reconfigurable region. Figure  13  represents a MARTE configuration used to model one of the possible configurations (modes) of the reconfigurable estimator, which is the GS mode. Therefore, the GS version of the estimator task of the application is allocated to the estimator core module contained in the "EstimatorModule" of the architecture. As we mentioned earlier, in both centralized and decentralized reconfiguration decisionmaking, a global controller is required to guarantee that reconfiguration decisions respect the global system requirements. In this case study, this task is performed by the processor. To do so, we apply the <<reconfigurationController>> stereotype, described earlier in Section 3.
The mode combination in this case is a combination of the active modes of all the reconfigurable regions. The coordinator can thus either allow or deny a reconfiguration decision made by a controller if it would lead to a mode combination that is not among the ones specified in the allowedModeCombinations field or is rather specified in the denied mode combination. Non-functional constraints can also be attached to the coordinator to be taken into account for reconfiguration decision-making, using the constraints field of the <<ReconfigurationController>> stereotype. MARTE configuration used to model one of the possible configurations (modes) of the reconfigurable estimator, which is the GS mode. Therefore, the GS version of the estimator task of the application is allocated to the estimator core module contained in the "Estima-torModule" of the architecture.
Deployment The deployment phase consists in assigning to each elementary component of the architecture or application a software or hardware IP implementing it. We use the <<im-plements>> stereotype to link the IP, which has the <<IP>> stereotype, to the application task that it implements. The code files of the used IPs are also specified at this stage using the <<codeFile>> stereotype. As shown earlier in Figure  4 , the <<IP>>, <<implements>>, and <<codeFile>> stereotypes are extensions we propose to the MARTE profile. The hardware IPs used at the deployment phase are retrieved from a MARTE components library obtained from a transformation of IP-XACT-compliant IPs. Thanks to the use of the IP-XACT standard, the IPs can be easily integrated and reused in various FPGA vendor tools. In addition to the application hardware IPs, the designer must specify IPs for other architectural elements, such as the processor and the interconnect.
Model Transformations and Code Generation At this stage, the deployed architecture is transformed into an IP_XACT design file, where MARTE components having the <<IP>> stereotype are transformed into an IP-XACT "component instance". Connections between the components of the deployed architecture are then transformed into either IP-XACT interconnections, adHocConnections, or hierConnections depending on the type of the connected ports (single port or bus interface) and the levels of hierarchy between the connected components. The obtained IP-XACT design file is then transformed into a tool-specific design file. In this case study, the IP-XACT file was transformed to obtain a. db (Block Design) file to be used in the Xilinx Vivado tool. To make this transformation easily reusable and extendable for different tools and technologies, we used model-to-model transformation before generating the tool-specific design file.
The final step of code generation is to generate tool-specific Tcl scripts, so all the synthesis and implementation flow can be run automatically to obtain bitstreams ready to be loaded onto the target FPGA. Our design flow generates three scripts. The first one handles the following steps: (1) importing the generated design file, (2) launching Synthesis for the static part of the system and reconfigurable modules, and (3) loading the Synthesis results into the floor planning tool. Designers can then place the reconfigurable regions using the floor planning tool. This is the only task that is performed manually since we cannot predict the resource usage of the reconfigurable regions before synthesizing them and therefore their placement is not completed in the high-level models. In this application, the reconfigurable region size corresponds to the size of PEs of the 4SS algorithm since it requires more resources than the GS algorithm.
Reconfiguration Time As for bitstreams, the GDF4DPR design flow generated one full bitstream and a set of partial bitstreams (nine partial bitstreams for the PEs of the GS algorithm and nine for the 4SS algorithm). The full bitstream is the one to be loaded initially and it contains the static part of the system and the partial bitstreams of the GS algorithm. Using SAD values, the adaptation module of the estimator decides which algorithm has to be executed and sends an interruption to the processor if a reconfiguration is required. The processor then launches the required partial reconfiguration through the PCAP (Processor Configuration Access Port) interface. The 32-bit PCAP interface has a theoretical reconfiguration speed of 400 MB/s when clocked at 100 MHz on a Xilinx Zynq SoC. The total size of the nine partial bitstreams is 1595 Kb, which implies a reconfiguration time of 30 ms.
Compared to the version in  [26] , the DPR version provides a better PSNR and faster execution time. The implementation results described in this section show that the reconfigurable watermarking architecture generated by the proposed design flow makes a good trade-off between execution time, video quality, resource usage, and power consumption. The proposed model-driven approach shows a significant design acceleration thanks to the high-level modeling and the automatic generation of VHDL/C code and tool-specific files and scripts.