FR2893156A1 - Procede et systeme de calcul intensif multitache et multiflot en temps reel. - Google Patents

Abstract

Le système de calcul intensif multitâche et multiflot en temps réel comprend au moins un bus système (SB), des entrées sorties (IOO,..., IOM-1), un coeur de processus central (SPP), chargé de l'exécution des traitements non critiques des tâches et du support du logiciel système, un ensemble de N unités de calcul auxiliaires (APU0, ..., APUN-1) optimisées pour le traitement rapide de certaines opérations, un espace mémoire (SMS) partagé par les unités de calcul auxiliaires (APU0, ..., APUN-1) via un réseau interne, une unité (ACU) de contrôle et d'allocation des ressources auxiliaires, pour gérer l'exécution en parallèle des traitements intensifs des unités de calcul auxiliaires (APU0, ..., APUN-1), et assurer la synchronisation entre les flots d'instructions et la gestion des contextes d'exécution des flots d'instructions. Les différents éléments constitutifs du système sont agencés de telle manière que la communication entre les différentes unités de calcul auxiliaires (APU0,..., APUN-1), entre ces unités de calcul auxiliaires (APU0,..., APUN-1) et le coeur de processeur central (SPP) ou les entrées-sorties (IO0,..., IOM-1), s'effectue par l'intermédiaire de l'espace mémoire partagé (SMS) et du réseau interne, sans passer par le bus système (SB).

Description

La présente invention a pour objet un procédé et un système de calcul

intensif multitâche et multiflot en temps réel.

L'invention s'applique plus particulièrement aux architectures embarquées multiprocesseurs. L'invention vise à proposer une solution de mise en oeuvre d'une architecture de traitement pour des systèmes disposant des propriétés suivantes : Forte puissance de calcul: la complexité des applications embarquées n'a de cesse de croître. Ceci s'explique notamment par la volonté d'intégrer toujours plus de fonctionnalités au sein des systèmes embarqués (association de fonctions multimédia, de jeu, de télécommunication et de positionnement dans un téléphone mobile) et à l'accroissement des volumes de données à traiter (capacités des capteurs vidéos, convertisseurs rapides, ...). Les systèmes embarqués se doivent en outre de pouvoir digérer concurremment plusieurs flots d'informations. Il est ainsi indispensable de collecter, distribuer et traiter efficacement toutes les informations des organes distribués dans le système. Cette nécessité de traiter concurremment plusieurs flots d'informations combinée à l'ouverture des systèmes se traduit également par des environnements d'exécution multitâches. ^ Flexibilité : Les systèmes visés se veulent ouverts. Ainsi, tout utilisateur du système est libre de l'utiliser à sa guise. L'architecture doit donc être suffisamment flexible pour supporter des scénarii d'utilisation très différents. Cette ouverture interdit des optimisations globales hors-ligne de l'architecture puisque le contexte applicatif ne peut être entièrement déterminé au moment de la phase de conception. D'autre part, si certaines classes d'algorithmes favorisent un découpage statique des traitements avec un contrôle simple du parallélisme (défini hors ligne), d'autres nécessitent un flot de contrôle dynamique, et cette tendance devrait aller en croissant avec la montée en complexité des applications embarquées. ^ Intégration poussée dans l'environnement : Les systèmes développés se doivent par ailleurs d'être profondément intégrés dans leur environnement. Cette intégration se traduit par des contraintes sévères de temps-réel, de consommation, de coût et de sûreté de fonctionnement ^ Hétérogénéité des traitements : Du fait de la diversité des applications ainsi que de la complication des flots de contrôle dans les systèmes embarqués, une très grande variété de types de traitements se doivent de cohabiter au sein des architectures embarquées. Ainsi, des tâches de calculs intensifs côtoient des tâches dominées par le contrôle, avec des interactions très fortes entre ces différents éléments des applications. En résumé, les systèmes embarqués ciblés disposent de fortes capacités à traiter les flux de données hétérogènes, de fortes possibilités d'adaptation dynamique à l'environnement et de bonnes capacités de communication adaptées à la demande. Ils sont par ailleurs fortement contraints par l'environnement extérieur (consommation, temps-réel, ...) et se veulent ouverts, c'est-à-dire qu'un même produit peut être destiné à plusieurs usages. Ceci inclut notamment les systèmes multiapplications au sein desquels des tâches peuvent être dynamiquement (c'est-à-dire lors de l'exécution) créées, suspendues, détruites, .... Dans de tels systèmes, il est problématique d'envisager une optimisation hors-ligne de l'architecture puisque l'impossibilité de déterminer précisément les scénarii d'utilisation induit une sous-utilisation des ressources. A l'inverse, il est préférable de privilégier une optimisation en-ligne de la structure de calcul éliminant la nécessité de prévoir l'ensemble des scénarii d'utilisation. L'impossibilité d'optimiser hors-ligne l'architecture impose cependant la mise en place de mécanismes de contrôle très coûteux en performance. L'objet de cette invention consiste à proposer une structure de calcul dans laquelle l'intégration des solutions de contrôle dynamique ne se fait pas au détriment des performances. Dans le cadre de la course à la performance, l'exploitation du parallélisme s'est historiquement attachée à proposer des solutions permettant de bénéficier du parallélisme au niveau opération au sein des applications. Malgré l'activité intense de la recherche autour de la définition d'architectures capables de gérer efficacement un fort degré de parallélisme au niveau instructions, on ne peut que constater les limites de ces approches. Dans le même temps, la complexité des systèmes embarqués rend extrêmement difficile ou peu efficace leur modélisation sous la forme d'un flot de contrôle unique. Ainsi, utilisateurs et concepteurs d'architecture s'accordent pour privilégier un parallélisme au niveau tâche. En conséquence, une tendance forte observée actuellement est l'intégration sur un même substrat silicium de plusieurs coeurs de processeurs, permettant l'exécution parallèle de tâches sur un même circuit.

Dans cette course à la performance, plusieurs solutions sont envisagées, classées selon la méthode employée pour exploiter le parallélisme. Les principaux modèles sont le multiflot simultané ou SMT (Simultaneous MultiThreading), les multiprocesseurs sur un seul composant ou CMP (Chip MultiProcessing), et les architectures de processeur multiflot ou CMT (Chip MultiThreading). La technique du multiflot simultané ou SMT est par exemple mise en oeuvre dans les dernières générations de processeurs Intel, IBM ou HP Alpha. Elle consiste à utiliser plusieurs compteurs de programmes, afin d'approvisionner les unités de calcul en instructions issues de plusieurs flots d'instructions. Les dépendances entre tâches étant limitées, le parallélisme au niveau des instructions ou ILP (Instruction Level Parallelism) vu par le processeur est accru et par voie de conséquence les performances du processeur le sont aussi. La mise en oeuvre de ces solutions est toutefois un exercice délicat et la complexité des étages de lecture et de distribution des instructions de ces solutions est très élevée. En conséquence, ces architectures conduisent à de très gros circuits, incompatibles avec les contraintes des systèmes embarqués, du fait notamment qu'ils exigent plus de 100 watts par composant. La Figure 1A est un schéma bloc illustrant le principe d'une architecture SMT du type multiflot simultané. Des unités fonctionnelles ou unités de calcul FU sont alimentées en traitement par une ressource de contrôle unique OS associée à un allocateur de tâche TD. A chaque cycle, le bloc de contrôle OS, TD assigne concurremment des instructions aux unités fonctionnelles FU en fonction de la disponibilité des données et des éventuels aléas de fonctionnement. Les unités fonctionnelles coopèrent avec un espace mémoire partagé sms.

La Figure 1B illustre un exemple de fonctionnement d'une unité fonctionnelle FU. Sur cette figure, chaque carré 1 représente une instruction et les traits noirs verticaux 2 représentent les tâches de contrôle et d'assignation des instructions.

