De l idée au produit

Transcription

1 Chapitre 1 De l idée au produit 1.1. Introduction 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 œuvre 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. 1 Cet ouvrage fait partie d une trilogie ayant pour but de décrire les méthodes et les outils d aide à la conception de systèmes électroniques digitaux intégrés. Il s agit de couvrir : Chapitre rédigé par Ahmed-Amine JERRAYA.

2 16 Conception logique des systèmes monopuces 1) les méthodologies pour la conception de haut niveau des systèmes monopuces, 2) les méthodologies de conception logique et physique des systèmes monopuces, 3) les méthodologies de conception des logiciels et systèmes d exploitation embarqués pour les systèmes monopuces. Ces trois ouvrages couvriront les méthodes et flots globaux permettant de prendre en compte le cycle de conception complet allant de l idée au produit. Le reste de ce chapitre introduit les étapes du processus de conception et donne un aperçu de l ensemble du présent ouvrage, qui est essentiellement consacré à la conception de haut niveau Les systèmes sur puces Les prévisions stratégiques d ITRS annoncent que 70 % des ASIC comporteront au moins un CPU embarqué à partir de l année Ainsi, la plupart des ASIC seront des systèmes monopuces (SoC pour System On Chip). Cette tendance semble non seulement se confirmer mais se renforcer : les systèmes monopuces 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éseau. 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 seule 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 des 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 standard 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 performance et de coût. 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

3 De l idée au produit 17 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 : 1) la conception des systèmes multiprocesseurs monopuces entraînera inévitablement la réutilisation de composants existants qui n ont pas été conçus spécialement pour être assemblés sur la même puce. Il sera donc nécessaire d utiliser des méthodes d assemblage de composants hétérogènes ; 2) le concepteur d un système contenant des processeurs programmables doit obligatoirement fournir, en plus du matériel, une couche logicielle permettant la programmation de haut niveau du circuit. Il sera donc nécessaire d aider les concepteurs de circuits à concevoir les couches logicielles ; 3) l assemblage de composants hétérogènes sur une même puce pour concevoir des architectures dédiées à des applications particulières peut nécessiter des schémas de communication très sophistiqués mettant en œuvre des parties matérielles, des parties logicielles et des parties non numériques telles que les interfaces de composants optiques ou micromécaniques. La conception de ces interfaces hétérogènes sera vraisemblablement le principal goulet d étranglement du processus de conception des systèmes multiprocesseurs monopuces ; 4) la complexité des systèmes est telle qu il devient quasi impossible de les spécifier/valider manuellement à des niveaux bas tels que le RTL où il faut donner/valider des détails au niveau du cycle d horloge. Des méthodes de conception/validation basées sur des concepts de plus haut niveau sont donc nécessaires. Comme pour le logiciel, des outils de synthèse de haut niveau seront nécessaires pour le matériel. La vérification des composants synthétisés sera obligatoire afin de pouvoir en assurer la qualité. 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èmes monopuces multiprocesseurs et ce sous de fortes contraintes de qualité et de temps de conception. La figure 1.1 montre l architecture d un système monopuce. 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) ;

4 18 Conception logique des systèmes monopuces la couche de communication matérielle embarquée sur la puce. Il s agit des dispositifs nécessaires à l interaction entre les composants. Cette couche peut contenir un réseau de communication complexe allant du simple pont (bridge) entre deux processeurs au réseau de communication de paquets. Bien que le réseau de communication lui-même soit composé d éléments 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. /RJLFLHOVSpFLILTXHjODSSOLFDWLRQ &RPSURPLVPDWpULHOORJLFLHO $3, 6HUYLFHVGXV\VWqPHG H[SORLWDWLRQLQWHUUXSWLRQV JHVWLRQGHVUHVVRXUFHVHQWUpHVVRUWLHV 3LORWHV 5pVHDXGHFRPPXQLFDWLRQPDWpULHOHPEDUTXp ORJLFLHO &38,3PpPRLUHV '630&8$6,&&276 PDWpULHO Figure 1.1. Architecture logicielle/matérielle d un système monopuce 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 nécessaire 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ée «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

5 De l idée au produit 19 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 ; le code de l application. 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 1.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-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 changer plus facilement les modules de base. Ainsi, l abstraction des interfaces de communication devient le pivot de la conception des systèmes monopuces.