dataesr/scientific-paragraphs-categorization huggingface dataset:
(iii) A reconfigurable SystemC module for dynamic spawned creation is modeled and implemented relying on calls to sc_spawn function and use of the abstract factory design pattern providing the necessary level of abstraction. (iv) e MARTE profile is also extended with SystemC/ TLM concepts in order to smoothly move to the executable code of the underlying system. e remainder of the paper is organized as follows. Section 2 gives a brief overview of a set of modeling concepts, languages, and tools used in this work. Section 3 presents the previous literature related to DPR modeling at a high abstraction level. Following a bottom-up approach (driven from the SystemC platform), it reviews the most important solutions for modeling Dynamically Reconfigurable Systems with SystemC and UML. Section 4 details the proposed modeling framework with an emphasis on MARTE profile specialization covering DPR specific concepts while describing the refined stereotypes of the involved subprofiles.
Systems are represented by a module hierarchy to manage structure and connectivity. A module can contain ports, exports, channels, processes, events, instances of other modules, other data members, and member functions. SystemC is often associated with electronic system-level (ESL) design and with transaction-level modeling (TLM). TLM. TLM is a transaction-based modeling approach for describing systems at a higher abstraction level above RTL, with emphasis on the separation of communication from computation within a system. By eliminating unnecessary details, it offers an adequate trade-off between simulation speed and accuracy while enabling interoperability of models. TLM-2. 0 classes are layered on top of the SystemC class library and consist of a set of core interfaces, the global quantum, the initiator and target sockets, the generic payload and base protocol, and the utilities.
sc_spawn. sc_spawn is a SystemC function used to create a static or dynamic spawned process instance. A spawned process is typically a dynamic process, but if sc_spawn is called before the end of elaboration, it would be a static process. Function sc_spawn may be called during elaboration or from a static, dynamic, spawned, or unspawned process during the simulation phase  [2]. Papyrus. Papyrus is an environment for editing any type of Eclipse Modeling Framework (EMF) model, in particular supporting UML2 and associated modeling languages such as SysML and MARTE. Papyrus is a complete UML modeling environment, it can also be used to develop UML profiles and generate code from UML models. ATL. ATL (Atlas Transformation Language) is a model transformation language specified as both a metamodel and a textual concrete syntax.
In  [30] , the proposed approach involves a Process-based Reconfigurable SystemC Module (PRM) for design space exploration speedup. e PRM uses Unix calls for process   [31]  propose a layered dynamic resource manager that provides a set of services to perform efficient scheduling and control of the sequence and processes related to the partial reconfiguration of FPGAs. Furthermore, a SystemC-based simulation framework has been defined by introducing the concept of Dynamic Module. e reconfiguration process is simulated as swap between the different module models running in different SystemC threads by switching from one to another inside the Dynamic Module. e main drawback of this framework is that, for a Dynamic Module, the number of threads implementing its various behaviors must be determined statically at compile time.
Next, the resulting untimed modebased HAP is refined to a clocked synchronous mode-based HAP, and the adaptive functionality is still included within a SC_THREAD process. e reconfigurable object wrapping consists in converting the mode functions within the context of the adaptive module into implementation classes. In the last refinement step, the asynchronous threads are replaced by SC_CTHREADs to work with bounded loops and to replace dynamic memory handling by code based on static data structures. As in OSSS + R library, the adaptive computations are assigned to HAP modules in a static way, making it impossible to update the set of adaptive functionalities in runtime. e authors in  [34]  propose a Y-chart based methodology to model dynamically reconfigurable architectures at high level of abstraction by using SystemC/TLM.
On the one hand, they attempt to provide an easy way to develop scheduling strategies for hardware task management, and, on the other hand, they introduce design space exploration in their methodology to provide the developer with a design flow completely integrated in Xilinx partial reconfiguration flow. In the described model, a reconfigurable module is composed of two SystemC dynamic threads: User Algorithm thread spawned during the execution and representing the functionality of the reconfigurable module and Reconfig Control thread which is responsible for the creation and the destruction of the User Algorithm. In addition, a reconfigurable module contains target and initiator sockets used for communication between modules in accordance with the TLM2. 0 base protocol. Each component communication interface is associated with a pool of functions called socket control used to connect the sockets to the module.
e presented methodology was later used to build the RecoSim reconfigurable simulator integrated into FoRTReSS design flow  [35]. ReChannel library  [36]  extends SystemC with advanced language constructs for high-level reconfiguration modeling. Portals are introduced to connect a channel of the static design part to ports of reconfigurable modules. Portals for all SystemC channel interfaces are provided by the ReChannel library. e dynamic reconfiguration is assimilated to circuit switch allowing the activation of only one module at a time if all its portals can be switched. While reconfigurable modules are created from static ones via a special macro, rc_control object provides registration and reconfiguration control functions for modules. ReChannel also provides a set of language extensions used for explicit description of reconfiguration allowing modules resetting without SystemC kernel altering.
e authors in  [38]  present a MDE-based Gaspard2 framework for implementation of DRSoCs, in which automatic VHDL/C code at RTL is generated from high-level MARTE models. e proposed design flow generates both the code for a dynamically reconfigurable region related to a high-level application model, and control semantics used for the generation of the reconfiguration controller source code. Works  [7, 38]  use MARTE standard concepts without any specific DPR semantics support, which limits models expressiveness and affects the quality of the generated code. In  [39] , a codesign MARTE-based approach is used to model DRS targeting Multiprocessor System on Programmable Chip (MPSoPC). For platform modeling, a reconfigurable zone is specified by the HwPLD stereotype from MARTE HRM profile. At the application level, strategy and state software design patterns are used to model, respectively, the dynamically swap algorithms and the behavior depending state of an object in the application.
e adaptive stereotype extending RtUnit is used to model the dynamic component. e reconfiguration method can be strategybased or state-based which is modeled by reconf_op and reconf_state tagged values, respectively. After allocating the client component into a HwProcessor and the dynamic component into HwPLD, a code targeting Xilinx FPGAs is generated. e limited extension of MARTE described in this work is still insufficient to model the DPR basic concepts. A MDE-based methodology for DRS codesign is presented in  [40]. To model DPR concepts, a MARTE extension called RecoMARTE has been proposed. At the application level, the RtUnit stereotype is extended to Reconfigura-bleRtUnit to describe reconfigurable tasks. For component interconnection, the ExtendedFlowPort stereotype is used to specify the port kind.
In another work  [42] , a Reco-MARTE extension is provided to specify a reconfiguration controller for DRSoCs. For constraint verification using NFPs values, an extension of the NFP concepts is proposed. An NfpType has been extended by NfpMeasure stereotype enabling the combination and comparison of values of NfpMeasure types. Additionally, the Controller stereotype extending the RtUnit has been proposed for control definition. From the RecoMARTE models, different transformations are carried out to obtain a controller specification in BZR language ready for discrete controller synthesis. Despite covering several features of DPR, RecoMARTE defines semantics for Xilinx coding style with advanced design skills, which may alter the high level of abstraction sought. Table  2  summarizes a comparison between the related works and our proposed framework.
A service consumer can look up services by querying the service registry; it is also responsible for the selection and sorting of the available services to extract the best. e binding between service consumer and provider at TLM level can be performed by using initiator and target sockets through an interconnect component. A service consumer is notified about the arrival and removal of new and existing services, respectively. By using the UML/MARTE and SystemC languages to raise the abstraction level of DPR modeling within a SOCMbased framework, we are inevitably faced with various challenges. e main challenge is how to model DPR in MARTE especially since the profile does not present any complete support. Another dilemma is that SOCM is not natively supported by MARTE besides the fact that it remains difficult to bridge the gap between UML/MARTE and SystemC/TLM domain-specific concepts.
To address these challenges, we propose a framework layered architecture in which abstraction levels are built upon each other until reaching technical levels as shown in Figure  2. e SOCM principle implementation enabling support for dynamic availability of services is layered on the top of the architecture. MARTE is extended with DPR and SOCM concepts on the one hand and with SystemC/TLM concepts on the other hand giving rise to MARTE4DPR and MAR-TE4SCTLM profiles, respectively. TLM interoperability layer is composed of core interfaces, sockets, generic payload, and base protocol. e lower layer includes the Sys-temC library providing the core language, SystemC data types, predefined channels, and utilities.
e functional elements are mapped onto architecture resources within an allocation model, which encompasses both spatial distribution and temporal scheduling features. From this allocation model which must be sufficiently detailed and precise, a SystemC/TLM simulation model can be obtained in two ways: either automatically through a model transformation following a rule-based approach or manually by the application of the MARTE4SCTLM profile. In turn, the resulting model is used for automatic SystemC/TLM code generation, which transforms a specification into an implementation according to a template-based approach. Finally, the execution of the generated code encompasses two major phases: elaboration followed by simulation. e simulation results can lead to a refinement of the specification models for performance improvement.
Extending MARTE Profile. e intention of profiles is to give a straightforward mechanism for adapting an existing metamodel with constructs that are specific to a particular domain, platform, or method  [8]. It is possible to extend profiles to create new adapted elements suitable for the modeling purpose. To tailor the MARTE profile for covering DPR, SOCM, and SystemC/TLM domain concepts, we propose to extend it with specific constructs, stereotypes, and tagged values referenced in two profiles: MARTE for DPR (MARTE4DPR) and MARTE for SystemC/TLM (MARTE4SCTLM). As illustrated by Figure  4 , the MARTE4DPR package (stereotyped as profile) depends on HLAM, GCM, SRM, HRM, and GRM packages. It enables using adapted terminology, giving syntax and semantics to new types, and adding information used in model transformation.
On the other hand, the MARTE4SCTLM package (stereotyped as profile) depends on HLAM, GCM, SRM, and GQAM packages; the intent is to provide specific stereotypes with iconic representation to map SystemC/TLM domain concepts. e proposed profiles enable the use of DPR domainspecific semantics and SystemC/TLM platform terminology while sharing all of MARTE's basic objectives. us, MARTE stereotypes can be reused by being referenced or specialized in MARTE4DPR and MARTE4SCTLM profiles. Users could apply the increment integrated or not with the International Journal of Reconfigurable Computing MARTE profile to address different concerns without conflicting constraints.
MARTE4DPR Profile. From the relevant starting points, MARTE stereotypes are refined to incorporate the missing DPR concepts. In what follows, we present the different extensions involving the MARTE subprofiles. (1) Extending MARTE::HLAM. e concern of the HLAM package is to provide high-level modeling concepts to deal with real-time and embedded features modeling  [17]. e related extensions are outlined in Figure  5. e ReconfigurableUnit stereotype specializes the RtUnit (real-time unit) by adding several properties related to DPR and SOCM domains. An RtUnit is a high-level construct; it owns one or more schedulable resources which can be created dynamically and a specific state-based behavior in which states represent configurations and transitions characterize reconfigurations of the unit.
e stopped state is reached after a disconnecting request, and consequently the service instance would be unregistered. e shared ServiceRegistry stereotype specializes the concept of protected passive unit (PpUnit). It provides permanent data storage for service metainformation including service description, IP configurations, and resource utilization parameters. e IPCoreService is an abstract concept that denotes the real-time behavioral features owned by a component. It could be specialized into SoftCoreService and HardCoreService stereotypes according to the type of core. (2) Extending MARTE::GCM. e GCM package provides additional modeling concepts for real-time and embedded system component-based strategies. We mainly focus on particular refinements related to communication aspects to better catch dynamic reconfiguration domain concepts.
A dependency is identified by the remote service component (provider) name, its port identifier, and the connection (binding) state. (3) Extending MARTE::SRM. e SRM package is a specialization of resources and services defined in the GRM package; it focuses on the modeling of application programming interfaces of software multitasking platform. We are mainly interested here in modeling concurrent execution contexts described in the SW_Concurrency package. As shown in Figure  9 , the FactoryProcess stereotype defines a business processing context owned by a factory unit; it specializes the SwSchedulableResource stereotype in order to support the modeling of static/dynamic spawned processes. e spawnedFunction attribute represents the function associated with the spawned process instance. e ReconfigurationControllerProcess stereotype provides specific services to dynamically manage and supervise the reconfiguration process; it specializes the SwSchedulableResource stereotype to support services dependencies resolution, reconfiguration triggering, and service publication and discovery.
MARTE4SCTLM Profile. A SystemC module is the smallest container of functionality with state, behavior and structure for hierarchical connectivity  [44]. e Sc_Module stereotype maps the SC_Module domain element. It specializes the HLAM::RtUnit stereotype with additional attributes; the component role within TLM interoperability layer is specified by the role attribute that takes its values in the enumeration {initiator, target, interconnect, top}. e variables and helpers attributes define local member variables and helper functions declared in the Sc_Module. e image associated with that stereotype is. e whole profile is presented in Figure  11. SC_PrimChannel is a SystemC construct used for implementing processes communication and modules interconnection. e Sc_Prim_Channel stereotype specializes the MessageComResource stereotype of SRM::SW_Interaction package with specific semantics appropriate to the transaction-level modeling.
SystemC/TLM Simulation Model. A SystemC/TLM simulation model is obtained by applying the MARTE4SCTLM profile to the allocation model as depicted in Figure  17. e top-level component Active3WayCrossover is stereotyped as Sc_Module; its isMain attribute is set to true meaning that the module will be instantiated within sc_main function. To construct the module hierarchy, the Sc_Module stereotype is applied to Filter#1 component to create a submodule within the parent module. Its role attribute is set to target specifying that the module will act as a target in TLM modeling. e variables and helpers attributes are part of data members and member functions to be declared within the Sc_Module. Factory#1 and Controller#1 nested components are also stereotyped as Sc_Module. e former contains a special member function called 64TapHPF stereotyped as Sc_Spawned and Sc_ read to handle the creation of a spawned process instance called from a thread process, and the latter holds a member function stereotyped as Sc_ read to map the control service.
Automatic Code Generation. e concept of transformation is fundamental to MDE; it consists of a refinement process decreasing the abstraction level of models by adding enough details to mapped models for automatic code generation. Depending on the nature of the target model, it is possible to distinguish between model-to-model (M2M) transformations and model-to-text (M2T) transformations. To implement our toolchain, we combined a M2M transformation to produce a SystemC/TLM target model from a MARTE4DPR source model with a M2T transformation to translate the previously produced model into a SystemC/ TLM source code. In our framework, M2M transformation is expressed by means of the Atlas Transformation Language (ATL): a domain-specific language and toolkit developed on the top of Eclipse platform.
e input model precisely specified in    International Journal of Reconfigurable Computing the MARTE4DPR metamodel is transformed into a target model that conforms to SystemC/TLM metamodel by following a common model transformation pattern. Eclipse Modeling Framework (EMF) provides support to create and instantiate ecore metamodels. In Figure  19 , we used the EMF tree-based editor to show a part of the hierarchy of the MARTE4DPR metamodel with a conforming model instance. Since ATL is a textual rule-based language, the generation of SystemC/TLM model elements is performed by applying declarative rules written at the metamodel level. In order to specify these matched rules, it is necessary to find similarities between source and target model concepts to relate the metamodels. Despite semantics variations between UML and SystemC, it is still possible to reduce the gap by building a mapping relationship of similar elements between UML/MARTE, MARTE4DPR, and SystemC/TLM.
e mapped concepts have been chosen so that they are semantically close to one another. In the context of DPR, the convergence between UML/MARTE and SystemC/TLM can be achieved through MARTE4DPR profile because of its conformance with UML/MARTE on the one hand and to the common domain of interest with SystemC, i. e. , the real-time and embedded domain, on the other hand. Table  4  shows the mapping from UML, MARTE, and MARTE4DPR concepts into SystemC/TLM ones, taking into account DPR structural and behavioral semantics. Once the declarative rules are triggered, the MAR-TE4DPR model elements should be matched and navigated in order to create and initialize the elements of the target model. As depicted in Figure  20 , the ATL transformation module is composed of helpers, model elements, and standard matched rules (written in declarative style).
Both isSpawned and isDynamic helpers are defined in the context of the FactoryProcess element and used to calculate Boolean values stating whether a factory process is dynamically spawned. e ReconfigurableUnit2SCModule rule is intended to generate SystemC module from a reconfigurable unit. e attributes of the generated Sc_Module are initialized using bindings. Other transformation rules as well as the generated SystemC/TLM model are presented in Appendix A. 1. Now that the semantics is precise enough, the application code can be generated by transforming models into textual artifacts. A template-based M2T transformation is specified and built with the Acceleo language. is transformation specification is structured into two modules that generate SystemC/TLM source code and C++ abstract factory pattern implementation.
e first generation engine takes as input the previously produced SystemC/TLM model which is in compliance with the metamodel shown in Figure  21. An Acceleo module contains templates made up of static and dynamic parts specifying text files with placeholders to be filled with data extracted from the input model. Figure  22  depicts a part of a related template used for generating the object hierarchy within a SystemC module. e second engine is dedicated to the code generation of business logic according to the abstract factory design pattern. e generated code contains template classes and services declaration to be paired with code files (refer to Appendix A. 2).
Experimental Results. Benefiting from the advantages of Eclipse-based tools, our framework offers facilities for graphical expressiveness with highly customization, extensibility, reusability, and maintainability capabilities. rough more than 50 new stereotypes to cover missing DPR concepts and SystemC/TLM constructs in MARTE, the proposed extensions should ensure the profile completeness with almost no modeling overhead. Furthermore, Papyrus tool provides extensive support facility for defining and applying increments conforming to the UML/MARTE standard. Existing tools and knowledge can be reused, thus reducing learnability effort and tooling cost. In order to demonstrate the effectiveness of the proposed framework with regard to produced artifacts, a comparative analysis between the automatic code generation and hand-coded implementation of the system is proposed.
e performance was measured on a Intel(R) Core (TM) i5-8265U running at 1. 6 GHz with 4 GB RAM under Windows 10. Table  5  summarizes the quantitative evaluation of the hand-coded implementation of the system calculated with LocMetrics tool  [46]. e system implementation has a total of 1256 lines of code spread over 6 source files requiring 6. 041 person-months of development effort. With a measured value of 117 for the cyclomatic complexity, the code appears to be very difficult to maintain and test. In addition, hand coding is well known to be a very tedious, error prone, and time-consuming process. For assessing the internal quality of ATL model transformation, we used a set of specific metrics based on quality attributes introduced in  [47, 48]. ese latter include inter alia understandability, modifiability, reusability, modularity, completeness, consistency, and complexity.
Conclusion In this paper, we have presented a high-level modeling framework for Dynamically Reconfigurable Systems-on-Chip targeting SystemC at transaction level. To better leverage software engineering solutions in terms of dynamic availability and service adaptation support, a service-oriented component-based approach was applied to DRSoC modeling. For this purpose, we have proposed an MDEbased design flow using extended MARTE models as initial specification. e latter are progressively refined to reach a SystemC/TLM executable code. One of the main contributions of this work is the extension of MARTE profile with missing modeling capabilities. Indeed, although dedicated to model-driven development of embedded systems, MARTE needs to be specialized with both DPR and service orientation semantics, which has been realized in the MARTE4DPR profile.