Les carrés 3 marqués d'une croix correspondent à des tranches de temps non utilisées par les unités fonctionnelles pour cause de dépendances de données ou de ressources. La solution des multiprocesseurs unipuces (CMP) est générale-ment privilégiée dans les systèmes embarqués en raison de sa relative simplicité de mise en oeuvre. Le principe de cette solution est de distribuer concurremment des tâches aux ressources de calcul suivant leur disponibilité. Chaque ressource de calcul exécute alors les tâches qui lui sont assignées les unes à la suite des autres. Ces architectures se répartissent en deux familles, les structures homogènes et les structures hétérogènes : • Structures hétérogènes: ces structures intègrent des unités de calcul hétérogènes et optimisées pour un domaine applicatif donné, la distribution des tâches sur ces ressources étant préalablement identifiée au moment de la compilation. Le partitionnement logiciel réalisé à la compilation permet ainsi de simplifier les mécanismes de distribution (dynamique) des tâches au moment de l'exécution. Parmi ces solutions orientées application, se trouvent notamment les plateformes OMAP, VIPER, PNX ou Nomadik. • Structures homogènes: ces structures sont basées sur l'intégration d'unités de calcul homogènes. Ces unités peuvent être généralistes, comme dans les plateformes Cells de IBM ou MPCore de ARM, ou optimisées pour un domaine applicatif donné, à l'image du CT3400 de Craddle Technologies, optimisé pour le codage/décodage MPEG4-AVC. Les premières solutions permettent de cibler de très larges gammes de problématiques, alors que la seconde est optimisée pour un domaine applicatif bien identifié. La Figure 2A est un schéma-bloc illustrant le principe d'une architecture CMP du type multiprocesseurs unipuces. Les unités fonctionnelles ou unités de calcul FU qui coopèrent avec un espace mémoire partagé sms sont alimentées en traitements par une ressource de contrôle unique OS associée à un allocateur de tâche TD. L'unité de contrôle OS, TD se charge de déterminer les tâches prêtes à être exécutées. Dès qu'une ressource de calcul se libère, elle se voit assigner une tâche qui sera traitée dès la fin du chargement des données. Ces zones 4 figurent en hachures sur la Figure 2B qui illustre un exemple de fonctionnement d'une unité fonctionnelle FU, avec des carrés 1 représentant des instructions et des traits noirs verticaux 2 représentant des tâches de contrôle et d'assignation des instructions. Les architectures de processeurs multiflot du type CMT sont une combinaison des deux précédents modèles. Le concept des 10 multiprocesseurs unipuces CMP est étendu afin d'autoriser l'exécution de plusieurs tâches sur les primitives de calcul. Cette technologie est envisagée essentiellement dans le cadre de solutions de type serveur. La Figure 3A illustre un modèle générique d'architecture du type 15 CMT. Un ensemble d'unités fonctionnelles ou unités de calcul FU sont alimentées en traitement par une ressource de contrôle unique OS associée à un allocateur de tâche TD. Les unités fonctionnelles FU coopèrent avec un espace mémoire partagé sms. La Figure 3B illustre un exemple de fonctionnement d'une unité 20 fonctionnelle FU. L'unité de contrôle OS, TD se charge de déterminer les tâches prêtes à être exécutées. Dès lors qu'une ressource de calcul se libère, elle se voit assigner une tâche qui sera traitée dès le chargement des données réalisé. Ceci est représenté par les zones rayées 4 sur la Figure 3B, tandis 25 que les carrés 1 représentent des instructions et les traits noirs verticaux 2 représentent des tâches de contrôle et d'assignation des instructions. Chaque ressource de calcul peut gérer concurremment plusieurs tâches. Dès qu'une tâche est bloquée, par exemple à cause d'un défaut de cache, l'unité fonctionnelle FU la remplace par une nouvelle. Dans ce cas, 30 la commutation de tâche au sein de l'unité fonctionnelle ne se traduit pas par des pénalités de chargement de contexte. Malgré l'émulation autour de ces architectures misant sur le parallélisme de flots d'instructions (threads) pour accroître les performances, ces architectures, quelles soient de type SMT, CMP ou CMT, 35 ne répondent que partiellement à la problématique des systèmes embarqués. La principale cause à cet état de fait est l'absence de distinction entre les différentes classes de traitement cohabitant au sein d'une application. Ainsi, les traitements fortement dominés par le contrôle sont traités de manière équivalente, sur une même ressource de traitement, qu'un traitement régulier et critique du point de vue de son temps d'exécution. Les ressources de calcul devant alors supporter les traitements réguliers tout autant que les traitements très irréguliers, il en découle des systèmes construits sur des primitives de calcul non optimisées, et de ce fait en inadéquation avec les besoins applicatifs suivant trois aspects de la consommation électrique, du rapport coût/performance et de la sûreté de fonctionnement. Quelques solutions de type CMP conduisent toutefois à faire la distinction entre les traitements réguliers et irréguliers. Ces architectures intègrent dès lors des ressources de calcul dédiées à la mise en oeuvre des traitements intensifs. Les traitement irréguliers sont alors traités avec le logiciel système sur un processeur généraliste. Si l'intégration de ressources de calcul dédiées aux traitements intensifs autorise la mise en oeuvre d'optimisations permettant d'améliorer les performances ou encore l'efficacité énergétique de ces architectures, l'inefficacité des communications entre les tâches de traitement ainsi qu'entre les tâches de traitement et le logiciel système ou les traitement de contrôle fait perdre le bénéfice de ces optimisations au niveau système. Les communications entre les différents éléments de l'architecture se font en effet par l'intermédiaire de bus systèmes, s'accompagnant de fortes pénalités, tant au niveau des latences que des bandes passantes. De ce fait ces systèmes sont pénalisés par la latence accompagnant la transmission d'informations de contrôle et par le débit perturbant les transferts de données. Ces pénalités se traduisent par une réactivité plus faible de l'architecture et par une incapacité du logiciel système à optimiser l'utilisation des ressources de calcul.

