Abonnez-vous à DeepL Pro pour traduire des fichiers plus volumineux.

Visitez www.DeepL.com/pro pour en savoir plus.

IN V I
TED P A
P E R

Codesign matériel/logiciel : Le
passé, le présent et la
prévision de l'avenir
Ce document passe en revue le passé, le présent et les perspectives d'avenir du
codage matériel/logiciel, qui est largement utilisé dans les systèmes électroniques
embarqués.
pour les automobiles, l'automatisation de la conception industrielle,
l'avionique, les appareils mobiles, les appareils ménagers et d'autres
produits.
Par J U ¨ RGEN T EICH , Senior Member IEEE

ABSTRACT | Le codage matériel/logiciel étudie
conception simultanée des composants matériels et logiciels
de systèmes électroniques complexes. Elle tente d'exploiter la
synergie entre
Le système d'exploitation est un ensemble de composants
matériels et logiciels dont l'objectif est d'optimiser et/ou de
satisfaire les contraintes de conception telles que le coût, la
performance et la puissance du produit final. En même temps,
elle vise à réduire considérablement le délai de mise sur le
la Le codage matériel/logiciel est apparu comme une
nouvelle discipline pour la conception de circuits intégrés
complexes au début des années 1990. À cette époque, il
était déjà clair que les grands microprocesseurs de 16 et 32
bits ne seraient pas seulement disponibles en tant que
composants discrets sur des systèmes au niveau de la carte,
mais aussi en tant que composants programmables par
logiciel de n'importe quelle conception de circuit intégré.

marché. Cet article présente les principales réalisations de deux Manuscrit reçu le 16 décembre 2011 ; accepté le 20 décembre 2011. Date d'entrée en
vigueur
décennies de recherche sur les méthodes et les outils de publication le 22 mars 2012 ; date de la dernière version le 10 mai 2012.
L'auteur travaille au département d'informatique de l'université d'Erlangen-
conception de matériel/logiciel en commençant par un aperçu
Nuremberg, 91058 Erlangen, Allemagne (e-mail : teich@cs.fau.de).
historique de ses racines, en soulignant ses principales
Identifiant d'objet numérique : 10.1109/JPROC.2011.2182009
directions de recherche et ses réalisations jusqu'à aujourd'hui
et, enfin, en prédisant la direction dans laquelle la recherche
sur la conception de matériel pourrait évoluer au cours des
décennies à venir.

MOTS CLÉS : Cosimulation ; cosynthèse ; coverification ;

exploration de l'espace de conception ; niveau du système
électronique (ESL) ; codesign matériel/logiciel ; prototypage
virtuel.

I. INTRODUCTION
0018-9219/$31.00 ©2012 IEEE Vol. 100, 13 mai 2012 | Proceedings of the IEEE 1411
 A cette époque, la conception simultanée du
matériel et du logiciel était déjà une activité
quotidienne, du moins pour les sociétés de
microprocesseurs, car il fallait soigneusement décider
comment concevoir l'interface entre le matériel du
microprocesseur et le logiciel. Cette tâche impliquant la
définition et la mise en oeuvre de l'architecture du jeu
d'instructions n'a cependant pas encore été traitée
consciemment comme une tâche de conception de code.
Néanmoins, elle a motivé et stimulé les objectifs de
recherche que les méthodologies actuelles de codesign
tentent déjà d'atteindre : satisfaire le besoin
d'automatisation de la signature au niveau du système
(SLD), permettre le développement de systèmes
électroniques corrects comprenant des milliards de
transistors, exécuter des programmes avec des millions
de lignes de codes, et enfin, intégrer non seulement un
seul microprocesseur, mais éventuellement plusieurs
microprocesseurs sur une seule puce [système sur puce
(SoC)] avec ou sans accélérateurs, et achever un tel
processus de conception dans un délai typique de 18-24
mois pour la mise sur le marché.
Stimulées par les avancées technologiques prédites
par Gordon Moore, les techniques de conception de
matériel/logiciel sont aujourd'hui indispensables à la
réussite de la conception d'un système électronique et
sont donc de plus en plus utilisées dans les entreprises
qui développent des produits de systèmes électroniques
embarqués. Le nombre et l'éventail des domaines
d'application qui ne cessent d'augmenter comprennent
des branches industrielles importantes telles que
l'automobile, l'automatisation de la conception
industrielle, l'avionique, les appareils mobiles, les
appareils électroménagers et bien d'autres encore. Enfin,
dans un avenir où l'on s'attend à des progrès techniques
croissants - la vie après la loi de Moore - le
codéveloppement pourrait devenir encore plus
important pour deux raisons. D'une part, le nombre de
ventes de nouveaux produits techniques réussis ne sera
plus autant déterminé par les facteurs suivants

1412 Proceedings of the IEEE | Vol. 100, 13 mai 2012

 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

