On-line abstract:

The 11-year activity cycle of the Sun is a consequence of a dynamo process occurring beneath its surface. We analyzed photometric data obtained by the CoRoT space mission, showing solar-like oscillations in the star HD49933, for signatures of stellar magnetic activity. Asteroseismic measurements of global changes in the oscillation frequencies and mode amplitudes reveal a modulation of at least 120 days, with the minimum frequency shift corresponding to maximum amplitude as in the Sun. These observations are evidence of a stellar magnetic activity cycle taking place beneath the surface of HD49933 and provide constraints for stellar dynamo models under conditions different from those of the Sun.

CoRoT reveals a magnetic activity cycle in a Sun-like star

Rafael A. García, 1* Savita Mathur, 2 David Salabert, 3,4 Jérôme Ballot, 5 Clara Régulo, 3,4 Travis S.

Metcalfe, 2 Annie Baglin 6 1 Laboratoire AIM, CEA/DSM-CNRS, Université Paris 7 Diderot, IRFU/SAp-SEDI, Centre de Saclay, 91191, Gif-sur-Yvette, France. 2 High Altitude Observatory, NCAR, P.O. Box 3000, Boulder, CO 80307, USA. 3 Instituto de Astrofísica de Canarias, 38200, La Laguna, Tenerife, Spain. 4 Depto. de Astrofísica, Universidad de La Laguna, 38206 La Laguna, Tenerife, Spain. 5 Laboratoire d'Astrophysique de Toulouse-Tarbes, Université de Toulouse, CNRS, 31400, Toulouse, France. 6 *To whom correspondence should be addressed. E-mail: Rafael.Garcia@cea.fr

Brevia Text:

Our understanding of and capability to predict the 11-year activity cycle of the Sun (1), which is driven by a dynamo process seated at the bottom of the convective zone, is far from being complete, as suggested by the recent unusually long solar minimum of cycle 23 (2,3). Observations of magnetic activity cycles in other stars can potentially improve our knowledge of dynamo processes because they allow us to sample different physical conditions distinct from those in the Sun. Although many stars exhibit activity cycles and some empirical relations have been found (4), a detailed knowledge of the internal structure and dynamics of the star, in particular the depth of the convective envelope and the degree of differential rotation, is required to improve the constraints on theory. Here we show how asteroseismology has revealed the signature of a magnetic activity cycle in a Sun-like star.

Helio-and asteroseismology are the only tools available that can probe the structure and dynamics of the Sun and stars through the study of acoustic oscillations (5). The oscillation modes are sensitive to variations in the magnetic field, and their characteristics change throughout the activity cycle. In the Sun, for instance, the oscillation frequencies are shifted higher during solar maximum while the amplitudes decrease, showing anti-correlated temporal variations (6)(7)(8)(9).

The Convection Rotation and planetary Transits (CoRoT) mission has so far observed 6 main-sequence stars exhibiting solar-like oscillations during more than 130 days each as part of its asteroseismic program (10). One of these stars is HD49933, an F5V star 20% more massive and 34% larger than the Sun. It has been observed twice, for 60 days in 2007 and 137 days in 2008, spanning a total of 400 days. More than 50 individual acoustic modes have been identified (11,12) and then used to model the stellar interior (e.g. 13). Its rotation period is 3.4 days (8 to 9 times faster than Sun).

To search for the effects of magnetic activity in this star, we measured the variation of the mode amplitude and the frequency shift of the acoustic-mode envelope (7). As observed in the Sun, there is a clear anti-correlated temporal variation between both parameters (Fig. 1), revealing a modulation in the second epoch that seems to indicate a period of at least 120 days related to the internal magnetic activity of HD49933. The observations agree with the scaling proposed by (8), which predicts larger than solar frequency shifts for stars that are hotter and more evolved, in contradiction to the scaling suggested by (9). The long-period variations detected in the luminosity of the star -interpreted as fluctuations in the positions and sizes of starspots-allow us to also study the surface activity (7). Indeed, the starspot signature changes with time showing a quiet period during the first part of the second set of observations (Fig. 1). This confirms the existence of an activity cycle, which seems to be shifted in time compared to the seismic indicators. Finally, medium resolution spectra of the Calcium H and K lines obtained on April 13, 2010 confirm that HD49933 is an active star with a Mount Wilson S-index of 0.3. Asteroseismology has thus revealed a stellar activity cycle analogous to that of the Sun.

Supporting Online Material for

CoRoT reveals a magnetic activity cycle in a Sun-like star Rafael A. García, 1* Savita Mathur, 2 David Salabert, 3,4 Jérôme Ballot, 5 Clara Régulo, 3,4 Travis S. Metcalfe, 2 Annie Baglin 6 1 Laboratoire AIM, CEA/DSM-CNRS, Université Paris 7 Diderot, IRFU/SAp-SEDI, Centre de Saclay, 91191, Gif-sur-Yvette, France. 2 High Altitude Observatory, NCAR, P.O. Box 3000, Boulder, CO 80307, USA. 3 Instituto de Astrofísica de Canarias, 38205, La Laguna, Tenerife, Spain. 4 Departamento de Astrofísica, Universidad de La Laguna, Tenerife, Spain. 5 Laboratoire d'Astrophysique de Toulouse-Tarbes, Université de Toulouse, CNRS, 31400, Toulouse, France. 6 LESIA, UMR8109, Université Pierre et Marie Curie, Université Denis Diderot, Obs. de Paris, 92195 Meudon Cedex, France.

1.-Methodology:

CoRoT is a 27 cm afocal telescope, imaging the stellar field onto four CCDs (2048 x 4096 pixels each), two dedicated for exoplanet research and two for asteroseismology. In this work, we have analyzed the so-called "Helreg" (S1) light curves of HD49933 provided by the CoRoT satellite with a regular sampling rate of 32 seconds.

We divided these observations into subseries of 30 days shifted by 15 days and computed the associated power spectra using a standard Fourier Transform algorithm. Then we subtracted the signal from the convective background using a one component standard Harvey model (see a detailed explanation in S2). Fig. S1 shows the time evolution of the photon noise and the granulation time scale (τ gran ). In both cases, there is no correlation with the seismic parameters. This is also the case in the Sun, for which no correlation has been found between the granulation characteristic time and several activity proxies during solar cycle 23 (S3).

Due to the short length of the subseries, the frequency resolution of the power spectrum is low and we started by using the full p-mode envelope instead of analyzing the amplitude and the frequency of each individual mode. Thus, for each subseries the root-mean-square maximum amplitude per radial mode was computed by fitting a Gaussian function to the pmode region between 1400 to 2500 µHz where this bump is visible (S2).

The frequency shift of acoustic modes has been used several times as a good proxy of the activity cycle (see for example S4, S5). In the present analysis it is calculated by two methods: the cross correlation of the p-mode region of different data segments and by computing the time evolution of the average of the individual p modes.

1.1.-Frequency shift compute by cross-correlation methods:

For each subseries, we calculate the cross correlation of the power spectrum (without smoothing the spectrum) with a reference one, taken during the minimum of activity in the region where the individual modes can be identified (1460 to 2100 µHz). As the crosscorrelation function is not symmetrical, we compute the third moment of the distribution of points (see Fig. S2) giving its skewness. To obtain the maximum of the cross-correlation function, we fit a Gaussian profile centered at the position given by the skewness to avoid any bias induced by this asymmetry. The frequency shift is then given by the centroid of the fitted Gaussian. The associated error is the 1σ error bar of the fit. This method has been extensively used to study the activity cycle using single-site helioseismic ground-based data (S6). In Fig. S2 we show two examples of the correlation functions found in the present analysis. On the left, the cross-correlation between the first subseries and the reference one is shown, while on the right we plot the cross correlation between the last subseries and the reference one. We have used the 7 th subseries as a reference because it corresponds to the minimum activity (see Fig. 1). The continuous red line is the Gaussian fit used to obtain the frequency shift. The left panel shows the cross-correlation between the first subseries and the reference one. The right panel shows the one between the last subseries and the reference one.

1.2.-Time evolution of average individual frequency shifts of HD49933

Even with a relatively low signal-to-noise ratio, the individual p-mode parameters can be extracted by fitting each subseries of 30 days using a standard likelihood maximization function (S7). Each mode component was described by a Lorentzian profile. The fitting was performed over frequency windows containing the l = 0, 1, and 2 modes. The initial parameters were taken from ( 12), the inclination angle and the rotational splitting were fixed to their estimated values (12). The temporal variation of the l = 0 and 1 modes was calculated over the frequency range 1460 -2070 µHz, the outliers above 5σ were removed. The resulting frequency shifts have the same temporal dependence and amount of change as those obtained with cross-correlation methods (see Fig. 1).

2.-Application to the Sun.

