Haut PDF Reconfiguration dynamique des architectures logicielles

Reconfiguration dynamique des architectures logicielles

Reconfiguration dynamique des architectures logicielles

3.2.4 Acme/Plastik Objectif de l’ADL. ACME/Armani est un langage déclaratif basé sur la logique de prédicat de premier ordre [Gar 00, Mon 01]. Son but initial était de définir un langage d’échange commun pour les outils de conception d’architecture. En outre, Il est conçu pour décrire les structures architecturales au niveau instance et type. Les extensions Acme/- Plastik [Bat 08, Joo 05] permettent de soutenir la reconfiguration dynamique et préservent son objectif initial. En plus, les configurations et reconfigurations dynamiques spécifiées à l’aide de cette extension (Acme / Plastik) sont basées sur la structure d’une architecture. Le langage Acme est utilisé pour la description des architectures. Acme est un ADL générique, focalisé sur les aspects structurels. Il joue le rôle de langage pivot car suf- fisamment riche d’un point de vue des concepts d’architecture manipulés (Composant, port, connecteur, rôle et système), et permet de décrire des architectures spécifiées dans d’autres langages. Les représentations permettent de décrire des systèmes à un niveau plus ou moins élevé d’abstraction. Les représentations autorisent ainsi la spécification d’implé- mentations multiples et alternatives pour un même composant. Par ailleurs, le langage inclut la notion de style architectural à travers les types et les familles d’architectures. Le système de typage permet d’étendre la spécification des éléments. Les familles regroupent des ensembles de définitions de types et décrivent les moyens autorisés pour les composer. Support de la reconfiguration dynamique. Acme/Plastik permet de décrire les reconfigurations dynamiques prévues et imprévues. Concernant les évolutions imprévues, il est possible de les décrire comme comportements spécifiques d’une configuration grâce à :
En savoir plus

100 En savoir plus

Vers une reconfiguration dynamique partielle parallèle par prise en compte de la régularité des architectures FPGA-Xilinx

Vers une reconfiguration dynamique partielle parallèle par prise en compte de la régularité des architectures FPGA-Xilinx

En exploitant les avantages de la reconfiguration dynamique partielle en vue de l’optimisation de la surface et de la consommation d’énergie, ces systèmes parallèles peuvent évoluer donnant naissance à des systèmes plus flexibles supportant plusieurs applications sur la même architecture. Ceci se manifeste par la spécification d’une Région Partiellement Reconfigurable (RPR) au sein de chaque unité de calcul et qui est partagée par diverses tâches appelées Modules Partiellement Reconfigurables (MPR) portant chacun une fonctionnalité bien particulière. En effet, chaque RPR doit satisfaire les contraintes de ressources requises par cet ensemble de MPRs ainsi que leurs interfaces qui doivent être communes avec la partie statique du système. En s’appuyant sur le flot de la reconfiguration dynamique partielle de Xilinx qui exige que chaque MPR (bitstream) soit relatif à une seule RPR, une seule configuration du système parallèle nécessite que chaque RPR soit reconfigurée dynamiquement par un MPR relatif réalisant chacun la même fonction. Dans ce cadre nous envisageons exploiter la régularité et la symétrie des composants FPGAs pour proposer des mécanismes de reconfiguration qui sont adaptés à des architectures parallèles dynamiquement reconfigurables.
En savoir plus

170 En savoir plus

Pépite | Vers une reconfiguration dynamique partielle parallèle par prise en compte de la régularité des architectures FPGA-Xilinx

Pépite | Vers une reconfiguration dynamique partielle parallèle par prise en compte de la régularité des architectures FPGA-Xilinx