Le progrès technologique n'est pas le seul facteur à des implémentations de systèmes fonctionnant
prendre en compte, mais de plus en plus les outils correctement et hautement optimisées (par
permettant de concevoir des systèmes de meilleure exemple, en ce qui concerne le coût, la puissance,
qualité et plus fiables que n'importe quel concurrent avec la performance).
une technologie donnée. D'autre part, le ralentissement du Le présent document donne une vue d'ensemble des
progrès technologique justifiera également que l'on réalisations historiques et des orientations actuelles de la
consacre plus de temps à l'analyse et à l'exploration recherche en matière de conception de matériel/logiciel et
minutieuses des options de conception. est structuré comme suit. En commençant par un résumé
Avant d'entrer dans les détails techniques, nous des racines historiques des techniques de codage et des
résumons les principaux objectifs et intentions du codage réalisations correspondantes à partir du début des années
du matériel et des logiciels. Ceux-ci sont expliqués en 1990 dans la section II, les principales facettes et les
examinant les différentes interprétations de la syllabe co méthodologies disponibles du codage moderne sont
du mot codesign. présentées dans la section III. Dans la section IV,
• Coordination : Les techniques de codification sont différentes variantes du codage matériel/logiciel sont
utilisées aujourd'hui pour coordonner les étapes de présentées.
conception des groupes de conception
interdisciplinaires, y compris les développeurs de
microprogrammes, de systèmes d'exploitation
(OS) et d'applications du côté logiciel, ainsi que
les développeurs de matériel et les concepteurs de
puces de l'autre côté, afin de travailler ensemble
sur toutes les parties d'un système. C'est
également l'interprétation originale de la syllabe
latine co dans le mot codesign. Les autres
interprétations suivantes sont plus subtiles.
• La coïncidence : Les délais serrés de mise sur le
marché obligent les développeurs de matériel et
de logiciels à travailler de manière concomitante
au lieu de commencer le développement des
microprogrammes et des logiciels ainsi que leurs
essais seulement après que la plate-forme
matérielle est disponible. On peut constater que le
codesign a permis de réaliser d'énormes progrès
pour éviter ce goulot d'étranglement en
commençant par une spécification exécutable et/ou
en appliquant le concept de plates-formes virtuelles
et de prototypage virtuel afin d'exécuter le logiciel
développé simultanément sur un modèle de
simulation de la plate-forme dès les premières
étapes de son développement. En outre, les essais
et le partitionnement des composants logiciels et
matériels à exécution simultanée nécessitent des
techniques de cosimulation spéciales pour refléter
la concurrence et la synchronisation des sous-
systèmes.
• La co-réactivité : Il va sans dire que les chal-
es défis posés par le matériel et les logiciels
complexes exigent des techniques permettant non
seulement de vérifier l'exactitude de chaque sous-
système individuel, mais aussi de couvrir leurs
interactions correctes après leur intégration.
• La co-mplexité : Bien entendu, les techniques de
codesign sont principalement motivées par la
complexité de la conception des systèmes
électroniques d'aujourd'hui et servent de moyen
(ou du moins tentent) de combler le fossé bien
connu en matière de conception afin de produire
0018-9219/$31.00 ©2012 IEEE Vol. 100, 13 mai 2012 | Proceedings of the IEEE 1411
Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir
Les signes qui sont apparus simultanément sont
présentés et expliqués, comme la conception conjointe
des parties analogiques et numériques d'un circuit
intégré. Par la suite, nous essayons également de
prédire l'avenir des méthodologies de codesign qui
devront émerger au cours des prochaines décennies.
Ces changements et les développements futurs
nécessaires sont d'une part stimulés par les nuages qui
coordonnée d'un système électronique comprenant des
composants matériels et logiciels basés sur une
description du système qui est indépendante de la mise en
œuvre grâce à l'aide de l'automatisation de la conception.
Dans les travaux initiaux de Prakash et Parker [5], un
problème de cosyn- thèse a été formulé sous la forme
d'un problème mixte linéaire en nombres entiers.
1Cette situation est similaire à la quantité d'options d'écriture

se profilent à l'horizon de Moore pour faire face à différentes disponibles pour l a discipline de la conception de
l'imperfection et à la variabilité croissantes au niveau matériel/logiciel elle-même.
des composants de base de chaque conception : le
transistor. Ici, le compromis et l'interaction entre le
matériel et le logiciel deviendront certainement plus
importants pour résoudre les problèmes de fiabilité.
D'autre part, nous pouvons constater une tendance et un
désir d'intégrer plus de flexibilité [1] et d'adaptation au
moment de l'exécution dans la conception d'un système
à des fins d'optimisation et de réduction du coût du
système. Ainsi, nous verrons que la résilience aux
erreurs ainsi que l'adaptabilité nécessiteront de modifier
la fonctionnalité du système et la répartition entre le
matériel et le logiciel de manière dynamique au
moment de l'exécution. Par conséquent, certaines
techniques de codification devront être intégrées dans
le produit afin d'obtenir l'adaptabilité requise en ligne.
En fait, cela ouvre la voie à toute une série de nouveaux
défis qui devront être relevés à l'avenir.

II. L'ÉVOLUTION DE LA CONCEPTION

GRAPHIQUE
Dans cette section, l'évolution du codesign est résumée
en partant d'une discipline émergente au début des
années 1990 jusqu'à une technologie d'ingénierie courante
dans sa deuxième génération. Il convient de noter que la
littérature disponible sur les principales réalisations ainsi
que sur les outils et les cadres de conception de code est
devenue si vaste1 qu'il est impossible de passer en revue
tous ces travaux méritoires dans un seul document. Par
conséquent, les principaux thèmes de recherche abordés
au cours de chaque décennie de recherche ne peuvent
être mis en évidence qu'en soulignant certains points
importants.
approches.

A. Premiers travaux
Bien que la conception conjointe du matériel et du
logiciel ait été pratiquée dès l'introduction du premier
microprocesseur par l'ingénierie conjointe de
l'architecture matérielle et de l'architecture du jeu
d'instructions, la découverte et l'essor ultérieur de la
conception conjointe en tant qu'étape essentielle vers
l'automatisation des systèmes électroniques complexes
ont commencé dans les années 1980 [2] et au début des
années 1990 [3], [4], respectivement.
Le codage matériel/logiciel, parfois également
appelé codage logiciel/matériel ou simplement codage
de manière équivalente, a commencé à être considéré
comme le processus de conception simultanée et
1414 Proceedings of the IEEE | Vol. 100, 13 mai 2012
 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

qui détermine simultanément une topologie multiprocesseur des tâches vers le matériel afin de satisfaire les contraintes
ainsi qu'un calendrier et une allocation des tâches sur de performance tout en essayant de minimiser le coût des
l'architecture. Depuis lors, le problème de la répartition blocs matériels qui en résultent. Même si ces deux
automatique des tâches ou des processus entre le matériel approches impliquaient également l'application d'une
et le logiciel a été rapidement reconnu comme un sujet de synthèse matérielle de haut niveau dans la boucle de
recherche de plus en plus important, avec la formation partitionnement afin d'estimer les performances de
d'une communauté de recherche à partir de 1992 [6]. Le différentes implémentations matérielles des tâches, les deux
premier atelier international de l'IFIP sur le codage premières approches étaient assez limitées non seulement
matériel/logiciel a eu lieu à Grassau, en Allemagne. Sous par le modèle architectural simple, mais également par le
ce nom ou simplement CODES/CASHE, les principaux modèle d'exécution : elles supposaient toutes deux que
événements ultérieurs consacrés à ce nouveau domaine de l'implémentation était "à la carte".
recherche ont été organisés au Colorado (1992), à
Cambridge, MA (1993) et à Grenoble, France (1994),
respectivement. Plus tard, l'événement a été simplement
appelé CODES et organisé dans des lieux tels que
Braunschweig, Allemagne (1997), Seattle, WA (1998),
Rome, Italie (1999), San Diego, CA (2000), Copenhague,
Danemark (2001), et Estes Park, CO (2002). Enfin, en 2003,
le CODES est devenu la Conférence internationale sur le
codage matériel/logiciel et la synthèse de systèmes [7], à la
suite d'une fusion avec le Symposium international de l'IEEE
sur la synthèse de systèmes. Depuis lors, il s'agit toujours de
la conférence annuelle la plus importante au monde, axée
sur tous les aspects de la conception de matériel/logiciel.
Depuis 2006, cet événement important est organisé sous
la direction de la semaine des systèmes embarqués
(ESWEEK) [7] avec d'autres conférences majeures telles
que EMSOFT et CASES.

B. Réalisations de Codesign : La première génération

Au cours des premières années, l'accent a été mis sur
la résolution du problème de la partition d'une
spécification fonctionnelle donnée en matériel et en
logiciel, d'où le problème de la bipartition. Une
spécification fonctionnelle donnée, telle qu'un ensemble
de modules ou de tâches communicants spécifiés dans un
dialecte de type C, est mappée sur une plate-forme
matérielle donnée composée d'une unité centrale de
traitement (CPU) à processeur unique et d'un bloc
matériel défini par l'utilisateur (spécifique à l'application)
ou d'un circuit intégré spécifique à l'application (ASIC), les
deux parties communiquant sur un bus et utilisant une
mémoire partagée ou des registres pour l'implémentation de
la mémoire tampon. Ainsi, à l'exception de la question des
parties à mettre en œuvre sur le circuit intégré spécifique
à l'application, la plate-forme cible était déjà fixée. Ici,
deux approches initiales assez complémentaires méritent
d'être soulignées : Dans l'approche Vulcan développée par
Gupta et al. à Stanford, CA [8], l'idée était de commencer
avec une solution uniquement matérielle et de migrer
autant de tâches que possible vers le logiciel tout en
satisfaisant les contraintes de performance dans le but de
réduire les coûts de conception. Le système de conception
Cosyma développé simultanément à l'Université
technique de Braunschweig [9] a pris un point de départ
exactement opposé en commençant par une partition des
blocs uniquement logicielle avec une migration ultérieure
Vol. 100, 13 mai 2012 | Proceedings of the I E E E 1413
Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir
techniques d'ordonnancement connues des systèmes en
et que l'unité centrale et l'ASIC travaillaient mutuellement
de manière exclusive. Ainsi, l'unité centrale devait attendre en temps réel pour estimer le comportement du temps dans
mode inactif que le matériel termine une fonction et était le meilleur des cas, dans le pire des cas et dans le cas
donc traitée plutôt comme un accélérateur et pas même moyen des systèmes mixtes matériel/logiciel de manière
comme un coprocesseur. Néanmoins, ces deux premières adéquate. La performance étant l'un des facteurs les plus
approches ont stimulé de nombreux travaux sur des critiques pour l'optimisation ou utilisée comme contrainte
recherches ultérieures concernant les approches de lors de la conception, le calcul en temps réel développé
partitionnement et les extensions architecturales. par Thiele et al [15] à la fin des années 1990 et la
méthode de calcul en temps réel ont permis d'améliorer la
C. Réalisations de Codesign : La deuxième génération performance des systèmes mixtes matériel/logiciel.
Au cours des années suivantes et jusqu'au début des
années 2000, non seulement le problème du
partitionnement matériel/logiciel a été approfondi et
considérablement étendu à des types d'architectures plus
complexes, comprenant plus d'une unité centrale, mais
l'hypothèse d'une exécution de programme à un seul fil
a été étendue à la multiprogrammation et au
multiprocessus. Enfin, la cosimulation [10], [11] a
également commencé à devenir un domaine de recherche
important pour la validation précoce des décisions de
conception.
Dans la cosimulation, l'exécution du logiciel sur le
processeur est simulée à l'aide d'un modèle virtuel du
matériel du processeur ou avec la partie matérielle
synthétisée de la conception du système. La raison en est
la complexité de la conception du système lors de la
réalisation d'une simulation matérielle au niveau des
portes ou au niveau du transfert de registre (RTL), qui est
généralement beaucoup trop lente. Par conséquent, les
processeurs doivent être modélisés à un niveau
d'abstraction plus élevé que la partie matérielle mise en
œuvre. Selon [12], le problème de la simulation réside
dans le couplage de différents modèles pour rendre la
simulation matérielle suffisamment précise. Un
exemple de produit à l'époque était Seamless CVS de
Mentor Graphics qui utilisait un modèle de processeur
(c'est-à-dire un simulateur de jeu d'instructions) et des
modèles de bus pour abstraire l'interaction du
processeur avec la mémoire. Bien qu'une modélisation
comportementale encore plus abstraite du logiciel
puisse s'abstraire complètement du matériel en ne
modélisant que le comportement temporel de l'interface
et en permettant à la simulation logicielle de s'exécuter
sur n'importe quel hôte couplé à un simulateur des
parties matérielles, l'analyse de la synchronisation et des
performances est généralement restreinte ici à la partie
matérielle. Dans le domaine de la cosimulation,
Zivojnovic et Meyr [11] ont proposé d'utiliser
également la simulation compilée pour accélérer la
cosimulation. Un cadre important pour la cosimulation
de systèmes hétérogènes était et est toujours le cadre
Ptolemy de l'Université de Californie à Berkeley [13]. Il
peut être utilisé pour cosimuler et comprendre les
relations entre plusieurs modèles de calcul tels que les
modèles de flux de données et d'événements discrets.
En outre, les techniques formelles d'analyse du temps
ont évolué dans la communauté, notamment les algo-
rithmes de Li et Malik pour l'analyse du temps
d'exécution dans le pire des cas (WCET) [14] et
l'application et l'analyse des performances des
1414 Proceedings of the IEEE | Vol. 100, 13 mai 2012
 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

