Qu’est-ce qu’un système sur puce ?

Qu’est-ce qu’un système sur puce ? 

Les systèmes sur puces (SoCs) sont la dernière incarnation des technologies VLSI (Very Large Scale Integration). Un SoC peut se définir comme un système mixte matériel/logiciel implanté sur une puce unique. Il représente l’intégration de la plupart ou la totalité des composants et des fonctions d’un système embarqué dans une seule et même puce (fig.2). Une puce de mémoire peut avoir plusieurs transistors, mais sa structure régulière la rend un composant et pas un système. Les composants assemblés dans un SoC varient selon l’application à réaliser. Les SoCs peuvent inclure différents blocs fonctionnels réutilisables tels que :
– Des éléments de traitements (Microprocesseurs, Microcontrôleurs, DSPs) ;
– des blocs mémoires (RAM, ROM, Flash) ;
– des structures d’interconnexions (Bus, Crossbar, NoC) ;
– des blocs d’entrées/sorties (USB, Ethernet) ;
– des convertisseurs analogique/numérique ;
– des interfaces externes (IP).

L’approche SoC a été créée dans un premier temps pour le développement d’ASIC mais a été étendue pour le développement de FPGA. On parle alors de SoPC pour System on Programmable Chip. Le SoPC (acronyme inventé par Synopsys) correspond à l’intégration d’un ou plusieurs cœurs de processeurs et de ses périphériques sur une même puce programmable de type FPGA. Le programme est alors situé soit dans une mémoire interne du circuit FPGA si l’empreinte mémoire le permet, soit dans une mémoire externe le plus souvent [5]. Mais dans les littératures le terme SoC (System on Chip) est généralisé quel que soit le type de circuit (FPGA ou ASIC).

Les systèmes sur puces peuvent être trouvés dans de nombreuses catégories de produits allant des dispositifs de consommation à des systèmes industriels (fig.3) :
– Les téléphones portables utilisent plusieurs processeurs programmables pour gérer les tâches de traitement du signal et de protocole requis par la téléphonie. Ces architectures doivent être conçues pour fonctionner à des niveaux de très faible puissance fournies par des piles ou des batteries.
– Les télécommunications et les réseaux utilisent des SoCs spécialisés, tel que les processeurs de réseau, pour gérer les énormes débits de données offertes par les équipements de transmission moderne.
– Les téléviseurs numériques et les décodeurs utilisent des multiprocesseurs sophistiqués pour effectuer des fonctions de vidéo, de décodage audio et d’interface utilisateur en temps réel.
– Les consoles de jeux vidéo utilisent plusieurs machines de traitement parallèles complexes pour rendre l’action de jeu en temps réel.

Les différentes structures d’interconnexions

Les composants, dans un système sur puce, sont reliés entre eux par une structure d’interconnexion qui prend en charge toutes les communications de données entre composants, tant au sein de la puce que des périphériques externes (exemple, les lecteurs de flash externes). Ces structures de communication pour SoC ont été conçues pour avoir une incidence importante sur la performance, la consommation d’énergie, les coûts et les délais de conception de systèmes sur puce. Dans cette section, nous montrerons les différentes structures d’interconnexions utilisées pour la communication entre les modules d’un SoC.

La connexion point à point

Ce type d’interconnexion est le plus simple. Il permet de relier chaque deux IPs directement sans aucun protocole de gestion de communication (fig.4). Cette solution offre plusieurs avantages en termes de latence et de débit. De plus, ce type de structure n’a pas besoin d’un arbitrage pour gérer les communications ainsi qu’il ne peut y avoir aucune congestion de données [6]. Cette structure a toutefois des limites au niveau de la flexibilité et de la scalabilité. Par ailleurs, elle ne peut offrir aucune tolérance aux fautes [6, 7] pouvant survenir sur un lien. Donc cette architecture est très limitée et on ne peut pas l’utiliser pour des systèmes compliqués.

La connexion à base de bus partagé

Il s’agit de la structure d’interconnexion la plus utilisée dans les systèmes actuels à cause de sa simplicité. Cette structure est venue pour résoudre les problèmes rencontrés dans l’architecture point à point en termes de flexibilité. Dans les systèmes à base de bus partagé, tous les modules (IPs) sont connectés à un seul médiat de communication ; c’est le bus (fig.5). Cette structure ne permet qu’une seule communication à la fois. Les communications sont gérées par un arbitrage qui décide quel IP a le droit d’accéder au bus pendant un certain temps (en général le temps d’un transfert) et la sélection d’IP se fait par priorité.

Lorsque le nombre d’IP augmente, on a besoin d’étendre le lien qui peut causer plusieurs inconvénients comme : l’augmentation de la consommation énergétique, la réduction de la fréquence de fonctionnement, l’augmentation de la latence ; cela nous donne une perte de temps et diminue la bande passante [7]. Lorsque le nombre de communications augmente, le bus devient un goulot d’étranglement. Dans ce cas, cette architecture ne semble pas fonctionnelle avec les futurs systèmes qui demandent l’intégration de plusieurs éléments pouvant communiquer entre eux en parallèles. Dans cette structure, le nombre d’IPs connectés au bus est limité à une dizaine d’éléments [8].

Citons quelques exemples de bus utilisés dans les systèmes sur puce :
• Le bus AMBA (Advanced Microcontroller Bus Architecture) : ce bus est conçu par la société ARM pour supporter la communication entre les processeurs ARM [9].
• Le bus Sonics SMART Interconnects : de la société Sonics [10]. Plusieurs compagnies tels que Samsung, Toshiba, Broadcom ou encore Texas Instrument utilisent cette structure.
• Le bus CoreConnect : est un bus sur puce développé par la société IBM [11]. Ce type de bus est très utilisé dans les FPGA Xilinx.
• Le STBus : de la société STMicroelectronics. Ce type de bus et dédié au SoC désigné pour des applications qui demandent une grande bande passante comme le traitement de vidéo [12].
• Le bus AVALON : de la société Altera [13].