––––––––––––––––––––––––––––––––––––––––––––– Vers une Reconfiguration Dynamique Partielle Parallèle Par Prise En Compte De La Régularité Des Architectures FPGA-Xilinx ––––––––––––––––––––––––––––––––––––––––––––– Résumé : Ce travail propose deux flots de conception complémentaires permettant le broadcast d’un bitstream partiel vers un ensemble de Régions Partiellement Reconfigurables (RPRs) identiques. Ces deux flots de conception sont applicables avec les FPGAs – Xilinx. Le premier appelé ADForMe (Automatic DPPR Flow For Multi-RPRs Architecture) permet l’automatisation du flot traditionnel de la RDP de Xilinx grâce à l’automatisation de la phase de floorplanning. Ce floorplanning est assuré par l’algorithme AFLORA (Automatic Floorplanning For Multi-RPRs Architectures) que nous avons conçu qui permet l'allocation identique de ces RPRs en termes de forme géométrique en tenant compte des paramètres technologiques du FPGA et des paramètres architecturaux de la conception dans le but de permettre la relocalisation de bitstream . Le deuxième flot proposé vise à favoriser la technique de relocalisation 1D et 2D afin de permettre le broadcast d’un bitstream partiel (fonctionnalité) vers un ensemble de RPRs pour une configuration du système. Ce flot permet donc l’optimisation de la taille de la mémoire de bitstream. Nous avons également proposé une architecture matérielle adéquate capable d’effectuer ce broadcast. Les résultats expérimentaux ont été effectués sur les FPGAs-Xilinx récents et ont prouvé la rapidité d’exécution de notre algorithme AFLORA ainsi que l’efficacité des résultats obtenus suite à l’application du flot d’automatisation de la relocalisation de bitstream. Ces deux flots permettent d’assurer la flexibilité et la réutilisabilité des composants IPs intégrés dans les architectures à Multi-RPRs afin de réduire la complexité en termes de temps de conception et d’améliorer productivité des concepteurs.
En savoir plus

169 En savoir plus

Modélisation des architectures logicielles dynamiques : application à la gestion de la qualité de service des applications à base de services Web

Modélisation des architectures logicielles dynamiques : application à la gestion de la qualité de service des applications à base de services Web

a l’int´ erieur de la configuration du composite de fa¸con ` a d´ ecrire la configuration de mani` ere dynamique. Par exemple, Darwin permet de fixer le nombre d’instances d’un composant lors de son initialisation. Les services requis ou fournis (ang. require et pro- vide) correspondent ` a des types d’objets de communication que le composant utilise pour respectivement communiquer avec un autre composant ou recevoir une communi- cation d’un autre composant. Ainsi, les services n’ont pas de connotation fonctionnelle. Ils d´ ecrivent les types d’objets de communication utilis´ es ou autoris´ es ` a appeler une fonc- tion du composant. Ces types d’objets sont d´ efinis par le support d’ex´ ecution r´ eparti appel´ e Regis, Magee et al. ( 1994 ) et sont limit´ es. Ainsi, ` a l’ex´ ecution, un composant Darwin est un processus qui communique avec d’autres composants grˆ ace ` a des objets de communication cr´ e´ es et g´ er´ es par le syst` eme d’ex´ ecution Regis. Parmi les types d’ob- jet, le port est le plus courant : il s’agit d’un objet envoyant des requˆ etes de mani` ere synchrone ou asynchrone entre composants r´ epartis ou non.
En savoir plus

219 En savoir plus

Architectures logicielles pour la radio flexible : intégration d'unités de calcul hétérogènes

Architectures logicielles pour la radio flexible : intégration d'unités de calcul hétérogènes

3.4. CONCLUSION DU CHAPITRE CHAPITRE 3. ÉTAT DE L’ART collecte de statistiques en interne de chaque bloc (dans le cadre de la distribution du contrôle) fait également partie des objectifs. A partir de cet environnement, une approche de la reconfiguration dynamique est proposée dans [DLD11]. L’objectif est ici de permettre le délestage des processeurs afin d’offrir une qualité de service donnée à certaines communications. Afin d’y parvenir, plusieurs implantations de la même fonctionnalité sont proposées dans Surfer. Un superviseur est implanté, qui se sert des capacités de collecte de statistiques des blocs afin de détecter s’il y a besoin de changer de moyen de calcul. Par exemple, une application s’exécute sur une plateforme qui contient un GPP et un GPU. Le GPP étant suffisant pour exécuter cette application, il n’y a pas de raisons de lancer deux périphériques. Cependant, si une application externe est lancée sur ce GPP, il risque de ne plus suffire. Le superviseur délestera alors le GPP en lançant le calcul sur le GPU. L’application reviendra sur le GPP une fois celui-ci allégé. Sans prendre en compte le superviseur, la méthode de reconfiguration dynamique est assez proche de [CDPR10] sur SCA.
En savoir plus