Les travaux d'Ernst et al [16] sur l'analyse temporelle l'architecture est donnée et fixe ne sont pas applicables lors de
compositionnelle sont également dignes d'intérêt. la conception d'un SoC complexe. En outre, les techniques
Bien entendu, les hypothèses architecturales des premiers d'optimisation à objectif unique, telles que la minimisation du
travaux présentés ne sont pas valables pour les architectures coût du matériel sous contrainte de performance ou la
complexes des SoC d'aujourd'hui. Tout d'abord, un système maximisation de la performance sous contrainte de coût, ont
peut contenir non seulement un, mais plusieurs processeurs de été jugées trop restrictives et trop spéciales, car chaque
différents types, tels que des noyaux d'ordinateurs à jeu produit envisagé peut avoir des objectifs complètement
d'instructions réduit (RISC), des processeurs de signaux différents, notamment en termes de coût, de consommation
numériques (DSP), des processeurs à jeu d'instructions d'énergie ou, plus récemment, de fiabilité [23]. Pour pouvoir
spécifiques à une application (ASIP) ou des processeurs à explorer l'espace de conception des différentes solutions
mots d'instructions très longs (VLIW). En 1998, une matérielles et
approche basée sur les graphes a été publiée dans [17] et
présentée plus tôt au CODES 1997 [18] qui permet de
modéliser formellement des architectures cibles
hétérogènes, y compris leur interconnexion. Un graphe
de spécification composé d'un graphe de tâches avec des
dépendances de données et d'un graphe d'architecture
décrivant la variété des composants matériels disponibles et
leurs facilités de communication a été défini dans le but de
formaliser et de généraliser le problème de partitionnement.
Dans ce modèle basé sur un graphe, les arêtes entre les
tâches et les ressources sont utilisées pour décrire les
possibilités de mappage restreintes. Chaque arête de
mappage peut être annotée avec un nombre quelconque
d'attributs de coût tels que la taille du code, la puissance et
d'autres attributs de qualité liés au mappage. En outre, les
retards temporels causés par le transport des données des
tâches communicantes sur les liens de communication sont
pris en compte et mappés en introduisant les tâches dites
de communication entre les tâches dépendantes des
données et en les mappant sur les ressources de
communication en tant que partie intégrante du problème
de partitionnement. Dans [17] également, il a été démontré
que le problème de la recherche d'une allocation réalisable
d'un ensemble de ressources et de la mise en
correspondance (liaison) des tâches avec ces ressources
est NP-complet. Par conséquent, la recherche d'une
implémentation réalisable basée sur ce modèle formalisé
d'application et de graphe d'architecture motive l'application
d'algorithmes d'approximation sophistiqués. L'idée ci-
dessus et les avantages de la modélisation séparée de
l'application et de l'architecture cible se sont rapidement
répandus dans la communauté et ont été affinés et développés
beaucoup plus avant sous le nom de conception basée sur
la plate-forme (PBD) ; voir, par exemple, [19]-[21].
Si l'on considère des implémentations de SoC encore
plus réalistes, il faut aujourd'hui prendre en compte des
réseaux de communication complexes pour l'analyse des
performances et des coûts, comprenant non seulement des
bus de processeurs et des connexions point à point, mais
aussi des interconnexions de type réseau sur puce (NoC).
La figure 7 présente un exemple d'architecture cible
multiprocesseur complexe (MPSoC). La communication
des tâches peut donc impliquer plusieurs sauts et exiger que
le routage soit déterminé en plus du mappage des tâches ;
voir, par exemple, [22]. Par conséquent, les premières
approches de bipartitionnement basées sur l'hypothèse que
Vol. 100, 13 mai 2012 | Proceedings of the I E E E 1415
Teich : Codesign matériel/logiciel : Le passé, le présent et la prévisionseulement
de l'avenirdans la technologie SoC sur une seule
Il est donc important non seulement de permettre à un
concepteur d'implémenter facilement ses propres puce, mais aussi au niveau des dispositifs
fonctions d'évaluation dans un environnement de électroniques communicants distribués tels que les
conception assistée par ordinateur (CAO) pour le codage, unités de contrôle électronique (UCE) dans une
mais aussi de permettre l'examen simultané de plusieurs voiture moderne. Dans ce cas, pas moins de 70 à 90
objectifs sans parti pris ni pondération a priori. Enfin, le calculateurs fournissant des services spéciaux tels
problème de la synthèse des interfaces entre les parties que le contrôle de la stabilité, le freinage
matérielles et logicielles d'un SoC a également été antiblocage ou les fonctions de divertissement sont
reconnu par la communauté du codesign comme un interconnectés. Ainsi, non seulement l'industrie
domaine de recherche important ; voir, par exemple, [24]. des puces, mais aussi de nombreuses entreprises qui
Dans ce domaine, des méthodes permettant de générer conçoivent des systèmes embarqués ont découvert
automatiquement des circuits d'interface à partir de la nécessité de traiter les problèmes suivants
diagrammes de temps ou de réseaux de Petri ont été
étudiées. L'important problème du raffinement
automatique des protocoles de communication abstraits,
tels que les réseaux de processus, en protocoles de bus
relève également de ce domaine. Le système CoWare
[25] est l'une des premières tentatives à proposer non
seulement une synthèse pour le matériel et le logiciel, mais
aussi des techniques de raffinement pour les interfaces.
Dans la section suivante, nous résumons les
nouvelles réalisations importantes qui permettent de
remédier aux insuffisances des approches et des outils
de première génération pour la conception de codes.
Pour des études plus détaillées sur l'état de l'art à
cette époque, les études d'Ernst [12] de 1998 et de Wolf
[26], parues en 2003, sont recommandées.