Pour minimiser ce surcoût selon le document US2005/0149937A1, les mécanismes de synchronisation entre les ressources de calcul sont pris en charge par le biais d'une structure dédiée, mais il n'est plus apporté de solutions au problème de transfert de donnée entre ces tâches. Le document US2004/0088519A1, propose quant à lui une solution à la gestion d'un parallélisme de tâche dans le contexte des processeurs hautes performances mais la solution proposée ne peut pas s'appliquer aux systèmes embarqués, notamment pour des raisons de coût et de déterminisme. Les solutions développées actuellement pour exploiter un parallélisme au niveau tâche ne permettent donc pas de répondre à l'ensemble des contraintes mentionnées ci-dessus. Les solutions de type SMT sont par exemple typiquement basées sur des processeurs généralistes standard sur lesquels un étage de contrôle supplémentaire a été greffé. D'une part ces solutions ne résolvent pas les problèmes de consommation et de déterminisme inhérents aux processeurs généralistes actuels et d'autre part, elles ajoutent une complexité supplémentaire pour gérer concurremment plusieurs flots d'instructions. Malgré la variété de mise en oeuvre des architectures de type CMP, il est également difficile de retenir une solution répondant aux problématiques embarquées. D'une part les solutions orientées application ne disposent pas d'une flexibilité suffisante, et d'autre part les architectures plus généralistes ne proposent pas de solutions de calcul et restent basées sur des solutions coûteuses, développées pour les processeurs généralistes. De manière similaire, les solutions CMT, bien qu'étendant le parallélisme des architectures, ne permettent toujours pas de répondre aux exigences de consommation et demeurent confrontées aux problèmes de gestion de la cohérence des données et des communications dans le circuit. La présente invention vise à remédier aux inconvénients précités et notamment à permettre une très forte intégration des ressources de calcul dans un processeur. Ces buts sont atteints grâce à un système de calcul intensif multitâche et multiflot en temps réel, caractérisé en ce qu'il comprend au moins un bus système, des entrées-sorties, un coeur de processus central, chargé de l'exécution des traitements non critiques des tâches et du support du logiciel système, un ensemble de N unités de calcul auxiliaires optimisées pour le traitement rapide de certaines opérations, un espace mémoire partagé par les unités de calcul auxiliaires via un réseau interne, une unité de contrôle et d'allocation des ressources auxiliaires, pour gérer l'exécution en parallèle des traitements intensifs des unités de calcul auxiliaires, et assurer la synchronisation entre les flots d'instructions et la gestion des contextes d'exécution des flots d'instructions, et en ce que les différents éléments constitutifs du système sont agencés de telle manière que la communication entre les différentes unités de calcul auxiliaires, entre ces unités de calcul auxiliaires et le coeur de processeur central ou les entrées-sorties, s'effectue par l'intermédiaire de l'espace mémoire partagé et du réseau interne, sans passer par le bus système. Avantageusement, le système comprend en outre une mémoire de masse pour le stockage de l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires. Un contrôleur de mémoire principale peut être associé à la 10 mémoire de masse. Les unités de calcul auxiliaires peuvent comprendre des unités programmables, des unités reconfigurables et des unités dédiées. Le coeur de processeur central comprend une unité de contrôle, une unité de calcul, une unité de mémorisation et une unité de 15 chargement. A titre d'exemple, le système peut comprendre entre 4 et 8 unités de calcul auxiliaires qui à un instant ne traitent chacune qu'un flot d'instructions élémentaires faisant partie d'une tâche. Selon un mode particulier de réalisation, le système comprend 20 un arbitre de bus pour gérer la communication entre d'une part le bus système et d'autre part le coeur de processeur central ainsi que les entrées-sorties et la mémoire de masse. Selon une application particulière, le système comprend un ensemble de processeurs reliés à un bus système, chaque processeur 25 comprenant un coeur de processeur central, un ensemble de N unités de calcul auxiliaires, un espace mémoire partagé et une unité de contrôle et d'allocation des ressources auxiliaires. Le système peut comprendre un arbitre de bus système partagé entre plusieurs processeurs pour effectuer la liaison avec le bus système. 30 Le système peut encore comprendre une mémoire de masse partagée entre plusieurs processeurs. L'invention a encore pour objet un procédé de calcul intensif multitâche et multiflot en temps réel à l'aide d'au moins un processeur relié à un bus système et comprenant au moins un coeur de processeur 35 central, un ensemble de N unités de calcul auxiliaires, un espace mémoire partagé par les unités de calcul auxiliaires via un réseau interne, une unité de contrôle et d'allocation des ressources auxiliaires et des entrées-sorties, caractérisé en ce que le coeur de processeur central est chargé de l'exécution des traitements non critiques des tâches et du support du logiciel système tandis que les unités de calcul auxiliaire sont optimisées pour le traitement rapide de certaines opérations et l'unité de contrôle et d'allocation des ressources auxiliaires gère l'exécution en parallèle des traitements intensifs des unités de calcul auxiliaires et en ce que la communication entre les différentes unités de calcul auxiliaires, entre ces unités de calcul auxiliaires et le coeur de processeur central ou les entrées- sorties s'effectue par l'intermédiaire de l'espace mémoire partagé et du réseau interne, sans passer par le bus système. A un instant donné une unité de calcul auxiliaire ne traite qu'un flot d'instructions élémentaires faisant partie d'une tâche et chaque flot d'instructions élémentaires n'est exécuté que sur une seule unité de calcul auxiliaire. Avantageusement, l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires sont stockés dans une mémoire de masse. Selon une caractéristique particulière, l'accès du coeur du processeur central, des contrôleurs d'entrées-sorties et de la mémoire de masse au bus système est géré par un arbitre de bus. Une tâche allouée à la partie de traitement standard est traitée cycle par cycle sur cette même partie de traitement standard jusqu'à atteindre une instruction spécialisée qui est décodée et génère une commande en direction de l'unité de contrôle et d'allocation de manière à provoquer la création d'un flot d'instructions qui est exécuté sur l'une des unités de calcul sous la gestion de l'unité de contrôle et d'allocation tandis que, une fois l'instruction spécialisée décodée et la commande correspondante générée, l'exécution de la tâche en cours se poursuit dans la partie de traitement standard, sans intervention dans la gestion du flot d'instructions initié et exécuté sur une unité de calcul auxiliaire. En cas de déroutement pouvant intervenir suite à une exception, une interruption ou encore une trappe, on peut provoquer de façon sélective en fonction du type de déroutement, une synchronisation forte dans laquelle tous les composants du processus sont synchronisés.

En cas de déroutement pouvant intervenir suite à une exception, une interruption ou encore une trappe, on peut provoquer de façon sélective en fonction du type de déroutement, une synchronisation faible selon laquelle seul le contexte correspondant à la partie de traitement standard est synchronisé tandis que l'unité de contrôle et d'allocation de ressources auxiliaires continue de façon autonome une exécution des fonctions actives sur les unités de calcul auxiliaires. En cas de déroutement pouvant intervenir suite à un événement local au niveau d'une unité de calcul auxiliaire, on provoque de façon sélective une synchronisation locale selon laquelle l'unité de calcul auxiliaire concernée gère seule le déroutement et est synchronisée indépendamment du reste du processeur. A la différence des solutions existantes, l'invention intègre un nouveau mécanisme de couplage permettant une très forte intégration 15 des ressources de calcul dans le processeur. L'architecture du système selon l'invention intègre un premier sous-ensemble ou partie de traitement standard (SPP) qui constitue un coeur de processeur central et un deuxième sous-ensemble ou partie de traitement auxiliaire (APP) qui incorpore notamment les unités de calcul 20 auxiliaires ainsi que l'unité de contrôle et d'allocation des ressources auxiliaires et l'espace mémoire partagé. Ces deux sous-ensembles ont des propriétés et des fonctionnalités radicalement différentes mais pour autant participent à un même objectif, l'exécution d'une tâche. En conséquence, ces fonctionnalités sont 25 très fortement couplées, tant au niveau des données que du contrôle. D'autres caractéristiques et avantages de l'invention ressortiront de la description suivante de modes particuliers de réalisation, faite en référence aux dessins annexés, sur lesquels : - les Figures lA et 1B représentent respectivement un modèle 30 générique d'architecture SMT et un exemple de fonctionnement, - les Figures 2A et 2B représentent respectivement un modèle générique d'architecture CMP et un exemple de fonctionnement, - les Figures 3A et 3B représentent respectivement un modèle générique d'architecture CMT et un exemple de fonctionnement, - la Figure 4 représente symboliquement la décomposition d'un système en applications, puis en tâches et finalement en flots d'instructions ou threads, - la Figure 5 est un schéma-bloc montrant les éléments 5 principaux de l'architecture d'un processeur selon l'invention, - la Figure 6 est un schéma bloc montrant un mécanisme de couplage entre une partie de traitement auxiliaire et une partie de traitement standard, - la Figure 7 est un schéma montrant un mécanisme d'accès aux 10 données dans une partie de traitement auxiliaire, - la Figure 8 est un schéma montrant un mécanisme de transport de données entre une partie de traitement auxiliaire et une partie de traitement standard, - la Figure 9 est un schéma montrant un mécanisme de 15 transfert de données entre une partie de traitement standard et une partie de traitement auxiliaire, et - la Figure 10 est un schéma-bloc d'un exemple de système multiprocesseur à mémoire partagée mettant en oeuvre l'invention. On précisera d'abord en référence à la Figure 4 la 20 décomposition d'un système 10 en applications 11, 12, puis en tâches 21 à 25, et finalement en flots d'instructions ou threads 31 à 33. Un système embarqué 10 est typiquement susceptible de traiter plusieurs applications 11, 12 de manière concurrente. Une application fait référence à une fonctionnalité, un service offert par un système 25 embarqué. Toute application 11, 12 traitée sur un système embarqué peut alors se décomposer sous la forme de tâches 21 à 25 qui s'enchaînent les unes aux autres suivant des dépendances de contrôle exprimées dans l'application. Ces tâches 21 à 25 peuvent à leur tour être décomposées en opérations exécutées séquentiellement ou en threads parallèles 31 à 33 30 pour lesquels des exécutions concurrentes sont possibles. Dans la suite de la description, on utilisera ainsi le terme threads pour désigner un processus léger qui est un flot d'exécution partageant éventuellement l'intégralité de son espace d'adressage avec d'autres processus. 35 On a représenté sur la Figure 5 un exemple d'architecture de processeur conforme à l'invention, avec un premier sous-ensemble constitué par une partie de traitement standard SPP formant un coeur de processeur central, et un deuxième sous-ensemble constitué par une partie de traitement auxiliaire APP. D'une manière générale, la partie de traitement standard SPP se charge de l'exécution des tâches. Ceci inclut d'une part le traitement des instructions constituant le programme à traiter mais également le logiciel système. A la différence d'un processeur conventionnel, celui-ci est cependant capable de faire appel à des unités d'exécution auxiliaires APUO, APU1,..., APUN-2, APUN-1 incluses dans la partie de traitement auxiliaire APP pour traiter certaines portions applicatives nécessitant de très fortes puissances de calcul. L'invention met en oeuvre un procédé spécifique dans la façon de faire appel aux unités de calcul auxiliaires. La partie de traitement standard SPP se charge des calculs non spécialisés au sein des applications. Elle traite également le logiciel système gérant le partage des ressources et le contrôle des tâches. Elle est construite sur la base d'un processeur généraliste. Elle est donc classiquement basée sur quatre unités : 1. Unité de contrôle ESCU : cette unité se charge de la lecture et du décodage des instructions. La complexité de cette unité est variable. Elle est en effet susceptible de pouvoir gérer plusieurs instructions simultanément et de choisir les instructions prêtes à être exécutées, pour une exécution dite dans le désordre de l'application. Cette unité peut également intégrer un certain nombre de mécanismes permettant de prédire la direction des branchements. En fonction de l'instruction, cette unité envoie des commandes vers les autres unités de l'architecture. 2. Unité de calcul SPU : cette unité se charge de la réalisation des calculs standards identifiés par les instructions. Cette unité peut éventuellement intégrer plusieurs ressources de calculs si l'unité de contrôle ESCU peut gérer plusieurs instructions simultanément. 3. Unité de mémorisation : cette unité se charge du stockage des données et des instructions liées au programme. Cette unité peut être bâtie sur la base de deux niveaux de hiérarchies de mémoires cache suivant un modèle d'exécution Harvard et avec un cache de niveau 2 unifié.

