Csee B

Optimisation
architecturale pour la
conception conjointe des
systèmes embarqués
Introduction
Introduction
● Raison du développement des systèmes embarqués
– cf. intro Systèmes Électroniques Embarqués
● Méthodologie d'optimisation des systèmes :
– Organisation et représentation architecturale
– Introduction à l'optimisation architecturale
– Amélioration et intégration verticale du process global de
conception conjointe
– Réf. : Function/Architecture Optimization and Co-Design of Embedded
Systems, Bassam Tabbara, Abdallah Tabarra, Alberto Sangiovanni-
Vincentelli, 2000, Kluwer Academic Publisher [ Bib. Univ. Metz : 004.16 TAB ]
Conception haut niveau
des systèmes embarqués
Conc. haut niveau des syst. emb.
● Définition informelle des systèmes embarqués :
– ensemble de blocs programmables entourés d'ASICs et d'autres
composants standards qui interagissent avec l'environnement au
travers de capteurs et d'actionneurs
● État des lieux :
– prolifération de tels systèmes
– conception de ces systèmes de façon spécifique à chaque cas
de figure
– nécessité de définir une méthodologie de conception globale
● Conception des systèmes embarqués
Spécification
du design
Représentation
du design
Partitionnemen
Synthèse Évaluation
t HW/SW
Implantation
● Conception des systèmes embarqués
– Conception HW/SW : nouveau concept
● réduction du time-to-market
● besoin d'intelligence embarquée
– Optimisation : souvent négligée

● partie de la synthèse :
– synthèse logique
– synthèse logicielle
– Nécessité d'une approche co-design descendante guidée
par la synthèse où l'optimisation démarre au plus haut
niveau d'abstraction
● Validation haut niveau des systèmes embarqués
– Validation :
● pourcentage significatif des équipes de conception
● temps de simulations importants (plusieurs mois)
● augmente en même temps que la complexité des systèmes
– Systèmes embarqués :
● nombreux blocs fonctionnels hétérogènes, tant logiciels que
matériels
– Besoins = évaluation précise et rapide :
● des décisions de compromis
● des alternatives de co-design résultant des optimisations haut
niveau
● sans synthèse systématique
Technique de validation pour mesurer les conséquences des décisions

de compromis faites au haut niveau sur l'implantation finale
– Modélisation de la fonctionnalité combinée matérielle/logicielle
et de son architecture cible
– Compromis sur différents aspects de l'approche de validation :
● Exactitude (accuracy) : mesure la précision de l'estimation
et la fiabilité de cette information au niveau d'abstraction

courant
● Rapidité (throughput) : détermine la rapidité de la
simulation, nombre de cycles de simulation par seconde, à

quelle vitesse la méthode peut générer une réponse à la
demande
● Convenance (convenience) : mesure le nombre
d'interventions nécessaires, le degré d'automatisation de la

simulation, la facilité à générer des testbenchs
– Contraintes pour l'évaluation des performances
● co-simulation rapide des implantations mixtes logiciel/matériel
● synchronisation précise des deux composants HW/SW
● évaluation de différentes famille de processeurs
● co-simulation de systèmes hétérogènes
– traitement de données et traitement réactif simultanés

– mélange des méthodes de représentation, de validation, et
de synthèse adaptées à chaque sous-tâche particulière
● Cadre de travail pour la validation de la co-simulation
– Méthodes classiques :
● modèles trop détaillés
– chers à développer
– lents
● modèles fonctionnels
– timing approximatif
– communications négligées
– Solutions :
● nombreuses interventions manuelles
● environnement de simulations sur mesure

– Méthodologie de co-simulation
● comble le fossé entre les deux modèles de validation
précédents
(modèles rapides peu précis et modèles lents très précis)
● ne repose pas sur un simulateur dédié
– Principe : utilisation du VHDL

● modélisation de tous les composants à synthétisés
indépendamment de la technologie d'implantation

● spécification initiale : langage formel, sémantique précise
Matériel
Émulateu
r HW
(SW)
Logiciel
Exactitude
SW
et HW
MBF
Fonctionnel
Modèl Modèl
e e
SW HW
MBF : modèle de bus Rapidité
fonctionnel
– Modèles logiciels et matériels exécutés dans le même
environnement de simulation
– Code de simulation similaire au code exécuté par le
processeur
– Différents choix d'implantation concrétisés par :
● différents temps de simulation
– HW : 1 cycle – SW : plusieurs cycles

● différentes contraintes d'exécution
– HW : concurrence – SW : mutex (exclusions mutuelles)

● importance d'une synchronisation efficace entre les domaines
– détection des goulots d'étranglement associés au

partitionnement
● Simulation haut niveau en VHDL
– Décomposition du système en 3 classes de modèles
● Tâches logicielles exécutées sur des processeurs sous le
contrôle d'un RTOS (système d'exploitation temps réel).

Le RTOS (gestion des communications internes et externes
au processeur) est également modélisé
● Tâches matérielles communicant avec le reste du système
grâce à un protocole standard

● Blocs IP matériels [logiciels] modélisés en VHDL
comportemental ou RTL [C Foreign Language Interface (FLI)

en VHDL]
Tâches
systèmes
Partitionnement
HW/SW
Estimation SW Estimation HW
Co-Simulation
HW/SW – Évaluation
Performance/
compromis
– Définition d'un modèle VHDL pour
● chaque tâche
● l'ordonnanceur du RTOS
● les interfaces
– Fonctions de flot de données autorisées pour effectuer les

calculs
● décrites en VHDL ou C
● modélisées en appels de fonctions VHDL ou grâce au FLI du
VHDL
– Performance du modèle comportemental bien meilleure que celle
du modèle de processeur RTL
● réduit le nombre d'événements de simulation
● réduit le nombre de bits simulés
– Ces réductions sont effectives :

● en utilisant un simulateur de matériel sensible aux
événements dans les deux cas

● en utilisant un simulateur de matériel basé sur les cycles dans
le deuxième cas uniquement