In order to test our methodology we have applied it to solar photometric data obtained from the SPM/VIRGO instrument on board the SoHO spacecraft (S8) during solar cycle 23. We first computed the average of the three independent channels (red, blue, and green) and we divided the full time series into subseries of 1 year with 25% overlap from 1996 till 2006. This subseries length was chosen to avoid any periodicity due to the SoHO orbital period and to maintain a proportion of ~10% between the size of the subseries and the length of the activity cycle, which is close to what appears to be the case for HD49933. The frequency range used in the analysis is from 1900 to 5000 µHz for the amplitudes and between 2400 and 3400 µHz for the frequency shifts. Fig. S3 shows the temporal variation of the p-mode amplitude as well as the frequency shift obtained from the cross-correlation method and from the analysis of individual p-mode frequencies. The anti-correlation between the frequency shift and the amplitude variation is apparent. We also show the International Sunspot Number -obtained from the Solar Geophysical Data Centre (http://www.ngdc.noaa.gov/)-as a proxy of surface activity. Seismic indicators vary in phase with solar activity proxies, but the degree of correlation differs depending on the phase of the cycle (S9). The red triangles are the frequency shifts computed using the cross-correlation method. The black circles are the frequency shifts computed using individual frequencies of modes l=0 to 2. We have used the 5 th series as the reference (with a frequency shift 0). The continuous line is the International Sunspot Number. We have removed the series for which the duty cycle is less than 80% (corresponding to the SoHO vacation period in the second part of 1998 and beginning 1999).

It is important to notice that the frequency shift measured in the Sun using cross-correlation methods is smoother compared to the average frequency shift obtained from the analysis of individual modes. This is a consequence of the high signal-to-noise ratio of solar observations and the different weighted average implicit in each method. In the case of the individual frequency shifts, the modes l=0, 1 and 2 have the same weight while in the cross-correlation methods the modes are weighted by their intrinsic amplitudes (l=1 are higher than l=0 and l=2). Since the frequency shift is not the same for each degree, the global shape is the same but in the details there are some differences.

3.-Light Curve of HD49933

A visual inspection of the light curve of HD49933 (see Fig. S4) reveals a modulation of a few days that has been interpreted as the signature of starspots crossing the visible surface of the star. Spot modeling for the first set of observations provides an estimate of the rotation rate of the star, its inclination angle, and the lifetime of the starspots that was established to be around 3.45 days (S10). Moreover, we see quiet periods in which the starspot signature is small and others in which the signature of the rotation is better defined. To better uncover any signature of an activity cycle in the light curve we have built a starspot proxy by computing the standard deviation of the light curve using the same subseries of 30 days shifted every 15 days. The result is shown in the bottom panel of Fig. 1.

Once again, we see a clear modulation in this activity proxy with a maximum that is shifted around 30 days compared to the seismic indicators. The rising phase takes around 60 days to evolve from the minimum to the maximum. Unfortunately, as it is quite possible that the cycle would not be symmetric (the slope of the rising phase being probably different than the descending phase), we are not able to give the full length of the cycle. Indeed, to correctly interpret this activity proxy -obtained from the light curve-we need to take into account the small inclination angle of the star, € 17°-9 +7 (12), and make some assumptions about the active longitudes of the star.

4.-Observations of Ca H and K.

Two medium resolution spectra of HD49933 were obtained with the RCSpec instrument on the SMARTS 1.5m telescope at Cerro Tololo on 2010 April 13 (fits files are available as part of the support on-line material). The data were subjected to the usual bias and flat field corrections, and the spectra were extracted and wavelength calibrated using a reference Th-Ar spectrum obtained immediately before the stellar exposures. Following (S11) the

Fig. 1 .

 1 Fig. 1. Time evolution -beginning February 6, 2007-of the mode amplitude (top), the frequency shifts using two different methods (central): cross correlations (red triangles) and individual frequency shifts (black circles); and a starspot proxy (bottom) built by computing the standard deviation of the light curve (7). All of them are computed using 30-day long subseries shifted every 15 days (50% overlapping). The corresponding 1σ error bars are shown.

Figure S1 :

 S1 Figure S1: Variations with time of the photon noise (top) and the characteristic time of the granulation (bottom).

Figure S2 :

 S2 Figure S2:Examples of cross-correlation functions used to compute the frequency shift. We have used the 7 th subseries as a reference because it corresponds to the minimum activity (see Fig.1). The continuous red line is the Gaussian fit used to obtain the frequency shift. The left panel shows the cross-correlation between the first subseries and the reference one. The right panel shows the one between the last subseries and the reference one.

Figure S3 :

 S3 Figure S3: Temporal evolution of the p-mode amplitude (top) and the frequency shift (bottom) using solar SPM/VIRGO data. The red triangles are the frequency shifts computed using the cross-correlation method. The black circles are the frequency shifts computed using individual frequencies of modes l=0 to 2. We have used the 5 th series as the reference (with a frequency shift 0). The continuous line is the International Sunspot Number. We have removed the series for which the duty cycle is less than 80% (corresponding to the SoHO vacation period in the second part of 1998 and beginning 1999).

Figure S4 :

 S4 Figure S4: Light curve of HD49933 for the first set of measurements (top) and the second one (bottom). We have rebinned the light curve to 640s.

calibrated spectra were then integrated in 1.09 Å triangular passbands centered on the cores of the Ca H and K lines and compared to 20 Å continuum passbands from the wings of the lines to generate an S-index on the Mount Wilson system. These spectra confirm that HD49933 is an active star, with a Mount Wilson S-index of 0.302 ± 0.005.

References and Notes

S1


Daniela Genius
email: daniela.genius@lip6.fr

Letitia W Li

Ludovic Apvrille

Tullio Tanzi

Multi-level Latency Evaluation with an MDE Approach

Keywords: Embedded Systems, System-level Design, Simulation, Virtual Prototyping, Latency

Designing embedded systems includes two main phases: (i) HW/SW Partitioning performed from high-level functional and architecture models, and (ii) Software Design performed with significantly more detailed models. Partitioning decisions are made according to performance assumptions that should be validated on the more refined software models. In this paper, we focus on one such metric: latencies between operations. We show how they can be modeled at different abstraction levels (partitioning, SW design) and how they can help determine accuracy of the computational complexity estimates made during HW/SW Partitioning.

Introduction

Applications modeled at high levels of abstraction contain a very indeterminate notion of latency. This is typically the case for applications modeled in the scope of system-level hardware / software partitioning. When applications are mapped onto virtual or existing hardware, in particular onto multi-processor systems-on-chip (MP-SoC), latencies become a function of multiple precise factors: cache effects, memory latencies, bus or network on chip transfers, synchronization latency between processors.

TTool [START_REF] Apvrille | TTool for DIPLODOCUS: an environment for design space exploration[END_REF] supports both Partitioning and System Design, and considers that partitioning decisions may need to be changed due to additional information from verifications performed during the System Design phase. Recent work studied how to feed back information such as cycles per instruction and cache miss rate, but did not yet include latency between operators nor a definition of a refinement relation between abstraction levels [START_REF] Genius | Model-Driven Performance Evaluation and Formal Verification for Multi-level Embedded System Design[END_REF].

We explain how latencies of these modeling levels relate to one another, and how results can be backtraced to models at higher abstraction levels e.g. from software to partitioning models. We can thus generate hardware/software platform from models that can be simulated at very low level. Our method is suited to MP-SoCs with many processors and complex interconnections e.g. network on chip. Latency precision increases as cycle and bit accurate levels take into account application, hardware and operating system.

Section 2 presents the related work. Section 3 focuses on our method. Section 4 explains the notion of latency on different abstraction levels within an MDE approach. Section 5 details the rover case study and shows how latencies can be determined at different levels. Section 6 concludes the paper.

Latencies in Related Work

A number of system-level design tools exist, offering a variety of verification and simulation capabilities at different levels of abstraction.

Sesame [START_REF] Erbas | Multiobjective optimization and evolutionary algorithms for the application mapping problem in multiprocessor system-on-chip design[END_REF] proposes modeling and simulation features for MP-SoC at several abstraction levels. Semantics vary according to the level of abstraction, ranging from Kahn process networks [START_REF] Kahn | The semantics of a simple language for parallel programming[END_REF] to data flow for model refinement, and discrete events for simulation. Sesame is however limited to the allocation of processing resources. It models neither memory mapping, nor the choice of the communication architecture, and is thus less precise than tools including these aspects.

The same research team proposes the Daedalus [START_REF] Thompson | A framework for rapid system-level exploration, synthesis, and programming of multimedia MP-SoCs[END_REF] design flow, which allows to evaluate latencies at a register transfer level. Daedalus is however targeted towards automated synthesis of multimedia streaming applications on MP-SoC, which are somewhat more predictable than typical embedded applications that interact with the environment in many ways. SATURN [START_REF] Mueller | The SATURN approach to sysml-based hw/sw codesign[END_REF] uses Artisan Studio (Atego, 2017) for SysML editing and performs a co-simulation using the QEMU software emulator. It can also configure an FPGA. However, simulations under SystemC are performed only at the quite high TLM-2.0 abstraction level (OSCI, 2008) which makes latency measurements less precise.

The Architecture Analysis & Design Language AADL allows the use of formal methods for safetycritical real-time systems, with a focus on latency and safety, properties which are also important in the context we explore. Similar to our environment, a processor model in AADL can have different underlying implementations and its characteristics can easily be changed at the modeling stage [START_REF] Feiler | Model-based engineering with AADL: an introduction to the SAE architecture analysis & design language[END_REF].

MARTE [START_REF] Vidal | A co-design approach for embedded system modeling and code generation with UML and MARTE[END_REF] shares many commonalities with our overall approach; however, it lacks separation between control and message exchange. More recent work [START_REF] Taha | An entirely model-based framework for hardware design and simulation[END_REF] contains hardware platform generation and support simulation using Simics, a full-system simulator; originally purely functional, il now permits cycle-accurate simulation. A binary of the software is loaded onto the platform, and runs under an operating system.

The work shown in [START_REF] Lee | Dealing with aadl end-to-end flow latency with uml marte[END_REF] uses a UML/MARTE model to express AADL flow latencies and takes into account worst case latencies and jitter. This work is more (but not exclusively) focused on the periodic case and does not contain a virtual prototyping phase.

MDGen from Sodius (Sodius Corporation, 2009) generates SystemC code from SysML models. It adds timing and hardware specific artifacts such as clock/reset lines to Rhapsody models and generates synthesizable, cycle-accurate implementations. In these aspects, it is very similar to our tool, which generates a cycle and bit accurate simulation platform; MDGen however does not fully address correctness by construction aspects.

The B method and more recently Event-B [START_REF] Abrial | Modeling in Event-B: system and software engineering[END_REF]) model systems at different abstraction levels and mathematically prove consistency between refinement levels. Based on set theory and the B language, it is well established in large-scale public/private projects (urban transports etc.) but much less widespread in industry than UML/SySML based approaches.