III. FACETTES ET RÉALISATIONS

DE LA CONCEPTION MODERNE DE
CODES BASÉS SUR L'ESL :
CODESIGN 3.0
Aujourd'hui, nous vivons déjà dans une troisième
génération de technologie de codesign, avec des
environnements de conception à plusieurs niveaux pour
la synthèse de systèmes électroniques complexes qui
deviennent peu à peu disponibles. Au cours de la
dernière décennie, de nombreux progrès importants ont
été réalisés par rapport aux résultats initiaux. Ces
progrès ont été principalement motivés par les défis
suivants en matière de conception de systèmes.
• La technologie des systèmes hétérogènes est
devenue une réalité grâce aux progrès de la
microélectronique et de la nanoélectronique.
Aujourd'hui, un système complexe comprenant
plusieurs microprocesseurs de différents types,
allant des processeurs de signaux numériques
(DSP) aux processeurs d'instructions spécifiques à
une application (ASIP) pour les fonctions
spécifiques à un domaine particulier, et aux
microcon- troleurs, peut être intégré dans un
seul SoC à plusieurs milliards de transistors,
avec des blocs de propriété intellectuelle (IP)
d'accélération matérielle personnalisables et des
IP analogiques, des périphériques et des blocs
de mémoire.
• Complexité matérielle et logicielle : La
complexité matérielle de nombreux systèmes
électroniques embarqués ne se manifeste pas
1416 Proceedings of the IEEE | Vol. 100, 13 mai 2012
 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

l'énorme complexité des systèmes actuels. En effet, la La figure 1(a) montre un calendrier de développement
modélisation, la simulation, l'optimisation et la typique d'un système électronique classique impliquant des
synthèse de ces systèmes en réseau devraient composants matériels et logiciels. Supposons que la durée
également faire partie du champ d'application de la typique d'un produit d'une entreprise soit limitée à 24 mois
technologie du codage. Enfin, l'énorme au maximum. Ici, sur la base d'une spécification commune
complexité s'est accrue encore plus rapidement et peut-être de quelques simulations initiales de haut
dans le monde des logiciels pour les systèmes niveau, les décisions concernant le matériel sont prises en
intégrés. Imaginez que dans un seul véhicule, plus premier. Dans le pire des cas, les équipes chargées des
de 100 millions de lignes de code coexistent et microprogrammes et des logiciels ne peuvent donc pas
coexécutent aujourd'hui. Imaginez également la commencer à développer et à tester leurs logiciels tant que
complexité des essais et de la vérification de la conception matérielle n'est pas disponible. Cela présente
propriétés telles que la sécurité dans un système également le grand risque de retarder l'ensemble de la
aussi complexe. chaîne de conception du produit en cas d'erreurs
• La panacée de l'intégration : Du point de vue du conceptuelles dans la conception du matériel ou d'un
développement d'un système électronique manque de précision dans la conception du logiciel.
embarqué [27]-[30], un dernier obstacle a été et
est toujours le manque de normes et de moyens
pour décrire et intégrer des sous-systèmes
développés par d'autres entreprises et les réutiliser
afin de respecter des délais raisonnables de mise
sur le marché. Encore une fois, cela est très vrai
pour le domaine de l'automobile. Ici, l'intégration
des calculateurs commence généralement sur une
carte de test qui relie les différents sous-systèmes.
Des scénarios d'essais lourds sont ensuite
appliqués pour analyser l'exactitude fonctionnelle
et détecter les erreurs de synchronisation
potentielles avant l'intégration dans le véhicule. Il
est intéressant de noter que les tests d'intégration
sont très souvent effectués sans disposer ni
connaître les logiciels individuels mis en œuvre
dans chaque sous-système, car ils sont
développés par les fournisseurs. AUTomotive
Open System ARchitecture (AUTOSAR) [31] est
une architecture logicielle automobile ouverte et
normalisée, développée conjointement par les
constructeurs automobiles, les fournisseurs et les
développeurs d'outils. L'un de ses principaux
objectifs est de faciliter l'échange et la mise à jour
des logiciels et du matériel pendant la durée de
vie du véhicule.
Les défis susmentionnés ont rapidement conduit à la
découverte des éléments suivants
qu'il devait y avoir un moyen d'élever le niveau
d'abstraction auquel les concepteurs expriment leurs
systèmes en cours de conception, ce qui a donné naissance
à l'idée de la conception au niveau du système
électronique (ESL) ainsi qu'aux moyens d'interfacer et de
réutiliser les conceptions à travers différents niveaux
d'abstraction. Dans ce qui suit, quelques grandes étapes
sont résumées, en considérant la période allant d'environ
2005 à aujourd'hui comme la troisième génération de
codesign.

A. Réduction du délai de mise sur le marché et des

risques de conception grâce à l'analyse, l'exploration
et la conception simultanées du matériel et du logiciel
Vol. 100, 13 mai 2012 | Proceedings of the I E E E 1417
Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision
La de l'avenir
figure 1(b) présente l'expérience d'entreprises
utilisant des outils modernes de conception de codes
basés sur l'ALS, tels que SystemCoDesigner [32], un
outil d'ALS développé par notre équipe de recherche et de
développement.

Fig. 1. (a) Flux de conception classique et (b) flux de conception ESL à

partir d'une spécification exécutable et permettant un
développement simultané.
du matériel et des logiciels après un délai initial pour la
spécification et l'exploration de l'espace de conception. On peut
s'attendre à des économies de l'ordre de six mois. En même
temps, le risque d'erreurs de conception tardives, de
surconception et de sous-conception d'un système est réduit.

les erreurs de production sont détectées tardivement,

voire seulement une fois que le logiciel fonctionne sur le
prototype disponible. En outre, il n'existe aucun moyen
d'explorer les options potentielles des différents choix de
mise en œuvre en fonction d'objectifs multiples tels que le
coût, les performances, l'extensibilité, etc., de sorte que
les décisions relatives à la conception du matériel sont
généralement prises sur la base de l'expérience d'une équipe
de concepteurs de matériel et de l'avancement et du succès
du logiciel par une équipe d'ingénieurs en logiciel.
Les défauts de cette chaîne de conception classique
sont multiples :
• un long chemin critique qui se traduit par des
délais de mise sur le marché longs et souvent
imprévisibles ;
• les risques d'erreurs potentielles dans chaque
partie de la chaîne de conception ne sont
découverts que très tardivement ;
• le risque de surconception ou de sous-conception
d'un système en raison de l'absence d'évaluation
précoce des options de conception.

1418 Proceedings of the IEEE | Vol. 100, 13 mai 2012

 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