139 En savoir plus

Méthodologie basée sur des membranes pour la gestion de la reconfiguration dynamique dans les systèmes embarqués parallèles

Méthodologie basée sur des membranes pour la gestion de la reconfiguration dynamique dans les systèmes embarqués parallèles

6.3. Résultat de synthèse et analyse 6.3.1. Résultat pour l’exemple factorielle Nos simulations et la synthèse ont été réalisées sur un Virtex 6 FPGA intégré dans une carte ML605. Comme le montre le tableau 1, la membrane utilise très peu de ressources disponibles. Si la mémoire cache est exclu, la membrane nécessite 437 Luts et 26 blocs RAM /FIFO. Ces ressources sont indépendantes de la complexité de l’IP. Le seul surcoût possible et du à la taille de la mémoire cache, puisque la taille des lignes est un paramètre dépendant de la longueur souhaitée d’un contexte, ce qui rend la taille de la mémoire cache variable. Dans l’exemple décrit dans la session, deux lignes la mémoire cache est composée de deux lignes de 64 bits chacune. Ainsi, on observe que le cout de surcharge matérielle due l’implémentation de la membrane n’est pas vraiment significative sur un FPGA Virtex 6. Cela nous permet d’imagi- ner des architectures reconfigurables hautement parallèles à l’aide de notre approche basée sur des membranes. Comme le montre le tableau 2, une membrane traite quatre commandes pos- sibles, ces commandes proviennent du contrôleur de reconfiguration du système (Microblaze par exemple), ainsi notre membrane prend 3 cycles pour exécuter un ordre STOP, 14 cycles pour l’ordre ’IP RUN + CONTEXTE’ en avec un défaut de cache, on demande l’exécution de l’IP avec un contexte, (fréquence d’horloge de 100 Mhz).
En savoir plus

14 En savoir plus

Vers la reconfiguration dynamique dans les systèmes embarqués: de la modélisation à l'implémentation

Vers la reconfiguration dynamique dans les systèmes embarqués: de la modélisation à l'implémentation

indicate that the RAM memory that is used is OCP com- pliant, and that its estimator is connected to its OCP slave interface. So, at the generation of the code for the simula- tion, there will be an insertion of an estimator between the memory and the other component of the MPSoC to which the memory is normally connected. That is what we will im- plement in future works. For now, to validate our approach we have to use it in an architecture described at the CABA level. Provided that the connections between the compo- nents and the estimators cannot be done yet at the CABA level using Model Driven Engineering, we used instead some script shells that generate different architectures giving as parameters the number of processors, the cache size, etc. So, the previously developed energy models were integrated into the SoCLib architectural simulator in order to profit from a fast architectural exploration environment for MP- SoC design. To validate our approach, we used a Visiophony application for the UMTS network. For this application, we chose a minimal resolution using the QCIF format (144*176 pixels). The coding standard chosen was the H.263, adapted for Visiophony and Videoconference applications. For this paper, we evaluated only the DCT task to validate our ap- proach. Figure 2 shows an example of the architectures used in the simulations. The hardware components used in these architectures are MIPSR3000 processors, 16KB SRAM memories and micro-networks. The used caches contain ac- tually two independent instruction and data caches, sharing the same interface. They are direct mapped caches. The data cache’s writing policy is write-through. To prove the accuracy of our approach, we have to compare its consump- tion results with those of the intrusive approach followed in our previous work [1]. Therefore, we executed the DCT task
En savoir plus

182 En savoir plus

Modelisation et implementation d’un systeme d’information de gestion de flux multimedia pour des architectures logicielles integrant des appareils sans-fil mobiles

Modelisation et implementation d’un systeme d’information de gestion de flux multimedia pour des architectures logicielles integrant des appareils sans-fil mobiles