Methodology Overview

Our methodology for the design of embedded systems involves design at four levels of abstraction where different latency measurements (see Figure 1). The partitioning level features two sub-levels.

The purely functional level relies on logical time,

where latency is based on the logical time between functional operators describing the behavior of tasks. These operators can describe non deterministic behavior, and model in an abstract way the complexity of computations.

2. The system-level mapping level gives a physical time to complexity operations, thus giving a physical time to latencies. However, the high level abstract hardware components of our approach make these latencies imprecise: the values we obtained -which might be used as a partitioning decisionare meant to be confirmed during the next levels.

The software level also includes two sub-levels.

1. At the software design level, software is modeled with blocks and state machine diagrams. The transitions between states can be annotated with minimum and maximum physical time functions (after, computeFor). Latency estimates between states/transitions are obtained by interactive simulation, without any hardware model.

2. The deployment level allows a designer to map software blocks onto hardware elements (CPU, memory, etc.). A cycle and bit accurate SystemCbased simulation is then used to obtain a cycleprecise measurement of latencies. Latencies obtained there can be used to correct decisions (e.g. partitioning decisions) taken at the higher level (e.g., at system-level mapping).

Latencies in MDE

In this section, we formally define latencies with regards to their abstraction levels.

Latencies

We assume a model M = (T,Comm), which contains a set of execution elements (Tasks) and communications between tasks. T can be defined as T = (Op, n) with Op being a set of operators -control, communication, complexity -and n a next function n : op → {op } returning all the subsequent operators of a given operator. A complexity operator is an op that abstracts a computation into either a number of operations to be executed or a physical time. Also, an operator op that belongs to a task t of a model M is denoted op M,t . An execution environment is denoted as E = (M, H, m t , m c ) where M is a model, H

Computing Latencies

Occurrences O of an operator op 1 of an execution of t ∈ T are expressed as the set of all times x of op 1 :

O(op 1 ) = {x op 1,1 , x op 1,2 , . . . }.
We can thus determine for a given E the set of all latencies L E op 1 ,op 2 between op 1 and op 2 , where for each x op 1 ∈ O(op 1 ), we find the first occurrence of op 1 after each occurrence of op 2 , calculated as the minimum of all x op 2 ∈ O(op 2 ) where x op 2 > x op 1 . Then, we can define the min latency as: l E min;op 1 ,op 2 = min(L E op 1 ,op 2 ). Similarly, the max and mean can be defined.

Correspondence Between Latencies

Our objective is to be able to relate latencies of models at different abstraction levels so as to confirm decisions taken at the highest abstraction level. To relate latencies, we first need to relate operators of different abstraction levels. We thus define a correspondence relation between operators of two abstraction levels u (for upper) and l (for lower). C (op) is therefore defined as:

∀op M l ,t l , noted op l , C (op l ) = op u φ
otherwise We can thus relate latencies when op l,1 and op l,2 of M l have both a non empty correspondence in M u . Figure 2 explains how latencies and models relate across different abstraction levels. Since the goal is to relate operators of functions and blocks, we do not need R to be a refinement relation between the exe-cution environments E u and E l . Therefore, the engineer is in charge of ensuring that hardware nodes have been correctly refined, and mapping relations adapted to the refined model.

R can be defined as follows. Tasks can be split in subtasks. Complexity operators can be replaced by a sub-behavior. Communications between tasks may be added in order for subtasks to exchange information, but communication operators can only be added in sub-behaviors replacing complexity operators. More formally, if M u = (T u ,Comm u ) with ∀t ∈ T u , t = (Op u , n u ), then t can be refined by R : 1. t u can be replaced by k tasks t 1,l ,t 2,l , . . . ,t k,l with k > 0 and Op u ∈ ∪Op x,u i.e. the operators of t u are split among the k tasks if k > 1, then additional communications and controls may be introduced between operators of the original tasks, thus provoking an update of next functions n l in the lower levels.

2. Each complexity operator can be replaced by a sub-behavior:

Op u = (O u,ctrl , O u,comm , O u,complexity , O u,sub ).
A sub-behavior Sub = (Op, n, n r ) can be seen as a sub-activity of the main task that suspends the main task when it is triggered, and that has a next operator n r that resumes the task to the corresponding next operator in the main task. Therefore, the n function of a sub activity must reference only operators of this sub activity.

Let us now apply the latency concepts to our abstractions levels: partitioning, and software design.

Partitioning

The HW/SW Partitioning phase of embedded system design models the abstract, high-level functionality

M u E u (M u , H u , mt u , mc u )

Models

Execution env. and architecture of a system [START_REF] Knorreck | Formal System-level Design Space Exploration[END_REF].

It follows the Y-chart approach, first modeling the abstract functional tasks, candidate architectures, and then finally mapping tasks onto the hardware components [START_REF] Kienhuis | A Methodology to Design Programmable Embedded Systems: The Y-Chart Approach[END_REF]. The application is modeled as a set of communicating tasks on the Component Design Diagram (an extension of the SysML Block Instance Diagram). Task behavior is modeled using control, communication, and computation operators.

A Partitioning P is defined as a set of models P = (FM, AM, MM), with FM a Functional Model, AM an Architecture Model, and MM a Mapping Model.

Functional Level

A Functional Model is defined as FM = (T,Comm) when T is a set of Tasks, and Comm is a set of Communications between tasks. A Task t is defined as t = (Attr, B) with Attr a set of Attributes, and B a behavior.

The Behavior B = (Ctrl,CommOp,CompOp) consists of Control Operators Ctrl -such as loops, choices, etc. -Communication Operators CommOp -channel read/write, events send/receive -, and Complexity operations CompOp, who model the complexity of algorithms through the description of a min/max interval of integer/float/custom operations on an execution hardware (CPU, hardware accelerator, FPGA, etc.), see the top left part of Figure 3.

At this abstraction level, latency is defined as the logical time between complexity operators as shown in Figure 1.

Mapping Level

Mapping involves allocating tasks onto the architectural model. A task mapped to a processor will be implemented in software, while a task mapped to a hardware accelerator will be implemented in hardware.

The architectural model is a graph of execution nodes (CPUs, Hardware Accelerators), communica-tion nodes (Buses and Bridges), and storage nodes (Memories). Hardware components are highly abstracted: a CPU is defined as a set of parameters such as an average cache-miss ratio, go idle time, context switch penalty, etc. An Architecture Model

Software Design

A software design consists of both a software model, and a experimentation of this software running on a (virtual) prototype.

Software Model

A Software Design model can be considered a refinement of a Partitioning model, where only software-implemented tasks are modeled with their detailed implementation, thus realizing the R relation: some tasks of P might be split while extra communications related to split tasks can be added.

Figure 3 shows the relation of Behavior Models between Partitioning and Software Design models.

The Software Model S = (T, I) can also be defined as a set of Tasks t and Interactions i between tasks. Regarding the behavior of tasks, while Partitioning models express algorithms as an abstract complexity operation and communications in terms of their size only, Software Design models describe the implementation of algorithms with a sub-behavior description using attributes, and interactions (based on signals exchanges) contain exchanged values stored in attributes of blocks. Thus, the set of attributes of software tasks is likely to be enriched both with regards to the partitioning model for algorithms details and communication details. Furthermore, the complexity operators in Partitioning, expressed as a function of execution cycles, are translated into either a time function T F() or subbehavior subB. More formally, the transformation relation of partitioning behavior to software design behavior can be expressed as:

B P = (Ctrl,Comm,Comp) → B S = (Ctrl ,Comm , T F, subB)
thus following the approach explained in section 4.1.2. For those tasks present in both Partitioning and Software Design models, while their behaviors appear different, their overall functionality should be the same; traces of their execution flow should involve the same sequence of operations and complexities/times. If the complexities are accurate and the model correctly translated, measured latencies between corresponding elements should remain the same.

Concerning latencies pertaining to communications, we restrict our analysis to those that remain unchanged between levels. If significant discrepancies occur, then there is an error in one of the models. The computation complexities for certain algorithms may have not been well estimated. Also, there could be an inaccurate modeling of the architecture, with a CPI (cycles per instruction) parameter not correctly set.

The formalizations introduced before provide a correspondence function C which takes as input an operator of a Software Design (lower level) and outputs an operator of the upper level (e.g., partitioning): it can thus be used to relate latencies between software design and partitioning models.