Cette unité de mémorisation comprend alors des mémoires caches L1 D-Cache et L1 I-Cache de niveau 1 et une mémoire cache L2-Cache de niveau 2. 4. Unité de chargement LSU : L'unité de chargement se charge de faire le lien entre les données stockées dans la mémoire et les unités manipulées parl'unité de calcul SPU. Ce lien un matérialisé par une file de registre dont le nombre de ports varie en fonction du nombre d'instructions traitées par cycle. Pour fournir un couplage très étroit entre la partie de traitement standard SPP et la partie de traitement auxiliaire APP, quelques particularités sont apportées à l'unité de contrôle ESCU et à l'unité de chargement LSU par rapport à un coeur de processeur central classique. Ainsi, l'unité de contrôle ESCU comprend des instructions supplémentaires pour contrôler la partie de traitement auxiliaire APP. Ces instructions permettent par exemple de demander l'exécution d'un traitement critique. L'unité de chargement LSU intègre pour sa part une file de registre supplémentaire. En plus de la file de registre générale classique, une seconde file de registre est intégrée à l'unité de chargement LSU.

Celle-ci permet des échanges entre les deux sous-ensembles SPP et APP. D'un point de vue structurel, il n'existe pas de différence, du point de vue de l'unité de chargement LSU entre cette file de registre auxiliaire ARF et la file de registre générale GPRF (voir Figures 8 et 9). Le processeur distingue les registres généraux des registres auxiliaires grâce à leur adresse. Il est à noter que ce mode de communication entre les deux sous-ensembles SPP et APP convient particulièrement bien aux transferts de données peu volumineuses. La partie auxiliaire APP prend en charge les calculs spécialisés et/ou intensifs de l'application. Elle intègre plusieurs unités APUO, APU1,...

APUN-2, APUN-1 de calcul auxiliaire partageant un unique espace mémoire SMS. Le nombre N d'éléments de calcul auxiliaires APUO,... APUN-1 ne fait l'objet d'aucune limitation particulière. De même, ces éléments de calcul qui, dans la suite, ne seront pas distingués les uns des autres et seront simplement notés APU, pourront indifféremment être construits sur la base d'une logique synchrone ou asynchrone. La partie de traitement auxiliaire APP se prête donc particulièrement bien à la mise en place de structures du type GALS (Globalement Asynchrone et Localement Synchrone). Une partie auxiliaire APP contiendra typiquement de 4 à 8 éléments de calcul APU. A un instant donné, une unité de calcul auxiliaire APU ne traite qu'un thread et un thread n'est exécuté que sur une unité de calcul auxiliaire APU. Dans ce document, on appelle thread, un bloc d'instructions élémentaire, faisant partie d'une tâche. Un thread est assigné aux unités de calcul auxiliaires APU par l'unité d'allocation et de contrôle ACU incluse dans la partie auxiliaire APP suite à des demandes d'exécution issues de l'unité de contrôle ESCU.

L'allocation physique des threads aux unités de calcul auxiliaires APU ainsi que la gestion de leur exécution et la synchronisation entre différents threads sont à la charge de cette unité d'allocation et de contrôle ACU. La partie de traitement auxiliaire APP intègre également des contrôleurs d'entrées/sorties IO dits temps critiques. Ceux-ci sont directement liés aux périphériques d'entrées/sorties temps-critiques. Ces derniers peuvent par exemple correspondre à des convertisseurs Analogique-Numérique rapides, à des interfaces Radio Fréquence, des capteurs vidéo ... Ces M contrôleurs d'entrée/sortie IO0 à I0M-1 sont considérés par l'unité de contrôle et d'allocation ACU comme des unités de calcul auxiliaires APU. L'unité de contrôle et d'allocation ACU se doit alors d'assigner une tâche au contrôleur d'entrée/sortie pour charger celui-ci de gérer l'accès à l'entrée/sortie. Les données émises ou reçues sont en provenance ou à destination de l'espace mémoire partagé SMS. Les entrées/sorties moins critiques, comme par exemple celles correspondant à un clavier ou une souris, sont en revanche connectées par des moyens plus standards, tels que le bus système SB, à la partie de traitement standard SPP. La partie de traitement auxiliaire APP peut encore contenir une mémoire de masse MM afin de stocker l'ensemble des données et des programmes manipulés par les unités de calcul APU. Cette mémoire MM dispose par ailleurs de son propre contrôleur MMC sur lequel l'unité de contrôle et d'allocation ACU alloue des threads de transfert de données entre le système (matérialisé sur la Figure 5 par le bus système SB) et les threads de calcul intensif. Ce contrôleur MMC intervient également lors des transferts de données entre l'espace mémoire partagé SMS et la mémoire de masse MM.