Les langages de description d’architecture (ADL) que nous venons de présenter ont tous pour vocation la formalisation, la vérification et la validation d’architectures. Leur but est de raisonner à un niveau plus abstrait que l’implémentation. Cette abstraction permet au concepteur de mieux appréhender la complexité de l’application et de mieux concevoir le fonctionnement et le découpage de celle-ci ainsi que les connexions entre ses différents éléments. La définition de l’architecture d’un système revient donc à la définition des différents composants et connecteurs utilisés dans le système ainsi que de la topologie de leur interconnexion, à l’exception de Rapide où les connexions sont seulement spécifiées dans les composants comme des comportements de communication. Fractal a la particularité d’être introspectable et autorise le partage de composants. Alors que Kmelia présente l’avantage de mettre en avant la notion de service ce qui procure un pont relativement naturel avec les architectures orientées services. Le comportement (dynamique) d’un service est caractérisé par un automate qui précise les enchaînements d’actions autorisés. Ces actions sont des calculs, des communications (émissions, réceptions de messages), des invocations ou des retours de services. SCA propose la notion de liaison pour l'assemblage et de modules pour la création des hiérarchies de composants. SCA n'impose pas une forme prédéterminée de liaison, mais autorise l'utilisation de différentes technologies, comme SOAP, JMS (Java Message Service) ou IIOP pour mettre en œuvre ces liaisons. De même, Fractal autorise différents types de liaisons et n'impose pas de technologie particulière.
En savoir plus

220 En savoir plus

Une approche dirigée par les modèles pour les architectures logicielles

Une approche dirigée par les modèles pour les architectures logicielles

3.2 Les Langages de Description d’Architectures Les langages de description d’architecture mettent en évidence les concepts de base de l’architecture logicielle et prennent en charge la spécification rigoureuse des composants constituant un système logiciel, leur interconnexion et leurs propriétés [Med 00]. Ils ont pour objectif principal de fournir une notation formelle, représentée textuellement ou graphiquement, selon laquelle les architectures logicielles vont être décrites. La communauté scientifique a proposé une diversité de langages issus de plusieurs centres de recherches, entreprises et universités [Med 00]. La prolifération des ADLs montre l’intérêt important de l’architecture logicielle et est le résultat logique de la couverture continue des aspects non abordés précédemment. Par exemple, Darwin [Mag 96] s’oriente vers la description d’architectures distribuées et la prise en compte de leur reconfiguration dynamique. ACME [Gar 00] cible la fourniture d’un standard qui définit les éléments architecturaux communs aux ADLs existants. Wright [All 98] est plus axé sur la description du comportement dynamique et la formalisation des connecteurs, tandis qu’Olan [Bal 98] représente une solution aux problèmes de conception des systèmes fortement distribués ainsi que leur déploiement.
En savoir plus

220 En savoir plus

Styles d'évolution dans les architectures logicielles

Styles d'évolution dans les architectures logicielles

Figure 1.1 – Catégories d’architecture logicielle face à la complexité croissante des systèmes. Le constat clé est que plus un système logiciel devient complexe, plus il devient nécessaire d’expliciter sa structure. Face à l’accroissement de la complexité, la vision de l’ingénierie des logiciels s’est donc radicalement modifiée en passant de la perspective de développement d’un système monolithique – ou "monobloc" – vers un système construit comme un assemblage de morceaux logiciels. Ainsi, de nouvelles catégories d’architectures ont émergées, offrant chacune des unités granulaires différentes pour le partitionnement d’un système (cf. figure 1.1). Les objets constituent des briques de base qui ont l’avantage de trouver une correspondance directe avec les langages de programmation à objet. L’image retenue est celle d’un ensemble d’objets qui communiquent entre eux en s’échangeant des messages afin de collaborer dans un objectif com- mun. Cependant, même si l’orienté objet offre une base saine pour le développement d’éléments réutilisables à fine ou à plus forte granularité [Jaz95], elle n’offre pas les notations adéquates pour la construction à plus large échelle. Les composants constituent des briques de construction à plus large échelle et sont vus comme le prolongement des objets [Szy98]. Traditionnellement, les composants sont à "gros grain" [SG96] car ils offrent de nombreuses fonctionnalités et/ou des fonctionnalités complexes. L’architecture à base de composants vise à construire un système à la manière d’un puzzle, où chaque composant est une pièce bien définie et destinée à être assemblée à une tierce pièce. L’emboîtement des pièces repose sur la correspondance entre les fonctionnalités qu’elles offrent et celles qu’elles requièrent. Puis, la forte complexité de certains systèmes en termes d’hétérogénéité dans les technologies utilisées, et en terme de distribution à travers les réseaux a fait naître les architectures à base de services. Les services constituent des briques de construction à très large échelle destinées à construire des systèmes logiciels caracté- risés par un environnement distribué et hautement dynamique. Ici, la métaphore n’est plus celle du puzzle, mais celle d’un ensemble de fournisseurs et de consommateurs de services qui a priori ne se connaissent pas, mais qui ont vocation à être mis en relation dans un cadre contractuel.
En savoir plus