To find each corresponding Partitioning operator op P for a Software Design operator op SD , we must first determine if op SD was part of the subB added during the refinement of a complexity operator. If so, we conclude there is no corresponding operator op P .

If not, and the communication exists in both Software Design and Partitioning, then we find the partitioning operator that was translated into op SD during the refinement process.

The software model can be functionally simulated, taking into account temporal operators but completely ignoring hardware, operating systems and middleware. This simulation aims to identify logical modeling bugs, and estimate latencies, but the real computation of latencies (min, max, mean) is expected to be performed with the Software Prototyping execution model.

Software Prototyping

In order to prototype the software components with the other elements of the destination platform (hardware components, operating system), we use a so-called Deployment Diagram in which tasks are mapped to a model of the target system. Then, a model transformation generates the software elements (tasks, main program) and the hardware elements are built from the deployment information e.g. top cells of the hardware components in SoCLib (So-cLib consortium, 2003). The latter is an open library of multiprocessor-on-chip components based on the shared memory paradigm, consisting of SystemC models of hardware modules and an operating system. Precise cycle and bit accurate models for the hardware allow to measure the latency in terms of simulation cycles.

In order to evaluate latencies when the system is running, we proceed by intercepting the traffic on the interface between interconnect and memory bank, which has minimal impact on performance as it does not increase the code size. The trace thus obtained can then be analyzed to obtain latency values.

Case Study

Autonomous vehicles and other robots have been proposed for disaster relief efforts. Our case study describes the design of a rover, a small autonomous vehicle which will search through rubble for disaster victims. The rover is equipped with telemetric sensors, located in the front, rear, top, and sides. These sensors allow the rover to detect obstacles and navigate the terrain autonomously [START_REF] Tanzi | Towards "drone-borne" disaster management: Future application scenarios[END_REF]. The rover adjusts its acquisition behavior based on the situation. When it detects no obstacles in proximity, the rover decreases its sampling rate, assuming that no obstacles will suddenly appear in its path. When an obstacle is detected in close proximity, or within its "safety bubble", the rover adapts its behavior and increases its rate of acquisition. When the rover has detected obstacles in very close proximity, exact distances to obstacles become more critical.

Precise distance calculations depend not only on the telemetric sensor measurements, but also on ambient conditions. Therefore, to obtain an exact measurement, temperature and pressure sensors can be activated. The rover must be able to respond to obstacles within a set time frame -i.e., a maximal latencyto avoid collisions. The ultrasonic sensor's sampling rate depends on the proximity of the obstacle.

Functional and Partitioning Levels

We begin by modeling at the partitioning level using TTool's DIPLODOCUS environment. The rover consists of a main controller which receives data from a distance sensor and temperature sensor, which it uses to determine motor commands sent to the motor control, as shown in Figure 4. The main controller behavior and sampling rate of the distance sensor depends on the proximity of an obstacle (far away, intermediate, close). For simplicity, we map all tasks on one processor and all data transfer on one bus and one memory.

The mapping of tasks for our case study should ensure that the maximum latency between the detection, decision and the resulting actions occurs within a required time frame. Latency checkpoints, represented by small blue flags, are inserted at important points in each component's activity, such as on channel data transfers which relay the sensor data to the main controller and command transfers controlling the motor (Figure 4). We moreover evaluate the latency between reception of a signal of the DistanceSensor and a reaction via motorCommand. We sssume the rover moves at 6 km/h, thus covering a distance of 100 meters per minute. To determine the maximum latency between two checkpoints, we use the interactive simulation of TTool. Minimal, maximal and average latencies as well as the standard deviations are determined for the paths that were taken (left part of Table 1).

Software Design

Software Model

Figure 5 shows the tasks of the rover modeled using TTool's Software/System Design environment, AVATAR. There are four blocks corresponding to the fours tasks already present in the functional model in Figure 4. Figure 6 shows part of the the state machine diagrams of MainControl, leaving out the states which compute the change of the sampling rate and the motor control instructions. The two sensors with their latency checkpoints and the data transmitted as well as MotorControl closely resemble their higherlevel modeling counterparts. As a refinement on distance detection, we model left, front and right distances separately. MotorControl is essentially unchanged, while temperature measurement simplifies the stop and start events with a single control signal. While the data transmitted through the channels is more precise than in the partitioning model -for example, motorCommand now consists of two integers leftCommand, rightCommand, whereas ultrasonicData has three parameters (distanceLeft,distanceFront,distanceRight, mo-torCommand has two (leftVelocity, rightVelocity). On the other hand, the main control automaton is simplified; branches can be taken depending on the data received. Only five signals are required, regrouped into three channels: from the viewpoint of mainControl, two each for reception and control of data from the distance and temperature sensors, and a last one for motorControl.

Latency Evaluation

The right hand side of Table 1 shows the results we obtained by performing an interactive simulation on the software model (i.e. without any target platform), examining as before the sensor data and motor control channels as well as the latency between reception of sensor data and sending of motor commands to determine if the reaction time is adequate. Again, the data stemming from the DistanceSensor has a higher latency and the differences between ultrasonicData and tempData are even more important. The maximum reaction time (last row) is higher, yet the rover controller reacts on time to obstacles at least 3 cm away.

Software Prototyping

From the Rover Deployment Diagram (see Figure 7), we generate the prototyping environment based on SystemC top cells. In Figure 7, all tasks are mapped onto one processor, and the three signals are mapped 1 shows the results we obtain under SoCLib. Latency variations on the prototype are much less significant than those derived by interactive simulation. In particular, the cost of a transfer of ultrasonic data was overestimated in the Partitioning and Software Models. On a MPSoC, using burst transfers, the cost of transmitting several values is thus mostly overshadowed by the cost of the protocol.

Feedback of Latency Results

Latency requirements on channels are annotated by the designer in the TTool diagrams. There are two kinds of problems that can be detected after simulation on the prototype and marked in the diagram: if the simulation result at the current level does not meet the requirement, or if it deviates more than a percentage fixed beforehand, we mark the label in red. Figure 8 shows the latency for a motorCommand issued by MainControl and received by MotorControl. The boxes on the left denote that the signal arrives from another block. We detect a deviation of the latency for motorCommand on the software design level. Thus we can correct the assumptions on the partitioning. This paper formalizes latency modelling and latency measurements at different abstraction levels in an MDE design flow. The principal contribution is the establishment of a formal connection between the latencies on the higher and lower levels of abstraction followed by a validation by simulation of the software part on a cycle-accurate model of a MP-SoC. Our work makes it possible to detect incoherencies in the models, backtrace results to the higher levels and indicate when latency requirements are not met or diverge too strongly across different levels.

Our toolchain relies entirely on free software; many others, also cycle-accurate, use commercial SysML editors or simulation tools [START_REF] Taha | An entirely model-based framework for hardware design and simulation[END_REF][START_REF] Mueller | The SATURN approach to sysml-based hw/sw codesign[END_REF]Sodius Corporation, 2009).

The complete backtracing phase, also containing information on cache miss rate, cycles per instruction, etc., obtained at the lower levels, will be fully automated in the future, a step towards a complete multilevel Design Space Exploration environment.

Figure 1 :

 1 Figure 1: Latency Measurement through the Embedded System Design Process

Figure 2 :

 2 Figure 2: Relations between models and latencies between two abstraction levels

Figure 3 :

 3 Figure 3: Relation between latencies in Partitioning and Software Design Models

  Figure 4: Rover Functional Model