groupe. Ici, la spécification initiale du système En outre, la liaison ne tient pas seulement compte de la
commence par une spécification fonctionnelle, mais déjà mémoire partagée mutuellement exclusive et des
exécutable, du système, par exemple en C, C++ ou communications sur un seul bus, mais elle doit également
SystemC. En outre, en fonction d'une plate-forme déterminer les itinéraires des sources aux destinations. En
existante ou d'IP matérielles, un modèle de plate-forme outre, la liaison ne tient pas seulement compte de la
doit être développé, y compris des modèles de coûts. Sur la mémoire partagée mutuellement exclusive et des
base de cette modélisation initiale, il est possible communications sur un seul bus, mais elle doit aussi
d'explorer rapidement l'espace de conception des déterminer les itinéraires entre les sources et les
solutions potentielles dans le choix des composants du destinations, reflétant ainsi les réseaux d'interconnexion
système, de l'interconnexion et de la disposition de la très complexes des conceptions actuelles d'intégration à
mémoire, ainsi que de la distribution des fonctions très grande échelle (VLSI), y compris non seulement les
logicielles, et donc des compromis de conception. Cette structures de bus mais aussi les réseaux sur une puce
étape nécessite bien sûr une réflexion approfondie, car (NoC).
elle peut prendre un temps considérable pour modéliser Cependant, le codage ne fournit pas seulement
l'architecture du système, paramétrer les modèles pour d'importantes aides à la conception au niveau du système.
l'exploration de l'espace de conception et les calibrer en En même temps, il devrait permettre de combiner les
conséquence. Néanmoins, les avantages seront étapes de conception (semi-)automatisées existantes et
importants dans la mesure où la spécification exécutable d'interfacer différents niveaux d'abstraction dans une
peut être utilisée comme un modèle de référence en or large mesure. Ainsi, le codesign permettra d'affiner
pour le processus de développement du logiciel, y automatiquement la conception, d'économiser du temps
compris le micrologiciel et l'environnement d'essai. En de développement et de vérifier rapidement les étapes de
effet, une telle spécification et l'utilisation d'outils de conception susmentionnées [29]. Dans le modèle à
cosimulation peuvent également contribuer à révéler très double toit (Fig. 2) selon [28] et [35], les niveaux
tôt les erreurs dans le cycle de test et de développement d'abstraction typiques de la conception électronique auto-
du micrologiciel. Le risque d'erreurs cachées ou de Les données sont représentées.
surconception ou de sous-conception d'un système par Le modèle à double toit définit le processus de
rapport aux contraintes données peut également être conception descendant typique pour les systèmes
considérablement réduit. D'après notre expérience, matériels/logiciels intégrés. La partie gauche du toit
l'avantage de l'introduction du codesign peut conduire à montre les niveaux d'abstraction typiques rencontrés au
des économies allant jusqu'à six mois dans le délai de cours du processus de conception du logiciel, tandis que
mise sur le marché dans de nombreux cas, comme le la partie droite correspond aux étapes de raffinement
montre la figure 1(b). typiques au cours du processus de conception du matériel.
Chaque côté est organisé en différents niveaux
B. Le modèle de conception à double toit d'abstraction, par exemple les niveaux module (tâche) et
Outre la nécessité d'outils de spécification, d'analyse bloc (instruction) pour les étapes typiques de la
formelle et de cosimulation pour l'analyse des conception de logiciels, et les niveaux architecture et
performances et des coûts, il a été rapidement découvert et logique pour les processus de conception de matériel,
admis que le principal problème de synthèse dans la respectivement. Il existe un niveau d'abstraction commun
conception de systèmes électroniques, appelé aujourd'hui : l'ESL qui a été décrit ci-dessus et auquel il n'est pas
de manière synonyme ESL ou SLD dans [32]-[34], encore possible de faire la distinction entre le matériel et
implique trois grandes tâches dites de mise en le logiciel.
correspondance. Les deux toits illustrés décrivent les deux vues
• Allocation : Sélection d'un ensemble de typiques qu'un développeur rencontre lors de la
ressources système comprenant des processeurs, conception d'un système matériel/logiciel complexe. Le
des blocs IP matériels (par exemple, des toit supérieur décrit la vue fonctionnelle ou la
interfaces, des mémoires, etc.) et leur spécification du système au niveau d'abstraction
interconnexion. correspondant, tandis que le toit inférieur décrit sa mise
en œuvre structurelle, y compris les éléments alloués.
réseau, composant ainsi l'architecture du système en termes de ressources.
ture du système en termes de ressources. Ces ressources
peuvent
être existants en tant que modèles de bibliothèque.
Sinon, le flux de conception doit pouvoir les
synthétiser.
• Liaison : Les fonctionnalités (par exemple, les
tâches, les processus, les fonctions ou les blocs de
base) sont mises en correspondance avec les
Vol. 100, 13 mai 2012 | Proceedings of the I E E E 1419
Teich : Codesign matériel/logiciel
sources de traitement, :les
Le passé, le présent
variables et la prévision de l'avenir
et les
structures de données avec les mémoires, et les
communications avec les itinéraires entre les
ressources correspondantes.
• Ordonnancement : Déterminer quand les fonctions
sont exécutées sur les ressources appropriées, y
compris l'exécution des fonctions, les accès à la
mémoire et la communication. Cela peut
impliquer soit la définition d'un ordre partiel
d'exécution, soit la spécification d'ordonnanceurs
pour chaque unité centrale, chaque
communication et chaque mémoire.
les sources impliquées ainsi que les priorités des Fig. 2. Le modèle à double toit de la conception du code. Le niveau du
système est illustré à
tâches, etc. en haut, reliant les chaînes de développement du logiciel (à gauche)
Ainsi, contrairement aux premiers travaux sur la et du matériel (à droite) par des raffinements successifs de la
conception de codes, la plate-forme ou l'allocation des synthèse (flèches verticales). Chaque étape de la synthèse fait
correspondre une spécification fonctionnelle à une implémentation
ressources n'est pas supposée fixe, mais plutôt considérée
structurelle au niveau d'abstraction immédiatement inférieur.
comme une partie de ce que l'on appelle l'espace de
conception de différents types de ressources.

1420 Proceedings of the IEEE | Vol. 100, 13 mai 2012

 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

