Memoire Online - Les systèmes embarqués

La conjonction de l'évolution des technologies de fabrication des circuits intégrés et de la nature du marché des systèmes électroniques fait que l'on est amené à concevoir des circuits de plus en plus complexes (plusieurs millions) de transistors en un temps de plus en plus court (quelques mois). Ce phénomène a entraîné une métamorphose du processus de conception allant de l'idée au produit.

Durant les dernières décennies, on est passé de la conception de circuits composés de quelques milliers de portes à des systèmes structurés et intégrés comme un réseau sur une même puce. Les puces modernes peuvent contenir plusieurs processeurs, de la mémoire et un réseau de communication complexe. Le principe de la conception reste le même ; il s'agit de générer une réalisation physique sous forme d'une puce en partant d'une spécification système. Par contre, les outils mis en oeuvre et l'organisation du travail durant le processus de conception ont beaucoup évolué. Partant d'une conception complètement manuelle où l'on dessinait les masques du circuit à réaliser sur du papier spécial, on est passé à une conception quasi automatique en partant d'une description du comportement du circuit sous forme d'un programme décrit dans un langage de haut niveau.

Le ciblage de logiciel dans le cas des systèmes embarqués est traité aussi dans ce chapitre. Dans le domaine de la conception de logiciel, de très nombreux travaux ont été et sont effectués sur la compilation de descriptions de haut niveau vers les langages machines (interprétés par les processeurs). Les habitudes de programmation pour les ordinateurs portes à croire que la compilation et l'édition de liens sont les seuls traitements à apporter au logiciel pour pouvoir le faire fonctionner sur une architecture cible. Le but de ce chapitre est de montrer que dans le cas des systèmes embarqués, une autre étape est nécessaire avant la compilation : elle adapte le logiciel à l'architecture cible spécifique et sera nommée dans ce mémoire le ciblage logiciel.

II.2.Les systèmes pour puces :

Les prévisions stratégiques d'ITRS annoncent que 70 % des ASIC comporteront au moins un CPU embarqué à partir de l'année 2005. Ainsi la plupart des ASIC seront des systèmes mono-puces (SoC pour System on Chip en anglais). Cette tendance semble non seulement se confirmer mais se renforcer : les systèmes mono-puces contiendront des réseaux formés de plusieurs processeurs dans le cas d'applications telles que les terminaux mobiles, les Set top box, les processeurs de jeux et les processeurs de réseaux. De plus, ces puces contiendront des éléments non digitaux (par exemple analogique ou RF) et des mécanismes de communication très sophistiqués. Etant donné que tous ces systèmes correspondent à des marchés de masse, ils ont tous été (ou seront) intégrés sur une seul puce afin de réduire les coûts de production. Il est prévu que ces systèmes soient les principaux vecteurs d'orientation de toute l'industrie des semi-conducteurs. Il est donc crucial de maîtriser la conception de tels systèmes tout en respectant les contraintes de mise sur le marché et les objectifs de qualité.

Tous les acteurs dans le domaine des semi-conducteurs travaillent déjà sur des produits intégrant des processeurs multiples (CPU, DSP, ASIC, IP, etc.) et des réseaux de communication complexes (bus hiérarchiques, bus avec protocole TDMA, connexion point à point, structure en anneau et même réseaux de communication par paquets) dans des systèmes monopuces. Certains commencent même à parler de réseaux de composants monopuces (network on chip). Il s'agit

d'assembler des composants standards pour en faire un système comme on le fait pour les cartes. Ainsi, le problème n'est plus tant de concevoir des composants efficaces mais surtout d'obtenir une architecture qui respecte les contraintes de performances et de coûts. Pour les composants, le problème devient plutôt de s'assurer de leur validité avant de les utiliser. Cette évolution fait que le goulet d'étranglement du processus de conception devient maintenant la réalisation du réseau de communication des composants embarqués sur la puce et la validation globale de l'ensemble du système avant sa réalisation. Ainsi, nous sommes déjà passés de l'ASIC au SoC et nous sommes en train de passer au réseau sur puce.

La conception de ces nouveaux systèmes à l'aide de méthodes classiques conduit à des coûts et des délais de réalisation inacceptables. En fait, la conception de ces systèmes induit plusieurs points de cassures qui rendent difficile la mise en échelle des méthodes de conception existantes. Les principaux défis sont les suivants :

La grande difficulté sera de maîtriser la complexité lors de la conception de ces réseaux monopuces. Il s'agira de réussir la conception rapide de système monopuces multiprocesseurs, et ce, sous de fortes contraintes de qualité et de temps de conception. La figure II.1 montre l'architecture d'un système monopuces. Cette architecture est structurée en couches en vue de maîtriser la complexité. La partie matérielle est composée de deux couches :

- la couche basse contient les principaux composants utilisés par le système. Il s'agit de composants standard tels que des processeurs (DSP, MCU, IP, mémoires) ;