Les unités de calcul auxiliaires APU sont optimisées pour le traitement rapide de certaines opérations. Elles peuvent offrir différents compromis entre performance, flexibilité, coût ou consommation en fonction de leur type. La sélection de tel ou tel type d'unité de calcul est alors fortement influencée par le contexte applicatif. Les unités de calcul auxiliaires peuvent comprendre des unités programmables, des unités reconfigurables ou des unités dédiées. Unités programmables : ce type d'unité correspond à des coeurs de processeurs génériques (MIPS, ARM, etc...) ou optimisés (DSP, ST2)o, etc...) pour le calcul embarqué. Ces unités étant optimisées pour le calcul, elles voient leurs structures de contrôle simplifiées, par exemple en éliminant les mécanisme de prédiction de branchement, de gestion d'interruptions ou de virtualisation des données. Ces unités peuvent par ailleurs intégrer des unités de calcul spécialisées comme des unités flottantes et/ou vectorielles. Unités reconfigurables : des unités reconfigurables sont également susceptibles d'être utilisées en tant qu'accélérateur de calcul. Des structures de gros grain sont privilégiées du fait de leur capacité à être reconfigurées rapidement, et du bon compromis performance/flexibilité quelles peuvent offrir. Des structures de grain fin peuvent également être intégrées si une grande souplesse d'utilisation est nécessaire ou si des opérations travaillant sur des données de très petites tailles (1 à 4 bits) sont susceptibles d'être traitées. En raison de leur très faible réactivité, c'est-à-dire des très longs temps de reconfiguration, ces ressources de grain fin sont susceptibles d'être gérées différemment, par exemple afin d'éviter leur préemption. Unités dédiées : des unités optimisées pour certains traitements critiques peuvent finalement être intégrées au composant. Ces accélérateurs dédiés prennent en charge les traitements critiques, pour lesquels des solutions programmables ou reconfigurables n'offrent pas de puissance de calcul suffisante. Des traitements de cryptographie ou de gestion de flux d'entrées/sorties à très fortes cadences sont par exemple de bons candidats à de telles implémentations. Quel que soit leur type, les unités de calcul auxiliaires APU sont par ailleurs susceptibles de contenir des ressources de stockage privées. Celles-ci peuvent être utilisées soit pour stocker des données intermédiaires afin de faciliter leur accès et de minimiser la bande passante sur l'espace mémoire partagé, soit pour stocker les instructions du programme en cours d'exécution. Les programmes susceptibles d'être exécutés pourraient par ailleurs également être stockés localement afin d'accélérer les phases d'allocation de tâches. Les deux sous-ensembles SPP et APP se partagent un accès au reste du système. Le medium de communication est alors le bus système SB et le partage de cette ressource est géré par un arbitre de bus SBA. Deux éléments peuvent nécessiter un accès au bus système dans la partie de traitement auxiliaire APP, la mémoire principale et les contrôleurs d'entrées/sorties I0. Du point de vue de la partie de traitement standard SPP, cet accès au bus système SB est utilisé pour charger la mémoire cache L2-Cache par des données ou des instructions provenant de la mémoire de masse MM ou d'éléments périphériques. En cas de demandes d'accès simultanées de plusieurs éléments du processeur, l'arbitre de bus SBA séquence les demandes d'accès afin de garantir l'unicité des communications sur le bus système SB. En fonction du contexte applicatif, la bande passante requise pour chacun de ces éléments va significativement varier. Ainsi différentes variantes de ce schéma peuvent être envisagées pour des domaines applicatifs dans lesquels plusieurs éléments sont simultanément susceptibles de requérir une forte bande passante. Il est ainsi possible d'envisager d'autres schémas dans lesquels un second (voire un troisième) bus système serait ajouté afin d'offrir une bande passante suffisante à tous les éléments du système. Lorsqu'une tâche est allouée à la partie de traitement standard SPP, par le logiciel système exécuté sur cette même partie SPP, celle-ci déroule son programme de manière tout à fait conventionnelle pour un processeur programmable. Le traitement des instructions se réalise cycle après cycle jusqu'à atteindre une instruction spécialisée. Lorsque celle-ci est décodée par l'unité de contrôle ESCU, une commande est générée en direction de l'unité de contrôle et d'allocation ACU, provoquant éventuellement la création d'un thread devant être exécuté sur l'une des unités de calcul APU. Dans un tel cas de figure, l'unité de contrôle et d'allocation ACU se chargera alors de la gestion de l'exécution de celui-ci.

Il est à noter que ce modèle d'exécution est adapté à un modèle de programmation dans lequel l'activation de threads de calcul se fait par appel à des fonctions optimisées dans une bibliothèque. Cette approche, déjà largement employée dans le domaine du logiciel embarqué, correspond par exemple à l'utilisation d'instructions AltiVec ou MMX dans les processeurs généralistes. Une fois l'instruction spécialisée traitée par l'unité de contrôle ESCU, la partie de traitement standard SPP poursuit l'exécution du programme, sans intervenir dans la gestion du thread initié sur la partie de traitement auxiliaire APP. L'exécution du programme se poursuit donc jusqu'à son terme ou le traitement de nouvelles instructions spécialisées, pouvant provoquer entre autre la création ou la destruction de threads, la lecture de données générées dans la partie de traitement auxiliaire APP, ... En cas de déroutement, pouvant intervenir suite à une exception, une interruption ou encore une trappe, trois comportements sont envisageables : 1. Synchronisation forte : tous les composants du processeur sont synchronisés (pour les deux sous-ensembles APP et SPP). Cette phase de synchronisation pouvant être longue, des mécanismes de synchronisations partielles pourront être définis afin de réduire ces pénalités dans le cadre d'un fonctionnement multitâches. Le contenu de la mémoire de masse pourrait par exemple être maintenu quelques temps afin d'accélérer le prochain changement de contexte, à la manière d'un cache de victime. 2. Synchronisation faible : Seul le contexte correspondant à la partie de traitement standard SPP est synchronisé. Dans ce cas de figure, les fonctions actives sur les unités de calcul auxiliaires APU sont maintenues sur la partie de traitement auxiliaire APP. L'unité ACU de contrôle et d'allocation de ressources auxiliaires se charge seule de leur exécution. Ce fonctionnement autonome peut ainsi perdurer tant que le thread ne fait pas appel à des informations produites ou maintenues par la partie standard de la tâche (celle traitée par la partie de traitement standard SPP). 3. Synchronisation locale : En cas de déroutement intervenant suite à un événement local à une unité de calcul auxiliaire APU, par exemple, division par zéro, celle-ci peut gérer seule le déroutement et ainsi être synchronisée indépendamment du reste du processeur. L'unité d'allocation et de contrôle ACU se charge d'exécuter les instructions spécialisées issues de l'unité de contrôle ESCU. Le détail de ce couplage permettant à l'unité de contrôle ESCU de communiquer avec l'unité d'allocation et de contrôle ACU est modélisé sur la Figure 6. On voit ainsi sur la Figure 6 l'unité de contrôle ESCU, l'unité de chargement LSU et l'unité de calcul SPU de la partie de traitement standard SPP, ainsi qu'une partie de l'unité de mémorisation L1 I-Cache.

La Figure 6 montre également l'unité de contrôle et d'allocation ACU faisant partie de la partie de traitement auxiliaire APP. Les instructions standard de la partie de traitement standard SPP sont lues puis décodées, respectivement dans les étages de lecture et de décodage de l'unité de contrôle ESCU, afin de commander l'unité de chargement LSU et l'unité de calcul SPU. A l'inverse, dans le cas d'instructions spécialisées, l'unité de contrôle ESCU redirige le flot de commandes vers l'unité d'allocation et de contrôle ACU. Ces instructions spécialisées peuvent être de différentes natures et concerner par exemple : - la création/suppression de threads, - la suppression des threads associés à une tâche, - le transfert de données de la mémoire principale MM vers le bus système SB ou vice-versa, - le transfert de données entre les sous-ensembles SPP et APP.

En allouant une tâche à la partie de traitement standard SPP, le logiciel système réalise une allocation virtuelle des threads aux unités de calcul auxiliaires APU. C'est ensuite à l'unité de contrôle et d'allocation ACU de réaliser physiquement cette allocation et de prendre en compte l'ensemble des paramètres permettant de déterminer la meilleure allocation possible. Outre l'allocation, l'unité de contrôle et d'allocation ACU gère également les synchronisations entre les threads ainsi que les accès aux ressources critiques partagées. Cette unité de contrôle et d'allocation ACU peut également se charger de fournir un support au logiciel système, par exemple en gérant seule les préemptions ou en se chargeant de la mise à jour des listes des tâches.