ainsi que les décisions en matière de calendrier et synthèse. En particulier, nous montrerons plus loin que
d'obligations et le code correspondant. l'utilisation de composants existants peut être réalisée en
L'automatisation de la conception est visualisée dans contraignant le problème de synthèse à utiliser des
le modèle à double toit par des flèches verticales, chacune composants déjà préalloués tout en réduisant l'espace de
représentant une étape de la synthèse. Par exemple, au cours conception.
de la synthèse logique, une spécification donnée d'un Examinons maintenant de plus près le flux de
système d'équations booléennes ou d'une machine à états conception typique. Le processus de conception représenté
finis (FSM) fournie sous la forme d'un tableau, d'un par le modèle à double toit commence généralement par
diagramme ou d'une spécification en langage de une spécification ESL donnée par une spécification
description matérielle (HDL) est donnée au niveau du toit fonctionnelle (comportementale) de l'ensemble du système
fonctionnel. La synthèse logique génère alors une liste de (basée sur un modèle ou sur un langage). Ici, la spécification
réseaux mettant en œuvre cette FSM en choisissant des fonc-
codages de variables, en appliquant une minimisation
logique et enfin en allouant des portes logiques et des
éléments de mémoire à partir d'une bibliothèque. Ainsi,
au niveau du toit structurel du diagramme, on peut voir la
liste de réseaux résultant du raffinement. Ainsi, par le
biais d'une étape de synthèse, une spécification est
transformée en une implémentation au niveau
d'abstraction immédiatement inférieur. Les flèches
horizontales indiquent l'étape consistant à transmettre des
informations sur l'implémentation à un certain niveau
directement au niveau d'abstraction immédiatement
inférieur en tant qu'informations ou contraintes de
spécification supplémentaires. Par exemple, au niveau de
l'architecture du côté matériel, l'allocation consisterait à
déterminer le nombre d'unités fonctionnelles telles que les
multiplicateurs et les additionneurs de chaque type qui
seront choisis pour composer le chemin de données du
composant matériel résultant. Ici, l'information sur le
choix de l'unité fonctionnelle, telle qu'un additionneur de
carry-ripple avec une certaine précision, servirait d'entrée
supplémentaire au niveau fonctionnel pour la synthèse
logique ultérieure de cet additionneur.
Le modèle à double toit peut être considéré comme
une extension du diagramme en Y [36] par une séparation
explicite de la conception du logiciel et du matériel. Bien
entendu, il n'existe pas de flux de conception entièrement
automatisé pour tous les niveaux d'abstraction présentés
aujourd'hui. En outre, chaque conception peut nécessiter
différentes étapes de raffinement et différents outils à
choisir au cours de la conception d'un système embarqué.
En outre, une conception purement descendante peut
ne pas être possible ou souhaitable pour de nombreuses
entreprises dans de nombreux cas de produits. Par
exemple, certains composants tels que les types et les
numéros de CPU peuvent avoir été choisis dès le début ou
seront réutilisés dans de nouvelles lignes de produits et
doivent donc être pris en compte lors de la mise en
correspondance. De même, lors de la conception du
matériel, certains blocs IP disponibles dans l'entreprise
seront instanciés au lieu d'être synthétisés à partir de zéro.
Une telle stratégie de conception au milieu n'est pas une
contradiction, mais plutôt un cas particulier du flux de
conception, car nous verrons que les allocations de
ressources peuvent être soit fixées, soit choisies au cours
d'une étape de synthèse sur la base des contraintes de
Vol. 100, 13 mai 2012 | Proceedings of the I E E E 1421
Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision
synthèsededel'avenir
haut niveau de manière automatique ; voir
Les entités à mapper sont généralement des tâches
communicantes, des processus ou des sous-algorithmes Cynthesizer de FORTE [38], Cyber- Workbench de NEC
qui font partie de la spécification. En outre, un ensemble [39], C-to-Silicon-Compiler de Cadence [40], et
de contraintes de mappage et d'implémentation (surface CatapultC de Mentor Graphics.
maximale, débit minimal, etc.) est donné. Le modèle de [41] pour quatre produits disponibles dans le commerce.
plate-forme de l'ESL est généralement un modèle Enfin, au niveau logique, la granularité des objets
structurel composé de composants architecturaux tels considérés lors de la synthèse logique correspond alors à
que des processeurs, des bus et d'autres composants des formes booléennes implémentées par des portes
d'interconnexion tels que des liens et des NoC, des logiques et des bascules. Bien entendu, le raffinement peut
mémoires et des blocs IP matériels qui peuvent être se poursuivre à des niveaux d'abstraction encore plus bas,
utilisés comme accélérateurs ou blocs d'interface de tels que le niveau du transistor pour la conception
communication externe. La tâche de la synthèse ESL physique.
consiste à sélectionner une architecture de plate-forme
appropriée parmi cette variété, à déterminer un mappage
du modèle comportemental sur cette architecture et à
générer une implémentation correspondante du
comportement fonctionnant sur la plate-forme. Le
résultat est un modèle affiné contenant toutes les
décisions de conception et généralement plusieurs
mesures de qualité non fonctionnelles, telles que le débit,
la latence, la surface et la consommation d'énergie. S'ils
sont sélectionnés, les composants de ce modèle affiné
sont ensuite utilisés comme intrants dans le processus de
conception à des niveaux d'abstraction inférieurs et,
fondamentalement, chaque composant matériel et
processeur logiciel de l'architecture du système peut être
affiné séparément. La synthèse à des niveaux
d'abstraction inférieurs est un processus similaire. Là
aussi, une spécification comportementale ou
fonctionnelle est affinée en une implémentation
structurelle. Cependant, en fonction du niveau
d'abstraction, la granularité des objets traités pendant la
synthèse diffère et certaines décisions peuvent être plus
importantes que d'autres. Par exemple, au niveau des
tâches (modules) du côté logiciel, les processus/fils
communicants sont liés à un ou plusieurs processeurs sur
lesquels ils doivent être hiérarchisés et programmés en
fonction d'un système d'exploitation en temps réel
(RTOS) prêt à l'emploi ou d'un environnement
d'exécution personnalisé. Cette étape peut également
impliquer la génération d'un code source dans un
langage de programmation cible pour une compilation
ultérieure du code. Enfin, au niveau des blocs, chaque
morceau de code logiciel tel qu'une fonction, une
méthode ou un bloc de base est compilé et lié en
fonction du processeur et du système d'exploitation en
temps réel sélectionnés. Par conséquent, le
Les outils de synthèse que nous rencontrons ici sont des
outils de compilation.
D'autre part, au niveau de l'architecture du côté
matériel, les processus et les tâches sélectionnés pour
être mis en œuvre en tant qu'accélérateurs matériels sont
synthétisés jusqu'à une description RTL sous la forme
de ma- chines d'état de contrôleur qui pilotent un
chemin de données composé d'unités fonctionnelles, de
fichiers de registres, de mémoires et d'interconnexions
appropriées. Cette étape de raffinement est
communément appelée synthèse comportementale,
architecturale ou de haut niveau [37]. Aujourd'hui, il
existe de nombreux outils permettant d'effectuer une
1422 Proceedings of the IEEE | Vol. 100, 13 mai 2012
 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

En résumé, le modèle à double toit tente non l'Université d'Irvine et l'Université d'Austin par les groupes
seulement de mettre en perspective le niveau système en de Gajski, D¨omer, et Gerstlauer ; SystemCoDe- signer
tant que niveau d'abstraction nouveau et important pour [32] développé par notre groupe à Erlangen, Allemagne ;
la conception de systèmes électroniques embarqués, mais Metropolis [48] de l'Université de Californie Berkeley ;
aussi de concaténer les niveaux d'abstraction et de Koski [49] développé par Kangas et al.et enfin PeaCE et
synthèse de conception existants en vue de leur Hope [50], [51] développés à Séoul, en Corée, par le
intégration et de leur interaction. Nous verrons plus loin, groupe de Soonhoi Ha.
lors de l'examen des exigences des cadres SLD
modernes, que l'intégration de certains outils de
conception entre les niveaux d'abstraction n'est pas
toujours libre et facile à réaliser et qu'elle nécessite
toujours une interaction manuelle ou une
personnalisation. Il s'agit d'une caractéristique très
importante dans la conception de l'ALS, car chaque
entreprise peut vouloir personnaliser sa propre suite
d'outils. Même pour chaque produit individuel, une telle
chaîne d'outils doit être personnalisable en fonction des
différents objectifs de conception.
Néanmoins, le modèle du double toit aide à raisonner
sur les trois défis majeurs mentionnés de la complexité de
la conception matérielle et logicielle ainsi que sur le
problème de l'intégration et de la réutilisation des sous-
systèmes conçus à des niveaux d'abstraction inférieurs.
En fait, les trois principales tâches de conception qui
doivent être assurées par tout outil de synthèse, à savoir
les problèmes d'allocation, de liaison et
d'ordonnancement, existent à chacun des niveaux
d'abstraction présentés. Dans [28], il est montré que les
différences résident principalement dans les différents
types de ressources, les différents objectifs d'optimisation
et les différentes techniques d'optimisation pour résoudre
ces trois classes de problèmes abstraits.
Plus loin, dans la section III-E, nous présenterons plus
en détail un cadre de conception ESL appelé
SystemCoDesigner [32] pour donner un exemple de cadre
de conception ESL transnational qui a déjà été appliqué
avec succès à de nombreux domaines d'application et
systèmes, allant de la conception de SoC à la conception
de systèmes intégrés en réseau tels que les réseaux d'ECU
dans le domaine automobile. Il n'entre toutefois pas dans
le cadre du présent document et il est également
impossible de présenter tous les cadres universitaires et
commerciaux existants qui permettent une conception
croisée selon le modèle à double toit présenté ici. Des
études telles que celle de Densmore et al [42] fournissent
une excellente vue d'ensemble de plus de 90 outils
ponctuels disponibles qui se concentrent sur des tâches
individuelles ou des sous-ensembles de tâches de
conception de l'ALS. Il convient également de
mentionner l'étude de Sangiovanni-Vincentelli sur les
cadres de conception de l'ALS [33] et celle de Gerstlauer et
al [43]. Cette dernière fournit une taxonomie pour les
méthodologies de synthèse ESL et compare également
six cadres universitaires disponibles, dont Daedalus [44]-
[46] développé aux Pays-Bas par les groupes de
Stefanov, Pimentel et Deprettere ; System-On- Chip
Environment (SCE) [47] développé conjointement par
Vol. 100, 13 mai 2012 | Proceedings of the I E E E 1423
Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir
complexes, ne sont pas efficacement parallélisables. En
C. Spécification d'applications et de plates-formes
basée sur un modèle ou sur un langage outre, le langage C ou C++ lui-même n'est pas en mesure
La question de savoir quels langages il est préférable d'exprimer la synchronisation, qui est importante non
d'utiliser pour la spécification des systèmes et si un seul seulement du côté matériel du toit, mais aussi du côté
langage doit être utilisé pour répondre à toutes les logiciel, c'est-à-dire pour les systèmes critiques de
exigences a fait et fait encore l'objet d'un débat. sécurité avec des contraintes de temps réel strictes [56].
L'expérience montre que les opinions divergent encore Comme solution intermédiaire, des modifications et
beaucoup à ce sujet. Certaines approches privilégient la des extensions des langages C et C++ purs ont été
conception dite basée sur les modèles par rapport à la développées pour couvrir les deux côtés du toit. Ici, les
conception basée sur les langages, car pour permettre langages SystemC (voir, par exemple,
l'analyse des propriétés du système et les garantir lors
de la synthèse, des formalismes mathématiques solides
sont nécessaires. Dans ce qui suit, une vue d'ensemble
des avantages et des inconvénients de plusieurs
langages utilisés pendant la conception et des approches
basées sur des modèles spécifiques à un domaine est
donnée. Dans [52], Lee et Sangiovanni-Vincentelli
présentent un cadre pour comparer les modèles de
calcul. Dans [53], Ha et al. donnent une vue d'ensemble
de l'application des techniques de conception basées sur
les modèles aux cibles MPSoC.

1) Langages pour le matériel, le logiciel et la conception :