173 En savoir plus

Architecture Logicielles pour des Applications hétérogènes, distribuées et reconfigurables

Architecture Logicielles pour des Applications hétérogènes, distribuées et reconfigurables

Bon nombre de travaux portent sur les architectures logicielles de reconfiguration des réseaux de capteurs et sur la collaboration entre composants logiciels et matériels. Les auteurs de [12] proposent une architecture pour configurer des réseaux de capteurs de façon rapide et dynamique. C’est une combinaison d’une architecture matérielle et d’une architecture logicielle qui permet l’échange d’information entre un réseau de capteur et d’autres applications. Un serveur gère les informations recueillies par les capteurs et les transmet vers les applications. Jusqu’à présent, lorsqu’une nouvelle fonctionnalité devait être chargée sur un capteur, il fallait mettre à jour le serveur pour qu’il charge le code nécessaire pour réaliser la translation des données brutes en données interprétables par les applications. [12] propose de détecter automatiquement la présence de nouveaux capteurs et d’en télécharger le composant logiciel permettant la translation des données. Ainsi il est possible de développer un serveur
En savoir plus

8 En savoir plus

IoT Design - Quelles architectures et couches logicielles pour l'IoT ?

IoT Design - Quelles architectures et couches logicielles pour l'IoT ?

autocontenue déployable. Le service intelligent de déploiement, à partir du modèle de flot de données entre les fonctions et à partir du contexte d’exécution, construit alors une architecture abstraite de containers à déployer. Selon l’infrastructure réelle existante, les containers sont alors compilés et spécialisés pour Kubernetes ou Mesos ou tout autre plateforme. Ce processus est dynamique et se répète en cas de changement de charge pour équilibrer entre plusieurs infrastructures hétérogènes ou en cas de mobilité de l’utilisateur pour que ces services le suivent (service roaming).
En savoir plus

13 En savoir plus

Gestion dynamique du parallélisme dans les architectures multi-cœurs pour applications mobiles

Gestion dynamique du parallélisme dans les architectures multi-cœurs pour applications mobiles

5.1 Introduction Comme nous l’avons vu lors des précédents chapitres, les appareils mobiles doivent supporter un grand nombre d’applications. Ces applications proviennent de différents do- maines tels que le multimédia, le traitement d’images, ou encore le graphique. Le multi- média ainsi que le traitement d’images sont des domaines connus, très bien supportés par les architectures multi-cœurs. Cependant, le rendu graphique est supporté de façon efficace principalement par les processeurs graphiques dans les architectures actuelles. L’analyse du rendu graphique a montré que c’est une application de type pipeline qui est très dynamique. Les temps de calcul par donnée, ainsi que le nombre de données à calculer pour chaque image peuvent varier d’un facteur 10 (cf. chapitre 3). Pour supporter cette dynamicité, nous avons proposé dans le chapitre précédent une méthode permettant d’adapter le paral- lélisme de l’application en fonction des besoins calculatoires de chaque étage. Ceci nécessite des mécanismes pour surveiller l’application et pour prendre des décisions afin d’adapter le parallélisme. Ce chapitre expose les éléments architecturaux nécessaires au support des applications de type multimédia, vision, audio. L’architecture multi-cœurs définie doit éga- lement supporter le rendu graphique grâce aux éléments architecturaux appropriés ainsi que grâce au support de la mise à jour dynamique du parallélisme.
En savoir plus

