Brevet FR2813681A1 — publié le 20020308

La présente invention se rapporte à un procédé de saisie graphique permettant le placement d'applications de traitement de signal en utilisant les ressources disponibles d'une machine sur laquelle elle est destinée à être mise en couvre. L'invention s'applique par exemple pour le placement d'applications de traitement de signal en fonction de l'architecture d'une machine Multi SIMD (abréviation anglo-saxonne de Single Instruction Multiple Data). Dans le cas particulier de la conception de circuits intégrés de traitement de signal, il existe des outils logiciels exploités sur stations de travail permettant de définir les blocs constitutifs d'une chaîne et de spécifier graphiquement leurs interconnexions. Ces. outils sont appropriés à une description de traitement sous l'aspect de flots de données circulant entre les blocs. Le brevet US 6.020.896 décrit un procédé de saisie graphique appelé Array-OL qui permet de spécifier des applications ou des chaînes de traitement de signal indépendamment de toutes considérations d'exécution. Le procédé décrit dans la demande de brevet FR 99/02 906 se rapporte à une saisie graphique pour le placement d'applications de traitement de signal dans une forme hiérarchisée, en particulier à une spécification des applications calquées sur une description par niveaux de l'architecture d'une machine SIMD. Toutefois, ce procédé présente l'inconvénient d'impliquer la connaissance par ailleurs d'une description de l'architecture de la machine. Un autre inconvénient est que la distribution de tâches et le placement des tableaux en mémoire ne sont pas menés conjointement. La présente invention a pour objet un procédé de traitement de saisie graphique permettant via un outil graphique le placement d'applications en fonction des ressources de l'architecture d'une machine, cette architecture étant décrite aussi par l'outil graphique. Les architectures des machines sur lesquelles la ou les applications vont s'exécuter peuvent être composées de cartes disponibles dans le commerce, appelées COTS (abréviation anglo-saxonne de Components on The Shelf). L'idée consiste à effectuer le placement d'applications de traitement de signal en utilisant des icônes figurant les ressources de la machine en respectant les dépendances imposées par la topologie de l'interconnexion de ces ressources. Sans considération de niveau de hiérarchie, la spécification d'une application avec le procédé Array-OL précité fait appel à deux modèles ; le Modèle Global et le Modèle Local décrits aux figures 1 A et 1 B. Une application est écrite du point de vue de son organisation générale en recourant au modèle global tel que représenté à la figure 1A. L'ensemble de l'application est par exemple visualisé sous la forme d'un graphe décrivant les dépendances entre les différentes tâches via les tableaux échangés. Le Modèle Local décrit sur la figure 1 B indique ensuite pour chaque tâche figurant dans le Modèle Global, comment bâtir le tableau résultant par itération d'une même transformation élémentaire TE. On rappelle qu'une TE opère sur des ensembles restreints d'éléments appelés motifs ayant une taille donnée, les éléments de chacun des motifs se plaçant sur les éléments des tableaux par des exemples d'ajustage et de pavage , tels que décrits dans le brevet et la demande de brevet précités. Bien qu'Array-OL ne définisse pas de modalités précises d'exécution, des paradigmes de parallélisme sont sous-jacents dans ces modèles Le Modèle Global suggère, tout au moins dans l'hypothèse d'une multiplicité de ressources physiques, un parallélisme potentiel de tâches, exécution en pipeline, chacune des ressources prenant en compte une ou plusieurs tâches ; Le Modèle Local, avec sa notion d'itérations multiples d'une même TE, suggère sans équivoque le Data Parallelism synonyme d'un mode d'exécution SIMD. Le fonctionnement d'une machine exécutant du traitement de signal systématique peut être de la même façon abordé dans une vision hiérarchique. Au plus haut niveau, la machine peut être vue comme un tout exécutant l'ensemble des traitements en consommant et en produisant une certaine quantité de données à chaque récurrence. Ainsi l'architecture d'une machine peut être définie sur plusieurs niveaux. Dans le procédé selon l'invention deux types de ressources sont utilisés Des ressources passives ayant une fonction de support vis-à-vis des tableaux, telles que Des mémoires apparaissant dans l'architecture de la machine destinataire, Des producteurs ou des consommateurs de tableaux à la périphérie de l'architecture, tels que le FEC ( abréviation anglo-saxonne de Front End Conditionning) et le traitement de données (TD). Contrairement aux mémoires, il n'y a pas de considération de placement des tableaux sur ces ressources périphériques. Des ressources actives capables. de lire ou d'écrire notamment dans les ressources passives, par exemple Des DMA (abréviation anglo-saxonne de Direct Memory Access) capables d'effectuer des transferts de données entre au moins deux ressources passives sans modifier à priori les données (au transcodage près), Des CPU (abréviation anglo-saxonne de Central Processing Unit), qui lisent les données dans une ressource passive, les modifient, puis les réécrivent dans la même ou une autre ressource passive. La figure 2 montre les différentes conventions graphiques utilisées dans l'invention pour distinguer ces différentes ressources. Dans la suite de la description, l'expression Array-OL Appli se rapporte à un procédé de spécification de l'application de traitement de signal et l'expression Array-OL Archi à un procédé de représentation de l'architecture de la machine destinataire de l'application. L'invention concerne un procédé permettant le placement d'applications de traitement de signal à partir de la présentation des ressources disponibles d'une machine destinée à recevoir l'application. L'objet de l'invention concerne un saisie graphique pour le placement d'applications de traitement de signal destinée à une machine comportant des ressources passives et des ressources actives, lesdites ressources et leur agencement entre elles pouvant être représentées dans un modèle global et dans un modèle local pour un niveau hiérarchique Li donné de l'architecture de la machine. II est caractérisé en ce qu'il comporte au moins les étapes suivantes a) présenter dans une première zone d'écran une Vue Archi figurant sous forme d'icônes les ressources actives ou passives disponibles de l'architecture de la machine pour un niveau Li donné et les liens entre les ressources, dans un modèle global et/ou dans un modèle local, b) construire l'application de traitement de signal dans une deuxième zone d'écran formant une Vue Appli , en empruntant une ou plusieurs icônes représentatives des ressources de la Vue Archi , et en ce que les 2 étapes a) et b) sont mises en couvre de manière hiérarchique en utilisant des vues successives de plus en plus fines de l'architecture de la machine. La Vue Archi ?> présente par exemple des icônes figurant des ressources dans le modèle global ou des icônes figurant des contraintes d'implantation en mémoire dans le modèle local. Une ressource active se décompose par exemple en plusieurs actives élémentaires (identiques) lors du passage du modèle global au modèle local pour un niveau Li. Une ressource active peut se dissocier en plusieurs ressources actives et/ou passives lors du passage du modèle local d'un niveau Li au modèle global du niveau suivant L41. Plusieurs icônes identiques sont par exemple représentées en superposition pour indiquer le nombre de décompositions restant à faire et en ce que le nombre d'itérations d'une ressource active élémentaire est indiquée sous l'icône précédé d'un signe de multiplication. L'emprunt d'icônes à la Vue Archi pour bâtir l'application dans la Vue Appli est par exemple effectuée de la manière suivante une tâche ou une transformation élémentaire TE de la Vue Appli est représentée en empruntant dans la Vue Archi une icône associée à un CPU ou un DMA, un tableau de la Vue Appli est représenté par une icône représentant une ressource passive telle qu'une mémoire. Dans la Vue Appli du modèle local, les exemples d'implantation en mémoire tels que de pavage peuvent être prolongés au delà du tableau résultat jusqu'à l'icône représentant la mémoire empruntée à la Vue Archi pour donner l'implantation en mémoire de l'origine des motifs résultats. Les ressources actives sont par exemple figurées par 2 icônes, une flèche représentant les accès directs mémoires (DMA), un V tourné de 90 représentant les unités de calcul (CPU) et en ce que les ressources passives sont figurées par deux icônes, un rectangle représentant les mémoires et un rectangle ouvert représentant les périphériques. L'invention concerne aussi un dispositif permettant de construire une application de traitement de signal destinée à une machine comportant des ressources passives et des ressources actives, lesdites ressources et leur agencement entre elles pouvant être représentées dans un modèle global et dans un modèle local pour un niveau Li donné de l'architecture de la machine. II est caractérisé en ce qu'il comporte au moins D des moyens adaptés à présenter à un utilisateur une zone Vue Archi figurant les ressources disponibles de l'architecture pour un niveau Li donné et leurs dépendances, dans un modèle global puis dans un modèle local, et une zone Vue Appli destinée à recevoir les icônes sélectionnées, D des moyens permettant à l'utilisateur d'emprunter une ou plusieurs icônes représentatives d'une ressource active ou d'une ressource passive, de faire glisser la ou lesdites icônes dans la zone Vue Appli pour construire l'application de traitement du signal, et D des moyens pour passer d'un niveau Li au niveau suivant L41. Le procédé et le dispositif selon l'invention s'applique pour construire une application de traitement de signal dans le domaine du traitement des signaux d'antennes radar ou sonar. Le procédé selon l'invention facilite grandement le placement sur des machines composées de COTS dont l'architecture, souvent complexe, peut être faite niveau par niveau grâce à la hiérarchisation propre au procédé. La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation pris à titre d'exemple non limitatif et illustré par les dessins annexés où # Les figures 1A et 1B représentent respectivement un exemple de modèle global et de modèle local utilisé dans l'art antérieur, # La figure 2 montre les conventions graphiques utilisées pour distinguer les différentes ressources mises en ceuvre dans l'invention, # La figure 3 schématise un exemple d'agencement de plusieurs ressources passives et actives d'une machine dans le modèle global, # La figure 4 montre un exemple du détail d'une ressource de la figure 3 en utilisant le modèle local, # Les figures 5 et 6 définissent des notions de distribution et de dissociation d'une ressource, # La figure 7 schématise un principe de représentation graphique d'une ressource passive, # Les figures 8 et 9 représentent un exemple de mise en oeuvre du procédé selon l'invention pour un niveau donné. L'architecture de la machine sur laquelle l'application va être exécutée est décrite de façon hiérarchique sur plusieurs niveaux, du niveau supérieur au niveau inférieur (top-down en termes anglo-saxon). Pour chaque niveau Li l'utilisateur dispose d'une vision partielle de l'architecture mais suffisante pour le niveau atteint. Array-OL Archi permet ainsi de représenter pour un niveau donné Li les ressources disponibles dans les deux modèles global et local comparables à ceux décrits respectivement aux figures 1 A et 1 B. La figure 3 représente un exemple d'agencement de ressources dans le modèle global d'Array OL Archi. Par exemple une ressource active telle qu'un CPU, 1, est relié à une mémoire, 2, qui lui foumit des données et à qui il transmet des données résultant de la tâche réalisée. La mémoire est elle-même reliée à une autre ressource active 3, 4 par exemple un DMA en liaison avec un FEC 5 ou un TD 6. La figure 4 représente dans le modèle local d'Array-OL Archi une description plus fine du CPU de la figure 3 et comment son activité se répète de façon identique sur des ressources actives plus fines de même type. On considère que chaque itération de la TE est prise en charge par une ressource active élémentaire. Dans l'exemple donné à la figure 3 la TE est itérée 8 fois. Pour qu'une tâche soit considérée comme terminée en Array-01L, la TE doit être répétée jusqu'à obtention de tous les éléments du ou des tableaux résultats, correspondant à leur remplissage complet. Le CPU de la figure 3 est ainsi décomposé en 8 CPU identiques faisant apparaître un parallélisme SIMD. Le nombre de répétition de l'activité est indiqué en dessous de l'icône précédé par exemple d'un signe de multiplication. Selon un mode de réalisation, on représente la ressource active élémentaire à l'aide d'une icône entourée par des motifs offrant à l'utilisateur une vision des contraintes d'implantation suivant les dimensions mémoire sous forme de pavage ou d'ajustage préétablis en appliquant la méthode décrite dans le brevet précité US 6.020.529. L'utilisateur accède ainsi aux détails de l'architecture de la machine au fur et à mesure de sa descente dans les niveaux Li de la hiérarchie. Dans la suite de la description # le terme distribution correspond au fait de décomposer une ressource active en plusieurs ressources actives élémentaires lors du passage du modèle global au modèle local. La figure 5 schématise la distribution d'un DMA en quatre DMA correspondant aux 4 itérations de la transformation élémentaire de l'application. Cette distribution spatiale peut aussi s'appliquer à une distribution temporelle (non représentée sur les figures) en considérant la répétition dans le temps de la ressource. Le choix entre ces 2 distributions est fait par l'utilisateur en fonction de la machine et de l'application en particulier de la taille des mémoires. # le terme dissociation correspond à la décomposition d'une ressource active en ressources multiples qui sont en général différentes lors du passage du modèle local d'un niveau Li au modèle global du niveau Li+1 suivant. La figure 6 représente un exemple de distribution d'un simple CPU dans le modèle local du niveau Li en un ensemble composé d'un CPU, de deux DMA, d'une mémoire de travail (WS). La convention adoptée dans les schémas pour indiquer le caractère composite d'une ressource est de superposer plusieurs icônes identiques. Le nombre d'icônes identiques apparaissant à l'utilisateur donnent une indication sur le nombre de dissociations ou de distributions possibles avant d'arriver au demier niveau de la décomposition. Le nombre d'icônes superposées est diminué de 1 à chaque passage du modèle global au modèle local pour un même niveau Li (figure 5), et à chaque dissociation lors du passage au niveau suivant (figure 6). Pour un niveau d'architecture donné Li, le modèle global d'Array- OL Archi précise l'interconnexion d'une ressource active à une ou plusieurs ressources passives et en particulier avec des mémoires. Ce modèle offre une première information de placement en désignant les mémoires dans lesquelles le tableau produit par la ressource active peut être placé. Le modèle local d'Array-OL Archi va permettre d'indiquer quelle dimension mémoire est pertinemment pavable pour le niveau considéré. Une mémoire apparaissant pour la première fois dans la hiérarchie présente par exemple plusieurs dimensions parmi lesquelles # une dimension adresse C , # des dimensions cartes ( C), Noeuds (N), Bancs (B) ...traduisant une organisation répartie (alias distribuée) de cette mémoire, # une dimension largeur (W) si dans un même cycle d'accès par une ressource active plusieurs mots sont lus ou écrits dans le même banc. La figure 7 représente un aperçu sur l'ensemble des dimensions avec, par exemple, une indication sur le nombre de mots contenus par les dimensions pavables. Le nombre de dimensions présentées à l'utilisateur décroît en descendant dans les niveaux de l'architecture de la machine. Une fois utilisée pour une distribution dans un niveau, une dimension physique telle que C, N ou B n'apparaît plus dans les niveaux suivants. Seule reste la dimension d'adresse @ dans le niveau le plus bas de la hiérarchie. La convention adoptée pour indiquer sur l'icône mémoire quelle est la seule dimension pavable, consiste à faire figurer des éléments uniquement sur cette dimension. Dans un exemple de mise en oeuvre du procédé, l'écran de la station de travail présente à l'utilisateur une zone Vue Archi à partir de laquelle est visualisé un niveau Li d'architecture de la machine avec ses icônes représentatives des ressources disponibles, ceci dans un modèle global ou local, et une zone Vue Appli ?> destinée à recevoir les icônes qui vont former l'application dans le formalisme Array-OL Appli. Ces deux zones se présentent par exemple sous la forme d'une fenêtre sur l'écran comportant une barre menu permettant de sélectionner le modèle global, le modèle local, l'enregistrement possible des configurations définies, l'exploration des différents niveaux Li de l'architecture de la machine. Les figures 8 et 9 schématisent un exemple de mise en ceuvre du procédé à un niveau donné Li selon l'invention. Les flèches en pointillés correspondent aux déplacements de différentes icônes, disponibles dans la Vue Archi qui est affichée à l'écran, effectués par l'utilisateur au moyen d'une souris par exemple. Les icônes affichées correspondent aux ressources de l'architecture avec les détails correspondant au niveau Li atteint dans la hiérarchie de l'architecture. Dans le bas des figures 8 et 9 est schématisée la Vue Appli. L'emprunt de certaines icônes figurant les ressources actives du modèle global et des ressources passives du modèle local à la Vue Archi pour construire la Vue Appli constitue un formalisme de placement selon les conventions suivantes # une tâche représentée dans le modèle global de la Vue Appli par emprunt dans la Vue Archi d'une icône CPU (respectivement un DMA) correspond à une tâche de traitement (respectivement de transfert) s'exécutant sur le CPU (respectivement DMA) emprunté à la Vue Archi, # les tableaux vus en entrée et en sortie par cette tâche sont stockés sur les mémoires en lecture et en écriture de cette icône CPU (ou DMA) tel qu'indiqué par la Vue Archi, # les exemples de pavage, et éventuellement d'ajustage, saisis dans le modèle local de la Vue Appli côté résultat et prolongés jusqu'à l'icône représentant la mémoire en écriture dans le modèle local de la Vue Archi, constituent les directives de placement suivant la dimension mémoire considérée par le niveau. La figure 8 représente un exemple de saisie d'informations dans le modèle global. Les ressources actives de la Vue Archi servent à bâtir un graphe de tâches dans la Vue Appli. Ce graphe comporte plusieurs tâches de transfert M1, M2, M3 prises en charge par DMA1, M4 par DMA2 et des tâches de traitement P1 et P2 prises en charge par CPU. Dans cet exemple de construction de l'application, les ressources DMA1 et CPU ont été respectivement empruntées trois fois et deux fois et descendues dans la zone de l'écran réservée pour construire la Vue Appli. Les liens entre ressources actives et passives de la Vue Archi permettent de déduire que dans la Vue Appli les tableaux A1, A2, A3 et A9 se trouvent mémorisés dans la mémoire Main Store et les tableaux A4, A5, A6, A7 et A8 dans la mémoire de travail Working Store . La figure 9 représente la saisie d'informations de placement dans le modèle local correspondant à la tâche P1 de la figure 8. Le CPU se décompose ici en 4 CPU élémentaires identiques lisant et écrivant dans la mémoire de travail Working Store . En conséquence, la TE de la Vue Appli doit être itérée 4 fois pour produire complètement le tableau résultat. La ressource passive Working Store est empruntée à la Vue Archi et descendue dans la Vue Appli. De cette façon, on désigne la mémoire si la ressource dispose de plusieurs mémoires en écriture. Les exemples de pavage sont prolongés au-delà du tableau jusqu'à la Working Store pour donner l'implantation en mémoire de l'origine des motifs résultats. Ainsi, à chaque niveau, distribution de tâche et placement des tableaux en mémoire sont menés conjointement. Le procédé dans sa totalité est exécuté en commençant par le niveau le plus haut dans la hiérarchie et dans le modèle global. La mise en ceuvre est alors effectuée pour chaque niveau jusqu'au niveau le plus bas en mettant en oeuvre les étapes suivantes # étape a) : l'utilisateur se positionne par le menu à un niveau donné Li dans la hiérarchie et dans le modèle global. II dispose donc à l'écran dans la zone Vue Archi d'icônes représentatives des ressources actives et passives et de leurs dépendances pour le niveau Li, # étape b) il sélectionne au moyen de la souris par exemple la ou les icônes représentatives des ressources passives et actives qui sont nécessaires pour construire son application dans le niveau correspondant Li, et il transfère à l'aide de la souris cette ou ces icônes dans la zone Vue Appli , # il répète cette étape b) autant de fois qu'il.est nécessaire pour obtenir une vue de l'application dans le modèle global dans ce niveau Li, # étape c), il reste au même niveau Li de hiérarchie de l'architecture et sélectionne le modèle local à partir du menu de la zone Vue Archi ce qui lui permet de disposer des icônes associées à une ressource du niveau global avec plus de détails et en sélectionnant les icônes détaillées correspondant aux icônes précédemment sélectionnées à l'étape b), de construire l'application dans le modèle local, par un transfert à l'aide de la souris l'icône sélectionnée de la zone Vue Archi vers la zone Vue Appli . # l'étape c) est réitérée jusqu'à obtenir toutes les ressources du modèle global précisées par l'étape b) dans le modèle local, Le résultat final est stocké par exemple dans la mémoire d'une station de travail permettant le placement de l'application sur la machine destinataire. REVENDICATIONS 1 - Procédé de saisie graphique pour le placement d'applications de traitement de signal destinée à une machine comportant des ressources passives et des ressources actives, lesdites ressources et leur agencement entre elles pouvant être représentées dans un modèle global et dans un modèle local pour un niveau hiérarchique Li donné de l'architecture de la machine, caractérisé en ce qu'il comporte au moins les étapes suivantes a) présenter dans une première zone d'écran une Vue Archi figurant sous forme d'icônes les ressources actives et/ou passives disponibles de l'architecture de la machine pour un niveau Li donné et les liens entre les ressources, dans un modèle global et/ou dans un modèle local, b) construire l'application de traitement de signal dans une deuxième zone d'écran formant une Vue Appli , en empruntant une ou plusieurs icônes représentatives des ressources de la Vue Archi , et en ce que les 2 étapes a) et b) sont mises en oeuvre de manière hiérarchique en utilisant des vues successives de plus en plus fines de l'architecture de la machine. 2 - Procédé selon la revendication 1 caractérisé en ce que la Vue Archi présente des icônes figurant des ressources dans le modèle global ou des icônes figurant des contraintes d'implantation en mémoire dans le modèle local. 3 - Procédé selon la revendication 1 caractérisé en ce qu'une ressource active se décompose en plusieurs ressources actives élémentaires (identiques) lors du passage du modèle global au modèle local pour un niveau Li. 4 - Procédé selon la revendication 1 caractérisé en ce qu'une ressource active se dissocie en plusieurs ressources actives et/ou passives lors du passage du modèle local d'un niveau Li au modèle global du niveau suivant Li+1. 5 - Procédé selon l'une des revendications 3 et 4 caractérisé en ce que plusieurs icônes identiques sont représentées en superposition pour indiquer le nombre de décompositions restant à faire et en ce que le nombre d'itérations d'une ressource active élémentaire est indiquée sous l'icône précédé d'un signe de multiplication. 6 - Procédé selon l'une des revendications 1 à 5 caractérisé en ce que l'emprunt d'icônes à la Vue Archi pour bâtir l'application dans la Vue Appli est effectuée de la manière suivante une tâche ou une transformation élémentaire TE de la Vue Appli est représentée en empruntant dans la Vue Archi une icône associée à un CPU ou un DMA, D un tableau de la Vue Appli est représenté par une icône représentant une ressource passive telle qu'une mémoire. 7 - Procédé selon l'une des revendications 1 à 6 caractérisé en ce que, dans la Vue Appli du modèle local, les exemples d'implantation en mémoire tels que de pavage sont prolongés au delà du tableau résultat jusqu'à l'icône représentant la mémoire empruntée à la Vue Archi pour donner l'implantation en mémoire de l'origine des motifs résultats. 8 - Procédé selon l'une des revendications 1 à 7 caractérisé en ce que les ressources actives sont figurées par 2 icônes, une flèche représentant les accès directs mémoires (DMA), un V tourné de 90 représentant les unités de calcul (CPU) et en ce que les ressources passives sont figurées par deux icônes, un rectangle représentant les mémoires et un rectangle ouvert représentant les périphériques. 9. - Procédé selon l'une des revendications 1 à 8 pour construire une application de traitement de signal dans le domaine du traitement des signaux d'antennes radar ou sonar. 10 - Dispositif permettant de construire une application de traitement de signal destinée à une machine comportant des ressources passives et des ressources actives, lesdites ressources et leur agencement entre elles pouvant être représentées dans un modèle global et dans un modèle local pour un niveau Li donné de l'architecture de la machine, caractérisé en ce qu'il comporte au moins Y des moyens adaptés à présenter à un utilisateur une zone Vue Archi figurant les ressources disponibles de l'architecture pour un niveau Li donné et leurs dépendances, dans un modèle global puis dans un modèle local, et une zone Vue Appli destinée à recevoir les icônes sélectionnées, des moyens permettant à l'utilisateur d'emprunter une ou plusieurs icônes représentatives d'une ressource active ou d'une ressource passive, r de faire glisser la ou lesdites icônes dans la zone Vue Appli pour construire l'application de traitement du signal, et des moyens pour passer d'un niveau Li au niveau suivant L41. 11 - Dispositif selon la revendication 10 pour construire une application de traitement de signal dans le domaine du traitement des signaux d'antennes radar ou sonar.