••

  Temperature sensor data (written by Temperature-Sensor, read by MainControl) • Distance sensor data (UltrasonicData written by DistanceSensor, read by MainControl on three different paths Motor command (written by MainControl on three different paths, read by MotorControl)

Figure 6 :

 6 Figure 5: Software Model with a SysML Block Diagram

Figure 7 :

 7 Figure 7: Rover Deployment Diagram

  Figure 8: Backtracing latencies

  AM = (CommNode, StoreNode, ExecNode, link) is built upon abstract Hardware Components: Communication Nodes CommNode, Storage Nodes StoreNode, Execution Nodes ExecNode, and architectural links between Communication Nodes and any other node link. ExecNode defines a conversion from Complexities to Cycles, and a speed converting Cycles to seconds. Similarly, CommNode and StoreNode give a physical time to logical transactions. The mapping therefore specifies a physical time for latencies defined at functional level, as shown by the top right part of Figure 3. We can determine latencies in physical time in two different ways. 1. A Formal Verification FV : P → RG is a function that takes as argument a Partitioning P and outputs a Reachability Graph RG. RG contains all possible Execution Traces ET . The analysis of RG makes it possible to obtain minimum and maximum latency values i.e. l P min and l P max . 2. Less formally, a simulation of P generates one single Execution Trace, in which we can measure the minimum, maximum, and average latencies be-

	tween any given two operators during that single
	execution trace: l P min , l P max and l P mean

Table 1 :

 1 Latencies

	Signal			Partitioning level			Software design level
			min	max	avg	std dev	min	max	avg	std dev	SoCLib
	s(tempData)->	r(tempData)	4	4	4	0	0	4	0.2	0.8	21.7
	s(ultrasonicData)->r(ultrasonicData)	16	52	34	18	0	56	11.6	17.9	20.3
	s(motorCommand)-> r(motorCommand)	5.7	10.3	8	2.3	0	16	4.9	3.3	32.3
	s(ultrasonicData)-> r(motorCommand)	2	2	2	0	11	24	13.2	2.5	38.0
	r(rultrasonicData)-> s(changeRate)	4	42	23	19	0	68	10.6	13.0	45.7


Daniela Genius
email: daniela.genius@lip6.fr

Ludovic Apvrille
email: ludovic.apvrille@telecom-paristech.fr

System-Level Design and Virtual Prototyping of a Telecommunication Application on a NUMA Platform

The use of model-driven approaches for embedded system design has become a common practice. Among these model-driven approaches, only a few of them include the generation of a fullsystem simulation comprising operating system, code generation for tasks and hardware simulation models. Even less common is the extension to massively parallel, NoC based designs, such as required for high performance streaming applications where dozens of tasks are replicated onto identical general purpose processor cores of a Multi-processor System-on-chip (MP-SoC). We present the extension of a system-level tool to handle clustered Network-on-Chip (NoC) with virtual prototyping platforms. On the one hand, the automatic generation of the virtual prototype becomes more complex as topcell, address mapping and linker script have to be adapted. On the other hand, the exploration of the design space is particularly important for this class of applications, as performance may strongly be impacted by Non Uniform Memory Access (NUMA).

I. INTRODUCTION

Multiprocessor-on-chip system architectures feature complex, sometimes hierarchical, interconnect-on-chip architectures, allowing to execute communication-centric applications such as telecommunication and video streaming. Usual high-level UML/SysML-based model-driven approaches target usual embedded applications and therefore they do not natively support such task-farm parallelism, neither from the application nor from the complex interconnection networks points of view. Thus, interconnection facilities are often limited to simple buses.

The task farm paradigm consists of a set of tasks waiting for data to be processed from one of the (many) common input buffers, thus introducing a high degree of non-determinism. On the contrary, embedded systems communications are typically one-to one, more rarely one-to-many e.g. broadcast.

In order to explore designs for high-performance packet processing, virtual prototyping of clustered platforms has already been proposed in [START_REF] Faure | Communications matérielles-logicielles dans les systèmes sur puce orientés télécommunications[END_REF]. The task farm property was captured by multi-writer multireader (MWMR) interfaces for channels mapped to shared memory, accessible by hardware or software tasks. Yet, the generation of platform variants was only semi-automatic and the middleware protocol lacked a formal basis.

In [START_REF] Genius | System-level design for communication-centric task farm applications[END_REF], we proposed a SysML based design methodology for task-farm applications on a flat interconnect. Only a simplified version of the application was handled, abstracting from I/O and internals (such as generation of descriptors, feedback of addresses, inspection of packets). This paper proposes an extension in order to deploy and analyze the (nearly) complete application on NUMA architectures.

The paper is organized as follows. Section II presents the related work. Section III shortly introduces the System Level Design environment and explains our extensions. Section IV illustrates our approach with a case study. Section V discusses experimental results. Finally, section VI concludes the paper.

II. RELATED WORK

During the software development process, software components are generally tested/executed on a local host, and only later integrated once the target is available. Software-hardware integration is postponed to the availability of the hardware target, often leading to late and costly revision on the software side. A more adequate approach is to frequently validate the different refinements of software components in an as-realistic-as-possible prototyping environment.

FPGAs can be used for this purpose [START_REF] Goossens | A high-level debug environment for communication-centric debug[END_REF], [START_REF] Kumar | Interactive presentation: An fpga design flow for reconfigurable network-based multi-processor systems on chip[END_REF], but this requires to develop the hardware elements in detail, and to buy potentially costly FPGA.

Another promising, less costly, solution is the use of virtual prototyping platforms. Their obvious drawback is that software execution is commonly less realistic, and takes much longer wrt. FPGAs. Many fully software-based prototyping environments have been proposed, some restricted to highlevel analysis, others offering extended profiling capabilities.

PtolemyII [START_REF] Eker | Taming heterogeneity -the Ptolemy approach[END_REF] proposes a modeling environment for the integration of diverse execution models, in particular hardware and software components. If design space exploration can be performed, its first intent is the simulation of the modeled systems.

Metropolis [START_REF] Balarin | Metropolis: An integrated electronic system design environment[END_REF], an extension of Polis, targets heterogeneous systems and offers various execution models. Architectural and application constraints are however closely interwoven.

Sesame [START_REF] Erbas | Multiobjective optimization and evolutionary algorithms for the application mapping problem in multiprocessor system-onchip design[END_REF] proposes modeling and simulation of features at several abstraction levels. Preexisting virtual components are combined to form a complex hardware architecture. In contrast to Metropolis, application and architecture are clearly separated in the modeling process. Currently, Sesame is limited to the allocation of processing resources to application processes. It neither models memory mapping nor the choice of the communication architecture.

MARTE [START_REF] Vidal | A co-design approach for embedded system modeling and code generation with UML and MARTE[END_REF] shares many commonalities with our approach, in terms of the capacity to separately model communications from the pair applicationarchitecture. However, it intrinsically lacks separation between control aspects and message exchanges. Other works based on UML/MARTE, such as Gaspard2 [START_REF] Gamatié | A model-driven design framework for massively parallel embedded systems[END_REF], are dedicated to both hardware and software synthesis, relying on a refinement process based on user interaction to progressively lower the level of abstraction of input models. Still, such a refinement does not completely separate the application (software synthesis) or architecture (hardware synthesis) models from communication, which hampers exploration for NUMA platforms.

Di Natale et al. [START_REF] Di Natale | An MDA approach for the generation of communication adapters integrating SW and FW components from simulink[END_REF] propose the generation of communication managers for software low layers. Yet, they do not handle the specificity of task-farm applications nor they offer formal verification.

Batori [START_REF] Batori | Domain specific modeling methodology for reconfigurable networked systems[END_REF] proposes a specific design methodology for telecommunication applications. From use cases, the method proposes several formalisms to capture the application structure ("interaction model") and behavior (Finite State Machine) and for its deployment from which executable code can be generated. Design space exploration and virtual prototyping are not part of the methodology; code generation targets a real platform.

III. TTOOL

Our modeling framework is called TTool [START_REF] Apvrille | Webpage of TTool[END_REF]. TTool relies on SysML to propose two abstract modeling levels: (i) HW/SW partitioning and (ii) software design and deployment [START_REF] Pedroza | AVATAR: A SysML environment for the formal verification of safety and security properties[END_REF]. From software deployment, a virtual MP-SoC prototype can be generated where software tasks run on multipurpose processors.

TTool includes a tool chain for generating code -from software deployment diagrams -to be executed on SoCLib [START_REF]SoCLib: an open platform for virtual prototyping of multi-processors system on chip[END_REF] based MP-SoCs as explained in [START_REF] Genius | Virtual yet precise prototyping: An automotive case study[END_REF]. This toolchain thus takes as input a software design and a deployment of that design onto a hardware platform in order to generate a SoCLib representation. Basically, this tool chain works as follows:

• Each SysML block modeling a software task is translated into an executable thread. The behavior of the block, expressed with state machine diagrams, is translated to a set of actions relying on C primitives defined in a runtime library. • The main program instantiates the POSIX threads of the blocks, translating logical chan-nels as software objects stored in on-chip memory.

• The top cell generator generates a SystemC top cell for cycle-accurate bit-accurate simulation from the model of the HW architecture. • The linker script is generated taking into account the mapping specified in the deployment diagram. These four kinds of input necessary for SoClib are created by generators written in JAVA, profiting from a very powerful approach to generate code from SysML supported by TTool [START_REF] Apvrille | Ttool for diplodocus: An environment for design space exploration[END_REF]. For topcell and linker script generation, the information contained in the mapping diagram is parsed. Where information is missing, default values are supplied where possible, otherwise a warning is displayed. Addresses are automatically calculated based on the number of clusters, of targets etc..

Up to now, TTool did not provide support for modeling multi-level interconnects and NUMA architectures. Inspired from [START_REF] Faure | Communications matérielles-logicielles dans les systèmes sur puce orientés télécommunications[END_REF], we propose a way to integrate clustered interconnect and NUMA in our SysML framework, and to automatically generate from the SysML diagrams the corresponding platform (HW and SW). To do so, we suggest to add the following features to TTool:

• Multi-level interconnects can be built up from a (new) local crossbar modeling component and from the capacity to connect communication components (e.g., crossbar, bus) together. • The possibility to integrate I/O coprocessors.

• The definition and generation of more complex topcell and ldscript in order to support the new hardware elements listed above.

A. Clustered Interconnects

A Virtual Generic Micro Network (VGMN), with a round-robin arbitration policy, or a Virtual Generic Serial Bus (VGSB) serve as central interconnect, and local crossbars connect the components within the cluster. Thus, the TTool deployment diagram offers the possibility to use crossbars, and to connect interconnect models with one another.

B. I/O Coprocesors

In order to extend communication capacities, we have also defined hardware coprocessors reading packets from Ethernet connections. These coprocessors are connected by MWMR wrappers. Yet, in an early design phase, hardware coprocessors are not yet available because they need to be designed in a precise way in SoCLib, i.e. directly in SystemC, but our approach focuses on the use of high-level modeling languages only. An option is to rely on software tasks capturing the behavior of the hardware coprocessors, but since they are mapped on general processors, they tend to falsify the results.

Currently, we suggest to rely on the SoCLib models from [START_REF] Faure | Communications matérielles-logicielles dans les systèmes sur puce orientés télécommunications[END_REF], called Input and Output Engine. The software design shows the channels with which they are connected to the other (software) tasks, while the deployment diagram contains the I/O engines for the generation of the virtual platform with HW coprocessors.

C. Generation of Topcell and Ldscript

SoCLib is based on the shared memory paradigm. The SoCLib mapping table is a centralized description of both the address space segmentation and the mapping of the segments on the VCI physical targets. It is described in the topcell. When generating the topcell from the deployment diagram, we first detect if a clustered interconnect is present. If this is the case, we automatically generate a two level mapping table by determining the number of segments and their size. The size of the data items and the maximum depth of the channel determine the size of the allocated memory.

IV. CASE STUDY

We consider a parallel telecommunication application, where all tasks of level n can read the data output by all tasks of level n -1. Network packets are initially cut into chunks of equal size by the input coprocessor. Each packet chunk has a descriptor referencing the address of the next chunk and containing some additional information. Only 64 bit descriptors are sent through the channels: the packet chunks themselves are stored in on-chip or off-chip memory. We do not model the packet storage because it has no impact of the logical and physical channels of the classification application.

The application tasks are the following.

. Block Diagram of the classification application

• A bootstrap task organizes the system start-up and fills the address channel with a set of addresses generated from the addresses available in packet memory. • An input task reads one after the other the addresses initially generated by the bootstrap task. Also, addresses freed from packets having left the system can be reused. Messages between bootstrap, input and output tasks correspond to 32-bit addresses. The Input Engine reads Ethernet encapsulated IP packets, cuts them into slots of equal size, and copies these slots to dedicated memory regions. • A classification task reads one or several descriptors at a time, then retrieves the first chunk of the corresponding packet from memory. Any classification task can access any chunk. • The scheduling task reads one of the queues according to their priority order, and then writes the descriptor to the output queue. Both classification and scheduling tasks use try-read primitives to run as soon as data is available. • The output task constantly reads the output queue. Each time a slot is read, the output task frees corresponding addresses, and send them to the address channel for reuse.

Overall, the application task graph is thus inherently cyclic and very vulnerable to buffer overflows due to contentions. Former work [START_REF] Faure | Communications matérielles-logicielles dans les systèmes sur puce orientés télécommunications[END_REF] proposed to map this application on a clustered interconnect. This work also included the definition of new hardware components in SoCLib to better handle I/O operations. Our contribution reuses these enhancements. The Input Engine reads addresses from the bootstrap task until the counter arrives at a preconfigured number. Then, when no more bootstrap addresses are available, the Input Engine uses addresses liberated meanwhile by the Output Engine. It then assigns a random number corresponding to the priority -abstracting from a stream containing packets with IP addresses. The Input Engine works at a frequency which can be parametrized for exploration; if it is made to read packets too fast from Ethernet, buffers will overflow.

A. Software Design

The classification tasks are represented in an hierarchical manner but, as the behavior is described much more precisely (packet inspection, non-arbitrary choice of the priority queue), they are far more complex than in [START_REF] Genius | System-level design for communication-centric task farm applications[END_REF]. All classification tasks write into one of three priority queues, corresponding to three information signals exchanged on the central channel in the SysML block diagram. Figure 2 shows the rather complex state machines of the outer classification task. The non-deterministic dispatching of the descriptors read from the input queue and the retrieving of the descriptor as belonging to packets of low, medium, or high priority, as well as the dispatching to one of the three priority queues, is modeled in much more detail as in [START_REF] Genius | System-level design for communication-centric task farm applications[END_REF].

The scheduling tasks are also organized in a hierarchical manner. Each of them takes a descriptor as soon as it is available, and enqueues it after a waiting time depending on its priority. Figure 3 shows in the center and on its right the state machines of the outer and one of the two (identical) inner tasks, respectively.

The Output Engine receives descriptors from the channel shared by the scheduling tasks. A reordered flow of packets (in our abstracted model, descriptors are simply discarded) is then sent and freed addresses are fed back to the Input Engine.

B. Architecture and Mapping

The target architecture features a two-level interconnect based on a Virtual Generic Micro Network (VGMN), which behaves as two independent packet switched networks for commands and responses, and three local crossbars, one per cluster. The I/O operations and the communication channels between classification and scheduling tasks play a crucial role for investigating performance bottlenecks. Thus, we have extended deployment diagrams so that I/O tasks become explicit (Figure 4). Also, all functions (hardware, software) are now connected to the interconnect by MWMR wrappers.

V. EXPERIMENTS AND RESULTS

The case study we present is known to suffer from several major performance impediments, such as overflow of the channels for high throughput, which can only be revealed once input and output hardware accelerators with parameterizable throughput are available. Our previous work could not capture these effects since our models were limited to the software part of the application only.

A. Testbed

For virtual prototyping, hardware is described on CABA (Cycle/Bit Accurate) level, with high precision at the price of rather slow simulation. We perform simulations of the virtual prototype for three classifiers, three priority queues, and two schedulers and the initial mapping proposed in [START_REF] Faure | Communications matérielles-logicielles dans les systèmes sur puce orientés télécommunications[END_REF]. General purpose processors are SoCLib PowerPC 405 running at 433MHZ.

Hardware spies allow to log and analyze all traffic on the VCI interconnect. They are based on the VCI_logger module proposed in SoCLib. Figure 4 shows how this spy mechanism, described in [START_REF] Genius | Monitoring communication channels on a shared memory multi-processor system on chip[END_REF], is now integrated in the deployment diagram. These spies are represented in the form of magnifying glasses. The automatically generated topcell describes the corresponding logger/statistics modules, relying on the name of the software objects to spy, derived from the TTool diagrams.

As we now model the (nearly) complete application, the generated platform should yield results comparable to the original one with 3 classifiers, 2 schedulers, no bursts and no packet memory access.

B. Latencies

It is well known that memory access latencies for clustered platforms suffer a high standard deviation with regards to usual platforms. Channels are stored in memory, and the communications via these channels represented a high fraction of the application activity. The higher the number of tasks accessing a channel, the higher the amount of time spent waiting for the lock. Spies for measuring the latency are placed on all four channels in Figure 4. Figure 5 shows the mean latencies for all four channels. They are about 30% faster than those of the original application but results are only partially comparable as we do not yet model packet memory accesses and IP address inspection.

The single input channel (InputEngine/out packet, spyglass 1), mapped on the I/O cluster and accessed by the classification tasks from cluster 0 does suffer much less from high latency than the three priority queues (Classification/out queue_low, spyglass 2), mapped on Memory0 but written by three classification tasks and read by two scheduling tasks.

The graph also shows that the proportion of time to obtain a lock scales with the number of reader/writer tasks. Input and Output Engine being on the same cluster, the channel feeding back the addresses (OutputEngine/out address, spyglass 4) is less concerned by NUMA memory access, as expected. The Scheduling/out packet (spyglass 3), is even less concerned, even if descriptors have to transit from cluster 1 to cluster 2. Accordingly, standard deviations range from 214 for the priority queues to 61 for the output channel, which is still very high.

C. Buffer Fill State

Adding I/O coprocessors now also allows us to monitor the fill state of all channels of the original application, in particular InputEngine/out packet, known to suffer from overflows when the frequency of packet arrival increases. In the example shown here, we do not fix a frequency, addresses are read if they are available and there is space in the channel. The critical channel was dimensioned to hold 128 descriptors (1024 bytes), which proves sufficient here but will be too low when higher frequencies are imposed. Figure 6 shows the mean fill state of the channels, unsurprisingly low.

D. Discussion

Our overall results are rather close to the ones obtained with the original application and far more realistic than those obtained in [START_REF] Genius | System-level design for communication-centric task farm applications[END_REF] for only the software part, even though we do not model the access to packet memory on the one hand (to our advantage) and do not use burst transfers on the other (to our disadvantage). These two aspects remain to be added, but will not change results by orders of magnitude [START_REF] Faure | Communications matérielles-logicielles dans les systèmes sur puce orientés télécommunications[END_REF]. While the original modeling and deployment was a PhD thesis subject in itself, it took us little more than a week to write the models and do the evaluations shown here. The original application featured dozens of classification tasks; the design space was explored (using scripts) in order to determine the best number of and ation between classification and scheduling tasks for a given throughput. Currently, TTool block diagrams are limited by the fact that identical task replication cannot be represented.

VI. CONCLUSION AND FUTURE WORK

We extend a UML/SysML virtual prototyping environment for SoCLib-based platforms with new modeling and evaluation capabilities for streaming applications. Our extensions are based on clustered interconnects and I/O elements. We are currently working on another extension of the tool which will enable us to compare high-level simulation resultse.g., at partitioning -with results obtained with the virtual prototype. As high performance streaming applications usually feature a larger number of tasks, we will also add the possibility to describe and generate multiple identical tasks. Knowing well the results of former design space explorations for this particular application, we plan to use it as a particularly challenging test case for the explorations capabilities of our tool. Finally, we intend to enable the modeling and generation of Virtual Coprocessors from TTool descriptions, starting at partitioning level and handing these descriptions all the way down to the SoCLib virtual platform.

Fig. 1

 1 Fig. 1. Block Diagram of the classification application

Figure 1

 1 Figure 1 displays the software design, using a SysML block diagram, of the telecommunication application. Addresses are represented by 32-bit integers. Packet descriptor are modeled as a data

Fig. 2 .Fig. 3 .

 23 Fig. 2. State machines of the outer classification task

Fig. 4 .

 4 Fig. 4. Deployment Diagram with I/O cluster

Fig. 5 .Fig. 6 .

 56 Fig. 5. Mean latencies per channel


Rodrigo Cortés Porto

Daniela Genius

Ludovic Apvrille

Modeling and Virtual Prototyping for Embedded Systems on Mixed-Signal Multicores

This paper presents a tool for the virtual prototyping of analog and mixed-signal embedded (AMS) systems. The application and platform are modeled on a high (SysML-like) level, while the prototype is simulated on cycle-bit accurate level. In order to run software, we combine the AMS part with a multicore platform, which acts as initiator and controls the AMS part. The synchronization between these different Models of Computation (MoC) can be validated before the generation of the virtual prototype. We present a larger case study to illustrate our approach.

This paper presents the integration of analog components into a modeling and virtual prototyping framework. The synchronization between the different Models of Computations (MoC) is performed before a virtual prototype is generated from models. The cyclebit accurate prototyping environment can be used to feed back simulation results to higher modeling levels in order to check the taken assumptions e.g. on cache miss rate or memory access latency.

Our contribution adds analog components as targets in a MPSoC built upon general purpose CPUs running a (light) operating system and the application code.

The related work in the next section demonstrates the lack of an integrated tool offering both mixed-signal system modeling and precise simulation capabilities, as well as the possibility to run application code.

The following section presents the foundations of the present work: SystemC AMS extensions -in particular its Timed Data Flow (TDF) model of computation-and a high-level modeling and virtual prototyping tool named TTool. Our mdoeling extensions aare then presented using relevant systems with an important proportion of analog components.

RELATED WORK

Well established tools like Ptolemy II [? ][? ] target data-flow models for heterogeneous systems by defining several sub domains [? ]. Although hierarchy is provided, instantiation of elements controlling the time synchronization between domains is left to the responsibility of designers.

Metropolis [? ] is based on high level models with a clear separation between computation and communication concerns. Heterogeneous systems are taken into consideration, but heterogeneity can only be represented using processes, mediums, quantities and constraints. Hierarchical models are not allowed: all processes should be implemented in the same hierarchical level.

Metro II [? ] introduces hierarchy and allows Adaptors for data synchronization as a bridge between the semantics of components belonging to different MoCs. The model designer must cope with the implementation of time synchronization by means of constraints, assertions, annotators and schedulers. As a common simulation kernel handles all process execution, MoCs are not well separated.

There are other frameworks based on SystemC such as HetSC [? ], HetMoC [? ] and ForSyDe [? ], all having the disadvantage that designers must handle the instantiation of elements and synchronization aspects.

In the scope of [? ], a mixed analog-digital systems proof-ofconcept simulator has been developed [? ], based on the SystemC AMS extension standard [? ? ]. Another simulator is proposed in [? ]. Integration with software code for general-purpose CPUs and with an operating system is however not yet addressed in these approaches.

Outside the analog/mixed signal domain, UML/SysML based modeling techniques [? ? ] are popular with industry targeting embedded systems, but are still rarely used in the domain of heterogeneous system design. Furthermore, with few exceptions such as [? ? ], they do not lower the level of abstraction to cycle bit accurate level.

CONTEXT

Our work is based on two foundations: the AMS extensions for SystemC and a high-level modeling and prototyping tool (TTool) A TDF module is described with an attribute representing the time step and a processing function. The time step is associated to a time period during which the processing function should be executed. The processing() function corresponds to a mathematical function which depends on the module inputs and/or internal states. At each time step, a TDF module first reads a fixed number of samples from each of its input ports, then executes the processing function, and writes a fixed number of samples to each of its output ports. TDF modules can interact with the DE world (such as digital MPSoC platforms) using converter ports.

SystemC Extensions for AMS

Figure 1 shows a TDF cluster, where the DE modules are represented as white blocks, TDF modules as gray blocks, TDF normal ports as black squares, TDF converter ports as black and white squares, DE ports as white squares and TDF signals as arrows. The TDF modules of a cluster have the following attributes:

(1) Module Timestep (Tm) denotes the period during which the module will be activated. One module will be activated only if there are enough samples available at its input ports. (2) Rate (R). Each module will read or write a fixed number of data samples each time it is activated. This number is annotated to the ports and it is known as the port rate.

(3) Port Timestep (Tp) denotes the period during which each port of a module will be activated. It also denotes the time interval between two samples that are being read or written. (4) Delay (D). A delay can be assigned to a port. As its name suggests, this attribute will make the port to handle a fixed number of samples each time it is activated, and read or write them in the following activation of the port.

Despite of all these features, [? ] explains that it is hard to build a modeling environment synchronizing DE and TDF. Indeed, the TDF model of computation is based on the Synchronous Data Flow (SDF) formalism that considers models as a network of synchronous data flow blocks, and does not easily match the one of DE systems. Thus, when there are interactions between the TDF and DE models of computation, time synchronization may induce causality problems. A TDF module is connected to a DE module through converter ports. When the TDF module accesses its input converter port, the DE simulation time advances until it is equal to the TDF simulation time of the input converter port. If later an access to an output converter port occurs whose TDF simulation time is less than the new DE simulation time, a time synchronization issue will occur: the TDF simulation time of the output converter ports needs to be always greater or equal than the DE simulation time.

In the work mentioned above, this synchronization is modeled with the help of colored timed Petri Nets derived from the SystemC AMS code. Causality issues between TDF and DE MoC are then automatically checked.

TTool

TTool [? ] is a SysML based, free and open-source software initially conceived for model-based engineering of (digital) embedded systems at different abstraction levels: functional, partitioning, software design and deployment. The method associated to these levels [? ] details how to take hardware/software partitioning decisions at a high level of abstraction and to regularly (re)validate these decisions during software development. Software tasks for the partitioning model are captured within the functional abstraction level, and software tasks used in deployments are captured in the software design abstraction level. In both partitioning and deployment models, the computation part of tasks is allocated to processors (which can be hardware accelerators in the partitioning level), and the communication and storage part is allocated to buses and memories. An important advantage of TTool is that it offers an automated approach for formal verification and fast simulation for the digital part. Formal verification is based on internal model-checkers, or on external tools like UPPAAL [? ].

From deployment diagrams, TTool can generate a virtual prototype that can be simulated with a cycle bit accurate simulator for Multi Processor Systems on Chip (MPSoC) [? ]. Processor models stem from the SoCLib [? ] public domain library written in SystemC. SoCLib targets shared-memory multiprocessor-on-chip system architectures based on the Virtual Component Interconnect [? ] standard which separates the components' functionality from their communication. Software code is cross-compiled for a general purpose processor and runs under a micro kernel on the digital MPSoC.

However, while sensors, GPS, radar, etc. can be approximately modeled with highly abstracted digital blocks, the accuracy and verification would benefit from more realistic models taking into account the AMS part.

INTEGRATION OF ANALOG COMPONENTS INTO TTOOL

For the analog part, we focus on the Timed Data Flow (TDF) Model of Computation (MoC) which is based on the timeless Synchronous Data Flow (SDF) [? ]. So-called converter ports serve as interface between the TDF and DE MoC, raising potential causality issues.

Representing Analog Components

The graphical interface of TTool has been extended by SystemC AMS DE and TDF blocks. Analog and digital parts are designed on different views. Also, there is one view per TDF cluster. Figure 2 shows a panel for the design of the introductory example. Each TDF cluster is designed in its own panel (or view) using a dedicated toolbar.

When a TDF module is created, it is possible to modify its attributes and parameters e.g. the name and Timestep or Period (Tm) of a module can be defined and time resolution selected. The parameters of a TDF module such as its internal variables or template parameters can be also set up, as shown in Figure 3.

Analog components are difficult to parameterize since they are specifically designed for one given purpose. We thus decided to provide a specific dialog window where SystemC-AMS processing() functions can be entered, e.g. see Figure 4.

From these diagrams, we can generate SystemC AMS TDF code of the components, the cells of the mixed graphical/textual descriptions, and a Makefile.

Connecting AMS Components to the MPSoC

SoCLib is based on the shared memory paradigm, where components are interconnected based on the VCI [? ] protocol. These components can be initiators which issue requests (e.g. CPUs) and targets that respond to these requests (e.g. RAM memory). The main idea for the integration of SystemC-AMS and SoCLib components into TTool is that the analog components will act as targets for the SoCLib initiator digital components (CPUs, hardware accelerators, DMA, . . . ). The generated topcell is thus composed of SoCLib modules and interfaces to the SystemC-AMS clusters. It Our solution is to propose a new generic adaptor module as an interface between the SystemC-AMS modules and the the SoCLib interconnect components. This adaptor is modeled as a generalpurpose input/output (GPIO) adaptor to VCI. We called it GPIO2VCI. It fulfills the rules for writing cycle-bit precise SystemC simulation models of SoCLib. Figure 5 shows the model of this component and how it works as an interface between the SystemC-AMS modules (TDF_Module belonging to a TDF Cluster) and the SoCLib VCI interconnect component (VCI_Bus). The component is manually inserted in the graphical interface of the panel, then its instantiation and connection, in particular the required lines in the topcell, are automatically generated.

SRC SENSOR CTRL R out = 1 D out = 0 Tm ADC = 10us R out = 1 D out = 0 in out out in x_sig v_sig R in = 1 D in = 0 PGA R in = 1 D in = 0 R out = 1 D out = 0 R kin = 1 D kin = 0 vamp_sig ADC R in = 10 D in = 0 TDF2DE R in = 1 D in = 0 R out = 1 D out in adc_sig AAVG R clk = 1 D clk R in =

CASE STUDY: VIBRATION SENSOR

The model of a vibration sensor, taken from the H-Inception project [? ], is shown in Figure 6. It consists of six TDF modules and one DE module. The SRC module represents the vibration source, modeled as a generator of harmonic sinusoidal waves which represent a displacement signal (x_sig) caused by the vibration.

The SENSOR module represents a vibration sensor. It takes as input the displacement signal (x_sig) and yields a voltage signal (v_sig) which is proportional to the vibration velocity.

The programmable gain amplifier (PGA) amplifies the voltage input signal (v_sig) by a factor of 2ˆk, where k is the input value from signal k_sig. This signal is controlled by the gain controller DE module CTRL. It yields an amplified voltage signal vamp_sig.

The ADC module represents an analog to digital converter with a resolution of 5 (Nbits). The ADC has a rate of 10 in its input port. Hence, it takes 10 samples from the amplified voltage signal vamp_sig and produces a digitized integer value of N-bits (adc_sig) where the most significant bit corresponds to the sign. The Module-Timestep is assigned to this module as 10us.

The TDF2DE module is a converter from the TDF signal adc_sig to a DE signal out_sig. The delay D_out, shown in red, of its output converter port out has not been set yet.

The AAVG module represents an absolute amplitude averager. It calculates and outputs to the amp_sig the absolute average amplitudes of the received samples from the adc_sig. Its input port has a rate of 64, meaning that it will receive 64 samples int oder to calculate the absolute average amplitude. This module also generates a clock signal clk_sig at its output port clk, which has a rate of 2, meaning that a clock edge will be generated twice per activation of the module. Note that the delays D_clk and D_amp, shown in red, of its output converter ports have not been set yet.

The CTRL DE module represents the gain controller. This controller is modelled based on the state machine diagram shown in Figure 7. It controls the output signal k_sig based on the calculated absolute average amplitude given by amp_sig, and two given thresholds low_threshold and high_threshold.

Solving Causality Problems

The following algorithm detects causality issues and suggests how to fix them with extra delays. This algorithm is meant to be called before the generation of the virtual prototype. end for 16: end procedure Based on the static schedule for one complete TDF cluster period, each time a TDF module is executed, for each accessed input Then, for each accessed output converter port, the TDF simulation time (t TDF ) is computed on line 8. The t TDF of each port should be greater than or equal to the maximum stored DE simulation time, as shown in line 9. If this condition fails, it means there is a causality problem with the time synchronization and a delay in the output converter port where the issue was detected will be suggested in order to solve the problem 1 .

For a first validation, the three output converter port delays shown in red (see Figure 6) were set to 0. The vibration sensor was modeled in TTool, as shown in Figure 8. Figure 9 shows the output of the validation tab of the code generation window. As time synchronization issues are found, modifications for the three delays are suggested. in the context of [? ], as part of the model examples. The model was simulated without giving any delays to its output converter ports. As displayed, it also suggests the three same delays as the ones suggested by TTool in order to solve the causality problems.

Finally the SystemC-AMS model taken from [? ] was modified to include the same parameters as the ones used in TTool and SystemC-MDVP, i.e. the same port rates and ADC Nbits resolution. At first, the simulation was executed without assigning any delays to the output converter ports.

Synchronization issues are detected by the simulator each time the simulation runs, and delays referring to time units are suggested to solve the causality problems. First time the simulation was run, a delay of 9 µs in port tdf2de.out was suggested, corresponding to a delay of 1 since the propagated timestep of this port is 10 µs. After setting this delay, the simulation was run again; another synchronization problem was found, and a delay of 639 µs is suggested to the aavg.clk port. Since the timestep of this port is of 320 µs, a delay of 2 is needed. Finally, after setting this new delay, the simulation was run for the third time. This time, another causality problem was detected, and a delay of 639 µs is suggested to the port aavg.amp. The timestep of this port is of 640 µs, thus a delay of 1 is required.

All the delays suggested by the SystemC-AMS simulator are the same as the ones suggested by TTool and the SystemC-MDVP simulator from [? ]. But on its side, TTool can identify causality problems before code generation and execution. In SystemC-MDVP, synchronization issues are found in the pre-simulation phase. That means that the SystemC-MDVP model needs to be executed only once to find any synchronization problems. In SystemC-AMS, these issues are found during the simulation phase, meaning that the simulation needs to be executed once per identified causality problem. In our case study, it needed to be executed three times.

Simulation

A simple SoC model was created as shown in Figure 10, where one SystemC-AMS Cluster block representing the vibration sensor was created, with trace file generation enabled. Such a model can potentially contain a larger number of processor cores, their number being limited only by the interconnect. In order to compare the results of our approach with SystemC-AMS and SystemC-MDVP, simulations were run with the same delays and trace files with models signals were produced. Figure 11 shows the analog waveforms in blue, resulting from the simulation of the SystemC-AMS model. Figure 12 shows the analog waveforms in green, resulting from the simulation of the SystemC-MDVP model. Figure 13 shows the analog waveforms in red, resulting from the simulation of the SystemC model created from TTool. It can be seen that the outputs match, specially for the fourth signal, which corresponds to the digitized output from the ADC component. The first waveform corresponds to the signal x_sig which carries the output of the harmonic sinusoidal wavelets generator SRC, simulating a vibration source. The second waveform is from the signal v_sig, which is the voltage output from the vibration sensor module SENSOR. The third waveform corresponds to the v_amp signal, which is the signal being amplified by the PGA module. The fourth signal adc_sig is the digitized output from the ADC module. The fifth signal amp_sig corresponds to the output of the absolute amplitude averager AAVG module which is connected to the DE controller CTRL. This controller emits the sixth signal k_sig which carries the factor that will be used by the PGA module to amplify the voltage signal v_sig. The last signal is the clk_sig used as clock signal for the controller CTRL module. Note that the amp_sig and k_sig signals from the SystemC-MDVP simulation look different: this is due to the generated trace file that didn't create values when they were repeated. So only the value changes are shown, but they still correspond to the outputs from the other traces.

This case study demonstrates that the solution implemented in TTool to detect time synchronization issues yields the same results as the ones suggested by the SystemC-AMS and the SystemC-MDVP simulators. Moreover, the time synchronization issues detection is performed at the design level, before the virtual prototype or the software code are generated, thus giving the designer the possibility to adapt their design before simulation.

CONCLUSION AND PERSPECTIVES

We integrate SystemC-AMS (TDF) components into a High-level modeling tool for complex embedded systems and show how application code can be run in such systems by combining the AMS part with a prototype built out of SoCLib components. Contrary to other approaches, we detect causality issues between the two parts of the simulation before any code is generated, which is one of the major strength of our approach.

To do so, we created a library to provide read and write functions to the GPIO2VCI component, which can be used in the State Machine Diagrams of TTool. The AMS hardware components are considered to be targets inside the MPSoC platform. In the future, we suggest to authorize these components to act as initiators, or to support interrupts. Also, the static schedule computed by TTool could be optimized, so that the suggested delays to solve time synchronization issues are minimum.

The Electrical Linear Networks (ELN) model of computation of System-C AMS relies on a continuous time domain. We plan to push our studies further by integrating ELN into our tool.

Finally, even if analog components tend to be unique, for typical components such as filters, analog/digital converters, sine sources, we plan to provide a library of parametrizable building blocks.

  Figure 1: TDF Cluster

Figure 2 :

 2 Figure 2: Extension of TTool: SystemC-AMS Diagram

Figure 3 :

 3 Figure 3: TDF module parameters

Figure 6 :

 6 Figure 6: Vibration sensor model from [? ]

Figure 7 :

 7 Figure 7: CTRL module state machine

Figure 8 :

 8 Figure 8: Vibration sensor model in TTool

Figure 9 :

 9 Figure 9: Code generation window with suggested delays For the output converter port out of the TDF2DE module, we use a delay equal to 1. For the output converter port amp of the AAVG module, the delay is equal to 1. Finally, 2 is used for the delay of the output converter port clk of the same AAVG module. The vibration sensor model is already included in the SystemC-MDVP (Multi Domain Virtual Prototyping) simulator, developed 1 A more detailed version of the algorithm is shown in [? ].

Figure 10 :

 10 Figure 10: Deployment Diagram model including the vibration sensor TDF cluster

Figure 11 :

 11 Figure 11: Vibration sensor trace signal from SystemC-AMS simulation

  "SystemC AMS extensions" is a standard describing an extension of SystemC with AMS and RF features [? ][? ]. The usual approach for modeling the digital part of heterogeneous systems with SystemC [? ] is to rely on its Discrete Event (DE) simulation kernel. The Timed data Flow (TDF) model of computation (MoC) of SystemC AMS adds support for signals where data values are sampled with a constant time step. The Electrical Linear Networks (ELN) MoC of SystemC AMS on the other hand relies on a continuous time domain.