141 En savoir plus

Gestion dynamique du parallélisme dans les architectures multi-cœurs pour applications mobiles

Gestion dynamique du parallélisme dans les architectures multi-cœurs pour applications mobiles

Le modèle de programmation par passage de message (MPI) [34] part du principe qu’aucune donnée n’est partagée. Les échanges de données se font de manière explicite par envoi d’un message vers la tâche réceptrice. Ce modèle est approprié pour les architectures distribuées car il limite au maximum les communications. De plus, il ne nécessite pas une grande mémoire centralisée. Dans ce modèle, l’exécution des tâches se fait de manière totalement indépendante les unes des autres. Dans les modèles de programmation présentés, les applications sont découpées en plusieurs tâches qui peuvent être distribuées sur les processeurs. La distribution de ces tâches peut avoir été décidée statiquement, par exemple au moment de la compilation. Elle peut aussi être décidée au moment de l’exécution. Dans ce deuxième cas, le choix du processeur sur lequel va s’exécuter une tâche n’est connu qu’au moment de l’exécution. Par ailleurs, des tâches peuvent être démarrées et arrêtées en fonction des choix applicatifs (par exemple lors de fork/join). Le support d’un modèle dynamique nécessite donc un ordonnanceur qui va se charger de gérer les tâches en fonction de l’application. Cet ordonnanceur peut être supporté par une ressource dédiée ou sur les mêmes ressources que les applications. Une application complexe peut être constituée de plusieurs parties qui ont des modes d’exécutions différents. Par exemple, certaines tâches communiquent beaucoup et utilisent les mêmes données, ce sont des tâches qui sont donc proches d’un modèle OpenMP. À l’opposée, d’autres tâches peuvent être très indépendantes et donc plus proches d’un modèle MPI.
En savoir plus

131 En savoir plus

L'originalité des œuvres logicielles

L'originalité des œuvres logicielles

Cette pratique est contestable ` a plusieurs titres. En premier lieu, elle conduit ` a inverser la charge de la preuve par rapport au droit et ` a l’usage en mati` ere, par exemple, d’œuvres litt´ eraires et artistiques, alors que l’on n’a pas ` a distinguer l` a o` u la loi ne distingue pas. En deuxi` eme lieu, ce test est souvent conduit de fa¸ con erron´ ee, l’´ etude concernant les fonctionnalit´ es du logiciel au lieu de consid´ erer ce dernier en tant que cr´ eation de forme. Cela conduit ` a statuer sur la base des crit` eres de nouveaut´ e, d’activit´ e inventive et/ou de m´ erite, qui sont tous inop´ erants et contraires au droit d’auteur. En troisi` eme lieu, mˆ eme lorsqu’il est bien r´ ealis´ e, ce test n’apporte aucune information pertinente car, en mati` ere d’œuvres logicielles comme d’œuvres litt´ eraires, l’originalit´ e sera toujours pr´ esente, y compris dans le cas de plagiats.
En savoir plus

17 En savoir plus

Surveillance des interfaces logicielles

Surveillance des interfaces logicielles

privateSeverity Severity INFO Niveau de risque des violations émises lors d'un changement de type d'une variable de visibilité PRIVATE. scopeSeverity Severity CRITICAL Niveau de risqu[r]

78 En savoir plus

Reconfiguration dans les réseaux optiques

Reconfiguration dans les réseaux optiques