Pour la conception de matériel, l'expression de la
simultanéité et de la synchronisation est indispensable.
C'est pourquoi les HDL ont besoin d'un concept de
processus et de signaux simultanés. Le concept d'un
signal diffère de celui d'une variable dans un langage
de programmation logicielle par le fait qu'il porte des
événements qui apparaissent à certains pas de temps et
qui peuvent déclencher la modification d'autres
signaux. La simulation d'un circuit matériel est alors
réalisée par une simulation basée sur les événements.
Pour les concepteurs de circuits numériques, les deux
langages de conception dominants sont VHDL [54] et
SystemVerilog ; voir, par exemple, [55]. Ce dernier
s'appuie sur le HDL Verilog, largement utilisé. VHDL
et SystemVerilog couvrent bien toutes les vues
fonctionnelles et structurelles (liste de réseaux)
présentées du côté matériel (à droite) du modèle de
double toit de la figure 2. En outre, les deux niveaux de
synthèse architecturale (comportementale) et logique
sont aujourd'hui bien pris en charge par les outils.
Toutefois, il est peu probable que ces langages soient
largement acceptés par les concepteurs de logiciels qui,
du moins dans le domaine du développement de
systèmes électroniques intégrés, préfèrent des langages
de programmation largement répandus tels que C ou
C++. La question qui se pose est donc la suivante :
pourquoi ne pas utiliser un langage impe- ratif très
répandu comme C ou C++ ou ses dérivés pour
commencer la synthèse du système et du matériel ?
Bien qu'il existe également des outils et des cadres qui
prennent le C ou des extensions du C comme point de
départ pour la synthèse matérielle, le problème majeur
est que pour une génération matérielle efficace, des
techniques de parallélisation doivent être appliquées
pour extraire la concurrence d'une spécification
séquentielle. Souvent, d'importantes sources de
parallélisme, telles que les spécifications de boucles
1424 Proceedings of the IEEE | Vol. 100, 13 mai 2012
 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

[57]) et SpecC [47], [58] sont bien connus et établis. Alors élément distinctif de la technologie des signes codés. Les
que SpecC est un surensemble de ANSI C, SystemC est une éléments de base et les réalisations dans le domaine de
bibliothèque de classes du langage C++, les deux offrant l'exploration de l'espace de conception des systèmes
tous les types de données utiles et les structures de électroniques intégrés au niveau du système sont
programmation concurrentes connues des HDL brièvement décrits ci-après. Il convient de noter que les
mentionnés ci-dessus. Afin de simuler un programme idées et les techniques propres à l'exploration de l'espace de
SystemC, une bibliothèque de simulation basée sur les conception sont également valables et peuvent être
événements est disponible, de sorte que les aspects appliquées de la même manière à tout autre niveau
temporels d'une conception de code peuvent ê t r e évalués d'abstraction représenté dans le modèle à double toit de la
non seulement sur le plan fonctionnel, mais aussi en ce qui figure 2, comme l'exploration des calendriers logiciels
concerne les propriétés temporelles. En ce qui concerne la pour les cibles des processeurs de signaux numériques
synthèse du matériel à partir de SystemC, Forte [38], [66].
Cadence [40] et Mentor Graphics [41] proposent tous des
outils pour la synthèse du matériel à partir de sous-
ensembles de SystemC et de C++, respectivement. Pour le
développement de logiciels dans des domaines critiques
pour la sécurité tels que l'avionique, des langages de
programmation spéciaux appelés synchrones sont
appliqués avec succès, avec une sémantique formelle forte
qui permet une vérification plus facile des propriétés ainsi
que la génération automatique de code. Parmi ces langages,
on peut citer Esterel [59], Signal [60] et Lustre [61]. Pour
le langage synchrone Quartz [62] développé par Schneider
et al. l'analyse et la synthèse du code MPSoC sont
également étudiées, par exemple, par la génération d'un
code MPSoC.
Code parallèle OpenMP [63].

2) Modèles de calcul importants pour le codage : Les

langages de programmation manquent souvent d'une
sémantique formelle rigoureuse ou sont trop expressifs
pour prouver des propriétés importantes du système telles
que le caractère vivant ou limité, ou des propriétés non
fonctionnelles telles que le temps ou le coût. Dans ce
contexte, les modèles de calcul restreints tels que les
FSM, les automates temporisés, les réseaux de processus,
les réseaux de Petri et les modèles de calcul de flux de
données [64], [65] ont leur force. Alors que les premiers
sont principalement utilisés pour décrire, analyser et
vérifier des systèmes réactifs, les derniers sont
principalement utilisés pour décrire des systèmes de
traitement de signaux, d'images et de flux en utilisant la
notion d'acteurs [52].

D. Exploration de l'espace de conception