La connexion à base de bus hiérarchique

Afin de résoudre les problèmes rencontrés au niveau du bus partagé, l’architecture du bus hiérarchique a été proposée (fig.6). Cette structure permet à plusieurs bus de communiquer entre eux par des ponts (Bridge). Ces structures permettent le parallélisme des communications entre les IPs qui se trouvent dans des bus différents. Le nombre des IPs reliées à chaque bus est petit, ce qui implique, par rapport au bus partagé, une latence plus petite, une minimisation de la consommation d’énergie et une fréquence de fonctionnement plus élevée. Les communications entre les différents bus se fait à travers le pont ; ce dernier peut jouer un rôle de conversion de protocole dans le cas où les bus n’utilisent pas le même protocole de communication [14]. Cependant, les communications à travers le pont deviennent un goulot d’étranglement, ce qui implique une augmentation de la latence quand deux bus veulent communiquer entre eux. Mais, cette architecture, elle aussi, ne peut pas être fonctionnelle avec les futurs systèmes.

La connexion à base de Crossbar

Dans cette structure, tous les modules sont reliés entre eux par un crossbar (fig.7). Ce dernier nous permet des communications en parallèle ainsi que d’augmenter la bande passante car le médiat de transport n’est plus partagé entre tous les modules comme c’est le cas dans les topologies Bus. Cependant, l’inconvénient majeur dans ces architectures est le grand nombre d’interconnexions (câblages) qui croit en fonction du nombre d’IPs intégrées. Le câblage augmente avec le carré du nombre d’éléments communicants : ?(?²).

Table des matières

Introduction Générale
Chapitre 1 : Systèmes sur Puce
1. Les systèmes sur puce
1.1. Evolution des systèmes sur puce
1.2. Qu’est-ce qu’un système sur puce ?
1.3. Les différentes structures d’interconnexions
1.3.1. La connexion point à point
1.3.2. La connexion à base de bus partagé
1.3.3. La connexion à base de bus hiérarchique
1.3.4. La connexion à base de Crossbar
1.3.5. La connexion à base de réseau
2. Les circuits FPGAs
2.1. Les types des circuits logiques programmables
2.1.1. Simple Programmable Logic Device (SPLD)
2.1.2. Complex Programmable Logic Device (CPLD)
2.1.3. Field Programmable Gate Array (FPGA)
2.2. Pourquoi utilise-t-on le FPGA ?
2.3. Architecture des circuits FPGAs
2.4. Les méthodes de programmation des FPGAs
3. Conclusion
Chapitre 2 : Etat de l’art sur les réseaux sur puce
1. Architecture des réseaux sur puce
1.1. Les éléments de base d’un NoC
1.1.1. Le routeur
1.1.2. Les liens
1.1.3. L’interface réseau
2. Les caractéristiques d’un NoC
2.1. La topologie
2.2. Les algorithmes de routage
2.2.1. Les routages déterministes et oblivious
2.2.2. Le routage adaptatif (dynamique)
2.3. Les problèmes de routage
2.3.1. Deadlock (Inter-blocage statique)
2.3.2. Livelock (Inter-blocage dynamique)
2.3.3. Starvation
2.4. Les stratégies de commutation
2.4.1. Commutation de circuit
2.4.2. Commutation de paquet
2.5. Contrôle de flux
2.5.1. ACK/NACK
2.5.2. Stop & Go
2.5.3. A base de crédit
3. Quelques NoCs académiques et industriels
4. Conclusion
Chapitre 3 : Modélisation des Systèmes sur Puce en utilisant l’UML
1. L’Ingénierie Dirigée par les Modèles (IDM)
1.1. Modèles
1.2. Méta-modèles
1.3. Transformations des modèles
2. Le langage UML
2.1. Pourquoi modéliser ?
2.2. Les diagrammes UML
2.2.1. Les diagrammes structurels
2.2.2. Les diagrammes comportementaux
2.3. Les profile UML pour la modélisation des SoCs
2.3.1. SysML (System Modeling Language)
2.3.2. UML-SystemC
2.3.3. UML-SoC
2.3.4. UML-SPT (Schedulability, Performance, and Time)
2.3.5. UML-MARTE (Modeling and Analysis of Real-time and Embedded systems)
3. Le profile MARTE
3.1. Les paquetages du profile MARTE
3.2. La modélisation des structures répétitives
4. L’environnement GASPARD
4.1. Application
4.2. Architecture
4.3. Association ou l’allocation
4.4. Déploiement
5. Conclusion
Chapitre 4 : Architecture de l’approche proposée et résultats
1. La technique de clustering
2. Architecture du réseau réalisé
2.1. Le routeur utilisé
2.1.1. Les FIFOs utilisées
2.1.2. La logique de contrôle
2.1.3. Protocole de communication
2.1.4. L’unité FSM
2.2. Présentation de l’approche proposée
2.3. Algorithme de routage en mode cluster
3. Modélisation de l’approche proposée
3.1. Modélisation des concepts du NoC implémenté en UML
3.1.1. Modélisation de la topologie
3.1.2. Modélisation de la structure du réseau implémenté
3.1.3. Modélisation du comportement du réseau implémenté
3.1.3.1. Modélisation de l’algorithme de routage
3.1.3.2. Modélisation du protocole de communication et du fonctionnement de réseau
3.2. Du modèle vers la génération du code VHDL
4. Résultats expérimentaux
5. Conclusion
Conclusion générale

Lire le rapport complet