Modélisation pour la conception système basse consommation

Modélisation pour la conception système basse consommation : HeLP
(part 2)
Robert de Simone
Equipe Aoste (INRIA Sophia-Méditerranée & UMR I3S)
EcoFac 2012
avec Carlos Gomez-Cardenas, Julien Deantoni, Ameni Khecharem
Modéliser pour rassembler…
« Objectif : optimiser le profil de puissance en fonction de la
fonctionnalité à exécuter… »
Objectif: savoir relier des modèles de :
•
•
•
•
l’architecture fonctionnelle
•
de l’application fonctionnelle (scenario d’utilisation)
l’architecture de power
des infos de performance
des infos de thermique
Objectif : inclure des informations de
temps et d’énergie dans TLM, boucler
avec un modèle de température, étudier
la notion de fidélité non fonctionnelle
et rendre ces liens (allocations) flexibles pour explorer l’espace des solutions
Principe
•
•
•
•
Spécifier un scénario d’utilisation « typique » de fonctionnalités applicatives
Les « mapper »sur les ressources et services architecturaux (fonctionnels)
En déduire une trace fonctionnelle temporisée (et répartie sur l’architecture)
Jouer cette trace sur un modèle de consommation (et thermique?) pour
calculer les dépenses en intégrant les simulations
•
Modéliser l’architecture additionnelle de contrôle de l’énergie (et chaleur)
 power manager, élément de l’architecture fonctionnelle
•
On a alors des interactions de contrôle entre fonctionnalité (temporisée) et
critères extra-fonctionnels (énergie, chaleur)
 simulation couplée
Co-modelisation et/ou co-simulation
2 possibilités de combinaison
1. (loose) combiner un modèle comportemental (temporisé) et un modèle de
calcul de consommation/température, en alternant les pas de simulation
2.
(tight) intégrer les calculs de consommation/température à l’intérieur du
simulateur de comportememt temporisé
Questions (dans les 2 cas)
•
•
savoir exécuter un scénario de fonctionnalité (la plate-forme ne bouge pas seule)
savoir réagir correctement quand/si l’état énergie/chaleur dépasse un seuil
(au moins rapporter l’information et son contexte)
•
extraction des infos à partir d’une source commune (compatibilité?)
Exemples (courtesy Ons Mbarek)
Sur ces dessins, on voit se superposer une
description de haut niveau de l’architecture
fonctionnelle et une description de haut niveau
de l’architecture de power
Comment rendre ça opérationnel dans
des outils de design ?
(échange, transformations )



Ingénierie des Modèles (IDM)
basé sur profil OMG UML MARTE
compatible standards ? (UPF, IP-XACT)
De l’illustration au diagramme
VGA
•
•
•
Formats (XMI,XML)
Typage (composant, ports)
Machine-friendly
RAM
bus
CPU
Modèle puissance/horloge
Views
o
o
séparation des vues,
aggrégation sur une même architecture
VDD_TOP
PD_TOP
PD_2
Reset_2
S11
PD_11
S2
PD_1
VDD_3
VDD_2
Power
Controller
S3
Power
Manager
PD_3
S31
PD_31
Choix d’allocations (clock views for clock domains)
ou
Choix d’allocations (power views for power domains)
ou
Equational View
Specification des PowerStates, PowerSwitches
Power Controller
Power Manager
Application abstraite
•
UML activity/state diagrams pour modéliser des graphes de tâches
Objectif : transformations de modèles (en cours)
Traductions en vue d’analyse ou de (co-)simulation, depuis une même source
+ intégration avec première partie de
la présentation (Michel Auguin, LEAT)
Outil logiciel
En développement, <still_looking_for_a_good_name> …
•
basé sur
o
Eclipse (http://www.eclipse.org/)
o
Papyrus (http://www.eclipse.org/modeling/mdt/papyrus/)
o
UML (http://uml.org/)
o
MARTE (http://omgmarte.org/)
o
SysML (http://uml-sysml.org/)
o
TimeSquare (http://timesquare.inria.fr/)
Merci de votre attention !
à consommer avec modération
Questions ?