De par ces fonctions, l'unité de contrôle et d'allocation ACU se doit de disposer du contexte d'exécution de chacun des threads en cours d'exécution sur la partie de traitement auxiliaire APP. En effet, lors d'une synchronisation faible, l'unité de contrôle et d'allocation ACU est seule responsable de l'évolution des threads. En conséquence, lorsque la tâche est réallouée à la partie de traitement standard SPP, il est nécessaire de l'informer sur l'état d'avancement des threads de calcul. Ceci permet en effet à la partie de traitement standard SPP de ne pas réactiver des threads non terminés, mais en cours d'exécution sur la partie de traitement auxiliaire APP. La disponibilité d'un contexte local dans l'unité de contrôle et d'allocation ACU permet de garantir un état cohérent lorsqu'une tâche est allouée sur le processeur. Ceci est d'autant plus vrai si les tâches sont exécutées dans le désordre sur la partie de traitement standard SPP.

En dehors de ces services de base, l'unité de contrôle et d'allocation ACU pourra également prendre en charge des fonctions plus spécifiques aux domaines applicatifs. Parmi ces fonctions on peut citer la gestion dynamique de la puissance, la gestion des pannes ou encore la gestion des modes de crise .

Toutes les données manipulées au sein des unités de calcul auxiliaires APU sont stockées dans un espace mémoire partagé SMS. Cet espace mémoire partagé SMS est constitué de multiples ressources de mémorisation et d'un réseau d'interconnexion permettant de réunir toutes ces ressources au sein d'un seul et même espace. Un contrôleur d'espace mémoire MSC se charge d'établir un lien entre les ressources de calcul et les ressources de mémorisation. L'unité de contrôle et d'allocation ACU est par ailleurs utilisée pour fournir certaines informations permettant de faire le lien entre les adresses virtuelles dans l'espace mémoire partagé, manipulées par les unités de contrôle auxiliaires APU, (correspondant au nom d'une variable ainsi qu'à une position dans cette variable, par exemple nom d'image et indice de pixel) et l'adresse physique devant être propagée jusqu'à la ressource de mémorisation utilisée. Le mécanisme d'accès aux données est illustré par la Figure 7 pour un transfert de données opérant entre une unité de calcul auxiliaire APU producteur notée APUP et une unité de calcul auxiliaire APU consommateur notée APU. Ce mécanisme d'accès aux données dans la partie de traitement auxiliaire APP se décompose en deux étapes, identifiées par les cercles 1 et 2 sur cette Figure 7. La première phase d'un accès à une donnée n'est réalisée que lorsqu'une unité de calcul auxiliaire APU accède pour la première fois à une variable. Dans ce cas de figure, il n'existe pas de lien entre la donnée et la mémoire qui la contient. Pour obtenir cette information, l'unité de calcul APU interroge l'unité de contrôle et d'allocation ACU. Celle-ci intègre une unité de gestion d'espace mémoire MSMU réalisant cette fonction en associant au nom d'une variable la mémoire qui la stocke. Lorsque la donnée est identifiée dans cette unité, l'unité de gestion MSMU renvoie vers l'unité l'identifiant de la mémoire stockant la variable. A l'inverse, lorsqu'une unité de calcul APU tente d'écrire une donnée qui n'est pas référencée (lors de la première écriture de cette variable par exemple), l'unité de gestion MSMU se charge de lui allouer une mémoire parmi les éléments de mémorisation disponibles dans l'espace mémoire partagé SMS. Une fois la mémoire allouée, l'unité associant au nom d'une variable la mémoire qui la stocke est mise à jour et l'identifiant de la mémoire est renvoyé vers l'unité de calcul APU. Lorsqu'une unité de calcul APU tente de lire une donnée qui n'est pas référencée (lors de la première écriture de cette variable par exemple), l'unité de gestion MSMU se charge de la rapatrier (en lien avec le contrôleur de mémoire principale MMC,) et de lui allouer une mémoire parmi les éléments de mémorisation disponibles dans l'espace mémoire partagé SMS. Lorsqu'une donnée est écrite définitivement (résultat final), l'entrée correspondante dans l'unité associant au nom d'une variable la mémoire qui la stocke est libérée et une requête est transmise au contrôleur de mémoire principale MMC pour rapatrier cette donnée dans la mémoire de masse. La seconde phase de l'accès aux données est quant à elle systématiquement réalisée puisqu'elle permet de faire le lien entre l'unité de calcul APU et la mémoire contenant la donnée. Lorsque l'unité de calcul APU connaît la mémoire à laquelle elle souhaite accéder, elle transfère, dans le même temps de cycle que l'adresse de la donnée recherchée et les signaux de contrôle de la mémoire, cette information au contrôleur de l'espace mémoire partagé SMS. Le contrôleur d'espace mémoire MSC se charge alors d'acheminer ces signaux (puis les données en retour) vers la mémoire adéquate. En fonction du type de structure retenue pour interconnecter les ressources de mémorisation, ce service peut être différent. Dans le cadre d'un réseau sur puce tel que celui modélisé sur la Figure 7, ce contrôleur d'espace mémoire MSC servira à mettre en paquet les données, c'est-à-dire à rajouter aux données les informations de routage dans le réseau. Dans le cadre d'un réseau point à point de type crossbar, le contrôleur d'espace mémoire MSC se chargera de la configuration matérielle du chemin à emprunter. Il est à noter que la gestion des adresses de données au niveau des unités de calcul auxiliaires APU est assurée par des blocs d'entrée/sortie spécifiques, éventuellement capables de gérer des flux de données plus complexes et des communications par rafales (burst) par exemple. Ainsi, ces éléments de gestion de données se chargent d'aller récupérer les données manipulées par les unités de calcul APU. Si l'accès aux données est impossible ou ralenti, ces modules de contrôle peuvent geler l'exécution du thread sur l'unité de calcul auxiliaire APU, afin d'éviter que celle-ci tente de manipuler une donnée non stable. En fonction du domaine applicatif et de l'espace mémoire partagé SMS qui en découle, il est possible que des conflits apparaissent en cours d'exécution, suite à un nombre de demandes d'accès à une donnée Nbaccess supérieur au nombre Nbports de ports de la mémoire ou d'un noeud du réseau. Ce ralentissement possible doit alors être pris en compte lors du dimensionnement du système sachant que le temps d'accès à la mémoire Taccess devant être considéré sera donné par l'équation (1) : Nbpnr! (1) où Nbaccess représente le nombre d'accès, Nbport représente le nombre de ports de l'espace mémoire partagé SMS ou 30 d'un noeud du réseau, Tmem représente le temps d'accès mémoire minimum. Afin de minimiser ce surcoût, il est possible d'accroître virtuellement le nombre de ports de lecture de la mémoire en dupliquant les données dans différents bancs mémoire et ainsi permettre plusieurs 35 accès simultanés. Un compromis entre temps d'écriture et temps de lecture des données devra alors être déterminé par l'utilisateur afin Tàcces = Tmem x Sep Nb Access d'optimiser les performances globales du système. Il est à noter que lors d'un tel conflit, aucune politique de priorité particulière des accès n'est mise en oeuvre. Une solution simple de type FIFO remplira par exemple très bien cette fonction de gestion des conflits et permettra de garantir un temps d'accès maximum aux mémoires. On notera que la structure mémoire utilisée est intéressante car les données sont liées à une structure mémoire et non à un élément de calcul. La préemption peut donc être réalisée très rapidement car un changement de contexte n'implique pas nécessairement de transfert de données entre ressources de calcul. Des données de faible volume peuvent être échangées entre la partie de traitement auxiliaire APP et la partie de traitement standard SPP, comme illustré sur la Figure 5. Ces transferts de données sont explicités directement dans le programme source qui intègre des instructions permettant d'identifier : - la direction du transfert de la partie de traitement auxiliaire APP vers la partie de traitement standard SPP ou vice versa, - le registre câblé dans la partie standard, - le thread câblé dans la partie de traitement auxiliaire, 20 - la donnée du thread. Ainsi la lecture de l'instruction LOAD Rx, Ty, Rz de l'exemple illustré sur la Figure 8 permet de charger dans le registre Rx de la partie de traitement standard SPP, la variable Rz du thread Ty exécuté sur la partie de traitement auxiliaire APP. Lorsque l'unité de contrôle ESCU 25 décode cette instruction, elle se doit de générer trois commandes : 1. Read(Rz) : cette commande conduit la lecture dans chacune des unités de calcul auxiliaires APU de la variable Rz de l'unité de calcul auxiliaire APU. 2. Search(Ty) : cette commande est envoyée à l'unité de contrôle et 30 d'allocation ACU pour identifier l'unité de calcul APU qui exécute le thread Ty. Cette identification est réalisée au moyen d'un cache de la table de pages ou TLB (Translation Look-aside Buffer) associant à chaque thread actif sur l'unité de contrôle et d'allocation ACU, l'unité de calcul APU qui l'exécute. Ce TLB se doit de disposer 35 d'autant d'entrées que l'unité de contrôle et d'allocation ACU peut gérer de threads. Si ce TLB ne renvoie pas d'identifiant d'unité de calcul APU, le thread n'est pas en cours d'exécution et la tâche en cours d'exécution sur la partie de traitement standard SPP est en attente. Si le thread est en cours d'exécution, le TLB renvoie l'identifiant de l'unité de calcul APU qui l'exécute. Cet identifiant est utilisé au niveau de la partie de traitement standard SPP pour sélectionner la donnée devant être envoyée vers la file de registre auxiliaire de cette partie de traitement auxiliaire SPP. Cet identifiant peut également être utilisé au niveau des unités de calcul APU pour valider ou non la lecture des données dans la file de registre partagé SRF. 3. Write(Rx) : cette commande conduit l'écriture dans le registre Rx de la file de registre auxiliaire de la donnée renvoyée par la partie de traitement auxiliaire APP. On notera que l'envoi de la commande APUi aux unités de calcul auxiliaires APUO, APU1,..., APUN-2, APUN-1 est facultatif et peut être éliminé sans perturber le mode de transfert. Il permet cependant d'éviter des accès aux files de registres inutiles. Un mécanisme dual permet bien entendu de transférer des données depuis la partie de traitement standard SPP jusqu'à la partie de traitement auxiliaire APP. Ce mécanisme est représenté sur la Figure 9, qui est similaire à la Figure 8, mais avec la substitution des instructions STORE Rx, Ty, Rz, Write(Rz) et Read(Rx) respectivement aux instructions LOAD Rx, Ty, Rz, Read(Rs) et Write(Rx). Les accès au bus système se font par le biais de la mémoire principale MM. Le contrôleur de mémoire principale MMC, l'unité d'allocation et de contrôle ACU et le contrôleur d'espace mémoire MSC peuvent intervenir dans le contrôle de ces communications, en fonction du type de communication mis en oeuvre. Ainsi la mémoire principale MM intervient dans quatre types de communications : 1. Bus système SB - mémoire principale MM : Ce premier type de transfert permet de rapatrier des données depuis l'extérieur du système vers la mémoire principale MM de la partie de traitement auxiliaire APP. Ces transferts interviennent suite au décodage d'une instruction spéciale dans l'unité de contrôle ESCU. Cette instruction spéciale provoque la création d'une opération de transfert de données qui sera assignée par l'unité de contrôle et d'allocation ACU au contrôleur de mémoire principale MMC. Le comportement de celui-ci sera alors comparable à celui d'un contrôleur DMA (d'accès direct à la mémoire). Dans le même temps, le contrôleur de mémoire principale MMC renseigne une table qui lui permettra de faire le lien entre la donnée chargée et sa position dans la mémoire principale MM. 2. Mémoire principale MM - bus système SB : D'une manière symétrique, les données sont transférées depuis la mémoire principale MM vers le reste du système suite à l'arrivée d'une opération de transfert identifiée par des instructions spéciales au niveau de l'unité de contrôle ESCU. Les envois depuis la mémoire principale MM peuvent par ailleurs se traduire par une destruction d'une entrée dans la table de correspondance si cette donnée était un résultat final. Ceci suppose que les instructions spéciales décodées par l'unité de contrôle ESCU autorisent la distinction entre transfert destructif et non destructif. 3. Mémoire principale MM -> espace mémoire partagé SMS : Si une unité de calcul APU tente d'accéder à une donnée non présente dans l'espace mémoire partagé SMS, une requête de transfert est transmise par l'unité de contrôle et d'allocation ACU au contrôleur MMC, afin d'acheminer cette donnée dans l'espace mémoire partagé SMS. L'unité de calcul auxiliaire APU est alors bloquée le temps du transfert. 4. Espace mémoire partagé SMS -> mémoire principale MM : Ces transferts font suite à des transferts de données spéciaux des unités de calcul APU qui spécifient l'écriture d'un résultat final, c'est-à-dire qui n'est pas voué à être relu dans la partie de traitement auxiliaire APP, dans l'espace mémoire partagé SMS. Ces transferts peuvent également intervenir en cas de synchronisation forte dans le cadre d'une sauvegarde de contexte. Dans ce cas de figure, l'espace mémoire partagé SMS envoie une requête de transfert par l'intermédiaire de l'unité de contrôle et d'allocation ACU au contrôleur de mémoire principale MMC. En fonction des domaines applicatifs ciblés, il est possible que l'intégration d'une mémoire de masse soit inutile. Ce cas de figure correspond au cas où la mémoire de masse MM est intégrée dans l'espace mémoire partagé SMS au même titre que n'importe quelle ressource de mémorisation. Le procédéselon la présente invention, de même que l'architecture qui permet sa mise en oeuvre sont extensibles, c'est-à-dire qu'ils peuvent supporter un nombre variable d'unités de calcul APU. Dans la pratique, les performances de l'architecture sont cependant susceptibles de subir une certaine dégradation lorsque le nombre d'unités de calcul APU est trop grand, par exemple de l'ordre de plusieurs centaines.

Une façon de résoudre ce problème consiste à adopter l'architecture d'un système multiprocesseur à mémoire partagée. Un exemple d'une telle réalisation est représenté sur la Figure 10 qui ne montre à titre d'exemple que l'association de deux processeurs conformes à l'invention, mais pourrait naturellement comprendre un plus grand nombre de processeurs associés dont tous les coeurs disposent de la même organisation, centrée sur le couplage d'une partie de traitement standard SPP et d'une partie auxiliaire de calcul APP, comme décrit précédemment, notamment en référence à la Figure 5. Toutefois, dans le cas d'un système multiprocesseur à mémoire partagée, il est avantageux de partager certains éléments tels que l'arbitre du bus système SBA ou la mémoire de masse MM des parties de traitement auxiliaires APP, comme représenté sur la Figure 10, ou encore des contrôleurs d'entrée/sortie rapides, ceux-ci pouvant également être partagés entre les coeurs par l'intermédiaire de bus dédiés.

En résumé, l'invention concerne essentiellement un dispositif et un procédé de contrôle et d'allocation de threads sur une architecture embarquée avantageusement multiprocesseur dédiés au calcul intensif multitâche et multiflot en temps réel. De façon plus particulière, l'architecture de calculateur parallèle 30 temps réel comprend : - un coeur de processeur central SPP chargé de l'exécution des traitements non critiques des tâches et du support du logiciel système, - des unités de calcul auxiliaires APU programmables, reconfigurables ou dédiées optimisées pour le traitement rapide de 35 certaines opérations, - un espace mémoire partagé SMS par les unités de calcul auxiliaires APU via un réseau interne, - une unité ACU de contrôle et d'allocation des ressources auxiliaires, qui gère l'exécution des traitements intensifs des unités de calcul auxiliaire APUi en parallèle, - des entrées sorties I0. De façon plus particulière, la communication entre les différentes unités de calcul auxiliaire APU, entre les unités de calcul APU et le coeur de processeur central SPP ou une entrée sortie IO se fait par l'intermédiaire de l'espace mémoire partagé SMS et d'un réseau interne et non pas via le bus système SB. Le procédé d'allocation et de traitement des tâches permet de séparer les tâches de contrôle exécutées par le coeur de processeur central SPP, des tâches de calcul intensif, exécutées par les unités de calcul APU spécialisées. L'unité de contrôle et d'allocation ACU gère l'allocation des tâches de calcul intensif pour les différentes unités de calcul APU travaillant en parallèle. Ce contrôleur auxiliaire ACU permet la mise en oeuvre de mécanismes de synchronisation dits faibles grâce auxquels les unités de calcul APU peuvent traiter des threads d'une tâche différente de celle exécutée sur le coeur du processeur central SPP. L'état du système n'est alors plus représenté par un contexte unique, à l'inverse d'une architecture Von Neuman. Les entrées/sorties temps-critiques sont directement reliées à l'espace mémoire partagé par les unités de calcul APU. Cette architecture et ce procédé d'allocation permettent un traitement multitâches temps réel optimisé, c'est-à-dire avec une diminution des temps de chargements de données, et adaptable à différentes applications.

Claims (18)

REVENDICATIONS

1. Système de calcul intensif multitâche et multiflot en temps réel, caractérisé en ce qu'il comprend au moins un bus système (SB), des entrées sorties (I0), un coeur de processus central (SPP), chargé de l'exécution des traitements non critiques des tâches et du support du logiciel système, un ensemble de N unités de calcul auxiliaires (APUO,

., APUN-1) optimisées pour le traitement rapide de certaines opérations, un espace mémoire (SMS) partagé par les unités de calcul auxiliaires (APUO, APUN-1) via un réseau interne, une unité (ACU) de contrôle et d'allocation des ressources auxiliaires, pour gérer l'exécution en parallèle des traitements intensifs des unités de calcul auxiliaires (APUO, ..., APUN-1), et assurer la synchronisation entre les flots d'instructions et la gestion des contextes d'exécution des flots d'instructions, et en ce que les différents éléments constitutifs du système sont agencés de telle manière que la communication entre les différentes unités de calcul auxiliaires (APUO,..., APUN-1), entre ces unités de calcul auxiliaires (APUO,..., APUN-1) et le coeur de processeur central (SPP) ou les entrées-sorties (I0), s'effectue par l'intermédiaire de l'espace mémoire partagé (SMS) et du réseau interne, sans passer par le bus système (SB)...CLMF:

2. Système selon la revendication 1, caractérisé en ce qu'il comprend en outre une mémoire de masse (MM) pour le stockage de l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires (APUO,..., APUN-1).

3. Système selon la revendication 2, caractérisé en ce qu'il comprend un contrôleur de mémoire principale (MMC) associé à la 30 mémoire de masse (MM).

4. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les unités de calcul auxiliaires (APUO,..., APUN-1) comprennent des unités programmables, des unités reconfigurables et des 35 unités dédiées.

5. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le coeur de processeur central (SPP) comprend une unité de contrôle (ESCU), une unité de calcul (SPU), une unité de mémorisation (L1 D-Cache, L1 I-Cache, L2-Cache) et une unité de chargement (ELSU).

6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend entre 4 et 8 unités de calcul auxiliaires (APUO,... APUN-1) qui à un instant ne traitent chacune qu'un lot d'instructions élémentaires faisant partie d'une tâche.

7. Système selon la revendication 2 ou la revendication 3, caractérisé en ce qu'il comprend un arbitre de bus (SBA) pour gérer la communication entre d'une part le bus système (SB) et d'autre part le coeur de processeur central (SPP) ainsi que les entrées-sorties (I0) et la mémoire de masse (MM).

8. Système selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comprend un ensemble de processeurs reliés à un bus système (SB), chaque processeur comprenant un coeur de processeur central (SPP), un ensemble de N unités de calcul auxiliaires (APUO,..., APUN-1), un espace mémoire partagé (SMS) et une unité (ACU) de contrôle et d'allocation des ressources auxiliaires.

9. Système selon la revendication 8, caractérisé en ce qu'il comprend un arbitre de bus système (SBA) partagé entre plusieurs processeurs pour effectuer la liaison avec le bus système (SB).

10. Système selon la revendication 8 ou la revendication 9, 30 caractérisé en ce qu'il comprend une mémoire de masse (MM) partagée entre plusieurs processeurs.

11. Procédé de calcul intensif multitâche et multiflot en temps réel à l'aide d'au moins un processeur relié à un bus système (SB) et 35 comprenant au moins un coeur de processeur central (SPP), un ensemble de N unités de calcul auxiliaires (APUO,... APUN-1), un espace mémoire(SMS) partagé par les unités de calcul auxiliaires (APUO,... APUN-1) via un réseau interne, une unité (ACU) de contrôle et d'allocation des ressources auxiliaires et des entrées-sorties (I0), caractérisé en ce que le coeur de processeur central (SPP) est chargé de l'exécution des traitements non critiques des tâches et du support du logiciel système tandis que les unités de calcul auxiliaire (APUO,..., APUN-1) sont optimisées pour le traitement rapide de certaines opérations et l'unité (ACU) de contrôle et d'allocation des ressources auxiliaires gère l'exécution en parallèle des traitements intensifs des unités de calcul auxiliaires (APUO,..., APUN-1) et en ce que la communication entre les différentes unités de calcul auxiliaires (APUO,..., APUN-1), entre ces unités de calcul auxiliaires (APUO,..., APUN-1) et le coeur de processeur central (SPP) ou les entrées-sorties (I0) s'effectue par l'intermédiaire de l'espace mémoire partagé (SMS) et du réseau interne, sans passer par le bus système (SB).

12. Procédé selon la revendication 11, caractérisé en ce que à un instant donné une unité de calcul auxiliaire (APUO,..., APUN-1) ne traite qu'un flot d'instructions élémentaires faisant partie d'une tâche et chaque flot d'instructions élémentaires n'est exécuté que sur une seule unité de calcul auxiliaire (APUO,..., APUN-1).

13. Procédé selon la revendication 11, caractérisé en ce que l'ensemble des données et des programmes manipulés par les unités de calcul auxiliaires (APUO,..., APUN-1) sont stockés dans une mémoire de masse (MM).

14. Procédé selon la revendication 13, caractérisé en ce que l'accès du coeur du processeur central (SPP), des contrôleurs d'entrées-sorties (I0) et de la mémoire de masse (MM) au bus système (SB) est géré par un arbitre de bus (SBA).

15. Procédé selon l'une quelconque des revendications 11 à 14, caractérisé en ce qu'une tâche allouée à la partie de traitement standard (SPP) est traitée cycle par cycle sur cette même partie de traitement standard (SPP) jusqu'à atteindre une instruction spécialisée qui est décodée et génère une commande en direction de l'unité de contrôle etd'allocation (ACU) de manière à provoquer la création d'un flot d'instructions qui est exécuté sur l'une des unités de calcul (APUO,..., APUN-1) sous la gestion de l'unité de contrôle et d'allocation (ACU) tandis que, une fois l'instruction spécialisée décodée et la commande correspondante générée, l'exécution de la tâche en cours se poursuit dans la partie de traitement standard (SPP), sans intervention dans la gestion du flot d'instructions initié et exécuté sur une unité de calcul auxiliaire.

16. Procédé selon la revendication 15, caractérisé en ce que en cas de déroutement pouvant intervenir suite à une exception, une interruption ou encore une trappe, on provoque de façon sélective en fonction du type de déroutement, une synchronisation forte dans laquelle tous les composants du processus sont synchronisés.

17. Procédé selon la revendication 15 ou la revendication 16, caractérisé en ce que en cas de déroutement pouvant intervenir suite à une exception, une interruption ou encore une trappe, on provoque de façon sélective en fonction du type de déroutement, une synchronisation faible selon laquelle seul le contexte correspondant à la partie de traitement standard est synchronisé tandis que l'unité (ACU) de contrôle et d'allocation de ressources auxiliaires continue de façon autonome une exécution des fonctions actives sur les unités de calcul auxiliaires.

18. Procédé selon l'une quelconque des revendications 15 à 17, caractérisé en ce que en cas de déroutement pouvant intervenir suite à un événement local au niveau d'une unité de calcul auxiliaire, on provoque de façon sélective une synchronisation locale selon laquelle l'unité de calcul auxiliaire concernée gère seule le déroutement et est synchronisée indépendamment du reste du processeur.