FR 3001816 A1 20140808 FR 1300232 A 20130205 Système de processeur multi-utilisateurs de traitement d'informations La présente invention concerne un système de processeur multi-utilisateurs de traitement d'informations. Plus particulièrement, l'invention se rapporte à de tel système qui comporte un moteur d'échange de données associé à des utilisateurs multiples de ressources partagées. Ainsi, l'invention se place principalement notamment dans le domaine des coeurs numériques de traitement de données de type processeurs, multiprocesseurs, unités de contrôle, microcontrôleurs, etc. En particulier, un tel système de processeur multi-utilisateurs peut être utilisé en association avec des équipements mis en oeuvre dans des systèmes aéronautiques comme par exemple appliqués à de l'avionique embarquée. On sait que des études sont déjà menées depuis quelque temps pour améliorer la prédictibilité de fonctionnement des systèmes de cette nature. En effet, le contexte actuel correspond à un besoin de traitement prédictible par exemple du point de vue temporel, des transactions ou des échanges de données dans des ressources ou des zones partagées telles que par exemple des mémoires ou encore des entrées/sorties entre plusieurs utilisateurs ou initiateurs. Le but de l'invention est d'améliorer ce type de systèmes en s'appuyant sur une organisation temporelle robuste des transactions et des échanges et les mécanismes associés en garantissant un partage équitable des ressources partagées tout en maintenant la prédictibilité des accès. A cet effet, l'invention a pour objet un système de processeur multi-utilisateurs de traitement d'informations, du type comportant un moteur d'échange de données associé à des utilisateurs multiples de ressources partagées, caractérisé en ce qu'il comporte des moyens de contrôle des échanges de données dans le processeur, associés à chaque utilisateur, au moteur d'échange et aux ressources partagées, pour autoriser ou non des transactions et en ce que le moteur comporte des moyens de décomposition des transactions autorisées en sous-transactions élémentaires, des moyens d'entrelacement des sous-transactions obtenues à partir de la décomposition des transactions autorisées de plusieurs utilisateurs et des moyens de distribution de ces sous-transactions entrelacées entre les différentes ressources. Selon d'autres caractéristiques prises seules ou en combinaison du système suivant l'invention : - les moyens de décomposition comprennent des moyens de découpage des transactions selon leur taille et/ou leur type et/ou le nombre de ressources, identiques ou différents par utilisateur et/ou entre ceux-ci ; - les moyens de distribution comprennent de moyens de répartition des sous transactions entrelacées entre les ressources ; - les sous-transactions entrelacées sont distribuées/réparties dans chaque file d'attente associée à chaque ressource partagée ; - le moteur comporte des moyens d'insertion d'une transaction de substitution à une transaction non autorisée ou absente ; -le moteur comporte des moyens d'insertion d'une sous-transaction de substitution à une sous-transaction absente ; - le moteur comporte des moyens de surveillance de la bonne exécution des sous-transactions pour valider la bonne exécution de la transaction correspondante ; - le moteur est adapté pour répartir les sous-transactions entre les ressources de façon équilibrée ou non ; - le moteur est adapté pour répartir les sous-transactions entre les ressources de façon programmable en fonction de la configuration spatio-temporelle de raccordement des utilisateurs et/ou des ressources partagées ; - les moyens d'entrelacement des sous-transactions et de distribution de ces sous- transactions entrelacées répondent soit à une loi statique et/ou à une loi configurable et/ou à une loi évolutive en fonction du temps et/ou du comportement interne du moteur d'échange. L'invention sera mieux comprise à l'aide de la description qui va suivre donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés, sur lesquels : - la figure 1 représente un schéma synoptique illustrant la structure et le fonctionnement d'un système de processeur multi-utilisateurs de traitement d'informations selon l'invention, et - les figures 2 à 9 illustrent différents cas de fonctionnement d'une telle structure de processeur. On a en effet illustré sur ces figures et en particulier sur la figure 1, un schéma synoptique général illustrant la structure d'un système de processeur multi-utilisateurs de traitement d'informations. Celui-ci se place alors entre différents utilisateurs désignés par la référence générale 1 sur cette figure 1 et des ressources partagées désignées par la référence générale 2. En fait, ce système de processeur multi-utilisateurs de traitement d'informations peut comporter ce qui peut être appelé un moteur d'échange de données, désigné par la référence générale 3 sur cette figure 1, qui est donc placé entre des utilisateurs multiples et des ressources partagées. Dans l'exemple illustré, le moteur 3 est en fait un dispositif de gestion de transactions concurrentes qui proviennent de différents utilisateurs 0 à n, en direction ou à destination de différentes ressources partagées 0 à m. Ce dispositif garantit alors un partage équitable en termes de bande/débit des ressources partagées pour les utilisateurs, tout en rendant prédictibles le temps et la durée de leurs accès. Ce moteur comporte alors des moyens de contrôle des échanges de données dans le processeur, associés à chaque utilisateur, au moteur d'échange et aux ressources partagées pour autoriser ou non des transactions. Ceci vient en fait comme cela est connu par ailleurs d'un contrat d'autorisation/insertion de trames (ou/et de transactions). Ces moyens formant moteur sont désignés par la référence générale 4 sur cette figure 1 et comprennent alors des unités de filtrage et de gestion des utilisateurs, des cartographies spatio-temporelles d'utilisateurs, etc., permettant d'assurer un partage équitable (ou non) des ressources partagées afin de maintenir la prédictibilité de la durée des accès et donc la prédictibilité du fonctionnement d'un tel système, en autorisant ou non des transactions. En plus de ces éléments, le moteur comporte également des moyens de décomposition des transactions autorisées en sous-transactions élémentaires, des moyens d'entrelacement des sous-transactions obtenues à partir de la décomposition des transactions autorisées de plusieurs utilisateurs et des moyens de distribution de ces sous-transactions entrelacées entre les différentes ressources. Ainsi, sur cette figure 1, les moyens de décomposition des transactions autorisées en sous-transactions élémentaires sont désignés par la référence générale 5, et les moyens d'entrelacement des sous-transactions obtenues à partir de la décomposition des transactions autorisées de plusieurs utilisateurs, sont désignés par la référence générale 6, ces moyens comportant également des moyens de distribution de ces sous-transactions entrelacées entre les différentes ressources et plus particulièrement les différentes files d'attente associées à celles-ci, telles que désignées par la référence générale 7 sur cette figure 1. Ces moyens 6 d'entrelacement des sous-transactions et de distribution de ces sous-transactions entrelacées répondent alors par exemple soit à une loi statique et/ou à une loi configurable et/ou à une loi évolutive en fonction du temps et/ou du comportement interne du moteur d'échange. Comme cela sera décrit plus en détail par la suite, le moteur comporte des moyens d'insertion d'une transaction de substitution à une transaction non autorisée ou absente et des moyens d'insertion d'une sous-transaction de substitution à une sous- transaction absente. En fait et pour mieux faire ressortir le fonctionnement d'un tel système, on a décrit en regard de la figure 2, un exemple d'une mise en oeuvre de transactions selon une configuration à quatre utilisateurs, quatre sous-transactions et deux ressources partagées. Les quatre utilisateurs sont désignés par utilisateur 0, 1, 2 et 3 sur cette figure 2. Les transactions correspondantes sont désignées par transaction A, B, C et D. La première opération consiste alors à découper chaque transaction en sous-transactions désignées par exemple par (sous-)transaction A(0), A(1), A(2), A(3) pour la transaction A. Les autres transactions B, C et D sont découpées de la même façon en sous-transactions correspondantes. Comme cela sera décrit plus en détail par la suite, ce découpage est alors réalisé selon la taille de ces transactions et/ou leur type et/ou le nombre de ressources partagées disponibles (raccordées), et peut se traduire par des découpages identiques ou différents par utilisateur et/ou entre ceux-ci. Une fois ces sous-transactions obtenues par décomposition des transactions autorisées à partir des différents utilisateurs, ces sous-transactions sont d'une part entrelacées et d'autre part distribuées entre les ressources partagées disponibles par exemple 0 et 1. Ainsi, par exemple les moyens de distribution peuvent comporter des moyens de distribution/répartition des sous-transactions dans chaque file d'attente associée à chaque ressource partagée, comme par exemple les files associées aux ressources partagées 0 et 1 illustrées sur cette figure 2. Chaque groupe de sous-transactions ainsi créé, est alors relatif à une ressource partagée physique et il y a alors dans l'exemple décrit sur cette figure 2, deux files d'attente, c'est-à-dire une file par ressource partagée. Les files contiennent alors une répartition des sous-transactions comme cela est illustré, cette répartition pouvant être équilibrée ou non entre ces files, c'est-à-dire entre ces ressources partagées. D'ailleurs le moteur peut être adapté pour répartir les sous-transactions entre les ressources de façon programmable en fonction de la configuration spatio-temporelle des raccordements des utilisateurs et/ou des ressources partagées. Sur la figure 3, on a illustré une situation dans laquelle l'utilisateur 1 réalise une transaction de taille intermédiaire. Cet utilisateur voit alors sa transaction autorisée traduite en sous-transactions actives et en sous-transactions non-actives (non-opérationnelle) de type NOP. Ainsi, le moteur d'échange peut être équipé de moyens d'insertion d'une sous-transaction de substitution à une sous-transaction absente. De même ce moteur peut comporter des moyens d'insertion d'une transaction de substitution à une transaction non autorisée ou absente. Ceci est également illustré par exemple sur la figure 4, qui représente le cas où l'utilisateur 3 ne réalise pas de transaction, ce qui implique notamment la création et l'insertion de sous-transaction NOP de substitution. La figure 5 illustre quant à elle le cas de figure où l'architecture est surdimensionnée en termes de ressources partagées. Dans cet exemple, le nombre de ressources partagées, r, est de 3, le nombre de sous-transactions caractérisant les transactions, n, est limité à 4. r n'étant pas le plus petit sous multiple de n, ceci implique au cours des phases d'entrelacement et de distribution décrites précédemment, des insertions de sous-transactions de type NOP afin de garantir l'équité des accès aux ressources partagées. En termes d'accès elles correspondent alors au même type de transactions décrites précédemment. Ainsi et dans cet exemple illustré sur la figure 5, les lignes 5, 6, 7 et 8 des files d'attente des ressources partagées 1 et 2, contiennent des sous-transactions de type NOP de substitution. La figure 6 représente le cas de figure où l'utilisateur 0 réalise une transaction de type lecture (LOAD). Les premières sous-transactions à exécuter correspondent à LOAD A(0), LOAD A(1) et LOAD A(2). Au stade illustré sur la figure, aucune de ces sous-transactions n'est achevée. La figure 7 représente la situation de terminaison de ces trois sous-transactions. Mais la transaction n'est pas considérée comme achevée, car seules ses trois premières sous-transactions le sont. Par conséquent, il est nécessaire d'achever les sous-transactions des lignes 2, 3 et 4 des files d'attente associées (cf. figure 6). Ceci est illustré sur la figure 8, qui présente l'initiation des trois premières sous-transactions de l'utilisateur 1. La figure 9 représente quant à elle une initiation des trois premières sous-transactions de l'utilisateur 2. Cette procédure est répétée. Lorsque les sous-transactions LOAD A(3), LOAD A(4) et LOAD A(5) sont initiées, les bits de validité et de statut des sous-transactions LOAD A(0), LOAD A(1), et LOAD A(2), sont maintenus à l'état haut. Ainsi, il est possible au moteur de mettre en oeuvré des moyens intégrés de surveillance de la bonne exécution des sous-transactions pour valider la bonne exécution de la transaction correspondante. Ainsi l'unité d'exécution des transactions est par exemple observable et comporte éventuellement des moyens d'autocontrôle de bon fonctionnement intégrés. Sur les différentes figures annexées et en particulier sur la figure 1, on a utilisé les termes Al pour désigner des interfaces d'accès (également connus sous l'expression anglaise « Acces Interface »), EAC pour désigner des contrôleurs d'accès d'échange (également connus sous l'expression anglaise « Exchanger Access Check ») et EAD pour désigner des décodeurs d'accès d'échange (également connus sous l'expression anglaise « Exchanger Access Decoder »). Au cours d'un accès, chaque utilisateur présente en effet les attributs de sa transaction à son EAD. Chaque utilisateur n'accède qu'à un seul EAD qui lui est propre. Chaque EAD réalise séquentiellement deux opérations à savoir : - le décodage de la transaction, et - la décomposition de celle-ci en sous-transactions. Lors de la phase de décodage de la transaction, des descripteurs sont générés désignant chacun : - soit un type de transaction du même type que la transaction initiée par l'utilisateur, - soit une information indiquant que l'utilisateur ne réalise aucune transaction. Ce cas de figure se présente toutes les fois où un utilisateur ne réalise pas de transaction. Une transaction de substitution est alors utilisée. La décomposition en sous-transactions est initiée à l'issue de la phase de décodage. Lorsque le descripteur de transaction (ou de non transaction) est généré, celui-ci permet de définir les sous-transactions. En effet, chaque transaction est fragmentée par l'EAD en sous-transactions de taille sous multiple de la taille maximale de la transaction dont elles sont issues. Ceci est réalisé en cohérence avec la largeur du bus de données de l'utilisateur et éventuellement du nombre de ressources partagées disponibles. L'ensemble de ces sous-transactions forme un ensemble cohérent en termes d'adressage, de type de transaction et de taille totale de données émises/reçues. Le nombre de sous-transactions associé à chaque taille de transaction dépend comme cela a été indiqué précédemment, de la taille de largeur du bus de données et du nombre de ressources partagées. La sous-transaction correspond à la plus petite taille de transaction possible du point de vue de l'utilisateur. Ainsi, la taille des sous-transactions est un sous multiple de la transaction dont elle dérive. Dans le cadre d'une transaction de taille maximale, la transaction est décomposée en sous-transactions de taille sous multiple de la taille maximale de la transaction dont elles sont issues. Comme indiqué précédemment ceci est réalisé en cohérence avec la largeur du bus de données de l'utilisateur. Leur nombre dépend également du nombre de ressources partagées mises à disposition. Dans le cas où l'utilisateur n'effectue aucune transaction, un descripteur est généré au cours de la phase de décodage et indique qu'aucune transaction n'est effectuée. Ceci se traduit par la génération de sous-transactions particulières à savoir les NOP de substitution et n'implique aucun échange de données. Elles n'ont pour but que de garantir l'équité entre les utilisateurs même en cas de non échange. Ainsi le nombre maximum de NOP pour une transaction correspond au nombre maximum de sous-transactions possible pour une transaction de l'utilisateur. Si la plus grande transaction possible se décompose au maximum en quatre sous-transactions et si l'utilisateur ne réalise aucune transaction, ceci se traduira par la génération de quatre NOP de substitution par exemple. Dans le cas d'une transaction de taille intermédiaire, l'utilisateur réalise une transaction de taille intermédiaire, c'est-à-dire que la taille de sa transaction n'est pas nulle et ne correspond pas à la plus grande taille de transaction possible. Pour les transactions de taille intermédiaire, deux types de sous-transactions peuvent être mises en oeuvre. Une partie des sous-transactions peut être de taille sous multiple de la taille de la transaction dont elles sont issues et l'autre partie peut correspondre à des NOP de substitution, les autres transactions NOP permettront d'aligner le nombre de sous-transactions au nombre de sous-transactions nécessaire pour la réalisation d'une transaction de taille maximale afin de garantir un accès équitable aux ressources, par les différents utilisateurs. Les moyens d'entrelacement et de distribution des sous-transactions ont pour rôle d'entrelacer les requêtes de sous-transactions et de les distribuer dans chaque file d'attente associée à chaque ressource partagée. Chaque ressource partagée dispose en effet d'une file d'attente où est stockée la liste des requêtes à réaliser. En effet, une fois entrelacées, les sous-transactions sont organisées en groupes. Chaque groupe est associé à un et seulement un des contrôleurs de la ressource partagée. Les sous-transactions d'un même groupe sont exécutées les unes après les autres. Ainsi, les sous-transactions distribuées entre les différents contrôleurs de ressources sont exécutées en parallèle. C'est ce qui est illustré sur la figure 2, qui représente un exemple de distribution des sous-transactions pour une configuration à quatre utilisateurs 0, 1, 2, 3, et pour deux ressources partagées 0 et 1. Cette figure présente une situation où l'ensemble des utilisateurs réalise des transactions au même instant, et de même taille (la plus grande à l'occurrence). Deux étapes s'ajoutent à celles présentées sur les figures 2 à 5. En effet, une fois les sous-transactions réalisées dans le cadre d'une transaction par exemple de type « LOAD », il est nécessaire de reconstruire la donnée lue. En effet, la donnée est fragmentée en éléments de données dont le nombre correspond au nombre de sous-transactions effectives. Lorsque la dernière sous-transaction (NOP compris dans le cas d'une transaction de taille intermédiaire) est achevée, un signal est transmis à l'unité de terminaison de cette transaction LOAD, pour indiquer que l'ensemble des sous-transactions associées à cette transaction est achevé et que les données sont prêtes à être récupérées. Dès réception de ce signal, l'unité de terminaison de la transaction LOAD reconstruit la donnée issue des données obtenues par les sous-transactions et la transmet à l'utilisateur. Une fois la donnée reconstruite transmise à l'utilisateur, l'unité de terminaison de cette transaction confirme la fin de la transaction de l'utilisateur. Dans le cas d'une transaction de ce type, le groupe d'unités d'exécution des transactions reconstruit la donnée à partir des données obtenues par les sous- transactions issues de la transaction LOAD. Une fois la donnée reconstruite, elle est transmise à l'Al associé de l'utilisateur ayant réalisé cette transaction. Une transaction LOAD peut être considérée comme localement achevée lorsque tous les détails de validité et de statut sont à l'état haut. Dès que cette situation se présente des fragments de données sont transmis séquentiellement à l'utilisateur/initiateur de la transaction. Ainsi, les bits de validité et de statut associés aux dernières sous-transactions de la même transaction, ne passent à l'état haut qu'une fois toutes les sous-transactions exécutées. Les transactions A4 et A5 ne sont pas prises en compte car dans le cas de figure décrit, il s'agit de sous-transactions NOP. Ce n'est qu'à cet instant que les données deviennent disponibles et sont transmises séquentiellement à l'utilisateur. Lorsque l'utilisateur aura transmis son signal d'acquittement il sera autorisé à initier une nouvelle transaction. Le champ de « Drapeau d'utilisateur » (User Flag) de cet utilisateur sera alors réinitialisé. On conçoit alors qu'un tel système permet d'améliorer encore la prédictibilité de réalisation de ce type de transactions et donc de fonctionnement de ce type de système de façon générale. Bien entendu d'autres modes de réalisation encore peuvent être envisagés. REVENDICATIONS1.- Système de processeur multi-utilisateurs de traitement d'informations, du type comportant un moteur (3) d'échange de données associé à des utilisateurs multiples (1) de ressources partagées (2), caractérisé en ce qu'il comporte des moyens (4) de contrôle des échanges de données dans le processeur, associés à chaque utilisateur, au moteur d'échange et aux ressources partagées, pour autoriser ou non des transactions et en ce que le moteur comporte des moyens (5) de décomposition des transactions autorisées en sous-transactions élémentaires, des moyens (6) d'entrelacement des sous-transactions obtenues à partir de la décomposition des transactions autorisées de plusieurs utilisateurs et des moyens (6) de distribution de ces sous-transactions entrelacées entre les différentes ressources. 2.- Système de processeur multi-utilisateurs de traitement d'informations selon la revendication 1, caractérisé en ce que les moyens (5) de décomposition comprennent des moyens de découpage des transactions selon leur taille et/ou leur type et/ou le nombre de ressources, identiques ou différents par utilisateur et/ou entre ceux-ci. 3.- Système de processeur multi-utilisateurs de traitement d'informations selon la revendication 1 ou 2, caractérisé en ce que les moyens (6) de distribution comprennent de moyens de répartition des sous transactions entrelacées entre les ressources. 4.- Système de processeur multi-utilisateurs de traitement d'informations selon la revendication 2 ou 3, caractérisé en ce que les sous-transactions entrelacées sont distribuées/réparties dans chaque file d'attente (7) associée à chaque ressource partagée. 5.- Système de processeur multi-utilisateurs de traitement d'informations selon l'une quelconque des revendications précédente, caractérisé en ce que le moteur comporte des moyens d'insertion d'une transaction de substitution (NOP) à une transaction non autorisée ou absente. 6.- Système de processeur multi-utilisateurs de traitement d'informations selon l'une quelconque des revendications précédente, caractérisé en ce que le moteur comporte des moyens d'insertion d'une sous-transaction de substitution (NOP) à une sous-transaction absente. 7.- Système de processeur multi-utilisateurs de traitement d'informations selon l'une quelconque des revendications précédente, caractérisé en ce que le moteur comporte des moyens de surveillance de la bonne exécution des sous-transactions pour valider la bonne exécution de la transaction correspondante. 8.- Système de processeur multi-utilisateurs de traitement d'informations selon l'une quelconque des revendications précédente, caractérisé en ce que le moteur est adapté pour répartir les sous-transactions entre les ressources de façon équilibrée ou non. 9.- Système de processeur multi-utilisateurs de traitement d'informations selon l'une quelconque des revendications précédente, caractérisé en ce que le moteur est adapté pour répartir les sous-transactions entre les ressources de façon programmable en fonction de la configuration spatio-temporelle de raccordement des utilisateurs (1) et/ou des ressources partagées (2). 10.- Système de processeur multi-utilisateurs de traitement d'informations selon la revendication 9, caractérisé en ce que les moyens (6) d'entrelacement des sous-transactions et de distribution de ces sous-transactions entrelacées répondent soit à une loi statique et/ou à une loi configurable et/ou à une loi évolutive en fonction du temps et/ou du comportement interne du moteur d'échange.15