Il a été expliqué que la conception séparée du matériel
et du logiciel peut conduire à des mises en œuvre de
systèmes sous-conçues ne respectant pas toutes les
propriétés non fonctionnelles telles que le temps, le coût
ou la consommation d'énergie. Par ailleurs, les décisions
de conception relatives à l'allocation des ressources
peuvent avoir été prises de manière trop stricte, ce qui
conduit à des implémentations de systèmes trop
coûteuses et donc surconçues et réduit les marges de gain
ultérieures par unité vendue.
En conséquence, l'exploration de l'espace de
conception (DSE) a rapidement commencé à devenir un
Vol. 100, 13 mai 2012 | Proceedings of the I E E E 1425
Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision d'utiliser
de l'avenirde véritables techniques d'exploration
au niveau du module ou de l'architecture, par exemple
pour explorer l'espace de conception des accélérateurs multiobjectifs. Dans ce cas, les approches basées
de boucles massivement parallèles [67]. sur la population qui explorent simultanément
Dans [17] et [18], la distinction entre le modèle de l'espace de recherche, telles que les algorithmes
spécification fonctionnelle et le modèle d'architecture a été évolutionnaires [17], [68], sont devenues l'état de
faite et les tâches de la synthèse du système ont été l'art en matière d'exploration multiobjectif.
définies comme les trois étapes d'allocation des
ressources à partir du modèle d'architecture, de liaison 2Il convient de noter qu'un calendrier peut être une fonction
des tâches ou des entités similaires de la spécification attribuant une heure de début absolue ou relative à une tâche. Il peut
fonctionnelle aux ressources allouées, et également s'agir d'une priorité pour une politique d'ordonnancement
d'ordonnancement correct de ces dernières. Par telle que l'ordonnancement à priorité fixe, ou d'un nombre indiquant un
ordre d'exécution absolu ou partiel.
conséquent, l'espace de conception est donné par
l'ensemble de toutes les permutations possibles
d'allocations, de liaisons et d'horaires.2 Tout triple de ce
type satisfaisant un certain nombre de contraintes non
fonctionnelles supplémentaires, telles que le coût, la
performance, la puissance, la température, etc. est
appelé solution réalisable. À partir d'une solution
réalisable, l'implémentation structurelle correspondante
peut être facilement dérivée. Souvent, le code
programmé pour chaque ressource peut être généré
automatiquement en tant que raffinement de la
spécification initiale.
Comme son nom l'indique, l'exploration de l'espace
de conception d'un système consiste à explorer
l'ensemble des implémentations réalisables 1) de
manière efficace et 2) en trouvant non seulement l'une
d'entre elles, mais aussi une autre.
3) nombreuses et aussi 4) optimales. Le problème est
triple et est résumé dans la figure 3.
• Coût d'exploration et stratégies d'exploration
(algo- rithmes) : Quels sont les bons
algorithmes pour explorer des espaces de
recherche vastes et en général discrets avec des
millions de solutions potentielles ? Bien
entendu, toute technique de recherche connue
peut être appliquée pour trouver des candidats à
une mise en œuvre réalisable, comme les
techniques de recherche rationalisée, les
techniques reposant sur l'amélioration itérative,
comme le recuit simulé, ou les techniques
exactes basées sur des formulations de
programmes linéaires en nombres entiers (ILP).
• Nature multiobjective et évaluation des propriétés
non fonctionnelles : Cependant, les techniques
classiques de recherche mono-objectif telles que
celles mentionnées ci-dessus nécessitent une
seule fonction objective à optimiser. Ainsi, si
l'on veut trouver les meilleures options de
conception pour deux objectifs ou plus, tels que
le coût et la performance, il faut fournir une
fonction de pondération pour combiner les deux
objectifs en une seule fonction qui correspond
déjà à une prise de décision par le concepteur en
raison du choix d'une pondération appropriée.
Pour réaliser une véritable exploration non
biaisée de l'espace de conception et transférer le
processus de prise de décision à l'ingénieur
concepteur lorsqu'il voit quels compromis sont
réalisables pour la mise en œuvre, il est conseillé
1426 Proceedings of the IEEE | Vol. 100, 13 mai 2012
 Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir

3Dans l'optimisation multiobjectif, une solution candidate est dite non

dominée (par rapport à un ensemble de solutions de référence donné), si

aucune solution de l'ensemble de référence n'est (égale ou) meilleure pour
chaque objectif que la solution candidate considérée. Une solution
candidate est dite Pareto-optimale si elle est un point non dominé par
rapport à l'ensemble de toutes les solutions réalisables comme l'ensemble
de référence. Pour un problème d'optimisation donné, le front de Pareto
désigne l'ensemble de tous les points Pareto-optimaux.

Fig. 3. Facettes des outils d'exploration de l'espace de conception

(DSE) sur la base d'un modèle d'application ou d'un modèle de
calcul (MoC)
et un modèle d'architecture (plateforme) (MoA). Au cours de la DSE,
l'espace de conception des candidats à l'implémentation est exploré.
Chaque candidat à la synthèse est évalué en fonction d'objectifs
généralement multiples définis par l'utilisateur et mis en œuvre par
des fonctions d'évaluation.

art. Des algorithmes évolutionnaires spéciaux

explorant le front de Pareto3 tels que SPEA2 [69]
et NSGA-II [70] ont été mis au point pour
explorer très efficacement les ensembles de
qualité Pareto-optimaux ou au moins proches de
Pareto-optimaux pour les problèmes de synthèse
au niveau du système. Ici, la dimensionnalité
(nombre d'objectifs) ainsi que les fonctions
d'évaluation pour chaque objectif de conception
peuvent être choisies délibérément et d'une manière
spécifique à l'utilisateur.
• Comment évaluer de manière flexible la qualité d'un
point de conception ? Enfin, il faut tenir compte
non seulement du vaste espace de recherche et du
temps nécessaire pour l'explorer, mais aussi de la
souplesse avec laquelle différents objectifs
personnalisables peuvent être spécifiés et évalués.
Dans les outils d'exploration actuels, une grande
flexibilité est nécessaire car chaque entreprise
utilisant un tel outil d'exploration peut avoir non
seulement une chaîne d'outils différente dans son
modèle de double toit, mais aussi pour chaque
produit individuel et un nombre différent
d'objectifs à évaluer à chaque niveau d'abstraction
à explorer. Par exemple, dans

Vol. 100, 13 mai 2012 | Proceedings of the I E E E 1427

Teich : Codesign matériel/logiciel : Le passé, le présent et la prévision de l'avenir
des opérateurs génétiques appliqués à une population
Dans le cas d'un réseau de portes
programmables (FPGA) destiné à la mise en donnée de points. L'introduction de techniques symboliques
œuvre d'un système, les objectifs de coût [75], comme le montre la figure 4, a constitué une avancée
pourraient être le nombre de portes logiques, de importante pour l'exploration efficace d'immenses
bascules et de blocs de mémoire vive (RAM) espaces de recherche fortement contraints. En particulier,
utilisés, ainsi que deux objectifs de performance il a été démontré que le problème de la recherche d'une
tels que le débit et la fréquence d'horloge du implémentation réalisable peut être formulé comme un
système synthétisé. Pour une puce de téléphone problème de satisfiabilité booléenne (SAT). Par
portable, les objectifs pourraient être de minimiser conséquent, un solveur SAT peut être utilisé pour
la consommation d'énergie et la surface de la déterminer s'il existe une solution réalisable compte tenu
puce. Maintenant, pour leur évaluation, le d'un certain nombre de contraintes en matière
modèle d'exploration peut être annoté et utilisé d'allocation, de liaison, etc,
pour écrire des fonctions de coût spécifiques à
l'utilisateur. Il est également possible d'utiliser
un outil de synthèse ou d'estimation pour
chaque objectif, tel qu'un outil d'estimation du
temps d'exécution dans le pire des cas (WCET)
[71] pour déterminer le WCET d'une tâche
lorsqu'elle est mappée sur une certaine
ressource du processeur. Afin de parvenir à
cette personnalisation souhaitée, le concept de
fonctions d'évaluation générales, conformément
à la figure 3, a été développé. Par conséquent,
l'acceptation des outils d'exploration de l'espace
de conception dépend fortement de la flexibilité
de la personnalisation et de l'intégration
automatique des fonctions d'évaluation
spécifiques à l'utilisateur et au système, ainsi que
d'un noyau d'exploration hautement efficace.
Dans la section III-E, un exemple d'un tel cadre
d'exploitation flexible appelé SystemCoDesigner sera
décrit plus en détail.

1) Quelques avancées récentes dans l'exploration de

l'espace de conception : Dans [72], Lahiri et al. décrivent
une méthodologie d'exploration de l'espace de
conception pour l'optimisation des architectures de
communication sur puce. Dans [73], Bacivarov et
Jerraya décrivent comment explorer l'architecture
d'interconnexion d'un système. Dans [74], Pasricha et
Dutt décrivent un cadre pour la cosyn- thèse des
architectures de mémoire et de communication pour les
cibles MPSoC. De même, Pimentel et al. utilisent des
algorithmes évolutionnaires pour explorer le problème
du mappage des applications dans la conception des
MPSoC [68].
Une autre observation importante lors de l'utilisation
d'algorithmes évolutionnaires multiobjectifs pour
l'exploration de l'espace de conception à l'ESL est que
pour les espaces de recherche fortement contraints, ils
peuvent ne trouver aucune solution réalisable, en fonction
du codage de l'espace de recherche et de la nature de
l'espace des solutions réalisables. Des extensions ont
donc été proposées, par exemple pour ajouter le
nombre de violations de contraintes en tant qu'objectif
supplémentaire à minimiser afin d'orienter la recherche
au moins vers l'espace des solutions réalisables.
Malheureusement, de nombreux points peuvent être
explorés et évalués plusieurs fois si aucun soin
particulier n'est apporté à la mise en œuvre de l'ensemble
1428 Proceedings of the IEEE | Vol. 100, 13 mai 2012