Architecture des Soc Ben Fradj Hanene

Architecture enfouis Les méthodes de codesign ciblent généralement des systèmes embarqués/enfouis (SOC) Ces systèmes impliquent des contraintes : produits largement diffusés : coûts réduits contraintes temporelles strictes sûreté de fonctionnement (e.g. aéronautique) taille, poids consommation d’énergie Mais il faut aussi privilégier : la réutilisation la flexibilité : modifications tardives, correction d’erreurs

Architecture enfouis logicielles (SW) : processeur + Logiciel flexibilité faible temps de conception Faible cout matérielles (HW) : ASIC et FPGA performances consommation protection industrielle Cout élevé Mixtes Tire profit des 2 approches => cas d’un SoC

Complémentarité HW/SW performance XXX consommation intégration XX Cout de production XXX (si fort volume de production) flexibilité Protection industrielle Cout de développement Prise de risque Contraintes physiques Contraintes économique du produit Contraintes économique du développement

Exemple de SOC

Exemple de répartition HW/SW

Très grandes diversité des composants Les systèmes embarqués deviennent de plus en plus complexes. Le nombre de coeurs de processeurs dans un SOC de 1996 à 1998 chez IBM : 1998 : 9 en moyenne, 30 max 1996 : 2 en moyenne, 3 max Grande variété de composants disponibles : Cœurs de processeurs ASIP : Application Specific Instruction-set Processor ASSP : Application Specific Standard Product Microcontroleurs DSP : Digital Signal Processors RISC Fonctions logicielles Bus standardisés Fonctions matérielles (ASIC) Composants reconfigurables SPGA : System Programmable Gate Array - FPGA + IP) Intellectuel property (IP)

ASIP et ASSP ASIP : Application Specific Instruction set Processor Processeur spécialisé à l’exécution d’une (ou quelques) application (par exemple Modem) Jeu d’instruction et ensemble des ressources adaptés à l’application Meilleurs rapports MIPS/mW et MIPS/mm2 que RISC et DSP Mais compilateur plus délicat, time-to-market plus long qu’avec des processeurs standards ASSP : Application Specific Standard Product Composant complexe qui réalise une fonction spécifique (compression vidéo, modem) ASSP et interface standardisée : IP

Les processeurs embarqué RISC

Processeurs embarqués RISC et mémoire cache : recherche de compromis

Les processeurs de traitement du signal Il existe de nombreux constructeurs : nombreux DSP et leurs variantes chez chacun d’eux - Un DSP peut être particulièrement adapté à un type d’application (exemple : DSP56009, TMS320C54x) - Les performances des DSP peuvent varier significativement : exemple : localisation des données en mémoire, localisation du code

Design Reuse : IP Il devient de moins en moins possible de concevoir un SoC entièrement. Des parties déjà conçues doivent être réutilisées Développer des « composants virtuels » réutilisables Problèmes : Une compagnie seule ne peut pas toujours concevoir tous les composants dont elle a besoin Commerce de composants virtuels Nécessité d’instaurer une protection juridique => « intellectual Property » Nécessité d’utiliser un même formalisme pour la modélisation et l’utilisation pour l’adaptation rapide au système

Niveaux des IPs matérielle « Soft» IP Modèle de description de matériel. Peut être non synthétisable pour la validation purement fonctionnelle. Flexible, paramétrable Indépendant de la technologie Difficile à protéger « Firm» IP Liste d’équipotentielles post synthèse logique Dépend de la technologie Assez difficile à protéger « Hard» IP Liste d’équipotentielles placée et routée Contient les temps de propagation Facile à protéger (boîte noire avec uniquement les E/S)

Usage et format des IPs

Les fournisseurs d’IPs Sociétés d’études et de conception Sociétés sans fonderie (« fab ») dont le profit vient des droits sur les licences DSP Group (IP pour les télécoms), ARM (processeurs RISCs), offre incluant des IPs SOFT, de simulation et synthèse. Sociétés de semi-conducteurs Peuvent fournir des Ips HARD en plus des Ips SOFT TI, Motorola, Lucent, Altera, Xilinx, LSI Logic, STM Fournisseurs d’outils de CAO Fournissent des Ips SOFT uniquement Mentor Graphics, Cadence, Synopsys,…