Méthodologie
de co-design
fonction/architecture
20
Méthod. de co-design fonction/archi
● Designs au niveau système
– composé de matériels hétérogènes (tant numériques
qu'analogiques) et de composants logiciels
– Méthode traditionnelle (développement de blocs logiciels ou
matériels) inadaptée aux besoins actuels
● difficile, voire impossible, de changer d'échelle de complexité
● schéma d'implantation conventionnelle préconçue
– matériel
– logiciel
– interfaces
● itérations de conception coûteuses
● Méthodologie top-down (synthèse) bottom-up (contraintes)
Architecture Compromis Fonction
Synthèse Mapping Vérification
HW Compromis SW
● Méthodologie basée sur trois concepts
– 1 – Décomposition
● découpage de la fonction en unités
● répartition des contraintes sur ces unités

– 2 – Abstraction et raffinements successifs :
● étape top-down
● co-design et compromis depuis le + haut niveau d'abstraction
● raffinements successifs de la fonction jusqu'au bas niveau
● processus de raffinement = ajout de détails

– 3 – Exploration architecturale de la cible et estimation
● étape bottom-up
● analyse, caractérisation et estimation de l'architecture
● contraintes utilisateur + contraintes architecturales guident les
décisions de compromis et d'optimisation jusqu'au haut

niveau
● Description de la méthode
Bibliothèques Bibliothèques
comportementales d'architectures
Niveau
Capture du
comportement
Vérification du
comportement
Capture de
l'architecture
Vérification de
l'architecture
fonctionnel
Mapping du comporte- Vérification des Niveau

ment à l'architecture performances
mapping
Liaison vers la
Raffinement HW/SW
vérification de la
de la µArchitecture
µArchitecture
Niveau
Liaison vers
l'implantation
architectural
HW/SW
● Description de la méthode
– plus le choix correct d'une architecture sera effectué tôt, plus le
nombre d'itérations de la conception sera faible
– Travailler a un haut niveau d'abstraction augmente la flexibilité :
le design peut facilement être reciblé sur une nouvelle plateforme
– Approche de co-design et de synthèse : deux étapes

● Co-design fonction/architecture et compromis
● Mapping de la fonction sur l'architecture

– Co-design possible si :
● architecture 100% synthétisable
● cible paramétrable au niveau
– macro : multiplieurs, additionneurs, cellules MAC

– micro : taille/accès des registres, cache, mémoire
– Si synthèse complète ou modification de l'architecture impossible
:
● optimisation des fonctions indépendantes de l'architecture
● mapping de cette fonction sur l'architecture du mieux possible
● optimisation moins poussée, compromis limités

– Rôle de la co-simulation dans l'évaluation du compromis
● débuggage fonctionnel pour vérifier l'algorithme utilisé et
l'intégration des composants : exécution des modules sans

information de timing
● satisfaction des contraintes : ident. des composants critiques
● utilisation du processeur, diagramme d'ordonnancement des
tâches : détermination de la rapidité du processeur nécessaire

; mécanisme d'ordonnancement répond mieux aux contraintes
de timing
– Toutes ces informations permettent la sélection d'une
architecture tôt dans le flot de conception, réduisent le nombre
d'itérations et le time-to-market.
– Flexibilité + possibilité de reciblage
● Mapping de la fonction sur l'architecture
– Après la décomposition fonctionnelle et l'organisation
architecturale
● ensemble de composants préalablement conçus
● différents degrés de flexibilité (notion de plateforme)
● différentes tâches assignées à différentes portions de
l'organisation architecturale
Co-synthèse réactive de systèmes
● Défaut des techniques de co-design actuelles :
– utilisées à un niveau d'abstraction relativement bas
– médiocre qualité de synthèse
– stratégies de synthèse conjointe SW/HW :
● implantation d'un processus de décision réactif efficace
● aspects flot de données habituellement négligés
● optimisation gérées par les compilateurs logiciels et RTL
Décompose Associe Associe
Conception
Représentation HW/SW
orientée Représentation
CDFG
contrôle EFSM
EFSM : Extended Finite State Machine

– CDFG : idéal pour représenter les tâches réactives à synthétiser
● estimations de taille ou de vitesse
● synthèse du matériel
● génération de code du logiciel
– Beaucoup du flot de contrôle est caché dans les invocations du

module réactif
● effets sur les données non entièrement propagés, non
correctement évalué
● limite les optimisations des flots de données et du contrôle
dépendant des données à des optimisations restreintes aux

chemins dans le CDFG, sans considérer les optimisations
entre les chemins
BEGIN
S0
Case
a:=5 Mapping (état)
S0 S1 S2
émet(a) a := 5 a := a+1
S1
S2
a:=a+ état := 1 état := 2
1
END
EFSM CDFG
BEGIN
S1
Case
a:=6 Mapping (état)
S0 S1 S2
émet(a) a := 5 a := a+1
S2
état := 1 état := 2
END
EFSM CDFG
● Point clef
– compilateurs logiciels et matériels : ne peuvent pas effectuer en
statique de telles optimisations (décision au moment de
l'exécution)
– représentation au niveau implantation : barrage aux techniques
d'analyse visant à de telles optimisations potentielles
– Approche de co-design en deux phases :

● phase indépendante de l'architecture
● phase dépendante de l'architecture

● Approche de co-design en deux phases :
– phase indépendante de l'architecture
● on considère uniquement la fonction de la tâche
● analyse des flots de contrôle et de données
● optimisation
– phase dépendante de l'architecture

● optimisations basées sur l'information architecturale réglées
pour la plate-forme cible

● compromis entre les différentes métriques de conception qui
mesurent le coût d'implantation (taille, performance, etc.)

Optimisation et co-design
fonction/architecture
Représentation des
systèmes
Représentation des systèmes
● Introduction : tendances
– recherche d'une abstraction commune acceptable pour
l'application (la fonction) et l'architecture
– recherche d'un compromis pour trouver la meilleure plate-forme
matérielle pour une ou plusieurs applications
– pression des coût de fabrication : demande insuffisante pour une
production en grand volume de produits spécifiques
– utilisation nécessaire de plateformes génériques paramétrables,
programmables et flexibles
● Unification des représentations intermédiaires
Design
Décomposition
fonctionnelle
IDR Immediate Design

Indépendant de l'architecture Representation
Dépendant de l'architecture
Cont
raint
S es H
W W
● Applications et plate-formes
Espace application
Spécification
de la Instances de l'application
plate-forme
Exploration
de l'espace
plate-forme
Instance de la plateforme
Espace architecture
Repr. des systèmes : contexte
● Modèles de calcul
– Modèles orientés état :
● courants dans les systèmes orientés contrôle
● décrivent la fonction d'une tâche par un ensemble d'états et
de transitions entre les états

– Exemples de modèles :
● Réseaux de Petri : langage graphique, description de
workflows, inadapté aux systèmes complexes

● Machine d'état finies (FSM) : ensemble d'états et de
transitions associés à des sorties : Mealy = f(s,i) ; Moore = f(s)

● FSM concurrents hiérarchiques : décomposition d'un état
en plusieurs sous-états éventuellement concurrents

● Sémantique de Polis et modèles de calcul
– sémantique du modèle de calcul (MOC : Model of Computation)
de Polis : Co-design Finite State Machines (CFSM)
– Système = réseau de CFSM
– Un CFSM a :
● une partie FSM : ensemble d'entrées, sorties et états,
transition et relations de sortie

● une partie de traitement de données sous forme de
références aux fonctions

● un comportement localement synchrone : chaque CFSM
exécute une transition en produisant une sortie pour une

entrée : synchrone du point de vue de la CFSM
● un comportement globalement asynchrone : chaque
CFSM lit les entrées, exécute une transition, et produit des

sorties en un temps fini non borné : aysnchrone du point de
vue du système
– Représentation proche du partitionnement : chaque élément
décrit un composant du système et définit la granularité de
partitionnement et d'ordonnancement
– Communication entre CFSM : n'utilise pas des variables
paratgées mais des évènements
– Évènements : primitives de communication qui permettent la
lecture synchronisée et l'écriture désynchronisée d'un buffer
– Lecture synchronisée : utile pour capturer la réactivité des tâches
– Écriture désynchronisée : permet de continuer l'exécution sans
devoir attendre le récepteur
● Représentation d'un système dans Polis
C=>F
F B=>C
C=>G
G
F^(G==1)
C=>A
C
CFSM1 CFMS2
C
C=>B
A B
C=>B
(A==0)=>B
CFSM3
● Langage de spécification des systèmes
– applications : systèmes embarquées hétérogènes orientés
contrôle
– conception :
● décomposition fonctionnelle
● réseau de modules FSM étendus (EFSM) avec traitement de
données
● comportement : langage réactif basé FSM (ex.: Esterel)
– approche peu intrusive vis-à-vis des considérations

fonctionnelles ou architecturales
● Esterel comme front-end pour la spécification fonctionnelle
– Esterel : langage de programmation synchrone pour la
spécification des systèmes temps-réels
– Assume que la synchronie est parfaite : temps d'exécution nul
– Contraintes temporelles ne peuvent pas être modélisées
– Front-end de spécification d'une fonction monotâche
– Supporte la préemption
– Langage d'entrée de l'environnement de co-design Polis
– Facilité de description utilisant la concurrence ou le
séquencement
● Esterel comme front-end pour la spécification fonctionnelle
module simple: in if y = 1 then

input inp : integer; await inp; emit outp(a) ;
output outp : integer; a := ?inp ; else
var loop emit outp(b) ;
a := 0 : integer , a := b+c ; end ;
b := 0 : integer , loop a := x ;
c := 0 : interger , await tick ; end;
x := 1 : integer , x := x + y ; end.
y := 1 : integer x := x + y ;
a := b + c ;
a := x ;
● VHDL comme front-end réactif
– Esterel :
● pas très transparent pour l'utilisateur
● sa sémantique n'est pas apparente pour le concepteur
– Définition d'un sous-ensemble du VHDL réactif

– Identification d'une règle d'utilisation du VHDL pour la description
d'un ensemble de tâches CFSM interconnectées
CFSM : Communicating Finite State Machine

● VHDL comme front-end réactif
-- System I/O Begin

Entity system is -- sample inputs
port( inp :in integer; . . . ); ...
End; -- update state
State := Next_State;
-- Overall Composition ...
Architecture CFSM of system is Case State is
--types/constants when S1 => if ( . . . ) then . . . ;
--communication signals Next_State := S2;
Begin when S2 => . . .
Task1: ...
Process(inp, ...) End Case;
-- local types/constants/variables End Process
type S_Type is (S1, S2, . . . );
variable State, Next_State : S_Type := S1; Task2:
... ...
End Architecture
● Représentation intermédiaire
– Modèle précédent :
● capture du modèle de calcul
● pas orienté optimisation et synthèse
– Techniques d'optimisation et de synthèse :

● faible niveau d'abstraction
● DAG représentant les flots d'exécution des tâches

– Nouvelle représentation des tâches indépendante de
l'implantation : FFG : Function Flow Graph
● ordonnancé selon les entrées/sorties
● préserve la sémantiques des E/S des tâches
– Le FFG décrit aussi bien les fonctions des tâches que leur
interaction avec l'environnement :
● quand la tâche lit des entrées
● quand la tâche fournit des sorties

– contrôle et analyse des flots de données
– techniques d'optimisation : optimiser la fonction tout en
préservant le comportement externe de la tâche
– Design décomposé en un ensemble d'EFSM communicantes
● composition gouvernée par un modèle de calcul (ex : CFSM)
– Le modèle FFG ne contient pas de sémantique CFSM

● l'intention est de pouvoir « mapper » le FFG sur différents
modèles
– Après décomposition, sémantiques des tâches capturées par le
FFG
● capable de décrire les flots de données et de contrôle d'un
logiciel
● capture d'un comportement réactif : notion de sémantique des
E/S
– FFG : niveau d'abstraction initial où l'on peut effectuer nombre
d'optimisations de fonctions
– Niveau d'abstraction suivant raffine le précédent en y ajoutant
des contraintes : imposition de sémantique EFSM sur le modèle
– Application de l'ordonnancement calculé par le front-end* pour
obtenir un AFFG (Attributed Function Flow Graph)
– L'AFFG s'élabore sur la base du FFG par l'addition d'attributs, ce
qui étend le CFG classique
– Domaine orienté contrôle, utilisation de la sémantique EFSM
pour former le FFG (qui reste général)
Design
Raffinement Restriction
Décomposition
fonctionnelle
IDR
Indépendant de l'architecture Co Sémantique d'E/S

ntra
Dépendant de l'architecture inte Sémantique d'EFSM
s
AFFG
SW HW
● Représentation intermédiaire : Graphe de Flot de Fonctions
– Définition 1 : graphe de flot de fonction
● un graphe de flot de fonction est un triplet où G=(V,E,N0)

● V est un ensemble fini de noeuds
● E={(x,y)}, sous-ensemble de VxV, où (x,y) est une arête de x
à y telle que x ∈ Pred(y), l'ensemble des nœuds
prédécesseurs de y (et y ∈ Succ(x), l'ensemble des nœuds
successeurs de x)
● N0 ∈ V est le nœud de départ. Une arête extérieure connecte
N0 au(x) nœud(s) du FFG suivant
– Définition 1 : graphe de flot de fonction
● Des opérations sont associées à chaque nœuds N
– tests effectués sur les entrées et les variables internes de

l'EFSM
– assignations des calculs sur l'alphabet d'entrée à
l'alphabet de sortie de l'EFSM
● Les tests et les calculs qui lisent une ou plusieurs entrées
d'un EFSM sont marquées comme « dépendants des

entrées »
● Les assignations aux sorties d'un EFSM sont marquées
comme « sorties observables »

● Ces opérations définissent l'interaction des tâches avec
l'environnement externe
– Le comportement de la tâche est capturé par le front-end est
représenté par un FFG
– Chaque ensemble d'opérations est un nœud
– Un branchement (conditionnel ou saut) nécessite la présence
d'un nœud cible pour le branchement
– La représentation FFG est basée sur le graphe de flot de contrôle
classique (graphe cyclique) où les deux flots de contrôle et de
données peuvent être représentés
– Les arêtes dans un FFG représentent le flot de contrôle entre les
nœuds
– Les nœuds des FFG sont multi-entrées (à l'exception de N0 qui
ne possède qu'une seule entrée)
– L'ordre initial d'exécution des opérations n'est pas fixé dans la
représentation du FFG
– N'importe quel ordre d'opérations dans un nœud de FFG est
acceptable tant qu'il est valide d'après la définition suivante
– Définition 2 :
● un ordre d'exécution o pour les opérations dans un nœud de
FFG est valide si :

– la dépendance de données de l'alphabet d'entrée des
opérations est préservée entre l'ordre initial i généré par le
front-end à partir de la description de l'EFSM, et l'ordre o
– la sémantique des E/S de la tâche est préservée :
l'échantillonnage d'entrée et l'émission en sortie restent les
même entre l'ordre initial i et l'ordre o
● Représentation intermédiaire :
– C-like Interchange Format
● Le format d'échange d'un FFG est appelé C-like Intermediate
Format (format intermédiaire de type C)

● Il consiste en une liste non ordonnée d'opérations de test et
d'assignation
– instruction d'assignation :
dest = unop(src1)
dest = src1 binop src2
dest = func (arg1, arg2, ...)
– instruction de test :
[ if (condition) ] goto label
● Le format d'échange d'un FFG est appelé C-like Intermediate
Format (format intermédiaire de type C)

● Il consiste en une liste non ordonnée d'opérations de test et
d'assignation
– instruction d'assignation :
dest = unop(src1)
dest = src1 binop src2
saut conditionnel
dest = func (arg1, arg2, ...) absent lors d'un saut
inconditionnel
– instruction de test :
[ if (condition) ] goto label
● Toutes les variables sont des registres : elles conservent leur
valeur jusqu'à la prochaine assignation

● Sémantique des opérations en CLIF (dans un nœud FFG)
cohérente avec celle des langages de programmation itératifs

● Nécessaire pour monitorer les flots de données et permettre
l'analyse de flot de données

● Cette sémantique, sans influer sur l'ordonnancement final des
opérations et l'allocation des registres, est une abstraction

simplifiée du niveau fonctionnel
● L'instruction de transfert de contrôle d'un bloc CLIF vers un
autre est l'instruction goto

● Les labels de la forme identifiant: indiquent le début
d'un bloc CLIF qui est la cible d'un goto
● Chaque bloc CLIF correspond à un unique noeud FFG
– Function Flow Graph – C-like Interchange Format
S1 : x=x+y ;
x=x+y ;
y=1
a=b+c ;
a=x ;
cond1 = (y==cst1) ;
S1
cond2 = !cond1 ;
S1L0 if (cond2) goto S1L0 ;
x=x+y
x=x+y
output = a ;
output=b a=b+c output=a goto S1 ;
a=x
cond1 = (y==cst1) S1L0 : output = b ;
cond2 = !cond1 goto S1 ;
(cond2==1) (cond2==0)
– Formes structurelles des FFG
● Le FFG est un CFG qui capture le comportement des tâches
et introduit une seule considération supplémentaire :

l'identification du comportement des entrées/sorties
observable de façon externe de la tâche
● Le FFG est généré par le front-end à partir d'une description
d'EFSM
● Chaque état de l'EFSM est représenté dans le FFG comme
un ensemble de noeuds qui modélisent le calcul et le

comportement des transitions de l'EFSM d'entrée
– Formes structurelles des FFG
● Le FFG peut être construit à partir de l'EFSM par le front-end
en deux formes structurelles distinctes :

– la forme en arbre (Tree Form)
– la forme en graphe acyclique direct partagé (Shared DAG
Form)
– FFG en forme d'arbre
● parmi tout ceux qui capturent un état de l'EFSM, un unique
noeud du FFG constitue le noeud de départ (start node)

● les autres sont des noeuds cibles conditionnels ou par saut
● tout les noeuds au sein d'un même état sont des noeuds à
entrée et sortie uniques et forment l'arbre

● les boucles dans l'arbre ne peuvent exister qu'entre états :
entre un noeud feuille d'un arbre du FFG, et un noeud de

départ d'un autre
S1
N4
N3
S0
N5
N1
N0
S2
N2
N6 N7
N9 N8
● les nœuds N se réfèrent aux nœuds du FFG, alors que les
états sont représenté par un S

● La figure tr. 71 montre un Attributed FFG : les états sont des
attributs associés aux nœuds du FFG : il s'agit d'un

raffinement de la description du FFG
● Le nombre de nœuds n dans le FFG en arbre construit à partir
de l'EFSM généré par le front-end est :
𝑛 =1+& (1 + 2×𝑐' )
'∈ (..*
où N est le nombre d'états de l'EFSM

ci est le nombre de tests dans l'état i
– FFG en forme de DAG partagé
● Une forme de DAG peut également être construite à partir du
front-end là où certains nœuds FFG qui effectuent une

fonctionnalité commune sont partagés au sein de et entre les
états
● Les nœuds partagés forment un graphe acyclique direct de
calculs, et peuvent être partagés :

– entre différents chemins de calcul au sein d'un état
– entre différentes états
● En plus des nœuds de départ d'état, un unique noeud de
départ de DAG de FFG représente le départ du DAG

● Les nœuds FFG peuvent être à multiple entrées et sortie
unique
● Les boucles ne peuvent avoir lieu qu'entre états : depuis une
feuille de FFG jusqu'à un nœud de départ

● Le nombre de nœuds du FFG en DAG est considérablement
plus petit que pour un FFG en arbre, grâce au partage de

nœuds
S1
N2
N1 S3
N3 D7
N6
S2 N4
N5
● Preuve du concept
Input inp ; goto S1 ; S3 : x = x+y ;

Output outp ; S0 : goto S0 ; x = x+y ;
int a, b, c ; S1 : a = cst0 ; a = b+c ;
int x, y ; b = cst0 ; a=x;
int cst0 = 0 ; c = cst0 ; cond = (y ==
int cst1 = 1 ; x = cst1 ; cst1) ;
int cond1, cond2, y = cst1 ; cond4 = !cond3
cond3 ; goto S2 ; ;
int cond4 ; S2 : cond1 = inp ; if (cond4) goto
cond2 = S3L1 ;
!cond1 ; outp = a ;
if (cond2) goto goto S3 ;
S2L0 ; S3L1 : outp = b ;
a = inp ; goto S3 ;
a = b+c ;
goto S3 ;
S2L0 : goto S2 ;
● Preuve du concept : exemple de design en CLIF
Input inp ; goto S1 ; S3 : x = x+y ;

Output outp ; S0 : goto S0 ; x = x+y ;
int a, b, c ; S1 : a = cst0 ; a = b+c ;
int x, y ; b = cst0 ; a=x;
int cst0 = 0 ; c = cst0 ; cond = (y == cst1) ;
int cst1 = 1 ; x = cst1 ; cond4 = !cond3 ;
int cond1, cond2, y = cst1 ; if (cond4) goto S3L1 ;
cond3 ; goto S2 ; outp = a ;
int cond4 ; S2 : cond1 = inp ; goto S3 ;
cond2 = !cond1 ; S3L1 : outp = b ;
if (cond2) goto S2L0 ; goto S3 ;
a = inp ;
a = b+c ;
goto S3 ;
S2L0 : goto S2 ;
CLIF : C++ Language Interface Foundation

Optimisation de fonctions
Optimisation de fonctions : intro
● Optimisation :
– c'est le procédé qui vise à améliorer une tâche particulière dans
le but de trouver la meilleure façon d'accomplir la fonction
requise
– l'utilisation d'un contrôleur intelligent peut permettre de résoudre
ce problème d'optimisation avec contraintes
– on considère que l'environnement impose un ensemble fini de
contraintes connues sur la durée de vie du contrôleur, et qu'une
analyse statique peut être effectuée une fois avant que la
fonction et l'architecture soient fixées
– Dans le cas d'environnement changeant constamment, il est
nécessaire d'utiliser des techniques comme l'introspection, pour
lesquelles le contrôleur a besoin de s'auto-reconfigurer par
apprentissage (machine learning) en fonction des demandes
environnementales
Optim. de fonctions : introduction
● Méthodologie d'optimisation
– résoudre un problème de façon optimale
– nécessité d'un modèle d'optimisation
● Modèle :
– représentation du problème qui capture son essence
– systèmes : processus réactifs, en exécution continue et
interagissant avec leur environnement
– environnement : ensemble de contraintes imposées sur le
processus à modéliser
Optim. de fonctions : méthodologie
● Contraintes
– potentiellement très nombreuses
– gestion du problème :
● relâchement des contraintes les moins fortes
● optimisations des contraintes restantes
– solution adaptée tant que l'on surveille les contraintes relâchées

– Beaucoup de décisions à prendre lors de l'optimisation et de la
synthèse sous contraintes. Pour une gestion adéquate et de
façon optimale :
● connaître le bon ordre des étapes d'optimisation
● utilisation de la séparation des problèmes
● abstraction et raffinements successifs

Optim. de fonctions : cadre mathém.
● Cadre mathématique pour l'analyse des flots de contrôle et de
données
– optimisations à effectuer sur la représentation d'un design :
● résolution d'une classe de problèmes pouvant être
appréhendés de façon similaire

● solution dérivée de l'information statique issue de la
description comportementale
● impossible de déterminer le résultat exact de l'exécution de ce
comportement avant l'exécution à proprement parler

● problèmes d'analyse globale du flot de données mettent en
œuvre la détermination et le rassemblement statique de

l'information distribuée à travers la tâche
● Cadre d'analyse de flot de données (DFA)
– cadres de travail : modéliser les problèmes de propagation
● problèmes qui rassemblent et manipulent l'information en
accord avec le flot de contrôle

● approche itérative
● un flot rétropropagé peut être modélisé simplement en
inversant le flot et en apportant de légers ajustements

syntactiques aux notions
– But de l'optimisation
● être capable de manipuler l'information, la propager à travers
le comportement, effectuer des observations

● simplifier le processus de génération de cette information
● Cadre d'analyse de flot de données (DFA)
– Résumé :
● le but de l'analyse et de l'optimisation est de rassembler
l'information sur le comportement d'une tâche de façon

préservatrice
● on applique ensuite des transformation préservatrices et
sûres afin de trouver une solution valide

● la solution trouvée est la solution valide déterminée
statiquement la meilleure possible

● Cadre d'analyse de flot de données monotone (MDFA)
– si 𝑓 ∈ 𝐹 alors f est monotone
– il existe des problèmes qui n'entrent pas dans le cadre de DFA

mais bien dans celui du modèle de MFDA ; ex. : propagation de
constantes
– les propriétés des composants d'un cadre de travail affectent les
aspects suivants du problème de flot de données en cours de
modélisation :
● existence d'une solution exacte ou approximée
● applicabilité des méthodes pour arriver à une telle solution
● complexité de la méthode utilisée

● Solutions exactes ou approximées
– Points fixes (fixpoints) : solutions approximées, ou résultats
intermédiaires qui approximent la véritable solution
– MFP : un point fixe minimal (MFP : Minimum FixPoint) est un
point fixe qui est plus petit ou égal à un autre point fixe
– JOP : la jonction sur tous les chemins (JOP : Join Over all Paths)
:
● soit PATH(n) l'ensemble des chemins depuis le nœud initial 𝑁3
au nœud 𝑛 ∈ 𝑁 dans le graphe G, alors

● le JOP est ∨5∈6789 : 𝑓5 (⊥) où fp représente l'ensemble des
informations pour l'instance du problème le long du chemin p

Faible (petite)
0
Φ
1 2 3
{d1} {d2} {d3,d4}
ordre Lattice
4 5 6
{d1,d2} {d1,d3,d4} {d2,d3,d4}
7
MFP : {d1,d2,d3,d4}
Reaching definitions = ?
? JOP : {d1,d2,d3}
Élevé (large)
– on cherche à trouver les définitions à atteindre (reaching
definitions) du nœud 7
– pendant une itération, on obtient la solution {d1,d2,d3,d4} (le MFP
de cette itération)
– la procédure d'analyse n'a pas encore réalisé que la définition de
d4 est inutile parce que cette définition sera éliminée avant
d'atteindre le nœud 7.
– Cette solution est plus grande que le JOP :
{d1,d2,d3,d4} ≥ {d1,d2,d3}
– une solution sûre au problème de reaching definitions inclurait
toutes les définitions de la solution puisque cette surestimation
résulterait en des opportunités d'optimisation moins nombreuses
mais n'invaliderait pas le résultat
– on utilisera toujours le MFP comme la solution la plus large, tout
en cherchant des solutions plus petites jusqu'à ce que le JOP
soit atteint.
– le MFP est l'approximation normalement découverte lors d'une
itération
● plus la solution est large (ou d'ordre élevé) plus elle est sûre
● plus la solution est petite (ou d'ordre faible) meilleure elle est
● Algorithme itératif pour les instances MDFA
– L'algorithme itératif est typiquement l'algorithme utilisé pour
optimiser les compilateurs de logiciel, afin d'optimiser la solution
optimale :
● il est général
● il s'applique à n'importe quel graphe G sans imposer de
restriction
– D'autres approches comme « l'approche itérative par
élimination », ou « l'approche par recherche d'intervalle »
nécessitent que le graphe soit réductible
● Algorithme itératif pour les instances MDFA
– Un graphe de données G est dit réductible si l'entrée de chacune
des boucles de G se fait par l'en-tête de la boucle uniquement
N0
N1 N2
Graphe
irréductible
● Définition : semilattice
– une intersection semilattice est un ensemble L associé à une
opération intersection ∧ tel que pour tout a,b,c ∈ L :
a∧ a ≡ a (idempotence)
a∧ b ≡ b∧a (commutativité)
a∧ (b∧c) ≡ (a∧b)∧ a (associativité)
● Définition : monotone
– soit une semilattice bornée L avec intersection ∧, un ensemble
de fonctions F sur L est dit monotone si les conditions suivantes
sont remplies :
1. Chaque f ∈ F satisfait la condition de monotonicité suivante :
∀ x,y ∈ L, f(x∧y) ≤ f(x) ∧ f(y)
2. Il existe une fonction identité i dans F telle que :
∀ x ∈ L, i(x) = x
1. F est fermée par la composition (o), c.à.d pour 2 fonctions f et
g de F :
f,g ∈ F ⇒ f o g(x) ≤ f(x) ∧ f(y)
FD FFG & algo de contrôle de l'optim.
● Algorithme de contrôle de l'optimisation
– Proposition : Objectif de l'optimisation indépendant de
l'architecture
● l'objectif de l'optimisation à un niveau indépendant de
l'architecture est d'éliminer l'information redondante dans le

FFG
● représenter l'information dans un FFG optimisé qui possède
un nombre minimal de noeuds et d'opérations associées à

ces noeuds
● Algorithme d'optimisation du FFG
begin
while changes to the FFG do
Variables Definitions and Uses
FFG Build
● Build graph, symbol table, instruction table
● DFS order
● Node reaching definitions and reached uses
Reachability Analysis
● Unreachable Node Elimination
Normalisation
Available Elimination
● Available computation determination
● Available computation elimination
False Branch Pruning

Copy propagation
Dead operation elimination
end while
end
● Algorithme de contrôle de l'optimisation
– le flot global d'optimisation de FFG englobe le problème de
propagation de constante, et est donc mieux formalisé à l'aide
d'un cadre de travail de flot de donnée monotone
– ces techniques sont des variantes des techniques classiques,
mais :
● spécialisées au domaine où la sémantique réactive s'applique
● sûres : conditions de sûreté de manipulation de l'information
suivies
● toutes les interactions avec l'environnement sont gérées
différemment des opérations habituelles

● Définitions et utilisations de variables
– étape effectuée à chaque itération
– définitions et utilisations des variables mises à jour
– information mise à jour stockée dans les tables d'instruction et de
symbole
– Définition : endroit où sont définies les variables
– Utilisation : endroit où les variables sont utilisées
– Exemple :
● a = b + c définit a et utilise b et c
● Construction du FFG
– étape de construction du graphe de flot de fonction :
● initialement à partir de la description comportementale
● à chaque itération, mise à jour des informations dans chaque
noeud et retrait des noeuds impossibles à atteindre

– construction de deux structures de données auxiliaires :
● table des symboles mise à jour contenant les variables du
FFG
● table d'instructions contenant les instructions du FFG
– meilleure visibilité des variables et instructions

– simplification de l'implantation des algorithmes
● Construction du FFG
– résolution du problème d'atteinte des définitions :
● problème de flot direct
● problème des utilisations atteintes
– Détection de l'utilisation des variables avant leur définition :

utilisation de leur valeur initiale
– Problème du flot inverse utilisé pour détecter les assignations
inutiles (assignations sans utilisations atteintes)
a=b+c L'utilisation de a est atteinte à partir

de l'assignation a = b + c s'il existe
Pas de définition
de a un chemin depuis l'assignation
jusqu'à l'utilisation le long duquel a
c=a+b
n'est pas redéfini
● Analyse de l'accessibilité (reachability)
– Les termes « définition » et « utilisation » sont également utilisés
dans l'analyse de flot de contrôle. Les labels (étiquettes) sont
définis et utilisés comme dans l'exemple ci-dessous :
if (condition) then goto S1L1 ; /* définit le label du nœud S1L1 */
...
S1L1 : a = b + c ; /* utilise le label du nœud S1L1 */
– un label non défini est inaccessible, et un label défini mais non
utilisé gaspille des ressources
– l'élimination des nœuds inaccessibles est faite par la déclaration
du nœud comme étant à retirer ; les labels accessibles depuis ce
nœud et lui seul sont également marqués pour être retirés à
l'étape suivante.
● Normalisation
– procédure visant à effectuer la représentation canonique et à
rendre tous les calculs visibles par l'identification des calculs et
leur stockage dans une hash table associant une définition
unique à l'opération
– Exemple :
T(b+c) = b + c ;
a = T(b+c) ;
a=b+c; T(a*f) = a * f ;
d=f*a; sera transformé en : d = T(a*f) ;
x= c+b; T(b+c) = c + b ; /* This is the same T(b+c) */
x = T(b+c) ;
● Élimination d'expressions disponibles
– la détermination du calcul disponible est une implantation du
problème d'expression de disponibilité qui utilise les étapes
précédentes pour identifier les calculs disponibles l'entrée de
chaque nœud du FFG
AE=𝜙 AE= 𝜙
N1 N2
t1:=a+1
t:=a+1 t2:=b+2
AE={a+1} AE={a+1} AE={a+1,b+2}
N3
a:=a*5
t3:=a+2
AE={a+2}
– Fonctions de transfert de l'Information
∀𝑛 ∈ 𝐺, 𝑓: (𝑅𝑒𝑎𝑐ℎ 𝑛 ) = (𝑅𝑒𝑎𝑐ℎ 𝑛 − 𝐾𝑖𝑙𝑙 𝑛 ) ∪ 𝐺𝑒𝑛(𝑛)
où
● 𝑅𝑒𝑎𝑐ℎ(𝑛) est l'information atteignant le nœud n
● 𝐾𝑖𝑙𝑙(𝑛) est l'information tuée ou invalidée dans le nœud n
● 𝐺𝑒𝑛(𝑛) est l'information générée dans le nœud n

– ∧6∈6LMN O 𝑃𝑎𝑠𝑠(𝑃) et 𝑎 + 1, 𝑏 + 2 ∧ 𝑎 + 1 = 𝑎 + 1
P
donc 𝑎 + 1 est disponible pour N3,
c.à.d 𝑅𝑒𝑎𝑐ℎ(𝑁T) = 𝑎 + 1
𝐺𝑒𝑛(𝑁T) = 𝑎 ∗ 5, 𝑎 + 2 et 𝐾𝑖𝑙𝑙(𝑁T) = 𝑎 ∗ 5, 𝑎 +car 1 a est
redéfini dans la 1ere instruction de N3.
Donc 𝑃𝑎𝑠𝑠(𝑁T) = 𝑎 + 2
– Lorsque l'étape d'analyse est terminée, l'étape d'élimination est
effectuée : un scan linéaire des nœuds du FFG rejette les calculs
redondants
FD FFG & algo de contrôle de l'optim
● Taille des faux branchements
– But : enlever les faux branchements au fur et à mesure que
l'analyse du flot de données est effectuée
– La deuxième branche True de l'opération T1==True n'est jamais
empruntée et peut donc être « taillée »
– Les approches d'optimisation purement contrôle n'effectuent pas
ce genre d'optimisation qui dépend des données
– Implantation :
● analyse dédiée qui vérifie les calculs disponibles à chaque
branche
● technique d'ajout de redondance : les étapes de propagation
de copie et d'élimination des branches mortes supprimeront la

branche inutile
...
False True
T1==True
False True
T1==True c=d+e;
a=b+c;
...
False True
T1==True
T1=False T1=True
False True
T1==True c=d+e;
T1=False T1=True
a=b+c;
● Propagation de copie
– Processus de substitution des variables équivalentes
– Implanté par un scan linéaire des nœuds du FFG
– Utile pour éliminer les calculs intermédiaires ainsi que leurs
variables
– Peut simplifier les opérations en substituant des constantes aux
variables, et permettre d'autres simplifications ultérieures
– Exemples :
... T(false==true) = (false==true) ;

a = T(b+c) ; if (T(false==true)) goto label ;
T(a*f) = T(b+c) * f ; sera évalué en
... if (false) goto label ;
● Élimination des opérations mortes
– élimination de la redondance par analyse des variables vivantes
– toutes les opérations inutiles sont retirées après l'analyse, ainsi
que le contrôle mort
– Variable vivante : une variable est vivante à un point p
quelconque du FFG s'il existe une utilisation consécutive avant
toute redéfinition
● Optimisation des appels de procédures et de fonctions
– procédures non supportées dans les opérations du FFG parce
qu'elles passent des variables indirectes
– les fonctions à sortie unique sont supportées (comme une
opération)
– phase d'optimisation indépendante de l'architecture :
● propagation des simplifications sur les arguments de la
fonction
● pas de déplacement de calculs vers ou hors de la fonction
● (risque de modifier la sémantique)
● hypothèse : fonctions optimisées pour la synthèse (fonctions
non réactives : fonction de calcul simple)

Propriétés de l'algo d'optim. du FFG
● Préservation de l'information et théorème de sûreté
– L'algorithme d'optimisation du FFG préserve l'information
présente dans le corps du comportement du FFG, et est sûr
● Ordre des étapes efficace
– L'ordre des étapes comme décrit dans l'algorithme d'optimisation
du FFG est efficace car chaque étape utilise l'information de la
précédente étape, et lui succède « naturellement »
● Théorème d'arrêt
– L'algorithme d'optimisation du FFG s'arrête (l'optimisation
débouche sur une résultat, et ne se poursuit pas sans fin)
Propriétés de l'algo d'optim du FFG
● Théorème de sûreté
– La solution de l'application de l'algorithme d'optimisation du FFG
est sûre (ce qui est différent de la sûreté de l'algorithme)
● Théorème de proximité et d'optimalité
– La solution de l'algorithme d'optimisation du FFG est aussi
proche que possible de la solution idéale, et optimale pour un
ordre des étapes d'optimisation donné
Forme du FFG en arbre ou DAG partagé
– Le DAG partagé du FFG identifie les calculs communs et les
rassemble, ce qui conduit à un nombre de noeuds plus faible en
pratique que la forme en arbre
– Intérêt :
● complexité de temps et d'espace inférieure
● algorithme plus rapide, moins de besoins en ressources
mémoire
– Compromis :
● taille des nœuds + faible, optimisations de chaque état –
efficaces
● plus d'arcs sur les nœuds partagés, donc plus de choix,
puisque les nœuds partagés dépendent de plusieurs

contextes d'exécution
– Résumé : Accélération importante grâce au DAG, qualité
moindre
Optimisation de
fonctions/architectures
Optim. de fonctions/architectures
Contraintes Spécifications
architecturales fonctionnelles
Organisation Décomposition
Architecturale Fonctionnelle
Représentation
Matériel Fonction/Architecture Matériel
Optim. de fonctions/architectures
● Introduction : deux classes d'algorithmes d'optimisation
– Niveau indépendant de l'architecture :
● FFG analysé et optimisé comme un ensemble d'opérations
● E/S préservées
– Niveau dépendant de l'architecture :

● prise en compte de l'ordonnancement des E/S et de
l'assignation des états

● les nœuds dans les états sont optimisés
● allocation des registres et des opérations

Représentation de fonctions/architectures
● AFFG : Attributed Function Flow Graph
– utilisé pour représenter les contraintes architecturales appliquées
au comportement fonctionnel d'une tâche EFSM
– des attributs sont ajoutés au fur et à mesure du raffinement de
l'AFFG
Représentation de fonctions/architectures
● AFFG : Attributed Function Flow Graph
– un FFG attribué est un triplet 𝐺 = (𝑉, 𝐸, 𝑁3 ) où :
● V est un ensemble fini de nœuds
● 𝐸 = (𝑥, 𝑦), sous-ensemble de 𝑉×𝑉, où (𝑥, 𝑦) est un arc de x

à y tel que 𝑥 ∈ 𝑃𝑟𝑒𝑑(𝑦)
, l'ensemble des nœuds prédécesseurs
de y (et 𝑦 ∈ 𝑆𝑢𝑐𝑐(𝑥)
, l'ensemble des nœuds successeurs de
x)
● 𝑁 ∈ 𝑉 est le nœud de départ.
3
● Des opérations sont associées à chaque nœud N. Le seul
ordre imposé à ces opération est celui des dépendances de

données, pour préserver la fonctionnalité
● Des attributs sont associés aux nœuds et aux opérations
dans les nœuds : au moins un attribut d'état est obtenu du

front-end.
Co-design fonctions/architectures
● Co-design dans la macro-architecture
– on considère l'AFFG qui possède un ensemble d'attributs
associés aux nœuds et éventuellement avec les opérations à
l'intérieur de ces nœuds. Ces attributs sont :
● sollicités par l'utilisateur : ordonnancement d'états
(ordonnancement pour l'exécution des tâches de l'EFSM)

● obtenus depuis le front-end (Esterel, Reactive VHDL) et
utilisés pour qualifier les nœuds de l'AFFG

● obtenus par inférence ou profiling (coût des opération addition
et multiplication)
– Les attributs : coûts qui vont guider ou contraindre les
algorithmes d'optimisation exécutés à ce niveau
Co-design fonctions/architectures
● Objectifs de l'optimisation dépendant de l'architecture
– L'objectif au niveau dépendant de l'architecture :
– optimiser la représentation de la tâche de l'AFFG,
● tout d'abord pour la vitesse d'exécution,
● ensuite pour la taille,
● étant donné un ensemble de contraintes architecturales

Déplacement d'op. dans l'AFFG
● Introduction
CSE : Common Sub-expression Elimination
(élimination de sous-expressions communes)
ou
AEE : Available Expression Elimination
(élimination d'expressions disponibles)
– La différence entre les deux est que le CSE a un flot inverse
– L'objectif du CSE et de déplacer les opérations similaires depuis
certains blocs vers leur prédécesseurs si c'est possible
– Contexte général du déplacement d'opérations de l'AFFG
● Introduction
– Déplacement d'opérations similaire au déplacement de code :
● technique pour améliorer la vitesse d'exécution ou l'efficacité
d'un programme en évitant les recalculs inutiles d'une valeur

● But : minimiser le nombre de calculs sur tous les chemins
● Déplacement d'opérations en logiciel
– Interdire les recalculs inutiles lors de l'exécution
– Création de variables intermédiaires apporte une amélioration
pour la plupart des architectures
– Code ré-alloué vers des points du programme valides, et ce
déplacement doit être sûr (pas de changement dans le flot)
– Stratégie : déplacement des opérations candidates le + tôt
possible
– En pratique, ce déplacement vers les points du programme
précoces peut créer des pressions sur les ressources de
l'architecture cible, par exemple à cause du nombre limité de
registres, ce qui conduit à une surcharge du bus mémoire
● Approche pratique : minimisation temporaire
– Technique de Knoop
– Analyse du flot de données uni-directionnelle suivant le flot du
prog.
– Un programme réductible peut être géré en O(n.log(n)) étapes où
n est le nombre d'états du programme (à comparer à la
complexité en O(n2) des approches précédentes)
● Coût du déplacement d'opérations
– Approche de Hailperin
– Obtenu par analyse statistique
– Identification des segments de la description comportementale
les plus souvent visités
– Autres coûts :
● temps d'exécution moyen des tâches
● temps d'exécution des pires tâches
– Complexité de la méthode en O(n)

● Optim. fonction/architecture : cadre d'optimisation général
– définitions de variables atteignables
– utilisation des variables atteintes O(n2)
– complexité globale en O(n2)
– meilleure optimisation par rapport aux approches précédentes
car :
● déplacement d'opérations appliqué à toutes les opérations
candidates simultanément
● analyse et optimisation des autres flots de données et de
contrôles
● Relaxed Operation Motion (ROM)
– déplacement d'opérations relâché
– accomplit ses objectifs indirectement
– spécialisé dans le domaine de l'embarqué
● contraintes de préservation de l'ordonnancement des E/S
● comportement prédictible
● Exemple de Knoop :
– a, b, c : variables internes : initialisées à l'étape S1
– x, y, z : sorties : fixées à leurs états respectifs pour préserver les
traces des E/S avant et après l'optimisation
– But : éliminer les réévaluations redondantes et inutiles de
l’opération a+b
– On insiste sur les nœuds S8 et S9, plus coûteux que leur voisins
– On essaiera de réallouer l'addition vers d'autres nœuds moins
coûteux
● Exemple de Knoop S1
S2 y = a+b
a=c
x = a+b
S3
S6
Boucle
réactive
S4 y = a+b S5 S7 y = a+b
z = a+b
S8 S9 x = a+b
a=c
S10
● ROM guidée par le coût
– 4 étapes principales
– a) Optimisation des flots de données et de contrôle
● séquence d'étapes qui optimisent le FFG (ou l'AFFG)
– b) Progression inverse
● étape d'optimisation principale : réallocation de code d'un ou
plusieurs noeuds vers d'autres noeuds

● effectuée par une approche « aussitôt que possible » ou
« guidée par le coût »

● le déplacement d'opérations se fait indirectement
– b) Progression inverse
● déplacement d'opérations indirect
– i . ajout d'opérations mortes : des opérations sont ajoutées

à tous le nœuds du FFG, ou à une sélection de nœuds de
l'AFFG basée sur le coût
– ii . normalisation et élimination des opérations disponibles :
déplacement effectif des candidats au déplacement
d'opérations des nœuds du (A)FFG cible vers des noeuds
moins coûteux : en pratique, c'est souvent l'élimination des
opérations uniquement
– iii . élimination des opérations mortes : on enlève les
additions inutiles effectuées à l'étape i
– c) Progression normale
● phase optionnelle
● tente de minimiser la durée de vie des variables temporaires
en les rapprochant de leur utilisation

– d) Optimisation finale
● effectue le nettoyage final
– « l'explosion » en O(n2) peut apparaître à l'étape b puisque pour
tout nœud de l'(A)FFG, on peut potentiellement ajouter toutes les
définitions présentes dans les autres nœuds
– Mais :
● approche dirigée ou guidée par le coût : pénalité moindre
● autres approches nécessitent d'effectuer le calcul des
utilisations et des définitions (non pris en compte dans le

calcul de la complexité)
● dans le cas d'une optimisation du comportement, l'approche
est linéaire (O(n)) car la ROM sera dominée par l'étape b.i.
● ROM guidée par le coût : résultat après l'ajout des op. mortes
S7:
_T30 = a+b ;
y = T30 ;
_T30 = a+b ;
Étape d'optimisation Ajout des op. mortes
_T29 = c+b ;
_T30 = a+b ;
goto S8 ;
S8:
_T30 = a+b ; S8: S9:
z = _T30 ; _T30 = a+b ; _T30 = a+b ;
a=c; z = _T30 ; x = _T30 ;
goto S9 ; a=c; _T30 = a+b ;
_T30 = a+b ; a = c;
S9: _T29 = c+b ; _T29 = c+b ;
_T30 = a+b ; _T30 = a+b ; _T30 = a+b ;
x = _T30 ; goto S9 ; a=c;
goto S10 ; goto S10 ;
S7:
_T30 = a+b ;
y = T30 ;
_T30 = a+b ;
Étape d'optimisation Ajout des op. mortes
_T29 = c+b ;
_T30 = a+b ;
goto S8 ;
S8:
_T30 = a+b ; S8: S9:
z = _T30 ; _T30 = a+b ; _T30 = a+b ;
a=c; z = _T30 ; x = _T30 ;
goto S9 ; a=c; _T30 = a+b ;
_T30 = a+b ; a = c;
S9: _T29 = c+b ; _T29 = c+b ;
_T30 = a+b ; _T30 = a+b ; _T30 = a+b ;
x = _T30 ; goto S9 ; a=c;
Élimination des op. disponibles
S8: S9:
_T30 = a+b ; _T30 = a+b ;
z = _T30 ; x = _T30 ;
a=c; _T30 = a+b ;
_T30 = a+b ; a = c;
_T29 = c+b ; _T29 = c+b ;
_T30 = a+b ; _T30 = a+b ;
goto S9 ; a=c;
goto S10 ;
S8: S9:
_T30 = a+b ; _T30 = a+b ;
z = _T30 ; x = _T30 ;
a=c; _T30 = a+b ;
_T30 = a+b ; a = c;
_T29 = c+b ; _T29 = c+b ;
_T30 = a+b ; _T30 = a+b ;
goto S9 ; a=c;
goto S10 ;
S8: S9:
z = _T30 ; x = _T30 ;
a=c; a = c;
_T30 = a+b ; _T30 = a+b ;
Propagation des copies
_T30 = a+b ;
...
S8: S9:
z = _T30 ; x = _T30 ;
a=c; a = c;
_T30 = c+b ; _T30 = c+b ;
Optimisation finale : départ
S1:
_T31 = a+b ;
H = _T31 ;
_T29 = c+b ;
...
S8: S9:
z = _T30 ; x = _T30 ;
a=c; a = c;
_T30 = a+b ; _T30 = a+b ;
Optimisation finale : nettoyage
S1:
_T31 = a+b ;
H = _T31 ;
_T29 = c+b ;
...
S8: S9:
z = _T30 ; x = _T30 ;
a=c; a = c;
_T30 = a+b ; _T30 = a+b ;
Optimisation finale : résultat
S1:
_T31 = a+b ;
H = _T31 ;
_T29 = c+b ;
...
S8: S9:
z=H; x=H;
H = _T29 ; goto S10 ;
goto S9 ;
– Résulat final
● seulement deux opérations « a+b » et « b+c »
● tous les autres calculs peuvent s'y référer par des copies et
des assignations
● exemple : H
● Estimation de coût
– Le nombre de fois qu'une partie du programme est exécuté peut
être déterminé dès que la probabilité de chaque branche est
connue
– ce nombre peut être calculé par résolution d'un système de n
équations linéaires, où n est le nombre de blocs (ou par analogie
le nombre de nœuds de l'(A)FFG)
– Généralisation de la prédiction de branchement
– Utilisation d'une approche similaire aux chaînes de Markov, mais
basée sur les réseaux bayésiens
● Réseau bayésien (Bayesian Belief Network)
– Un réseau bayésien est un graphe acyclique direct composé de
noeuds chacun associés avec une table de probabilité du noeud
(NPT : Node Probability Table).
– Les noeuds représentent des variables discrètes aléatoires, alors
que les arcs connectant ces noeuds représentent les influences
causales
● Réseau bayésien
– L'avantage d'un RB est qu'il autorise la capture :
● Des probabilités subjectives basées sur l'expérience ou la la
connaissance de l'utilisateur
● Des probabilités basées sur les données statistiques dans un
cadre unifié
– Exemple de RB : où organiser une réception
Invités Météo
Réception
● Réseau bayésien
– 3 nœuds de décision
● Invités qui a pour valeurs (beaucoup, peu)
● Météo qui a pour valeurs (soleil, pluie, nuages)
● Réception qui a pour valeurs (intérieur, extérieur)
– La NPT pour le nœud Réception est :
Réception Intérieur Extérieur

(beaucoup, soleil) 0 1
(beaucoup, pluie) 0,6 0,4
(beaucoup, nuages) 0,3 0,7
(peu, soleil) 0,2 0,8
(peu, pluie) 1 0
(peu, nuages) 0,4 0,6
● Flot de conception ROM guidé par le coût
Estimation du coût Optimisation du design
Entrées
utilisateur
Profiling FFG
FFG
attribué
Moteur
d'inférence
ROM
Autres techniques d'optimisation
● Techniques d'optimisation guidées par des contraintes
– La plupart des techniques d'optimisation
● sont orientées contrôle,
● nécessitent des connaissances bas-niveau sur les
performances de la fonction décomposée et mappée sur

l'architecture
Optim. de fonction avant mapping
● Introduction
– On désire optimiser une fonction devant être mappée sur une
macro-architecture
– On considère ici des optimisations de fonctions additionnelles qui
peuvent être effectuées à partir d'informations architecturales
avant le mapping de la fonction sur l'architecture
– Nous avons vu précédemment que les techniques d'optimisation
globales devaient être spécialisées pour être sûres et préserver
la sémantique des entrées-sorties de l'EFSM
– Nous pouvons relâcher cette contrainte puisqu'il y a maintenant
plus d'informations sur l'ordonnancement de l'EFSM :
l'ordonnancement permet de transformer le FFG en AFFG
– Question : à partir de cette information additionnelle, quelle
optimisation supplémentaire peut-on effectuer ?
– Examinons les restrictions que nous avons imposées
aux entrées et aux sorties à travers l'exemple 1 :
input in ;
...
S1 :
t1 = in ;
a = t1 + t2 ;
b = t1 + t3 ;
– l'opération t1=in reste telle quelle, et in ne peut pas être
propagée
– L'exemple 2 suivant :
input in ;
...
S1 :
t1 = in ; /* sera retiré par l'élimination des
opérations mortes */
a = in + t2 ;
b = in + t3 ;
peut modifier le comportement désiré puisqu'il y a maintenant deux
échantillonnages de l'entrée in au lieu d'un seul, et la valeur de cette entrée
peut changer entre les deux échantillonnages
– En relâchant les contraintes sur les entrées, on peut transformer
l'exemple 1 en l'exemple 2 car le CFSM échantillonne les entrées
au début de l'état
– Tant que la sémantique du CFSM reste vérifiée, nous pouvons
effectuer la propagation de copies le long des chemins de calcul
de chaque état
AFFG Optimization Algorithm (G)

begin
while changes to the AFFG do
...
Relaxed Copy Propagation
...
end while
end
– L'étape de propagation de copie est effectuée comme suit :
Relaxed Copy Propagation (G)
begin
foreach state s ∈ G do
Copy = 0 ;
map_propagate_copy(G, s, Copy) ;
end foreach
end
– L'étape de propagation de copie est effectuée comme suit :
map_propagate_copy(G, n, Copy)
begin
copy_propagate(n, Copy) ; /* effectue la propagation */
Copy.append(find_copies(n)) ; /* scan toutes les opérations dans n */
foreach m ∈ Succ(n) do
if m ∈ Succ(n) then
return ; /* stoppe le traitement le long
de cette chaîne de calcul */
else
map_propagate_copy(G, m, Copy) ; /* récursion */
end if
end foreach
end
– principale distinction entre les algorithmes pour l'AFFG et ceux
pour le FFG est que pour l'AFFG est utilisé le concept d'état dont
:
● on sait où il commence
● on sait où il s'arrête
● on connaît tous les nœuds qui appartiennent à cet état le long
de ses différentes transitions

– ceci est formalisé par la définition d'un état dans un AFFG

Csee B

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Csee B

Загружено:

Авторское право:

Доступные форматы

Optimisation

● besoin d'intelligence embarquée

– Optimisation : souvent négligée

● temps de simulations importants (plusieurs mois)

● augmente en même temps que la complexité des systèmes

● des alternatives de co-design résultant des optimisations haut

Technique de validation pour mesurer les conséquences des décisions

et la fiabilité de cette information au niveau d'abstraction

simulation, nombre de cycles de simulation par seconde, à

d'interventions nécessaires, le degré d'automatisation de la

● synchronisation précise des deux composants HW/SW

● évaluation de différentes famille de processeurs

● co-simulation de systèmes hétérogènes

– traitement de données et traitement réactif simultanés

● environnement de simulations sur mesure

– Principe : utilisation du VHDL

indépendamment de la technologie d'implantation

– HW : 1 cycle – SW : plusieurs cycles

– HW : concurrence – SW : mutex (exclusions mutuelles)

– détection des goulots d'étranglement associés au

contrôle d'un RTOS (système d'exploitation temps réel).

