FR 2925719 A1 20090626 FR 0709043 A 20071221 1 ARCHITECTURE HAUT DEBIT PAR MULTIPLEXAGE DE FONCTIONS L'invention concerne une architecture permettant le traitement multicanaux ou multi trames, par multiplexage de fonctions. Dans le cas de traitement multi-canaux ou multi-trames, ou de manière plus générale, pour des applications qui ont besoin de ressources, l'architecture retenue habituellement consiste à dupliquer le nombre de composants fonctionnels traitant unitairement l'opération par le nombre de canaux ou de trames devant être traitées de façon simultanée. Cette approche nécessite donc soit une puissance de calcul importante soit un ensemble important de ressources. De fait, cette approche limite souvent le début de l'application aux ressources disponibles de l'équipement concerné. Or dans de nombreux cas d'application, les ressources de l'équipement sont limitées (consommation électrique, encombrement, dissipation de la chaleur, etc.) et il n'est pas possible de multiplier à l'infini le nombre de composants fonctionnels. Cela conduit donc dans la majorité des cas à trouver un compromis où le débit de l'application s'en trouve diminué. La présente invention concerne une nouvelle architecture capable d'optimiser les capacités de traitement en fonction des besoins d'une application donnée. Elle permet aussi de définir une capacité de contrôle et d'ajustement du flux de données à la demande. L'architecture selon l'invention présente notamment les avantages suivants : l'optimisation d'une fonction particulière afin qu'elle traite plusieurs flux et la mise à disposition de plusieurs fonctions appelantes utilisant cette ressource. L'invention concerne une architecture permettant de traiter en parallèle 30 plusieurs flux de données caractérisée en ce qu'elle comporte en combinaison au moins les éléments suivants : 2 • Une interface de gestion, reliée à un séquenceur interprétant des requêtes en provenance d'une interface de requêtes transmettant ces dernières à une mémoire des requêtes, le séquenceur générant des commandes vers une interface de sortie et aiguillant des données à traiter vers des blocs de traitement et des fonctions de traitement, • Les blocs de traitement et les fonctions de traitement étant configurables suivant une application donnée et étant disposés en parallèle les uns des autres, • Une mémoire reçoit les données issues des blocs de traitement et les transmettant à l'interface de sortie, • Une deuxième mémoire disposée entre la sortie des fonctions de traitement et des blocs de traitement, • Une interface d'entrée, recevant des informations en provenance du séquenceur et permettant d'initialiser suivant l'application les blocs et les fonctions de traitement. D'autres caractéristiques et avantages apparaîtront à la lecture de la description détaillée donnée à titre d'exemple et non limitative qui suit faite en regard de dessins annexés qui représentent : o La figure 1, un schéma d'architecture selon l'invention, o La figure 2, un exemple de mise en oeuvre de l'architecture de la figure 1, la génération d'un aléa haute définition I-ID pour étalement de spectre radio, et o La figure 3 représente une application pour chiffreur d'artère haut débit. Les numéros identiques sur les figures 1, 2 et 3 désignent les mêmes éléments. Pour optimiser une fonction particulière afin qu'elle traite plusieurs flux et 3o permettre à plusieurs fonctions appelantes utilisant cette ressource, une 3 solution exécutée grâce à l'architecture selon l'invention consiste notamment à: 1 û découper le traitement à réaliser en plusieurs étages, au moins deux étages, pouvant être connectés de manière simple , 2 û optimiser indépendamment les fonctions, en terme de rapidité de traitement, de compacité et de contrôle de flux, et 3 û contrôler le type de flux à la demande. La figure 1 représente un exemple d'architecture selon l'invention. Cette architecture est articulée autour d'un séquenceur 2 dédié au contrôle des différentes unités de traitement appelées � bloc de fonctions � et d'une interface de contrôle destinée à la gestion 1 (initialisation, alarme, mode manuel, test, autre) par une unité externe. L'architecture décrite à la figure 1 comporte les éléments suivants : Une interface de gestion 1, reliée à un séquenceur 2 coeur de l'architecture selon l'invention qui interprète les requêtes en provenance d'une interface de requêtes 3 transmettant ces dernières à une mémoire des requêtes 4, le séquenceur 2 génère des commandes 5 vers une interface de sortie 6 et aiguille les données vers des blocs de traitement 7n et des fonctions de traitement 8n. Les blocs de traitement 7n et les fonctions de traitement 8n sont configurables suivant l'application et servent à réaliser un ou des traitements spécifiques dont certains sont donnés à titre d'illustration. Un bloc de traitement est par exemple un module adapté au chiffrement ou au déchiffrement par un algorithme de cryptographie. Pour la fonction de traitement il est possible de mettre en oeuvre une fonction de pré-traitement des données. A titre d'exemple pour une fonction cryptographie AES en mode compteur, la fonction de traitement correspond à un incrément de la donnée et au niveau du bloc de traitement c'est l'algorithme de cryptographie AES qui est utilisé. Selon un autre exemple, la fonction de traitement peut être choisie parmi les fonctions suivantes : bijection/surjection/injection. Une première mémoire de type pipeline 9 reçoit les données issues des 5 blocs de traitement 7n et les transmet à l'interface de sortie 6. Une deuxième mémoire de type pipeline 10 est disposée entre la sortie des fonctions de traitement 8n et les blocs de traitement 7n. Cette deuxième mémoire reçoit les sorties des fonctions de traitement précitées. La commande est une étiquette plus connue sous l'acronyme anglo-saxon 10 � tag � sur les données de sorties. Elle permet d'identifier les données de sortie indépendamment du bloc de traitement utilisé. Ce � tag � permet notamment d'utiliser les ressources suivant la disponibilité des blocs de traitement et non d'allouer un bloc de traitement spécifique à une tâche. Un � tag � peut être une heure / un type de donnée / un numéro etc... 15 Une interface d'entrée 11, reçoit des informations en provenance du séquenceur 2. Cette interface d'entrée 11 permet notamment d'initialiser suivant le besoin les blocs et les fonctions de traitement. Une mémoire 12 est interposée entre l'interface d'entrée 11 et le séquenceur 2 et les fonctions de traitement 8n. 20 L'architecture décrite à la figure 1 permet notamment de traiter deux types de flux de données. Des flux directs pour lesquels les données arrivent par l'interface d'entrée. Des flux avec ajustement qui requièrent l'utilisation de deux interfaces. Une même interface de commandes qui génère des 25 informations type de flux, mode, test ou autre concernant les données disponibles sur l'interface de sortie. Ceci permet de � classer � le flux sortant. Une deuxième interface qui est l'interface de requêtes. Les demandes sont introduites sur l'interface de requêtes et sont acheminées vers une mémoire de requêtes. Ces demandes sont assez précises et 30 peuvent être adaptées au besoin (type de flux, contexte à utiliser, mode, ou tout autre demande susceptible d'être émise par une application utilisant l'architecture selon l'invention). La figure 2 représente un exemple d'utilisation de l'architecture décrite à la 5 figure 1 pour la génération d'aléa haute définition ou HD utilisé pour l'étalement de spectre radio. L'interface de gestion 1 est utilisée pour initialiser le bloc de traitement 7i. Cette initialisation comporte la configuration et l'injection de clés. Dans cet exemple, l'interface de gestion 1 est utilisée pour initialiser et 10 contrôler l'ensemble du composant. Elle réalise par exemple : 1. la configuration du bloc et/ou la configuration des fonctions de traitement 8n, 2. l'injection de clés/paramètres, 3. la gestion des modes de fonctionnement du système, 15 4. le contrôle et commande. L'interface d'entrée 11 sert à configurer et à initialiser la fonction de traitement flèche F2. Deux cas de figure peuvent être envisagés au niveau de l'interface d'entrée 11, par exemple. Dans un premier cas, Cas 1 : elle permet de gérer dans le flux le type de 20 traitement grâce à un � tag � sur les données d'entrée qui permet : 1. d'initialiser dynamiquement les blocs et/ou fonctions de traitement avant traitement 2. de définir le type de flux à générer Dans un deuxième cas, Cas 2 : elle sert uniquement d'initialisation 25 dynamique des blocs de traitement et/ou des fonctions de traitement et l'interface de requêtes est utilisée pour définir le type de flux à générer Le séquenceur 2 est informé en temps réel de la disponibilité des blocs de traitement selon une technique connue de l'Homme du métier. En effet pour générer un aléa HD, il faut pourvoir connaître la disponibilité des ressources 30 en temps réel afin de réaliser des traitements en parallèle. Le séquenceur 2 joue un rôle d'aiguilleur des données à traiter introduites dans le système (flèche F2) suivant les requêtes qu'il reçoit à travers l'interface des requêtes, flèche F3. Ces requêtes correspondant à des applications pouvant être différentes. Le séquenceur 2 applique un � tag � aux données de sortie du bloc commandes commandant l'interface de sortie. Les données à traiter introduites par l'interface 11, flèche F2 peuvent ou non traverser une fonction fi, f1, ....fn, de traitement avant d'être acheminées vers un bloc de traitement selon le schéma de la flèche F4 sur la figure 2. Les données traitées et leur étiquette ou � tag � sont ensuite récupérées à l'interface de sortie. Les fonctions de traitement peuvent ou non être utilisées suivant le � tag � contenu dans les données ou suivant la configuration au démarrage. Les n ressources gérées par le séquenceur permettent de multiplier le débit par le nombre de ressources disponible. La figure 2 est un exemple d'application de génération d'aléa HD pour étalement de spectre radio. Dans cet exemple, on génère de l'aléa HD sur requête et à destination de la radio. La figure 3 schématise un autre exemple d'application où l'architecture est 20 utilisée comme chiffreur d'artère haut débit. L'interface de gestion 1 est utilisée pour : • Initialiser les différents blocs de traitement composé de n blocs, Configurer et initialiser les différentes fonctions de traitement pour chaque bloc de traitement. 25 L'interface d'entrée 11 sert aussi dans cet exemple à réceptionner : • Les trames de données à chiffrer, • Les demandes de traitement associées à la trame (index de clé, type de traitement, etc.) Le séquenceur 2 est informé en temps réel de la disponibilité des blocs de 30 traitement selon une méthode connue de l'Homme du métier et qui de fait ne sera pas détaillé. Le séquenceur joue un rôle d'aiguilleur des données reçues sur l'interface d'entrée 11 (flèche F'2) vers les blocs de traitements 8n suivant la demande de traitement reçue. Le séquenceur insère un � tag � au niveau des données de sorties (commandes). Les données à traiter peuvent ou non traverser une fonction fi de traitement avant d'être acheminées vers un bloc de traitement selon le schéma de la flèche F'4 sur la figure 3. Les données traitées et leur étiquette sont ensuite récupérées à l'interface de sortie 6. Les étapes décrites en relation avec la figure 2, restent donc valables, mais à la place de générer de l'aléa sur requêtes, dans le cas d'un chiffreur haut 10 débit, une donnée doit être chiffrée. La différence entre de la génération d'aléa HD et un chiffreur haut débit HD est le type de donnée en entrée. Dans le cas du générateur d'aléa HD on génère de l'aléa sur requêtes. Dans le cas du chiffreur HD, on entre une donnée qui doit être chiffrée. II existe de fait une différence de taille de 15 donnée reçue et de chemins de données. REVENDICATIONS 1 ù Architecture permettant de traiter en parallèle plusieurs flux de données caractérisée en ce qu'elle comporte en combinaison au moins les éléments suivants : • Une interface de gestion (1), reliée à un séquenceur (2) interprétant des requêtes en provenance d'une interface de requêtes (3) transmettant ces dernières à une mémoire des requêtes (4), le séquenceur (2) générant des commandes (5) vers une interface de sortie (6) et aiguillant des données à traiter vers des blocs de traitement (7n) et des fonctions de traitement (8n); • Les blocs de traitement (7n) et les fonctions de traitement (8n) étant configurables suivant une application donnée et étant disposés en parallèle les uns des autres, • Une mémoire (9) reçoit les données issues des blocs de traitement (7n) et les transmettant à l'interface de sortie (6), • Une deuxième mémoire (10) disposée entre la sortie des fonctions de traitement (8n) et des blocs de traitement (7n), • Une interface d'entrée (Il), recevant des informations en provenance du séquenceur et permettant d'initialiser suivant l'application les blocs et les fonctions de traitement. 2 ù Architecture selon la revendication 1 caractérisée en ce que l'interface d'entrée (11) est adaptée à gérer dans le type de traitement en utilisant un � tag � sur les données d'entrée permettant d'initialiser les blocs de traitement et/ou les fonctions de traitement de façon dynamique et de définir le type de flux à gérer. 3 ù Architecture selon la revendication 1 caractérisée en ce que l'interface d'entrée (11) est adaptée à initialiser de manière dynamique les blocs detraitement et/ou les fonctions de traitement et en ce que l'interface de requêtes est adaptée à définir le type de flux à gérer. 4 ù Architecture selon la revendication 1 caractérisé en ce que le séquenceur (2) applique une étiquette ou � tag � aux données de sortie du bloc commandes (5). ù Architecture selon la revendication 1 caractérisée en ce que l'interface de gestion (1) est adaptée à exécuter l'une des fonctions suivantes : o configurer les blocs et/ou les fonctions de traitement, o injecter des clés/paramètres, o gérer différents modes, o contrôler et commander l'ensemble des composants formant ladite architecture. 6 ù Utilisation de l'architecture selon l'une des revendications 1 à 5 pour la génération d'un aléa HD (haute définition) pour étalement de spectre radio. 7 ù Utilisation de l'architecture selon l'une des revendications 1 à 5 pour chiffrer des artères à haut débit.