Les types d’IPs Processeurs: DSPs: Picoblaze, microblaze, Leon, Nios, LSI logic CW4001/4010/4100, ARM 7TDMI, ARM 810,NEC 85x, Motorola 680x0, IBM PPC,… DSPs: TI TMS320C54X, Pine, Oak,… Composants de traitement spécialisés Cryptographie, traitement d’images, multimédia : JPEGcodec, MPEGdecoder. Contrôleurs mémoire et bus : SDRAM, USB, PCI, UART,AMBA Réseaux : ATM, Ethernet Pointeurs : IP commerciales www.design-reuse.com IP « libres » www.opencore.org

SoC : ensemble d’unités interconnectées La conception de SoC: approche classique de type CPU-centric L’accent est mis pendant la conception sur le ou les CPUs et les IPs de calcul Puis on cherche à les connecter Or les performances dépendent de l’interconnexion La structure la plus utilisée : les bus Un bus : ensemble de fils IP Data (N bits) Adresse (P bits) Contrôle (Q bits) L’IP force l’état du fils à 0 ou à 1 Le temps de changement d’état dépend: - Des drivers de courants de l’IP - Des dimensions des fils - Du nombre d’IPs sur le bus

Synchrone ou asynchrone Bus synchrone Dans les signaux de contrôle, un signal d’horloge fixe les instants de changement d’états Simple et rapide si : Tous les IPs sur le bus ont la même vitesse d’horloge La longueur du bus sur le chip est limitée (clock skew) Bus asynchrone Dans les signaux de contrôle, des signaux permettent une synchronisation des échanges Overhead du à la synchronisation (handshake) Adapté à connecter des IPs de types/vitesses différents Req IP1 IP2 Ack

Bus avec Arbitrage Problème: IP1 et IP2 veulent utiliser en même temps le bus pour accéder à IP3 IP1 IP2 IP3 Data Adresse contrôle Les requêtes sont adressées à l’arbitre de bus qui alloue le bus (e.g. suivant une priorité) IP1 IP2 IP3 Data Adresse contrôle Arbitre de bus IP1 et IP2 des maitres (e.g. CPUs) IP3 est un esclave (e.g. Périphérique)

Bus pour l‘embarqué Les constructeurs de SOC s’orientent depuis quelques années vers l’utilisation de bus génériques : protocoles de transferts de données bien définis. Les grands acteurs du système sur puce emploient ce type d’architecture avec chacun une solution propriétaire : Core Connect d’IBM, AMBA d’ARM, AVALON d’ALTERA, WHISBONE d’openCores Exemple la proposition AMBA de ARM : Advanced Microcontroller Bus Architecture Bus Système : AHB ou ASB bus rapide, multi-maître, transferts pipelines ou en mode burst, priorité sur les transferts Bus Périphérique : APB bus adapté à la connexion de périphériques “lents”, non-pipeline, pas de priorité, optimisé en consommation Interfaces entre bus : Bridges

Bus AMBA Bus AHB rapide: peu chargé Possibilité de plusieurs maitres sur AHB Bus APB: périphériques Bridge : seul maitre sur APB Bus hiérarchisé : autant de bus AHB que de maîtres + Passerelles entre les bus AHB Problèmes: Latence entre début de requêtes et fin de communication peu déterministe Dépend du trafic sur le bus (e.g. Burst) Dépend du protocole (priorité, Round Robin) ARM RAM On chip Bus AHB DMA Bridge UART Timer GPIO Bus APB

Conclusion Concevoir les architectures embarquées à partir des composants les mieux adaptés vis à vis des traitements à exécuter Objectifs : globalement performances, consommation, time-to-market,... sont optimisés Hétérogénéité et évolution des composants : microcontroleur, DSP, ASSP, ASIP Stations de base UMTS : DSP VLIW ou multi-MAC ou superscalaire + SIMD ? Portable UMTS : RISC + DSP basse consommation + reconfigurable + accélerateurs HW Migration progressive des accélérateurs dans le chemin de données du DSP Des constructeurs proposent des architectures mixtes Philips/VLSI Technology VVS3771 : ARM7TDMI + OakDSPCore Motorola DSP56651 : RISC M-CORE + DSP56600 Optimiser l’organisation et l’utilisation de la mémoire des composants La mémoire sur le composant : rapide mais coûteuse en surface Défaut de cache : consomme environ 6 fois plus d’énergie qu’une opération ALU Accès en mémoire externe au composant : moins cher mais plus lent et plus coûteux en énergie