Dans l’exemple de la Figure 1, le graphe de d´ependance D est compos´e de quatre sommets a, b, c et d (Fig. 1(c)). Il y a un arc de a vers b car a utilise des ressources dans le nouveau routage R ′ , utilis´ees par b dans le routage initial R. En d’autres termes, b doit ˆetre rerout´ee avant a. Lorsque le graphe de d´ependance est un DAG (Directed Acyclic Graph), l’ordonnancement des d´eplacements des connexions est imm´ediat. Cependant des d´ependances cycliques peuvent exister. Dans ce cas, la reconfiguration n’est possible que si l’on s’autorise `a interrompre temporairement des connexions. L’objectif est alors de minimiser le nombre de connexions interrompues simultan´ement. Ce probl`eme a tout d’abord ´et´e ´etudi´e dans [JS03] puis a ´et´e mod´elis´e en termes de process number [CPPS05] similaire `a des jeux de capture (voir [FT08]).
En savoir plus

5 En savoir plus

Contributions à la simulation stochastique parallèle : architectures logicielles pour la distribution de flux pseudo-aléatoires dans les simulations Monte Carlo sur CPU/GPU

Contributions à la simulation stochastique parallèle : architectures logicielles pour la distribution de flux pseudo-aléatoires dans les simulations Monte Carlo sur CPU/GPU

Contributions to parallel stochastic simulation : application of good software engineering practices to the distribution of pseudorandom streams in hybrid Monte Carlo simulations Jonatha[r]

254 En savoir plus

Gestion dynamique locale de la variabilité et de la consommation dans les architectures MPSoCs

Gestion dynamique locale de la variabilité et de la consommation dans les architectures MPSoCs

3.4. ESTIMATION RAPIDE DE LA TENSION 81 celle de tension. Au premier ordre, on peut facilement estimer que le débit de la méthode proposée ne suffit pas pour surveiller les variations rapides de tension. En effet, les jeux de données comparés par le test d’hypothèse contiennent 21 éléments (CDF) chacun. Il parait donc difficile qu’une exécution d’un seul test (avec une implémentation logicielle ou matérielle) puisse être faite en moins de 50 cycles d’horloge en moyenne. De plus, les applications visées par les architectures adap- tatives sont des circuits basse consommation qui fonctionnent généralement avec des fréquences d’horloge en dessous du gigahertz. De ce fait, en choisissant une base de modèles en accord avec les recommandations de granularité proposées (∆T = 40°C et ∆V = 10mV , soit 305 modèles) il faudrait, d’après le raisonne- ment optimiste suivi, au moins une quinzaine de microsecondes par estimation avec une horloge de 1 GHz. Cet ordre de grandeur de débit introduit un retard dans la boucle de réadaptation de l’AVFS (voir Figure 2.7), qui ne permet pas de suivre dynamiquement les IRdrops de seconde classe (de l’ordre de la micro- seconde).
En savoir plus

177 En savoir plus

Vers l'intégration dynamique de contrats dans des architectures orientées services : une experience applicative du modèle au code

Vers l'intégration dynamique de contrats dans des architectures orientées services : une experience applicative du modèle au code

La technologie des Web Services offre un support particulièrement intéressant à la mise en oeuvre des architectures orientées services. En effet, au cœur de l’approche Web Services, les objectifs sont l’interopérabilité supportée par un protocole de communication et la standardi- sation des services (fichiers W SDL ). Cependant, l’intégration des contrats sur les Web Services n’a pas été à ce jour standardisé et reste dépendante des infrastructures de supports (Ludwig et al., 2004; Lazovik et al., 2004; Baresi et al., 2004; Baresi et Guinea, 2005). La vérification d’un contrat à l’exécution repose alors sur un déploiement de codes techniques, dépendant de la nature du contrats et des constituants mis en jeux. De tels déploiements exigent une expertise technique importante fortement dépendante de la plate-forme cible. La multiplicité des plates- formes et leur évolution sont alors un frein à l’introduction et au maintien des contrats dans les applications. Pour tenir compte de ce besoin de forte évolutivité, tout en conservant l’inter- opérabilité des architectures à base de Web Services, l’ingénierie des modèles (I DM ) apporte des éléments de réponses en basant le développement logiciel sur la définition de modèles faisant abstraction des infrastructures techniques. Ces modèles doivent être conformes à des métamodèles pour lesquels des outils de transformations ont été définis, permettant d’adresser à partir d’une modélisation la génération des codes vers de multiples plates-formes. Dans cet article, nous présentons un exemple d’utilisation de l’I DM pour l’intégration de contrats dans
En savoir plus

16 En savoir plus

Show all 3597 documents...