- la couche de communication matérielle embarquée sur une puce. Il s'agit des dispositifs nécessaires à l'interaction complexe allant du simple pont (bridge en anglais) entre deux processeurs au réseau de communication de paquets. Bien que le réseau de communication lui-même soit

composé d'élément standard, il est souvent nécessaire d'ajouter des couches d'adaptation entre le réseau de communication et les composants de la première couche.

Logiciel spécifique à l'application

API

Services du système d'exploitation
(interruptions, gestion des ressources, entrées/sorties)

Pilotes

Réseau de communication matériel ^embarqué

CPU, IP, mémoires

(DSP, MCU) (ASIC, COTS)

Figure II.1. Architecture logicielle/matérielle d'un système mono-puce Le logiciel embarqué est aussi découpé en couches :

- la couche de gestion de ressources permet d'adapter l'application à l'architecture.

Cette couche fournit les fonctions utilitaires nécessaires à l'application qu'il est indispensable de personnaliser pour l'architecture et ce pour des raisons d'efficacité.

Cette couche permet d'isoler l'application de l'architecture. Cette couche est souvent appelé « système d'exploitation » (OS). Les applications embarquées utilisent souvent des structures de données particulières avec des accès non standard (manipulation de champs de bits ou parcours rapides de tableaux) qui ne sont généralement pas fournis par les OS standard. D'autre part, les OS standard sont généralement trop volumineux pour être embarqués. Il sera souvent nécessaire de réaliser des OS spécifiques dédiés aux applications. Le lien avec le matériel se fait via les pilotes d'entrées/sorties et d'autres contrôleurs de bas niveau, qui permettent de contrôler les composants de l'architecture. Le code correspondant à ces pilotes est intimement lié au matériel. Ces pilotes permettent d'isoler le matériel du reste du logiciel ;

Cette représentation en couches des systèmes monopuces permet de séparer la conception des composants logiciels (application) et matériels (composants existants ou dédiés) des couches de communication. Elle permet aussi de définir les différents métiers de conception et la distribution du travail entre les différentes équipes.

La plupart des méthodes de conception actuelles essayent de copier le flot de conception des cartes. Ce dernier sépare la conception en quatre métiers, l'architecture système, la conception des composants matériels, la conception des composants logiciels et l'intégration ou la conception système. Les trois derniers métiers sont montrés dans la figure II.2a. Dans les schémas traditionnels, le travail de l'architecte consistait à tailler des composants matériels sur mesure afin de prévoir les interconnexions de manière efficace et d'obtenir les meilleures performances. Ainsi tout le matériel est taillé sur mesure, les composants et le réseau de communication. Le logiciel étant réalisé à part, le concepteur d'architecture doit juste fournir une couche mince de logiciel permettant d'accéder aux ressources matérielles. Le fait que la grande partie des couches de communication est réalisée par des équipes séparées (logiciel, matériel) peut entraîner des surcoûts dus aux précautions et/ou aux sous-

logiciel	Système d'exploitation sur mesure
	Piotes d'entrées/sorties	2
	Réseau de communication matériel
intégrateur	Conception des composants	3

2. Concepteur des interfaces logicielles/ Matérielles pour système sur puce Concepteur 3. Concepteur de circuit

utilisations. La vérification des différentes parties est aussi réalisée de manière séparée et chaque équipe utilise des programmes de test spécifiques.

Ce schéma n'est plus applicable à partir d'un certain degré de complexité. Ainsi la conception d'architecture consistera surtout à assembler des composants existants en vue de respecter des contraintes de performances et de coûts au niveau du système global et non plus au niveau du seul composant. Ainsi, il devient crucial de combiner la conception des couches de communication logicielles et matérielles. Cette évolution permettra la séparation totale entre la conception des couches de communication et les composants matériels et logiciels. Une telle séparation est nécessaire pour introduire un peu de flexibilité et de modularité dans l'architecture en permettant de charger plus facilement les modules de base. Ainsi, l'abstraction des interfaces de communication devient le pivot de la conception des systèmes monopuces.

C'est cette abstraction qui va permettre la conception de circuits à partir d'un modèle supérieur au niveau RTL utilisé aujourd'hui. Le fait de pouvoir décrire l'architecture globale du système et d'abstraire la communication entre les composants doit permettre de mieux finaliser les interfaces entre les différentes couches à l'aide de procédure d'interface (API pour Application Procédure Interface) de haut niveau. Ainsi on pourra décrire le matériel au niveau comportemental et le logiciel à un haut niveau ; bien entendu, le but étant de pouvoir simuler globalement le système à partir de ce modèle abstrait et de permettre la génération automatique de codes logiciel et matériel. C'est ce schéma (présenté figure II.2b) qu'essaient d'atteindre les nouvelles recherches dans le domaine de la conception système.

Les systèmes embarqués

Chapitre II

Conception des logiciels

embarqués

II.1.Introduction :

II.2.Les systèmes pour puces :