grâce à un protocole standard

comportemental ou RTL [C Foreign Language Interface (FLI)

– Fonctions de flot de données autorisées pour effectuer les

● modélisées en appels de fonctions VHDL ou grâce au FLI du

● réduit le nombre de bits simulés

– Ces réductions sont effectives :

événements dans les deux cas

le deuxième cas uniquement

● schéma d'implantation conventionnelle préconçue

Architecture Compromis Fonction

Synthèse Mapping Vérification

● répartition des contraintes sur ces unités

● co-design et compromis depuis le + haut niveau d'abstraction

● raffinements successifs de la fonction jusqu'au bas niveau

● processus de raffinement = ajout de détails

● analyse, caractérisation et estimation de l'architecture

● contraintes utilisateur + contraintes architecturales guident les

décisions de compromis et d'optimisation jusqu'au haut

Mapping du comporte- Vérification des Niveau

– Approche de co-design et de synthèse : deux étapes

● Mapping de la fonction sur l'architecture

● cible paramétrable au niveau

– macro : multiplieurs, additionneurs, cellules MAC

● mapping de cette fonction sur l'architecture du mieux possible

● optimisation moins poussée, compromis limités

l'intégration des composants : exécution des modules sans

● utilisation du processeur, diagramme d'ordonnancement des

tâches : détermination de la rapidité du processeur nécessaire

● différents degrés de flexibilité (notion de plateforme)

● différentes tâches assignées à différentes portions de

● aspects flot de données habituellement négligés

● optimisation gérées par les compilateurs logiciels et RTL

Décompose Associe Associe

EFSM : Extended Finite State Machine

● génération de code du logiciel

– Beaucoup du flot de contrôle est caché dans les invocations du

dépendant des données à des optimisations restreintes aux

– Approche de co-design en deux phases :

● phase dépendante de l'architecture

● analyse des flots de contrôle et de données

– phase dépendante de l'architecture

pour la plate-forme cible