FR2696257A1 - Appareil et procédé d'allocation de temps de traitement dans un système d'ordinateur à base de séquences. - Google Patents

Abstract

La présente invention concerne une procédé mis en œuvre dans un système d'ordinateur, incluant un processeur de signaux numériques de traitement d'une tâche (316 à 321) en temps réel sur une base de séquence (313), et destiné à déterminer si ladite tâche est exécutable à l'intérieur d'une séquence (313) particulière d'une manière telle qu'un temps total de traitement correspondant à ladite séquence particulière n'est pas dépassé si ladite tâche est traitée à l'intérieur de ladite séquence particulière. Le procédé comprend les étapes consistant à: déterminer un temps de traitement de ladite tâche; calculer un temps d'exécution d'une liste de tâches spécifiant au moins une tâche à traiter pendant ladite séquence; calculer une quantité de temps de traitement disponible (322) dans ladite séquence en soustrayant dudit temps total de traitement de séquence le temps d'exécution de la liste; installer ladite tâche dans ladite liste si ledit temps disponible est au moins aussi grand que ledit temps de traitement de tâche, et engendrer dans le cas contraire un signal indiquant que la tâche ne peut être installée. L'invention comprend aussi un appareil correspondant et un procédé de traitement de tâches en temps partagé correspondant.

Description

La présente invention concerne le domaine du traitement en temps réel dans des systèmes d'ordinateur à traitement à base de séquences. De façon plus particulière, la présente invention concerne un procédé et un appareil de mesure et de commande du temps d'exécution, dans un système d'ordinateur à base de séquences, d'une manière telle que des tâches en temps réel provenant de différentes applications peuvent être programmées de façon dynamique sans conflits sur le système de traitement.

Des données corrélées dans le temps, comme des sons, des images, des paroles, sont analogiques par nature, c'est-à-dire continues. En revanche, les ordinateurs sont, pour leur majeure partie, numériques, c'est-à-dire discrets. Pour qu'un ordinateur numérique traite des signaux analogiques, les signaux analogiques sont convertis en premier lieu en signaux numériques qui représentent les signaux analogiques. On y parvient en échantillonnant de façon répétée les signaux analogiques à de brefs intervalles de temps et en convertissant chaque valeur échantillonnée en une valeur numérique. Le signal numérique résultant peut ensuite être traité par l'ordinateur numérique. Le traitement, par un ordinateur, de tels signaux numérisés, est appelé un traitement de signaux numériques.

Actuellement, un traitement de signaux numériques est en train d'être appliqué à des applications multimédias, de sorte que des communications textuelles, audio, parlées, vidéo, de données et d'autres données à corrélation temporelle sont intégrées de façon à créer une présentation d'informations plus efficace.

Cependant, la manipulation de ces applications dans un environnement à temps réel exige une grande quantité de puissance de traitement. L'Unité Centrale de
Traitement, ou UCT, de l'ordinateur ne possède typiquement pas la puissance de traitement nécessaire.

Pour traiter la charge associée à la mise en oeuvre de ces tâches en temps réel, on emploie un ou plusieurs processeurs spécialisés de signaux numériques, ou DSP.

Un processeur spécialisé de signaux numériques est conçu pour accepter des échantillons entrant à la vitesse moyenne à laquelle les échantillons sont engendrés par un procédé d'entrée. Le processeur spécialisé de signaux numériques traite ensuite les échantillons entrés en fonction d'un programme d'ordinateur et produit des signaux sortant à la vitesse moyenne de consommation du traitement de sortie. Un procédé efficace d'exécution d'un traitement en temps réel sur un processeur spécialisé de signaux numériques est appelé un traitement à base de séquences. Dans un traitement à base de séquences, le temps est divisé en une série d'unités discrètes, appelées des séquences, à l'intérieur desquelles tout le traitement de signaux nécessaires pour cette séquence est achevé.

On y parvient en divisant des signaux numériques en groupes qui représentent la même quantité de temps qu'une séquence. Par exemple, étant donné que la vitesse de données audio sur un disque compact est de 44.100 échantillons par seconde et en supposant une vitesse de séquences de 10 millisecondes, c'est-à-dire 100 séquences par seconde, il existerait 441 échantillons par séquence. Pendant chaque séquence, le code de programme correspondant, des variables et des échantillons entrés sont chargés dans un cache ou antémémoire à haute vitesse. A partir du cache, les échantillons entrés sont ensuite traités selon les tâches. Finalement, la donnée de sortie qui en résulte est envoyée dans un tampon de sortie pour être utilisée par un traitement de sortie.

Dans une architecture à base de séquences, chacune des tâches est typiquement liée ou associée avec une autre au moyen d'une structure de données. Un signal d'interruption ou un autre de signal de synchronisation est engendré et envoyé au processeur spécialisé de signaux numériques au début de chaque séquence. Celui-ci lance le traitement de la structure de donnée de façon que chaque tâche soit successivement exécutée à l'intérieur d'une séquence.

L'un des avantages d'un traitement à base de séquences est qu'il réduit le temps inactif de commutation de tâches. Par exemple, étant données quatre tâches qui manipulent chacune un train d'échantillons de 44.100 échantillons par seconde, si chaque tâche doit être exécutée une fois pour chaque échantillon, on obtient un total de 4 x 44.100 ou 176.400 commutations de tâches en une seconde. En implantant un traitement à base de séquences qui exécute 100 séquences par seconde, il suffit de 400 commutations de tâches par seconde pour exécuter les mêmes quatre tâches, chacune d'elle étant exécutée 100 fois en une seconde. Ceci réduit le temps inactif de commutation de tâches par un facteur de 441.

Un inconvénient majeur d'un système à base de séquences est sa latence accrue. Un système de traitement qui ne traite qu'un échantillon à la fois peut, dès l'échantillon suivant, répondre à une modification dans l'entrée. Dans un système à base de séquences, une réponse exige deux séquences. La raison en est qu'une donnée est collectée dans une séquence, traitée dans la séquence suivante et sortie dans la séquence qui suit.

Un autre problème des systèmes à base de séquences est qu'il n'existe qu'une certaine quantité finie de temps de traitement par séquence parce que chaque séquence individuelle est d'une durée temporelle fixe. Par conséquent, lorsqu'un certain nombre de tâches sont en cours de traitement en temps réel, il faut s'assurer que le temps de traitement de séquence n'est pas dépassé. Dans le cas contraire, le traitement en temps réel est interrompu d'une manière inacceptable. Dans certaines circonstances, le traitement d'une séquence peut être dépassé lors de l'exécution des tâches à traiter pendant cette séquence. Par exemple, un aspect inattendu de l'un des algorithmes de la tâche peut amener cette tâche à exiger plus de temps de traitement, ce qui provoque un dépassement de séquence.Un autre exemple qui peut conduire à un dépassement de séquence est le cas où une tâche est sensible à une donnée d'entrée, et où la donnée a été corrompue ou endommagée. En fait, un bus surchargé peut détériorer la performance du système jusqu'au point où il se produit un dépassement de séquence. Dans certains cas, par exemple la mise au point d'un programme sur une base ligne par ligne, des dépassements de séquences sont inévitables. Parfois, l'algorithme d'une tâche peut fonctionner de façon appropriée 99,9% du temps, mais un ordre particulier ou une séquence de donnée peut provoquer, en raison d'un défaut, une boucle sans fin ou une augmentation désordonnée du temps de traitement.

S'assurer que 100% du traitement de séquence n'est pas dépassé est relativement facile à mettre en oeuvre s'il n'existe qu'une application exécutant une tâche unique. Lorsque l'application est écrite, le programmeur peut prendre en compte des tâches particulières et ajuster le traitement de façon appropriée. En revanche, si des tâches très diverses sont installées et sont exécutées par un certain nombre d'applications différentes, il se pose un problème sérieux pour déterminer s'il reste, dans une séquence particulière, une quantité suffisante de puissance de traitement disponible pour traiter des demandes ultérieures d'applications et/ou de traitement de tâches. Des réalisations ou configurations différentes du matériel peuvent également affecter la charge de traitement.

Par conséquent, ce qui est nécessaire est un appareil et un procédé de détermination 1) du temps de traitement disponible à l'intérieur d'une séquence lorsqu'une tâche additionnelle doit être installée et 2) du temps de traitement de cette tâche dans le pire des cas. ces deux valeurs peuvent être comparées pour garantir, lorsqu'une tâche est installée, qu'elle peut être complètement exécutée à l'intérieur de cette séquence. Il serait également avantageux que l'appareil et le procédé soient simple à implanter, que leurs temps inactifs soient faibles et qu'ils soient de plus dynamiques, c'est-à-dire adaptatifs en temps réel à l'environnement réel.

Compte tenu des problèmes associés au traitement à base de séquences, un but de la présente invention est de fournir un procédé et un appareil qui allouent un temps de traitement de séquence d'une manière telle que le temps nécessaire pour traiter en temps réel des tâches associées à cette séquence ne dépasse pas le temps total de traitement de la séquence.

Un autre but de la présente invention est de calculer le temps de traitement, dans le pire des cas, pour un groupe de modules d'une tâche, plutôt que d'additionner simplement les temps de traitement des modules individuels.

Un autre but de la présente invention est de produire des vecteurs d'échelle d'une manière telle qu'un élément de code peut fonctionner dans diverses représentations concrètes.

Un autre but de la présente invention est de mettre en oeuvre un procédé et un appareil d'allocation, à base de séquences, qui soit dynamique, c'est-à-dire adaptatif en temps réel à l'environnement réel.

Un autre but de la présente invention est de déterminer si une application peut être prise en charge de façon appropriée sur une base de temps partagé dans le cadre suivant: le mode de réalisation actuellement préféré de la présente invention inclut également une deuxième liste de tâches, appelées la liste de tâches en temps partagé. Cette liste de tâches est exécutée, à l'intérieur de chaque séquence, au cours d'un temps excédentaire quelconque qui n'est pas nécessaire pour exécuter la liste de tâches en temps réel. Ceci est appelé un traitement en temps partagé.

Ces buts, ainsi que d'autres sont atteints grâce à l'invention qui se présente sous trois aspects.

Selon un premier aspect de l'invention, il est fourni un procédé mis en oeuvre dans un système d'ordinateur, incluant un processeur de signaux numériques de traitement d'une tâche en temps réel sur une base de séquence, et destiné à déterminer si ladite tâche est exécutable à l'intérieur d'une séquence particulière d'une manière telle qu'un temps total de traitement correspondant à ladite séquence particulière n'est pas dépassé si ladite tâche est traitée à l'intérieur de ladite séquence particulière, caractérisé en ce qu'il comprend les étapes consistant à::
déterminer un temps de traitement de ladite tâche;
calculer un temps d'exécution d'une liste de tâches spécifiant au moins une tâche à traiter pendant ladite séquence;
calculer une quantité de temps de traitement disponible dans ladite séquence en soustrayant dudit temps total de traitement de séquence le temps d'exécution de la liste de tâche;
installer ladite tâche dans ladite liste de tâches si ledit temps de traitement disponible est au moins aussi grand que ledit temps de traitement de tâche, et engendrer dans le cas contraire un signal indiquant que la tâche ne peut être installée.

Ledit temps d'exécution de tâche peut être déterminé en ajoutant entre eux des temps de traitement de chaque tâche installée de ladite liste de tâches.

Chaque tâche peut comprendre dans ce cas au moins un module.

Ledit temps de traitement d'une tâche installée peut alors être déterminé en déterminant une utilisation, dans le pire des cas, desdits modules correspondant à ladite tâche et en additionnant entre eux les temps de traitement de chaque module pour ladite utilisation dans le pire des cas.

Lorsque ledit temps de traitement de module est calculé en référence au type d'algorithme dudit module, il peut être prévu que
si ledit module comprend un algorithme uniforme, le temps de traitement dudit module est un temps de traitement estimé si un temps réel de traitement n'a pas été mesuré pour ledit module, le temps de traitement dudit module étant constitué dans le cas contraire par ledit temps réel de traitement;
si ledit module comprend un algorithme fragmenté intelligent, ledit temps de traitement est constitué par la plus grande des deux valeurs: temps de traitement estimé et temps de traitement réel si ladite situation de temps de traitement dans le pire des cas ne s'est pas encore produite, et par le temps de traitement dudit module dans le cas contraire;
si ledit module comprend un algorithme fragmenté inintelligent, le temps de traitement dudit module est le plus grand des deux temps: temps estimé de traitement ou temps réel de traitement, dudit module.

Ledit temps de traitement réel dudit module peut en particulier être mesuré par une horloge.

Ledit temps de traitement réel mesuré par ladite horloge peut dans ce cas inclure des activités reliées du système.

Le temps de traitement dudit module, mesuré par ladite horloge peut alors être mesuré en référence auxdits cycles d'instruction de traitement de signaux.

Si ledit module est traité dans une séquence ultérieure, on peut prévoir qu'une comparaison soit effectuée entre ledit temps antérieur de traitement réel et ledit temps ultérieur de traitement réel dudit module, et que ledit temps réel de traitement dudit module soit mis à jour selon la plus grande de ces deux valeurs.

Une série de vecteurs d'échelle correspondant audit module actif peuvent alors être implantés, ce qui permet audit module actif de fonctionner dans différentes représentations concrètes.

De préférence, lesdits vecteurs d'échelle incluent une vitesse de séquence, un facteur d'échelle et une valeur de largeur de bande de traitement.

Le procédé peut comprendre en outre l'étape consistant à implanter un ou plusieurs vecteurs d'échelle correspondant audit module pour calculer ledit temps de traitement dudit module, lesdits vecteurs d'échelle incluant une vitesse de séquence, un facteur d'échelle et au moins un compte ou des comptes d'accès à la mémoire correspondant au moins à un type de référence de mémoire
Dans le cas de la modalité préférée mentionnée plus haut, le procédé peut comprendre en outre l'étape consistant à implanter un ou plusieurs vecteurs d'échelle correspondant audit module pour calculer ledit temps de traitement dudit module, ledit temps de traitement dudit module étant déterminé selon la formule mx + b dans laquelle m correspond à une quantité incrémentale de temps correspondant au traitement d'un échantillon entré, b correspond à un temps inactif dudit système d'ordinateur, et x correspond à un nombre d'échantillons à traiter, lesdits vecteurs d'échelle incluant une vitesse de séquence, un facteur d'échelle et des valeurs de m et b.

Dans le cas de la modalité préférée déjà mentionnée, une allocation de traitement dudit module actif peut être modifiée dynamiquement en fonction de ladite disponibilité de temps de traitement à l'intérieur de ladite séquence.

Dans ce cas, le procédé peut comprendre en outre l'étape consistant à mettre à jour ledit temps de traitement réel lorsque ladite tâche est déchargée et à mémoriser dans un moyen de mémorisation ledit temps de traitement mis à jour.

Ledit temps de traitement mis à jour peut alors être restitué et utilisé pour calculer ledit temps d'exécution de ladite liste de tâches.

Selon un deuxième aspect de l'invention, il est réalisé un appareil inclus dans un système d'ordinateur, dans lequel des tâches sont traitées en temps réel sur une base de séquences, et servant à assurer qu'une tâche peut être complètement traitée à l'intérieur d'une séquence d'une manière telle que ledit temps de traitement disponible de séquences n'est pas dépassé, caractérisé en ce qu'il comprend::
une liste de tâches servant à spécifier des tâches à traiter pendant ladite séquence;
un processeur de signaux numériques couplé audit système d'ordinateur pour exécuter ladite liste de tâches;
un système d'exploitation, couplé audit système d'ordinateur, qui détermine un temps de traitement disponible pour ladite séquence en soustrayant d'un temps total de traitement de ladite séquence un temps d'exécution servant à exécuter ladite liste des tâches, ladite tâche étant incluse dans ladite liste de tâches si le temps de traitement disponible est au moins aussi grand que ledit temps de traitement de ladite tâche, et ladite tâche n'étant pas incluse, dans le cas contraire, dans ladite liste de tâches.

L'appareil peut comprendre en outre un vecteur d'échelle servant à calculer ledit temps de traitement de tâche, ledit vecteur d'échelle incluant une vitesse de séquence, un facteur d'échelle et au moins un compte d'accès de mémoire correspondant à au moins un type de référence de mémoire.

L'appareil peut comprendre en outre un vecteur d'échelle servant à calculer ledit temps de traitement de tâche, ledit vecteur d'échelle incluant une vitesse de séquence, un facteur d'échelle, et des valeurs m et b, ledit temps de traitement de tâche étant déterminé selon la formule mx + b dans laquelle m correspond à une quantité incrémentale de temps de traitement d'un échantillon entré, b correspond à un temps inactif dudit système d'ordinateur, et x correspond à un nombre d'échantillons à traiter.

L'appareil peut comprendre en outre un premier drapeau correspondant à chaque tâche de ladite liste de tâches, l'état du premier drapeau déterminant si ladite tâche correspondante est active, des tâches actives de ladite liste de tâches étant traitées pendant ladite séquence lorsque ladite liste de tâches est exécutée.

Ledit temps d'exécution de liste de tâches peut alors être déterminé en ajoutant les uns aux autres tous les temps de traitement de chacune des tâches qui est installée dans ladite liste de tâches.

Chaque tâche peut en outre, dans ce cas, comprendre au moins un module.

L'appareil peut alors comprendre un deuxième drapeau associé audit module, l'état dudit deuxième drapeau déterminant si ledit temps de traitement dudit module doit être inclus dans le calcul dudit temps de traitement de tâche, ledit temps de traitement de tâche étant la somme des temps totaux de traitement de chaque module déterminé par ledit deuxième drapeau.

Dans ce cas, l'appareil peut comprendre en outre
un premier registre associé audit module pour mémoriser le temps de traitement réellement mesuré dudit module;
un deuxième registre associé audit module pour mémoriser un temps de traitement estimé dudit module;
un troisième drapeau qui détermine si ladite valeur de premier registre représente le pire des cas dudit temps de traitement de module, l'état desdits drapeaux dépendant de l'algorithme dudit module.

L'algorithme dudit module peut alors inclure l'un des trois types suivants: uniforme, fragmenté intelligent et fragmenté inintelligent.

Dans ce cas, l'appareil peut comprendre en outre une horloge servant à déterminer ledit temps réel de traitement du module, incluant toutes activités reliées du système, et
ladite horloge peut alors déterminer ledit temps réel de traitement du module en référence à un cycle d'instructions.

Dans un tel appareil, ladite horloge pourrait mesurer, chaque fois que ledit module est traité, un temps réel de traitement dudit module, ledit premier registre étant mis à jour à l'aide dudit temps mesuré de traitement si ledit temps mesuré de traitement est plus grand que la valeur actuelle dudit premier registre, et ledit premier registre n'étant pas mis à jour dans le cas contraire.

De préférence, l'appareil comprend alors en outre une série de vecteurs d'échelle associés audit module, permettant audit module d'exercer sa fonction dans une série de représentations.

Lesdits vecteurs d'échelle peuvent alors inclure une vitesse de séquence, un facteur d'échelle et une valeur de traitement.

Dans le cas de la solution préférée mentionnée plus haut, ledit temps de traitement estimé dudit module est dérivé dudit vecteur d'échelle.

Dans le cas de la solution préférée déjà mentionnée, le temps de traitement du module peut être modifié dynamiquement en fonction de ladite disponibilité de temps de traitement à l'intérieur de ladite séquence.

L'appareil peut comprendre alors un moyen de mémorisation pour mémoriser des temps de traitement mis à jour.

Dans ce cas, l'appareil peut comprendre un moyen de calcul dudit temps d'exécution de ladite liste de tâches sur la base desdits temps de traitement mis à jour dans ledit moyen de mémorisation.

Selon le troisième aspect de l'invention, il est fourni un procédé mis en oeuvre dans un système d'ordinateur à base de séquences, incluant un processeur de signaux numériques de traitement d'une tâche sur une base de temps partagé, et destiné à déterminer si ladite tâche peut être prise en charge de façon appropriée sur la base dudit temps partagé comprenant les étapes consistant à
déterminer un temps de traitement de chaque tâche, ladite tâche comprenant au moins un module, ledit temps de traitement de chaque tâche étant calculé en déterminant une utilisation des modules de ladite tâche dans le pire des cas et en ajoutant les uns aux autres les temps de traitement de chaque module correspondant à la situation du pire des cas;
déterminer une quantité de temps de traitement qui est disponible pour un traitement en temps partagé par séquence;;
déterminer la fréquence à laquelle des tâches en temps partagé sont actuellement en cours d'exécution;
calculer une fréquence d'exécution de tâches en temps partagé lorsque ladite tâche est elle aussi installée;
comparer ladite fréquence de traitement de ladite tâche à la fréquence nécessaire de tâche.

Ces buts, particularités et avantages de la présente invention, ainsi que d'autres, seront mieux compris à l'aide de la description d'un mode de réalisation préféré, donnée à titre d'exemple et non à titre limitatif, en liaison avec les figures des dessins annexés, dans lesquels des références numériques semblables désignent des éléments similaires et dans lesquels::
La Figure 1 illustre un système d'ordinateur qui peut être utilisé par le mode de réalisation préféré de la présente invention;
la Figure 2 illustre une architecture de système de logiciel qui peut être utilisé par le mode de réalisation préféré de la présente invention;
la Figure 3 illustre une succession de séquences incluant le traitement d'une tâche d'appareil de sonorisation dans l'une des séquences;
la Figure 4 illustre une structure de programmation comportant des tâches d'une liste de tâches, et des modules associés à chacune des tâches.

La Figure 5 est un graphe d'une valeur de largeur de bande de traitement garantie, ou GPB, réelle pour un module particulier.

La Figure 6 est un graphe illustrant la valeur de largeur de bande de traitement garantie estimée pour un module particulier.

La Figure 7 est un algorithme uniforme.

La Figure 8 illustre, en référence au traitement d'un module fragmenté intelligent, les états du drapeau UseActualGPB et du drapeau DelayUseActualGPB, c'est-à-dire littéralement: utiliser la GPB réelle et retarder l'utilisation de la GPB réelle.

La Figure 9 illustre une tâche de répondeur téléphonique comprenant des modules groupés.

On va maintenant décrire de façon détaillée l'invention à l'aide d'un mode de réalisation comprenant un procédé et un appareil de manipulation dynamique, c'est-à-dire adaptative en temps réel à un environnement réel, de l'allocation de ressources.

Dans la description qui suit, dans un but d'explication, de nombreux détails spécifiques, par exemple des dimensions de registres et de tampons, des fréquences, des longueurs de séquences, des valeurs d'horloge, des fréquences d'échantillonnage, des vecteurs de largeur de bande de traitement garantie, etc. sont exposés afin de permettre une compréhension complète de la présente invention. Il ressort cependant clairement à l'homme de l'art que la présente invention peut être mise en oeuvre sans ces détails spécifiques. Dans d'autres cas, des structures et des dispositifs bien connus sont représentés sous forme de schémas fonctionnels afin d'éviter d'obscurcir inutilement la présente invention.

On décrira d'abord un vue d'ensemble du système d'ordinateur du mode de réalisation préféré.

En se référant à la Figure 1, le système de traitement sur lequel le mode de réalisation préféré de la présente invention peut être mis en oeuvre, est représenté en 100. L'appareil 100 comprend une unité de traitement 110 qui est, dans ce mode de réalisation, un processeur spécialisé de signaux numériques, ou DSP. Par exemple, 110 peut être un processeur de signaux appelé DSP 3210 Digital(R)
Signal Processor, commercialisé par American Telephone and Telegraph (AT & ) Microelectronics de Allentown,
Pennsylvanie. Le DSP 110 est commandé par une horloge 111 de DSP qui fournit une référence de synchronisation.

Le système de traitement 110 est également couplé à un circuit 120 d'accès direct en mémoire, ou DMA, sériel audio qui facilite des transferts entre une mémoire locale 112 et/ou une information transférée sur un bus 150. Dans certains modes de réalisation, il n'existe aucune mémoire locale 112, de sorte que le circuit d'accès direct en mémoire 120 peut permettre des transferts par accès direct en mémoire sur un bus 150. Ceci peut inclure une information transférée par l'intermédiaire du bus 150 depuis un circuit 160 d'ordinateur serveur et/ou une mémoire de processeur serveur (non représentée). De plus, le circuit sériel audio 120 d'accès direct en mémoire fournit de façon sérielle une sortie à un port audio, par exemple 122 sous commande de l'horloge sérielle 121.Le DSP 110 est également couplé à un port de télécommunication 112 pour la transmission d'informations d'entrée/sortie, ou E/S sérielle et par bits, par exemple une information de donnée de télécopieur et/ou d'ordinateur, transmise par des lignes téléphoniques.

Le système de traitement 100 comprend en outre une unité de commande 140 de bus qui est couplée au
DSP 110 et un circuit d'interface 130 de bus qui facilite la communication entre le système 100 et le bus 150. Le bus 150 peut être, soit le bus de l'ordinateur dans lequel le système 100 est installé, soit un bus de serveur couplé à un processeur serveur 160. Le bus 150 peut être couplé à d'autres dispositifs, par exemple des unités d'entrée/sortie, une mémoire, des interfaces périphériques (non représentées) pour fournir diverses capacités à l'intérieur du système.

Le système de traitement 100 représenté à la
Figure 1 peut, soit être implanté sous forme d'un circuit résidant sur une carte mère, c'est-à-dire une carte principale de circuit, d'un système d'ordinateur, soit être implanté, selon un autre mode de réalisation, sous forme de carte d'expansion, insérée dans une fente d'un système d'ordinateur et communiquer ainsi avec un processeur serveur 160 par l'intermédiaire d'un bus dé communication 150. Selon un mode de réalisation, le serveur 160, le bus 150 et le système de traitement 100 peuvent être des éléments de la famille Macintosh(R) d'ordinateurs personnels, par exemple le Macintosh(R) Il ou le Macintosh(R)
Quadras, fabriqués par Apple Computer, Inc, de
Cupertino, Californie (Apple et Macintosh(R) sont des marques déposées de Apple Computer, Inc). Le serveur 160 peut comprendre un microprocesseur de l'une des familles 68000 de microprocesseurs, par exemple le 68020, le 68030, ou le 68040, fabriqués par Motorola,
Inc, de Schaumburg, Illinois.

Il faut noter que la structure du système de traitement 100 est représentée selon un mode de réalisation et n'est pas nécessaire pour la mise en oeuvre de la présente invention. Il faut également noter que plusieurs DSP additionnels peuvent être couplés, selon un autre mode de réalisation, à un bus 150 de façon qu'un environnement de traitement multiple puisse être employé pour apporter des capacités accrues. L'homme de l'art comprendra que de nombreuses variantes et modifications du circuit représenté à la Figure 1 peuvent être employées pour mettre en oeuvre la présente invention.

On va maintenant exposer une vue générale de l'architecture du logiciel.

Le logiciel d'exploitation du mode de réalisation préféré fonctionne selon une base de traitement en équipe. Il faut apporter une attention particulière à la division du travail entre le processeur serveur et le DSP. L'architecture d'ensemble du système est illustrée à la Figure 2. Une application de serveur ou client 201 est en interface avec un gestionnaire 202 de DSP. L'application de serveur ou client 201 représente soit un programme spécifique d'application, soit un coffre à outils de niveau supérieur auquel l'application de serveur accède. Le terme de client est utilisé classiquement pour décrire une relation entre une ressource et un demandeur de ressource. Dans ce cas, la ressource qui est demandée est le processeur DSP. On appelle coffre à outils un ensemble prédéterminé de sous-programmes qui peuvent être appelés et qui effectuent des fonctions utilisées classiquement.Typiquement, de tels coffres à outils sont associés à une fonction particulière (par exemple engendrer une sortie graphique). L'application de serveur peut utiliser la fonctionnalité DSP, soit directement en accédant au gestionnaire de DSP, soit par un coffre à outils de niveau supérieur.

Le gestionnaire 202 de DSP réalise la fonctionnalité de serveur au moyen duquel des applications DSP de serveur sont développées et commandées. Le gestionnaire 202 de DSP est en outre en interface avec un dispositif de commande 204 de serveur de DSP. Le dispositif de commande 204 de serveur de DSP exécute sur le processeur serveur et réalise, selon le matériel spécifique, une fonctionnalité nécessaire pour l'interface avec un processeur DSP particulier et une implantation de matériel. Le gestionnaire 202 de DSP est en outre en interface avec une Mémoire Partagée 218. La mémoire partagée 218 peut être définie, soit dans une mémoire locale, soit dans une mémoire principale, soit dans l'une et l'autre. La mémoire principale est la mémoire dynamique à accès direct ou DRAM du système.La mémoire peut résider dans une carte à enficher ou sur la carte logique principale, ou elle peut être définie comme une partie d'une mémoire principale. C'est par l'intermédiaire de cette mémoire partagée 218 que communiquent le gestionnaire 202 de DSP et le noyau résidentiel de programme, appelé simplement noyau résidentiel dans ce qui suit, 211 de DSP.

En ce qui concerne le processeur de DSP, un module 210 de DSP est en interface avec le noyau résidentiel 211 de DSP. Le module 210 de DSP représente une fonction d'un programme particulier qui a été écrit pour le processeur de DSP. Le noyau résidentiel de DSP réside dans un emplacement de mémorisation directement accessible par le processeur de DSP. Le noyau résidentiel 211 de DSP est en interface avec un dispositif de commande 212, le noyau résidentiel de DSP et avec la mémoire partagée 218. Le dispositif de commande 212 de noyau résidentiel de DSP contient des sous-programmes dépendant du matériel et il réside dans une mémoire locale ou dans la mémoire de système directement accessible par le processeur de
DSP.Le dispositif de commande 212 de noyau résidentiel de DSP communique avec le dispositif de commande 204 du serveur de DSP par l'intermédiaire de la mémoire partagée 218 et à travers des interruptions directes 219. La combinaison du gestionnaire 202 de
DSP, du dispositif de commande 204 de serveur de DSP, de la mémoire partagée 218, de noyau résidentiel 211 de DSP et de dispositif de commande 212 de noyau résidentiel de DSP constituent le système d'exploitation 220 de DSP.

On va maintenant décrire les structures de programmation.

L'environnement de programmation du mode de réalisation actuellement préféré de la présente invention comprend trois structures de base: des sections, des modules et des tâches. La structure de base d'une application de DSP est la section. Une section contient une information concernant le code exécutable par le DSP, des données, des variables et des tampons d'entrée/sortie. Un certain nombre de sections sont groupées entre elles pour former un module. Des modules sont envoyés au programmeur serveur sous forme de ressources et ils sont logés dans une structure de tâches de DSP en utilisant le gestionnaire de DSP. Un module contient une information servant à lier des modules entre eux et à commander l'exécution des modules, en permettant ainsi au gestionnaire de DSP et au noyau résidentiel de DSP d'exercer leurs fonctions.

Certains modules sont groupés entre eux pour former des tâches. Fréquemment, une tâche de DSP ne contient qu'un seul module de DSP. La raison de la formation d'une tâche est de placer ensemble, selon un ordre approprié et avec des liaisons de tampons d'entrée/sortie appropriés, toutes les fonctions de base du module nécessaires pour effectuer un travail particulier. Une autre raison est d'assurer que les fonctions combinées s'exécutent sous forme d'un ensemble, en produisant ainsi des résultats cohérents d'exécution. Les tâches et leurs modules respectifs sont lancées et arrêtées sous la forme d'une unité, sont installées dans la liste des tâches et en sont enlevées sous forme d'une unité, et elles sont construites et reliées à des courants de données sous forme d'une unité unique.Une tâche est construite par le programmeur d'application de serveur en utilisant une série d'appels au gestionnaire de DSP. Ces appels créent la structure de tâche, chargent et connectent les modules selon l'agencement souhaité, allouent la mémoire nécessaire et installent la tâche achevée dans la liste des tâches de DSP.

On va maintenant exposer le système de largeur de bande de traitement garantie, ou GPB.

La Figure 3 illustre un exemple d'une découpe du temps en tranches en une série de séquences 311 à 315.

La séquence 313 est la séquence actuelle; les séquences 311 et 312 sont des séquences antérieures qui ont déjà été exécutées; et les séquence 314 et 315 sont des séquences futures qui seront exécutées à la suite de l'exécution de la séquence 313. La Figure 3 inclut également un exemple d'une tâche d'appareil de sonorisation consistant en modules 316 à 321. La séquence 313 a été agrandie pour permettre une vue plus détaillée de l'exécution de la tâche de l'appareil de sonorisation. Les modules 313 à 321 de la tâche de l'appareil de sonorisation traitent et mélangent trois canaux sonores, par exemple musique, paroles et effets de son, en commutant entre cinq modules différents, 316 à 321 pour traiter successivement des blocs de données au moyen d'algorithmes différents. Un décompresseur 316 CD-XA est utilisé pour décomprimer une musique comprimée ou une parole comprimée. Puis, un décodeur 317 de sousbande et un convertisseur 318 à fréquence d'échantillonnage de 8 à 24 kHz sont utilisés pour traiter la parole qui a été comprimée selon une qualité téléphonique en vue d'un facteur de compression plus élevé et pour élever ensuite, par conversion, à la vitesse de transport du système. Un convertisseur 22.2545 à la fréquence d'échantillonnage de 24 kHz est implanté en vue de traiter des effets de sons enregistrés à une fréquence différente de la fréquence de 24 kHz du système. Un mélangeur audio 320 à 24 kHz est implanté de façon à mélanger les trois canaux sonores. Finalement, le son est sorti vers le
FIFO, ou premier entré-premier sorti, du haut-parleur en 321. Avant et après chaque exécution de module, des opérations d'entrée en cache 323 sont exécutées avec une commutation de contexte.

On peut voir que la tache 316 à 321 d'appareil de sonorisation utilise approximativement la moitié de la séquence 313. D'autres tâches pourraient être exécutées pendant le temps restant 322 de la séquence 313. Cependant, il faut déterminer en premier lieu si chaque tâche additionnelle peut être complètement exécutée à l'intérieur de la séquence 313. Par conséquent, chaque fois qu'un client demande qu'une tâche soit installée, le système d'exploitation doit déterminer s'il existe suffisamment de temps disponible pour traiter cette tâche à l'intérieur des séquences suivantes. La présente invention effectue ceci en implantant un système de largeur de bande de traitement garanti, ou GPB.

Le système de largeur de bande de traitement garantie comprend un ensemble de deux registres et de trois drapeaux associés à chaque module. Ces registres et ces drapeaux sont liés à chaque module et sont mémorisés avec lui. Les deux registres sont le registre de GPB réelle, qui mémorise la valeur réelle de GPB, et le registre de GPB estimée, qui mémorise la valeur estimée de la GPB. Les trois drapeaux, et leurs traductions littérales respectives, sont le drapeau
UseActualGPB, c'est-à-dire utiliser la GPB réelle, le drapeau DelayUseActualGPB, c'est-à-dire retarder l'utilisation de la GPB réelle, et le drapeau
DontCountThisModule c'est-à-dire ne pas tenir compte de ce module. Les calculs de ces valeurs et la manière dont les drapeaux sont placés, ainsi que les fonctions et les raisonnements concernant chacun de ces registres et drapeaux, sont expliqués ci-dessous.

On va maintenant décrire le registre de largeur de bande garantie réelle, ou registre GPB Actual.

Le registre de largeur de bande de traitement garantie réelle, ou registre GPB Actual est lancé à la valeur 0. Chaque fois qu'un module est exécuté, le temps nécessaire pour traiter ce module est calculé.

Ceci est atteint en implantant une horloge fonctionnant en continu. On suppose que l'horloge compte à une vitesse proportionnelle à la vitesse d'instruction de base du processeur, c'est-à-dire que l'horloge 211 de DSP à la Figure 1 fournit le signal d'horloge tant pour le processeur que pour le dispositif de mise à l'échelle préalable de l'horloge.

Immédiatement avant que le noyau résidentiel de DSP ne commence à traiter un module, la valeur d'horloge est lue et sauvegardée. Lorsque le noyau résidentiel de
DSP achève le traitement du module, la valeur d'horloge est à nouveau lue et sauvegardée immédiatement. La différence entre la première valeur d'horloge et la deuxième valeur d'horloge détermine le temps écoulé nécessaire pour traiter ce premier module. Le temps écoulé inclut toutes les activités du système, comme les opérations de cache, les opérations d'entrée/sortie inhérentes à l'exécution, la mise en place, l'exécution du module, les accès au bus, tout processus de nettoyage à la fin, par exemple annuler les effets de cache, renvoyer en sauvegarde à la mémoire, opération de sortie, etc. En d'autres termes, le temps écoulé est le temps total nécessaire pour traiter ce module particulier.Ce temps de traitement réellement mesuré est mémorisé dans le registre GPB
Actual.

En additionnant les uns aux autres les temps de traitement de chaque module de la liste de tâches, le temps de traitement de la liste de tâches peut être déterminé. La Figure 4 illustre une structure typique de programmation dans laquelle une liste 400 de tâches comprend des tâches 401 à 403 prêtes à être exécutées.

La liste 400 de tâches est utilisée pour identifier des tâches attendant d'être exécutées. La tâche 401 comprend trois modules 404 à 406. La tâche 402 comprend un module unique 407. Enfin, la tâche 403 comprend les deux modules 408 et 409. Chaque module est constitué de sections (non représentées).

L'ordre d'exécution de tâche va du haut en bas de la liste des tâches, par exemple 401, puis 402, puis 403. L'ordre d'exécution des modules va de la gauche vers la droite. Par exemple, en ce qui concerne la tâche 401, le module 404 serait exécuté en premier et serait suivi par le module 405 et finalement par le module 406. Le programme d'application de serveur spécifie si une tâche est active. Si une tâche n'est pas active, elle est contournée par l'ordre d'exécution. De même, l'exécution d'un module spécifique peut être contournée en implantant un mécanisme de saut de module.

En se référant à la Figure 4, lorsque le noyau résidentiel de DSP commence l'exécution de la tâche 401, la valeur de l'horloge to est lue et est sauvegardée. A la fin du module 404, la valeur d'horloge t2 est lue est sauvegardée. La différence de temps entre t2 et t0 est le temps écoulé 410. Le temps écoulé 410 étant nécessaire pour traiter le module 404, il inclut également toute les activités du système comme décrit ci-dessus. Lorsque le noyau résidentiel de DSP cesse d'exécuter le module 405, la valeur d'horloge est à nouveau lue et sauvegardée. Le temps écoulé 411, c'est-à-dire t4 - t2 est le temps nécessaire pour traiter le module 405. A l'achèvement du module 406, la valeur d'horloge, t6, est elle aussi lue et sauvegardée. Le temps écoulé 412 entre t6 et t4, est le temps nécessaire pour traiter le module 406.Le temps nécessaire pour traiter la tâche 401 est la somme des temps cumulatifs 410, 411 et 412. Cette procédure peut être répétée pour les tâches 402 et 403 afin de déterminer le temps total de traitement de la liste 400 de tâches. On notera que la valeur de l'horloge t6 est la valeur de t0 pour la tâche 402.

Si une tâche est inactive, le procédé de synchronisation décrit ci-dessus ajoute, dans la valeur de GPB du module suivant qui s'exécute, le temps de traitement nécessaire pour sauter au-dessus de la tâche inactive. Par exemple, si la tâche 402 est inactive, la valeur de t6 serait en définitive le t0 de la tâche 403. Ainsi, le temps nécessaire pour exécuter le module 408 inclurait le temps nécessaire pour sauter au-dessus de la tâche inactive 402. Afin d'éviter ceci, il faut recharger à partir de l'horloge la valeur de début utilisée pour une tâche si la tâche précédente est inactive, plutôt que d'utiliser la valeur finale venant du dernier module de la tâche active précédente. Ce processus, en fait, ne prend pas en compte le temps de saut de tâches inactives.

Cependant, lorsque la tâche est active, la charge de traitement est sensiblement plus grande que lorsqu'elle est inactive. On peut donc supposer que le temps de traitement de "saut de tâche inactive" est inclus en tant que partie du temps actif de traitement.

Chaque fois qu'un module est traité, la procédure de mesure ci-dessus est exécutée sur ce module afin de déterminer le temps nécessaire pour traiter ce module.

Le temps de traitement de module réel mesuré est comparé à la valeur du registre GPB Actual. La plus grande de ces deux valeurs est mémorisée dans le registre GPB Actual. Il en résulte un algorithme de détection de pics dans lequel la GPB maximale réelle utilisé, y compris des variations de bus et d'entrée/sortie est maintenue dans le registre GPB
Actual. En d'autres termes, la valeur de GPB Actual donne le temps de traitement dans le pire des cas qui est en cours d'utilisation par ce module, jusqu'à cet instant.

La Figure 5 est un graphe qui illustre la valeur de GPB Actual pour un module d'échantillon. L'axe des y est le temps de traitement réel mesuré utilisé par un module particulier. L'axe des x représente le temps réel. Le registre GPB Actual est initialement chargé à une valeur de 0. Le module est traité un certain nombre de fois, comme indiqué par les rectangles ombrés. Chaque fois que le module est traité, le temps réel de traitement est comparé à la valeur du registre
GPB Actual. Si le temps réel de traitement est supérieur à la valeur du registre GPB Actual, le temps réel de traitement remplace la valeur dans le registre
GPB Actual. Il en résulte une valeur 500 du GPB
Actual. On notera que la valeur 500 du GPB Actual est mise à jour quand la dernière valeur a été calculée et quand le module a achevé l'exécution de cette séquence.

On va maintenant décrire le registre de largeur de bande garantie estimée, ou registre GPB Estimate
Chaque module comprend également un registre GPB
Estimate. Le registre GPB Estimate est chargé initialement d'une valeur de GPB Estimate par le programmeur spécialisé de signaux numériques, ou DSP, ou par des outils automatique de profilage. La valeur de GPB Estimate est le niveau maximal estimé du temps de traitement qui pourrait être utilisé par ce module.

Une valeur estimée est utilisée parce que certaines parties du temps de traitement dépendent de la latence du bus et d'autres facteurs, par exemple différentes machines ou autres implantations, ou varient même, pour les mêmes machines, lorsque les utilisateurs les modifient la configuration à l'aide de cartes d'expansion facultatives additionnelles. La Figure 6 est un graphe qui illustre la valeur 600 de GPB
Estimate pour un module particulier. La valeur de GPB
Estimate peut être déterminée expérimentalement, calculée par les outils du DSP ou profilée en référence à une horloge.

Dans le mode de réalisation actuellement préféré, les temps de traitement sont mesurés en fonction de cycles d'instruction. En utilisant des cycles d'instruction de DSP comme unités de mesure, le temps d'exécution ajuste la vitesse du DSP particulier utilisé. Par exemple, pour des séquences de 10 millisecondes, 166.666 cycles sont disponibles pour des cycles d'instruction de 60 nanosecondes, et 125.000 cycles sont disponibles pour des cycles d'instruction de 80 nanosecondes. Par conséquent, si un processeur est mise en oeuvre avec des cycles d'instruction de 60 nanosecondes au lieu de cycles d'instruction de 80 nanosecondes, un nombre plus grand de cycles d'instruction est disponible pour cette séquence particulière. La vitesse de traitement est connue par le dispositif de commande de DSP pour cette implantation particulière de matériel.Lorsque le noyau résidentiel de DSP calcule le temps de traitement disponible, il demande cette information au dispositif de commande de DSP et il l'inclut dans les calculs. Les valeurs mémorisées dans les registre GPB actual et GPB Estimate sont en référence à des cycles d'instruction du processeur. Ainsi, lorsque des temps de traitement sont décrits, c'est en référence à des cycles d'instruction du DSP.

On va maintenant préciser les catégories d'algorithmes.

Les registres GPB Actual et GPB Estimate sont utilisés différemment selon la manière dont l'algorithme du module est catégorisé. Les algorithmes du module sont divisés en trois catégories séparées: uniforme, fragmenté intelligent et fragmenté inintelligent. Un algorithme uniforme est un algorithme qui prend en permanence à peu près la même quantité de temps pour exécuter une séquence. Les différences entre les temps d'exécution des différentes séquences sont dues à des variations mineures à l'intérieur de l'algorithme et elles sont également dues à des variations qui ne sont pas sous commande de l'algorithme, par exemple, un traitement d'entrée/sortie traité par le noyau résidentiel de
DSP, et le temps inactif de bus qui varie selon la quantité de circulation sur le bus.Il faut que ces différences soient maintenues à l'intérieur de quelques pour cent pour qu'un algorithme soit appelé uniforme. La Figure 7 illustre un algorithme uniforme.

Certains exemples d'algorithmes uniformes incluent des algorithmes d'implantation de filtres à réponse d'entrée finie (FIR) et à réponse d'entrée infinie (lIR), des égaliseurs, des processeurs d'échos, etc.

En général, un algorithme uniforme effectue une certaine quantité de traitements qui n'exige que peu de décisions, ou n'en exige aucune.

Un algorithme fragmenté est caractérisé par des périodes d'activité élevée. Un algorithme fragmenté peut utiliser des quantités variables de temps de traitement pour chaque séquence. Le temps de traitement varie selon la donnée qui est traitée, l'état de la fonction que le module est en train de traiter et d'autres variables. Les Figures 5 et 6 représentent des algorithmes fragmentés.

Un algorithme fragmenté intelligent est un algorithme qui possède la capacité de déterminer, par le programme, les cas dans lesquels il exécute un code qui l'amène à utiliser le temps maximal de traitement.

Un exemple d'algorithme fragmenté intelligent est un modem à fréquences multiples. Un modem à fréquences multiples comprend diverses étapes, par exemple lancement, mise en place et transfert de données. Le temps maximal de traitement est habituellement associé à la pompe de données d'état stable. Dans le mode de réalisation préféré, lorsque la situation de temps maximal de traitement se produit, l'algorithme fragmenté intelligent lance un appel au noyau résidentiel de DSP qui place alors le drapeau
UseActual GPB. Le noyau résidentiel de DSP ne place pas réellement ce drapeau avant que les calculs de GPB de ce module ne soient achevés. Cet aspect sera expliqué de façon plus détaillée ci-après.

Un algorithme fragmenté inintelligent est un algorithme qui ne possède pas la possibilité de déterminer, par le programme, les cas dans lesquels il exécute un code qui l'amène à une utilisation maximale, ou supérieure au maximum, du temps de traitement. Un exemple d'un algorithme fragmenté inintelligent est analogue à un décodeur de Huffman.

Un décodeur de Huffman prend un temps plus long pour décoder certains types de trains de bits que d'autres types de trains de bits. Le temps de traitement peut même devenir illimité dans le scénario du pire des cas, dans lequel un bruit aléatoire est entré. Un mécanisme séparé est prévu pour gérer ce type d'algorithme. Dans le mode de réalisation préféré, ceci est traité en ajoutant deux appels au noyau résidentiel de DSP: l'un pour déterminer la quantité de temps qui est allouée (par l'intermédiaire du GPB
Estimate) et l'autre pour déterminer la quantité qui a déjà été utilisée. C'est donc au programmeur de DSP qu'il revient d d'assurer que le module fragmenté inintelligent ne dépasse pas son temps de traitement alloué.

On va maintenant expliquer la manière dont la largeur de bande de traitement garantie ou GPB est utilisée.

Lorsqu'une demande d'installation d'une tâche dans la liste des tâches en temps réel est formulée, le gestionnaire de DSP détermine s'il existe suffisamment de temps de traitement disponible par séquence à cet instant. Lorsqu'une application appelle le gestionnaire de DSP pour demander l'installation d'une tâche, la GPB actuelle disponible est calculée.

La détermination est effectuée en comparant le temps estimé de traitement de cette tâche au temps de traitement restant disponible dans la séquence. Le temps de traitement restant est calculé en soustrayant, du temps total de traitement disponible pour cette séquence, les valeurs de GPB Actual ou GPB
Estimate pour les modules correspondants aux tâches déjà installées. S'il existe suffisamment de temps de traitement disponible, la nouvelle tâche est installée. Dans le cas contraire, un message d'erreur est renvoyé à l'application ou au client qui tente d'effectuer l'installation et la tâche n'est pas installée. Le gestionnaire de DSP peut demander facultativement la GPB de ses clients existants en premier lieu, et si un client quelconque envoie sa GPB au système, un message d'erreur peut être inutile.

On va maintenant décrire la manière dont il est déterminé s'il y a lieu d'utiliser la valeur GPB
Actual et la valeur GPB Estimate. Dans le cas d'algorithmes uniformes, le drapeau UseActualGPB est placé dans le code de source du module. L'état initial du drapeau est indiqué dans la source de donnée du module. Puisque le drapeau UseActualGPB est placé, la valeur GPB Actual est utilisée comme temps correct actuel de traitement du module. Cependant, si la valeur de GPB Actual est 0, la valeur GPB Estimate est utilisée en remplacement dans les calculs. En d'autres termes, la valeur de GPB Estimate est utilisée jusqu'à ce que le module ait une chance de fonctionner au moins une fois. Ensuite, la valeur GPB Actual est utilisée, qu'elle soit plus petite ou plus grande que la valeur GPB Estimate.Dans le mode de réalisation actuellement préféré, la valeur de GPB Actual est mise à jour (algorithme de pics) pour un module chaque fois que ce module particulier est exécuté. Le système de
GPB s'adapte ainsi à différentes configurations d'unité centrale de traitement et à des variations en temps réel, par exemple le chargement du bus.

Dans le cas d'algorithmes fragmentés intelligents le drapeau UseActualGPB n'est pas placé initialement parce que la valeur GPB Actual est sans signification jusqu'à ce que la situation de temps maximal de traitement soit atteinte. Puisque le drapeau
UseActualGPB n'est pas encore placé, la valeur du GPB
Estimate est utilisée comme temps correct actuel de traitement pour ce module. Cependant, si la valeur de
GPB Actual est plus grande que celle de GPB Estimate, c'est la plus grande des deux valeurs qui est utilisée. Cette condition se produit chaque fois qu'un module n'a pas encore tout à fait atteint le pire de ses cas mais a déjà dépassé l'estimation. Lorsqu'un algorithme fragmenté intelligent détermine qu'il a atteint la situation de temps maximal de traitement, il effectue un appel au noyau résidentiel de DSP pour placer le drapeau DelayUseActualGPB.

La raison pour laquelle un drapeau
DelayUseActualGPB est nécessaire est que, si le gestionnaire de DSP interroge les valeurs de GPB entre l'instant où l'appel au noyau résidentiel est effectué par le module de DSP et celui où le dernier GPB Actual est calculé à la sortie du module, il restitue une valeur erronée de GPB Actual. La raison en est que le registre GPB Actual contient encore, à cet instant, la valeur réelle mémorisée précédemmént. La valeur réelle du scénario actuel n'a pas encore été mise à jour.

Par conséquent, il faut un drapeau
DelayUseActualGPB. La Figure 8 illustre la manière dont le drapeau 800 UseActualGPB et le drapeau 801
DelayUseActualGPB sont utilisés en référence au traitement du module intelligent fragmenté. Un certains laps de temps après la limite 803 de début de séquence, le traitement du module intelligent fragmenté commence à l'instant 804. Le traitement continue jusqu'à l'instant 805. Le module de DSP appelle le noyau résidentiel de DSP pour placer le drapeau 800 UseActualGPB à l'instant 806. L'appel amène le drapeau 801 DelayUseActualGPB à être placé.

On notera que le drapeau 800 UseActualGPB est maintenu dans l'état hors fonction (non placé) un bref instant après que le module a été traité, la valeur GPB Actual est déterminée et mémorisée dans le registre GPB
Actual à l'instant 807. Le noyau résidentiel de DSP vérifie ensuite le drapeau 801 DelayUseActualGPB à un instant ultérieur 808. Si ce drapeau est placé, le drapeau 800 UseActualGPB est placé, le drapeau 801
DelayUseActualGPB est restauré à l'état hors fonction (non placé). Ainsi, s'il arrive que le gestionnaire de
DSP interroge la valeur de GPB dans l'intervalle, tandis que le module est en cours de traitement, c'est la valeur de GPB Estimate qui est utilisée et non une valeur erronée de GPB Actual (à moins que la valeur
GPB Actual ne soit déjà supérieure à GPB Estimate).

Dès lors que le registre GPB Actual a été mis à jour de façon appropriée, la valeur de GPB Actual est utilisée. Cette valeur de GPB Actual est utilisée ensuite et la valeur est mise à jour de façon additionnelle selon les besoins par l'algorithme de pics décrit précédemment.

Une variante de procédé de traitement de mise en place du drapeau consiste à demander au programmeur de
DSP de placer le drapeau UseActualGPB à la séquence qui suit l'instant où le traitement maximal s'est produit, par l'appel du noyau résidentiel. Ceci est fonctionnellement correct, mais ajoute un fardeau de programmation au programmeur de DSP et augmente le potentiel d'erreurs.

Comme décrit brièvement ci-dessus, l'algorithme effectue deux appels au noyau résidentiel de DSP dans le cas d'algorithmes inintelligents fragmentés. Un appel recherche le temps de traitement attendu pour ce module, qui est mémorisé dans le registre GPB
Estimate. L'autre appel recherche la quantité de temps de traitement qui a déjà été utilisée jusqu'à cet instant. L'algorithme compare ces deux valeurs. Si l'algorithme est proche de l'épuisement de son temps alloué, le module doit exécuter sa procédure de terminaison de traitement, c'est-à-dire qu'il abandonne pour cette séquence. Cette procédure doit terminer le traitement d'une manière appropriée pour ce module particulier. En effectuant de façon répétée le deuxième de ces deux appels, l'algorithme reçoit une information permettant de déterminer s'il doit terminer son exécution.Ainsi, un algorithme inintelligent fragmenté doit gérer lui-même son temps de traitement alloué.

Si un algorithme inintelligent fragmenté dépasse son temps alloué, le GPB Actual dépasse le GPB
Estimate. C'est en fait une situation assez probable en ce que le programmeur ne peut effectuer qu'une estimation basée sur ce qu'il sait, parfois appelée estimation éduquée, de la quantité de temps nécessaire pour achever la commutation de contexte à la sortie de son module. Comme décrit précédemment, la plus grande des valeurs est utilisée pour calculer la GPB disponible quand un autre client souhaite installer une tâche additionnelle. Ceci garantit que le temps additionnel de commutation de contexte est inclus dans les calculs futurs de disponibilité de GPB.

Ainsi, le calcul du temps de traitement restant s'effectue en ajoutant toutes les exigences actuelles de traitement de chacun des modules installés, comme décrit, et en soustrayant, du traitement disponible dans la séquence, ce traitement total. On notera que ce calcul inclut aussi bien des tâches actives que des tâches inactives. Ceci est nécessaire pour que le temps de traitement nécessaire pour les tâches inactives soit réservé lorsqu'elles sont activées.

Dès lors qu'une tâche et ses modules reliés ont été utilisés dans le but souhaité, et que l'application se prépare à quitter le traitement, la tâche est déchargée de la liste des tâches, en renvoyant automatiquement sa GPB au système pour qu'elle soit utilisée par d'autres modules. A cet instant, une valeur de GPB plus précise est mémorisée dans le registre de GPB Actual des algorithmes uniformes et intelligents fragmentés. Cette valeur reflète le temps réel d'exécution pour l'environnement actuel. L'application peut choisir de mettre à jour le module sur disque, à l'aide de cette nouvelle valeur réelle en la mémorisant dans GPB Estimate, en mettant effectivement à jour l'estimation. Cette opération est effectuée par le gestionnaire de DSP à la demande du client. En variante, le gestionnaire de DSP peut effectuer ceci automatiquement pour le client.

Cependant, il existe des inconvénients à cette approche, par exemple un traitement de fichiers verrouillés sur disque; une mise à jour des applications contenant des ressources du DSP qui modifie leurs dates de "modification"; ou des utilisateurs multiples mettant à jour une ressource partagée de DSP sur un serveur de fichiers.

Dans le mode de réalisation particulièrement préféré, un fichier "de préférences" est maintenu par le gestionnaire de DSP sur le disque d'amorçage de ce système particulier. Chaque fois qu'une tâche est déchargée, toutes les valeurs améliorées de GPB des modules situés à l'intérieur de la tâche sont écrites dans le fichier des préférences. Chaque fois qu'un module est chargé, le fichier de préférences est vérifié quant à la disponibilité d'une information plus précise, qui est alors utilisée au lieu de l'autre. Ceci élimine les problèmes associés à des serveurs de fichiers et à des dates de modification pour des applications.

On notera que la disponibilité d'un GPB Estimate mis à jour dans le fichier de préférences indique que le module a été utilisé précédemment dans ce système d'ordinateur particulier. Ceci indique également que le GPB Estimate a été ajusté pour refléter la performance de système d'ordinateur, et qu'il est donc de façon significative plus précis que le GPB Estimate du fichier des modules. Cette distinction peut être utilisée pour réduire des dépassements de séquences.

En particulier, le gestionnaire de DSP peut ajouter un certain pourcentage au GPB Estimate pour un module, si rien n'est trouvé dans le fichier de préférences, en comparant le temps de traitement estimé et le temps de traitement disponible. Cette marge additionnelle peut réduire les risques que l'estimation soit trop faible pour cette machine. En variante, cette marge additionnelle peut n'être ajoutée que si le temps de traitement restant disponible est voisin du traitement nécessaire comme indiqué par l'estimation.

Ce mécanisme de mise à jour réalise la dernière étape permettant de fermer la boucle du système pour le rendre réellement adaptatif. Notons que ce processus n'a de signification que pour des modules uniformes et des modules intelligents fragmentés. Des modules inintelligents fragmentés doivent eux-mêmes limiter leur traitement aux valeurs estimées.

On va maintenant décrire les modules groupés.

Le mode de réalisation actuellement préféré de la présente invention utilise une approche d'architecture de composants dans laquelle des modules génériques, permettant de réaliser des fonctions génériques, peuvent être couplés entre eux pour réaliser des fonctionnalités différents. Un exemple de cette approche par modules composants est celle d'un répondeur téléphonique, comme représenté à la Figure 9. La tâche 901 du répondeur téléphonique peut être implantée en groupant entre eux des modules normalisés 902 à 904. Le module d'état 902 fournit l'état et commande des fonctions comme détecter la sonnerie, décrocher la ligne téléphonique, raccrocher le téléphone etc. Puis, le module 903 de décodeur de sous-bande est utilisé pour réaliser une fonction de lecteur pour lire une salutation à l'appelant, et pour relire tout message enregistré.Le module 904 d'encodeur de sous-bande est utilisé pour exercer une fonction d'enregistreur.

La tâche 901 de réponse téléphonique n'utilise en fait pas tous ces modules 902 à 904 simultanément. Par exemple, lorsqu'un message est lu, la fonction d'enregistreur est inactive et vis-à-vis. Ainsi, calculer les valeurs de GPB pour cette tâche en additionnant les temps de traitement de chaque module provoquerait une surestimation parce que tous les modules ne sont pas exécutés dans la même séquence.

Ceci soustrairait en fait, au détriment d'autres tâches, une largeur de bande de traitement en temps réel qui ne serait jamais utilisée réellement. Par exemple, si la valeur de GPB du module d'état 902 est de 1000 cycles, si celle du module 903 d'encodeur de sous-bande est de 5000 cycles et celle du module 904 de décodeur de sous-bande de 6000 cycles, la valeur totale de GPB est de 12.000 cycles. La situation du pire des cas est en fait de 7000 cycles (module 902 de statut plus module 904 de décodeur de sous-bande).

Ainsi, la tâche 901 de répondeur téléphonique n'exige pas une allocation de 12.000 cycles. Bien plutôt, 7.000 cycles constituent la totalité des besoins.

Afin de rendre plus efficace l'allocation de temps de traitement dans ce type de situation, le mode de réalisation actuellement préféré de la présente invention utilise un drapeau DontCountThisModule, c'est-à-dire: ne pas tenir compte de ce module.

Lorsqu'est effectuée une demande de détermination du temps de traitement pour une tâche particulière, le gestionnaire de DSP vérifie chacun des modules de la tâche pour déterminer si ce drapeau est placé. Si le drapeau DontCountThisModule est placé pour un module, la valeur de GPB de ce module particulier n'est pas incluse dans la valeur totale de GPB de cette tâche.

C'est la responsabilité du client qui installe la tâche que de déterminer l'utilisation des modules dans le pire des cas et de placer les drapeaux
DontCountThisModule pour les modules concernés. Par conséquent, dans l'exemple donné ci-dessus, le drapeau
DontCountThisModule est placé pour le module 903 d'encodeur de sous-bande.

On notera que la GPB utilisée par la liste des tâches est, de façon incorrecte, calculée trop faible si le programmeur utilise de façon incorrecte le drapeau DontCountThisModule, en permettant l'installation de tâches additionnelles lorsqu'aucune d'elles en fait n'est souhaitable. Dans ce cas, il peut se produire un dépassement de séquence. Une manière de corriger ce problème consiste à maintenir un registre GPB Actual dans la structure de tâche pour une vérification de niveau de tâche sur la charge de traitement. Cette mesure additionnelle permet une meilleure correction d'erreur et une meilleure récupération si un programmeur effectue cette erreur.

On va maintenant décrire les vecteurs d'échelle.

Un autre aspect de la présente invention qui améliore les fonctions modularisées de processeur spécialisé de signaux numériques, ou DSP, dans diverses configurations, est l'utilisation de vecteurs d'échelle. Des vecteurs d'échelle permettent à un module de fonctionner dans des représentations concrètes multiples. En d'autres termes, des vecteurs d'échelle permettent à des module génériques de s'adapter à diverses dimensions de tampons, à diverses vitesses d'échantillonnage et à diverses vitesses de séquences. Diverses valeurs de GPB sont également mise en oeuvre pour correspondre aux diverses représentations concrètes. Par exemple, un module dont la valeur de GPB est de 5.000 cycles à une vitesse de séquence de 100 cycles peut n'exiger que 2.700 cycles à une vitesse de 200 séquences par secondes.Au lieu de devoir créer un ensemble de modules fonctionnellement identiques pour chaque cas possible, il est possible d'implanter un module unique pourvu de vecteurs d'échelle qui lui permettent d'être utilisé dans tous les cas souhaités.

Lorsqu'un module est programmé en premier lieu, le programmeur détermine les manières différentes dont le module peut être utilisé de façon concevable et il détermine les valeurs respectives de GPB pour chaque implantation différente. Le programmeur énumère ensuite les possibilités sous forme d'une liste de vecteurs d'échelle. La liste est mémorisée avec le module. Lorsqu'une application tente d'utiliser le module d'une certaine manière, le chargeur détermine, à partir de la liste de vecteurs d'échelle du module, si le module peut être utilisé pour cette représentation. Le chargeur choisit également la valeur de GPB de cet représentation.

Un vecteur d'échelle comprend trois valeurs: une vitesse de séquences, un facteur d'échelle et une valeur de GPB. Le facteur d'échelle est utilisé pour déterminer la dimension de tampons d'entrée/sortie qui peuvent être mises à l'échelle pour un module particulier. Le Tableau 1 ci-dessous illustre certaines applications possibles pour un convertisseur de vitesses d'échantillonnage selon un rapport 2 à 1.

Tableau 1 100 séquences/secondes 24 kHz à 12kHz 200 séquences/secondes 24 kHz à 12 kHz 100 séquences/secondes 8 kHz à 4 kHz 200 séquences/secondes 8 kHz à 4 kHz 100 séquences/secondes 16 kHz à 8 kHz 200 séquences/secondes 16 kHz à 8 kHz 100 séquences/secondes 48 kHz à 24 kHz 200 séquences/secondes 48 kHz à 24 kHz 100 séquences/secondes 32 kHz à 16 kHz 200 séquences/secondes 32 kHz à 16 kHz
Puisque ce module est un convertisseur selon le rapport 2 à 1, la dimension du tampon d'entrée qui peut être mis à l'échelle dans le code de source doit être réglée à la valeur de 2 et le tampon de sortie susceptible d'être mis à l'échelle doit être placé à 1. Le Tableau 2 représenté ci-dessous donne les dix vecteurs d'échelle correspondants.

Tableau 2 100,120,5000 100f/s, échelle = 120 pour dimension E/S
de 240/120, GPB = 5000 200,60,2500 200f/s, échelle = 60 pour dimension E/S
de 120/60, GPB = 2500 100,40,1666 100f/s, échelle = 40 pour dimension E/S
de 80/40, GPB = 1666 200,20,833 100f/s, échelle = 20 pour dimension E/S
de 40/20, GPB = 833 100,80,3333 100f/s, échelle = 80 pour dimension E/S
de 160/80, GPB = 3333 200,40,1666 200f/s, échelle = 40 pour dimension E/S
de 80/40, GPB = 1666 100,240,10000 100f/s, échelle = 240 pour dimension E/S
de 480/240, GPB = 10000 200,120,5000 200f/s, échelle = 120 pour dimension E/S
de 240/120, GPB = 5000 100,160,6666 100f/s, échelle = 160 pour dimension E/S
de 320/160, GPB = 6666 200,80,3333 200f/s, échelle = 80 pour dimension E/S
de 160/80, GPB = 3333
Lorsqu'une application demande qu'un module soit chargé, un appel est lancé au gestionnaire de DSP.

L'un des paramètres fournis au gestionnaire de DSP dans l'appel est le facteur d'échelle. La vitesse actuelle de séquences du DSP est envoyée automatiquement. S'il existe un facteur d'échelle concordant, les tampons d'entrée/sortie qui peuvent être mis à l'échelle dans le module sont mis à l'échelle de façon appropriée, et la valeur correspondante de GPB est utilisée. On notera qu'un drapeau de tampon de possibilité de mise à l'échelle est inclut dans les drapeaux de tampons pour indiquer si une mise à l'échelle doit être exécutée. Par exemple, si le vecteur 200, 80, 333 est choisi au tableau 1, les dimensions des tampons d'entrée/sortie seraient multipliées par 80, le facteur d'échelle.

Ceci rendrait le tampon d'entrée, dont la dimension initiale est de 2, suffisamment grand pour 160 échantillons, et le tampon de sortie, dont la dimension initiale est de 1, suffisamment grand pour 80 échantillons, ce qui est parfait pour un convertisseur de vitesse d'échantillonnage 2/1 fonctionnant à 200 séquences par seconde, et traitant des données à 32 kHz.

S'il n'existe aucun vecteur d'échelle concordant, une erreur est renvoyée. On notera que l'algorithme de module exige de connaître la dimension de tampon à l'instant de fonctionnement afin de déterminer la quantité de traitement qui est nécessaire. Un appel de noyau résidentiel de DSP ou macro doit être prévu pour fournir à la demande une information de dimension de tampon au module.

Le Tableau 2 indique une relation simple, linéaire, entre la dimension de tampon, ou facteur d'échelle, et la GPB. Si tel était réellement le cas, une valeur unique serait seule nécessaire: la GPB par unité de facteur d'échelle. En réalité, la valeur de
GPB consiste en une certaine valeur, liée à la charge et au traitement du module et ses tampons, et une charge de traitement qui est souvent mais non toujours, une relation linéaire avec la dimension de tampon d'entrée/sortie ou facteur d'échelle. Puisque les valeurs de GPB sont reliées aux facteurs d'échelle d'une façon plus complexe, chacune des valeurs de GPB des vecteurs d'échelle doit être estimée initialement comme représenté au tableau 2 et être ensuite mesurée de façon plus précise dans un système réel, à l'aide d'un certain type d'outils de profilage.

La technique de mise à jour de GPB Estimate décrite ci-dessus, c'est-à-dire le fichier des préférences, peut également être supportée à l'aide de vecteur d'échelle. On y parvient en amenant le gestionnaire de DSP à garder en mémoire le vecteur d'échelle qui a été utilisé et en ne mettant à jour que le GPB Estimate concerné.

Selon un mode de réalisation additionnel, destiné à des applications qui ne connaissent pas le détail d'un module mais qui souhaitent cependant l'utiliser comme bloc composant générique, un appel de gestionnaire de DSP est prévu pour restituer une information concernant le module. L'appel peut être utilisé pour choisir le facteur d'échelle souhaité.

L'appel renvoie les dimensions des tampons d'entrée et de sortie disponibles à la vitesse actuelle de séquences, et les facteurs d'échelle. Cette liste est limitée à des tampons d'entrée/sortie qui peuvent être mis à l'échelle, spécifiés par le programmeur de module. L'application doit effectuer un choix sur la base des dimensions de tampons d'entrée/sortie nécessaires. Le facteur d'échelle associé est ensuite envoyé au chargeur.

On va maintenant préciser le temps de traitement dynamique.

L'exécution de certains programmes pourrait prendre tout le temps de traitement d'une séquence, ou la majorité de ce temps, dans certaines circonstances.

Dans d'autres circonstances, ces mêmes programmes pourraient n'exiger qu'un temps de traitement sensiblement moindre pour être exécutés. Le mode de réalisation actuellement préféré de la présente invention fait varier de façon dynamique le temps de traitement d'un module particulier, selon la disponibilité du temps de traitement.

La présente invention y parvient en utilisant les vecteurs d'échelle. Lorsqu'un module est écrit, le programmeur peut engendrer non pas une seule valeur de
GPB mais un certain nombre de valeurs de GPB diverses pour une vitesse de séquences et un facteur d'échelle donnés. Les valeurs différentes de GPB pour la même vitesse de séquences et le même facteur d'échelle représentent différents niveaux ou modes, selon lesquels le module particulier pourrait être exécuté.

Ainsi, lorsqu'un module souhaite davantage de temps de traitement, l'application peut lancer un appel au gestionnaire de DSP pour déterminer si un temps additionnel est disponible. Si un temps additionnel de traitement est disponible, un vecteur d'échelle spécifique dont la valeur de GPB est plus grande, peut être choisi et utilisé par ce module. En variante, le vecteur d'échelle dont la valeur de GPB est la plus grande qui puisse être chargée, (c'est-à-dire qui s'ajuste dans le temps de traitement disponible), est choisie et utilisée pour ce module.

Un processus similaire est utilisé pour abandonner un temps de traitement inutile. On notera que l'application est responsable d'informer le module, par l'intermédiaire de la mémoire partagée, quand le niveau de GPB est modifié. De même, le module peut demander une modification du traitement en plaçant des valeurs dans la mémoire partagée pour que le client les lise, (mode d'interrogation), ou envoyer un message au client (mode d'interruption). De cette manière, un module particulier peut posséder différents niveaux d'exécution selon la disponibilité de temps de traitement.

Dans le mode de réalisation préféré, un mécanisme est établi entre le module, le client et le gestionnaire de DSP pour effectuer ces modifications de mode de GPB. Ce mécanisme consiste en un mot unique de 32 bits dans la mémoire partagée. Les 16 bits de poids fort contiennent une lecture/écriture pour le serveur et contiennent le numéro de mode souhaité. Les 16 bits de poids faible concernent une lecture/écriture pour le DSP et contiennent le numéro de mode actuel réel. Les deux processeurs peuvent lire tout le mot de 32 bits.

A un instant quelconque, le mode souhaité peut être placé par le serveur, en supposant que les calculs appropriés de GPB ont été formés au préalable.

Le gestionnaire de DSP peut ensuite interroger le mode réel, et traiter la variation de mode lorsque le module de DSP effectue finalement la commutation de mode. On notera que la variation de mode peut être provoquée à l'instigation, soit du module de DSP, par l'intermédiaire d'un message au client, soit par le client. Dans chacun des cas, c'est le client qui lance en fait les appels au gestionnaire de DSP pour effectuer la modification. C'est ensuite la responsabilité du module de DSP que d'activer le nouveau mode, lorsqu'il lit la variation de mode en mémoire partagée, et d'indiquer quand la modification de mode est complète en mémorisant le nouveau numéro de mode dans la mémoire partagée.

La modification de mode est réalisée par l'appel d'un client au gestionnaire de DSP, spécifiant le numéro de mode souhaité. Le gestionnaire de DSP recherche la valeur de GPB de ce mode à partir du vecteur d'échelle et détermine s'il s'agit d'une augmentation ou d'une diminution de la GPB. Si une diminution est indiquée, le nouveau numéro de mode est placé dans la mémoire partagée, et une tâche différée est établie pour interroger la mémoire partagée afin de détecter quand les modes de modules ont été changés. Le GPB Estimate est modifié pour refléter la nouvelle valeur plus faible. Le GPB Actual est laissé tel quel pour l'instant. La commande est ensuite renvoyée au client. Sous la commande de la tâche différée, la mémoire partagée est vérifiée jusqu'à ce que le module effectue la modification de mode.

Lorsque ceci s'effectue, le GPB Actual est sauvegardé, pour être utilisé dans une mise à jour ultérieure du fichier de préférences, et il est placé à 0. Ceci permet à la nouvelle valeur, plus faible, de GPB
Actual d'être calculée, en utilisant l'algorithme normalisé de pics, décrit précédemment.

Si une augmentation de la GPB est déterminée à partir de la modification de mode demandée, un appel interne au gestionnaire de DSP est lancé pour déterminer si une GPB suffisante est disponible pour traiter la demande accrue. S'il existe une GPB suffisante, la GPB nécessaire est prise et le GPB
Estimate est révisé à la hausse, en utilisant la valeur du vecteur d'échelle du nouveau mode. Le GPB
Actual est sauvegardé pour mettre à jour le fichier de préférences à un instant ultérieur. La commande est ensuite renvoyée au client. S'il n'existait pas suffisamment de GPB disponible, le gestionnaire de DSP pourrait demander leurs GPB à tous les clients actuels. Si un client abandonne une partie de sa GPB, et si le résultat en est une GPB disponible suffisante, le processus s'achève comme décrit. En revanche, s'il n'existe aucun moyen d'obtenir la GPB nécessaire, une erreur est renvoyée au client. Le mode actuel n'est donc pas modifié.

On notera que le format des vecteurs d'échelle pour traiter des modes multiples est une simple extension des vecteurs d'échelle de base. Les vecteurs peuvent être agencés selon un ordre quelconque qui permet un groupement par mode, par vitesse de séquence, ou par fréquence d'échantillon, selon le souhait du programmeur. Il existe d'autres procédés d'encoder les modes, qui présentent une certaine valeur mais qui exigent une intelligence additionnelle dans les outils. Par exemple, la dimension du vecteur scalaire pourrait être variable, et il pourrait contenir la vitesse de séquence, le facteur d'échelle et un compte de mode de GPB, suivi par le nombre des valeurs de GPB pour les différents modes. Ceci pourrait permettre plus simplement aux programmeurs de garder trace des modes.En variante, les vecteurs d'échelle pourraient comporter quatre valeurs: un numéro de mode pourrait être inclus pour chaque vecteur. Ceci pourrait éventuellement empêcher certaines erreurs de programmeurs.

L'exemple suivant d'un module de modem illustre comment il est possible de faire varier dynamiquement le temps de traitement selon la disponibilité du temps de traitement. Actuellement, des modems peuvent fonctionner dans une large plage de vitesses différentes, par exemple de 1.200 baud avec V.22 jusqu'à 9.600 baud avec V.32. En outre, diverses autres vitesses de modem existent aussi, et peuvent être développées dans le futur. Généralement, plus la vitesse d'exploitation est rapide, plus il faut le temps de traitement. En d'autres termes, le module de modem exige plus de temps de traitement pour traiter un appel V.32 que pour un appel V.22. Par conséquent, le module de modem peut posséder diverses valeurs de
GPB selon la vitesse d'exploitation souhaitée. Les différentes valeurs de GPB sont reflétées dans les vecteurs d'échelle du module de modem.Le Tableau 3 montre cinq . valeurs différentes de GPB qui correspondent à cinq vitesses différentes d'exploitation, pour une vitesse de séquence de 100 séquences/seconde et un facteur d'échelle de 20.

Tableau 3
Vitesse Vitesse Facteur Valeur d'exploitation de séquence d'échelle de GPB
V.22 100 20 4000
V.22 bis 100 20 4500
V.29 fax 100 20 7000
V.32 100 20 9000
V.32 bis 100 20 9500
Supposons que le module de modem est réglé initialement selon une exigence minimum pour fonctionner en V.22 (GPB DE 4.000 cycles). Lorsque le téléphone sonne, le module de modem demande un temps additionnel de traitement au cas où l'appel entrant serait un V.32 bis (GPB 9500 cycles). Il le fait en renvoyant un message au client de modem. Le client demande la modification de mode en appelant le gestionnaire de DSP. Le gestionnaire de DSP consulte le nouveau vecteur de mode et détermine qu'une quantité additionnelle de 5500 cycles de GPB est nécessaire pour commuter à ce mode. Il détermine ensuite si les 5500 cycles additionnels sont disponibles.Si le temps additionnel de traitement est disponible, le module de modem est notifié par l'intermédiaire de la mémoire partagée et implante le vecteur d'échelle correspondant à V.32 bis: 100, 20, 9500. Le gestionnaire de DSP prend soin des valeurs
GPB Estimate et GPB Actual, comme décrit précédemment.

La valeur de GPB du module de modem est alors 9500 au lieu de 4000. La réponse téléphonique s'effectue. Si l'appel entrant est un V.32 bis, le module de modem possède suffisamment de temps de traitement pour traiter l'appel. En revanche, si l'appel entrant est un V.22 bis, le module de modem retombe à une valeur de GPB de 4500 en implantant le vecteur d'échelle V.22 bis: 100, 20, 4500. Ceci est effectué en envoyant un message au client du modem, qui demande ensuite au gestionnaire de DSP la variation de GPB. Quand l'appel entrant est achevé, le module de modem libère le temps additionnel de traitement en utilisant le même mécanisme en revenant au vecteur d'échelle V.22: 100, 20, 4000.

Dans cet exemple on note que le modem répond au téléphone comme modem V.22 s'il n'existe qu'une GPB insuffisante pour dépasser V. 22, forçant à retomber à
V. 22 un modem appelant à une vitesse plus élevée. Ce processus permet une allocation dynamique de ressources du DSP, selon la charge qui vient des exigences des utilisateurs à un instant quelconque.

Une variante de mode de réalisation consiste à implanter des vecteurs d'échelle pour calculer une valeur initiale plus précise de GPB Actual pour un module. Il en résulte une valeur initiale plus précise de GPB Estimate. En premier lieu, le dispositif de commande du serveur fournit la donnée d'implantation sur des temps de transfert, mesurés en nanosecondes, nécessaires pour différents types de références de mémoire. Le temps d'accès est la durée moyenne en temps réel, depuis l'instant d'une demande de donnée jusqu'à la réception réelle de la donnée et la fin de la transaction. Il est tenu compte d'une performance de bus et de mémoire dans le temps de transfert. Puis, le nombre d'accès en mémoire de chaque type de référence de mémoire du module est déterminé.

Ceci peut être déterminé par l'un des trois procédés différents suivants. Un procédé consiste pour le programmeur à calculer ces nombres. Selon un deuxième procédé, le matériel de développement peut en fait compter le nombre de fois où le module accède à une référence de mémoire pour une séquence. Selon un troisième procédé encore, le temps nécessaire à l'exécution d'un type particulier de référence de mémoire peut être ralenti. Le temps total nécessaire pour traiter tout le module pour un type de référence de mémoire ralenti est mesuré. Le temps régulier non ralenti de traitement de tout le module est soustrait.

Puis, le différentiel de temps résultant est divisé par la différence entre les temps d'accès d'un accès ralenti et d'un accès réel pour ce type particulier de référence de mémoire. On obtient ainsi le nombre d'accès pour ce module pour ce type particulier de référence de mémoire. Ce procédé est répété pour chaque type différent de référence de mémoire.

Dès lors que les nombres sont connus, le temps total de chaque type de référence de mémoire du module peut être calculé en multipliant le nombre de transferts de mémoire de ce type particulier par le temps nécessaire pour effectuer ce type particulier de transfert de mémoire. Ensuite, le temps estimé de traitement du module entier est déterminé en ajoutant les uns aux autres les temps de chaque type de référence de mémoire. Ce temps de traitement estimé est ensuite converti en une valeur de GPB en le divisant par un rapport temps réel/GPB.

Le tableau 4 ci-dessous illustre par exemple la dérivation d'une valeur de GPB Estimate sur la base de ce type de vecteur d'échelle.

Tableau 4
Compte d'accès Type de référence Temps d'accès
mémoire (Ni) de mémoire (ns)
N1 = 10,00 Mémoire de cache 72 N2 = 205 Mémoire locale - unique 200
N3 = 117 Mémoire locale-recherche 150
ou transfert en bloc
N4 = 82 Mémoire de système - unique 1200
N5 = 41 Mémoire de système-recherche 1000
ou transfert en bloc
Etant donné un système d'ordinateur possédant cinq types différents de référence de mémoire, le temps moyen d'accès à chaque type de référence de mémoire est déterminé. On notera que d'autres types de systèmes d'ordinateur peuvent inclure des types additionnels de références de mémoire. Pour un module particulier, le nombre de fois où ce module effectue ce type de référence de mémoire, c'est-à-dire le compte d'accès de mémoire N1-5, est calculé.Le vecteur d'échelle comprend maintenant sept nombres: la vitesse de séquence, le facteur d'échelle et N1-5~ Le temps total de traitement de module peut être calculé sur la base du vecteur d'échelle de la façon suivante: (lo.ooo * 72) + (205 * 200) + (117 * 150) + (82 * 1200) + (41 * 1000) = 917.950. Etant donné un rapport temps réel/GPB de 72, la valeur de GPB Estimate pour ce module particulier est de 12.749. On note que le rapport utilisé est la fréquence de comptage de l'horloge et qu'elle est habituellement égale au temps de N1 comptes.

Un aspect négatif de cette variante de mode de réalisation est qu'elle ne peut pas être ultérieurement mise à jour sur la base des valeurs de
GPB Actual, même si la valeur de GPB Estimate est initialement plus précise. En d'autres termes, il n'existe aucun mécanisme de rétroaction pour fermer la boucle. Ainsi, la variante fournit une estimation initiale plus précise mais ne peut être adaptée à des variations additionnelles introduites dans le système par l'utilisateur, par exemple des cartes d'expansion, etc. Le résultat du mode de réalisation préféré est finalement une estimation plus précise.

Une autre variante de mode de réalisation implique un calcul de la valeur de GPB pour un mode particulier sur la base de l'équation suivante : GPB = mx + b où "m" correspond à la quantité incrémentale de temps pour chaque échantillon additionnel à traiter, "x" est le nombre d'échantillons et "b" correspond au temps inactif, par exemple l'entrée en cache, la commutation de contexte et les temps d'établissement de programmes. En vue d'une valeur plus précise de
GPB, cette variante de mode de réalisation peut également incorporer le concept de vecteur d'échelle décrit dans la variante précédente de mode de réalisation. En d'autres termes, des valeurs "m" et b différentes sont utilisées selon les différents types de référence de mémoire.Puisque le vecteur d'échelle contient le nombre d'accès pour chaque type de référence de mémoire, la valeur totale de GPB du module est la somme de la GPB pour chaque type de référence de mémoire, calculée selon la formule donnée ci-dessus: GPB = mx + b. Cependant, cette variante de mode de réalisation est limitée à des modules dans lesquels la charge de traitement est relativement linéaire par rapport au nombre d'échantillons qui sont traités.

On va maintenant expliquer le processus de partage de temps.

En plus de tâches de traitement en temps réel, le mode de réalisation actuellement préféré de la présente invention, traite des tâches sur une base de temps partagé. Des tâches en temps réel sont les tâches qui sont exécutées à des intervalles réguliers, c'est-à-dire à chaque séquence. En revanche, des tâches à temps partagé ne sont pas nécessairement exécutées à chaque séquence. Certains exemples de tâches qui peuvent être traitées sur une base de temps partagé incluent la compression de fichiers de disques, des graphiques, une animation, une décompression vidéo, etc.

Des tâches en temps partagé sont traitées à la fin de séquences dans lesquelles il reste un temps de traitement, lorsque la totalité des tâches en temps réel ont déjà été traitées. La quantité de temps de traitement disponible pour un temps partagé dans une séquence particulière dépend du nombre de tâches en temps réel qui sont traitées et de leur temps respectif de traitement. Si les tâches en temps réel épuisent tout le temps de traitement d'une séquence, aucune tâche en temps partagé ne peut être traitée dans cette Séquence. En revanche, si aucune tâche en temps réel ou un nombre minimal de tâches en temps réel sont traitées pendant une séquence particulière, il restera une grande quantité de temps de traitement pour des tâches en temps partagé pendant cette séquence.

Avant qu'une tâche ne soit traitée sur une base de temps partagé, il faut d'abord déterminer si cette tâche peut être prise en charge de façon appropriée sur une base de temps partagé, en raison du fait que le temps partagé total disponible varie d'une séquence à une autre. Le noyau résidentiel de DSP connaît la quantité de temps de traitement qui est disponible par séquence, puisqu'il calcule les GPB Actual pour toutes les tâches en temps réel. Le temps réel total moyen restant, c'est-à-dire inutilisé, disponible pour une utilisation en temps partagé, peut être calculé de la façon suivante: pour chaque séquence, il faut recalculer le temps moyen restant lorsque toutes les tâches en temps réel ont été achevées.Une forme de calcul à moyenne mobile est utilisée, par exemple
Temps moyen partagé = valeur moyenne précédente * 0,9 + valeur actuelle de séquence * 0,1
Ceci donne une pondération de 10% au temps restant de la nouvelle séquence et une pondération de 90% pour la moyenne précédente. Des variantes de techniques de calcul de moyenne peuvent être utilisées. Il est possible que le gestionnaire de DSP effectue ce calcul en échantillonnant la valeur toutes les n Séquences. Alors que ceci n'est peut être pas précis, ceci simplifie le noyau résidentiel.

Puisqu'il peut exister un temps inactif sensible de commutation de contexte lors d'une commutation entre le temps réel et le temps partagé et vice versa, cette quantité doit être soustraite afin de donner une valeur plus précise du temps de traitement réel disponible. Cette valeur doit être fournie par le dispositif de commande de serveur au gestionnaire de
DSP. On note que le temps inactif de commutation de contexte est la quantité minimale de temps qui doit être disponible avant qu'une tâche en temps partagé quelconque puisse être installée. Normalement, si aucune tâche en temps partagé n'est nécessaire, tout le temps de séquence nécessaire peut être alloué par des tâches en temps réel. S'il existe encore le temps minimum nécessaire, une tâche en temps partagé peut être installée alors qu'une erreur est renvoyée dans le cas contraire. Dès lors qu'il existe des tâches en temps partagé, l'allocation en temps réel ne peut jamais dépasser le temps total moins le temps minimal nécessaire de commutation de contexte. En fait, une installation de la première tâche en temps partagé alloue une certaine partie de la largeur de bande de traitement à une commutation de contexte de temps partagé. Si toutes les tâches en temps partagé sont enlevées, ce temps peut être alloué à des tâches en temps réel.

En plus du traitement moyen en temps partagé disponible, il faut la fréquence de l'exécution de la liste des tâches en temps partagé. S'il existe de nombreuses tâches dans la liste des tâches en temps partagé, la fréquence d'exécution de chaque tâche est faible. Une mesure de ceci peut être calculée en calculant une moyenne mobile du nombre de séquences nécessaires pour traiter complètement une fois la liste des temps partagés. Ceci doit être réalisé chaque fois en passant par la totalité de la liste des tâches en temps partagé. Le calcul pourrait être effectué de la manière suivante:
séquences utilisées = numéro de séquence de fin numéro de séquence du début
moyenne des séquences utilisées = moyenne précédente des séquences utilisées * 0,9 + séquences utilisées actuelles * 0,1.

On notera qu'il est possible que la valeur des "séquences utilisées" soit de zéro dans les cas où le nombre de tâches en temps partagé actives ou installées est faible, ou lorsque le majeure partie du temps de traitement est disponible pour le temps partagé. Il en résulte une valeur moyenne des séquences utilisées inférieure à 1,0. D'autres procédés de calcul de moyenne peuvent être utilisés.

La valeur moyenne des séquences utilisées pourrait en variante être calculée par le gestionnaire de DSP en échantillonnant sur une base régulière le nombre de séquences en temps réel et en temps partagé. Ceci est moins précis mais réduit la complexité du noyau résidentiel.

En utilisant les trames moyennes utilisées et le traitement en temps partagé disponible moyen par séquence, la fréquence à laquelle une nouvelle tâche en temps partagé est exécutée, peut être calculée de la façon suivante:
charge actuelle en temps partagé = temps partagé moyen * moyenne des séquences utilisées.

charge de temps partagé proposée = charge actuelle de temps partagé + GPB Estimate de tâche
séquences utilisées calculées = charge de temps partagé proposée / temps partagé moyen.

Si le nombre "proposé" de séquences est trop élevé pour la fonction souhaitée, c'est-à-dire que celle-ci est trop peu fréquente, la tâche ne devrait pas être installée dans la liste du temps partagé. On notera qu'un client en temps partagé doit surveiller la fréquence de traitement de ses tâches en temps partagé parce qu'une modification de la charge en temps réel ou de la liste des tâches en temps partagé affecte la quantité de traitement que sa tâche en temps partagé reçoit. Ce processus peut être aidé en notifiant un client en temps partagé chaque fois qu'une nouvelle tâche en temps réel est additionnée à la liste des tâches. Une autre technique de surveillance d'une fréquence de traitement en temps partagé consiste à ce que le client demande le numéro de séquence en temps partagé au gestionnaire de DSP.

Le nombre est incrémenté une fois avant chaque passage dans la liste des tâches en temps partagé. Une autre aide à la gestion du temps partagé, consiste à fournir la valeur non allouée de GPB par séquence, en plus de la valeur moyenne de temps partagé décrite ci-dessus.

Puisque la GPB peut être allouée et ne pas être utilisée, la GPB non allouée est typiquement plus faible que la GPB réellement disponible moyenne typique. Ce nombre utilisé pour donner une fréquence de séquence calculée "du pire des cas" de la façon suivante;
charge actuelle en temps partagé = temps partagé moyen * moyenne des séquences de temps partagé utilisées
charge proposée en temps partagé = charge actuelle de temps partagé + GPB Estimate de tâche
Nombre de séquences utilisées calculées dans le pire des cas = charge proposée en temps partagé / GPB non allouée
Le calcul donne les séquences utilisées pour l'exécution en temps partagé, en supposant que toutes les tâches en temps réel utilisent leur GPB allouées.

Lorsque des tâches en temps partagé sont en cours d'exécution, il est nécessaire de réaliser une préemption d'exécution pour des tâches en temps réel qui doivent être traitées "en temps". On y parvient dans le mode de réalisation actuellement préféré en interrompant une exécution en temps partagé pour exécuter la fonction en temps réel. Dans un tel cas, le contexte de la tâche en temps partagé est sauvegardé, il est ensuite restauré lorsque la tâche en temps réel a été achevée.

Si le processus de sauvegarde et de restauration de contexte prend un temps significatif pour sa réalisation, par exemple la sauvegarde du cache et la recharge du cache dans un système de traitement à base de cache, ce temps devrait être pris en considération lors de l'allocation de temps réel. C'est le même temps inactif qui est soustrait du traitement disponible pour le temps partagé, comme décrit précédemment. En particulier, lorsque la liste des tâches en temps réel est achevée, il est déterminé, par vérification sur l'horloge, s'il existe suffisamment de temps pour restaurer et sauvegarder le processus de temps partagé avant la fin de la séquence. S'il n'existe pas suffisamment de temps, le traitement de temps partagé n'est pas restauré pour cette séquence. Ainsi, dans un système fortement chargé, l'exécution du temps partagé peut tomber à zéro.

Un exemple d'une variante de technique de gestion du temps partagé consiste à n'exécuter des modules en temps partagé que si le temps restant de traitement disponible dans une séquence donnée dépasse le temps nécessaire pour le module: GPB Estimate et/ou GPB
Actual. Dans un tel cas, le module partagé doit terminer l'exécution avant la fin de la séquence.

Ainsi, aucun module en temps partagé n'est "à cheval" sur une limite de séquence. Si ceci est fait, la valeur GPB Actual est significative comme en temps réel. Cette technique élimine le temps inactif de sauvegarde/restauration mais exige un plus grand traitement pour la fonction d'exécution dans le noyau résidentiel de DSP. De plus, une capacité de récupération d'erreur doit être prévue, au cas où un module en temps partagé ne termine pas son exécution avant la limite de séquence. On note que cette technique exige que tous les modules soient exécutés à l'intérieur d'une séquence, ce qui pourrait rendre la programmation plus difficile pour de longues tâches, c'est-à-dire que le programmeur doit diviser manuellement son exécution en tranches plutôt que de se fier au processus de commutation de contexte pour le faire automatiquement.

Ainsi, dans un système d'ordinateur pourvu d'un processeur de signaux numériques pour le traitement de tâches en temps réel dans un système à base de séquences, il est décrit un appareil et un procédé servant à assurer que la tâche est exécutable à l'intérieur de la séquence d'une manière telle que le temps total de traitement de séquence n'est pas dépassé si la tâche est traitée à l'intérieur de cette séquence.

Claims (35)

REVENDICATIONS

1. Procédé mis en oeuvre dans un système d'ordinateur (100), incluant un processeur (110) de signaux numériques de traitement d'une tâche (316 à 321; 401 à 403) en temps réel sur une base de séquence (313), et destiné à déterminer si ladite tâche (316 à 321; 401 à 403) est exécutable à l'intérieur d'une séquence (313) particulière d'une manière telle qu'un temps total de traitement correspondant à ladite séquence (313) particulière n'est pas dépassé si ladite tâche (316 à 321; 401 à 403) est traitée à l'intérieur de ladite séquence (313) particulière, caractérisé en ce qu'il comprend les étapes consistant à:

déterminer un temps de traitement de ladite tâche (316 à 321);

calculer un temps d'exécution d'une liste de tâches spécifiant au moins une tâche (316 à 321; 401 à 403) à traiter pendant ladite séquence (313);

calculer une quantité de temps de traitement disponible (322) dans ladite séquence (313) en soustrayant dudit temps total de traitement de séquence (313) le temps d'exécution de la liste de tâches (316 à 321);

installer ladite tâche (316 à 321; 401 à 403) dans ladite liste de tâches si ledit temps de traitement disponible (323) est au moins aussi grand que ledit temps de traitement de tâche (316 à 321), et engendrer dans le cas contraire un signal indiquant que la tâche (316 à 321; 401 à 403) ne peut être installée.

2. Procédé selon la revendication 1, caractérisé en ce que,

ledit temps d'exécution de tâche (316 à 321; 401 à 403) est déterminé en ajoutant entre eux des temps de traitement de chaque tâche (316 à 321; 401 à 403) installée de ladite liste de tâches.

3. Procédé selon la revendication 2, caractérisé en ce que

chaque tâche (316 à 321; 401 à 403) comprend au moins un module (404 à 409).

4. Procédé selon la revendication 3 caractérisé en ce que

ledit temps de traitement d'une tâche (316 à 321; 401 à 403) installée est déterminé en déterminant une utilisation, dans le pire des cas, desdits modules (404 à 409) correspondant à ladite tâche (316 à 321; 401 à 403) et en additionnant entre eux les temps de traitement de chaque module (404 à 409) pour ladite utilisation dans le pire des cas.

5. Procédé selon la revendication 4 dans lequel ledit temps de traitement de module (404 à 409) est calculé en référence au type d'algorithme dudit module (404 à 409), caractérisé en ce que

si ledit module (404 à 409) comprend un algorithme uniforme, le temps de traitement dudit module (404 à 409) est un temps de traitement estimé si un temps réel de traitement n'a pas été mesuré pour ledit module (404 à 409), et le temps de traitement dudit module (404 à 409) est constitué dans le cas contraire par ledit temps réel de traitement;

si ledit module (404 à 409) comprend un algorithme fragmenté intelligent, ledit temps de traitement est constitué par la plus grande des deux valeurs: temps de traitement estimé et temps de traitement réel si ladite situation de temps de traitement dans le pire des cas ne s'est pas encore produite, et par le temps de traitement dudit module (404 à 409) dans le cas contraire;

si ledit module (404 à 409) comprend un algorithme fragmenté inintelligent, le temps de traitement dudit module (404 à 409) est le plus grand des deux temps: temps estimé de traitement ou temps réel de traitement, dudit module (404 à 409).

6. Procédé selon la revendication 5 caractérisé en ce que

ledit temps de traitement réel dudit module (404 à 409) est mesuré par une horloge.

7. Procédé selon la revendication 6 caractérisé en ce que

ledit temps de traitement réel mesuré par ladite horloge inclut des activités reliées du système.

8. Procédé selon la revendication 7 caractérisé en ce que

le temps de traitement dudit module (404 à 409), mesuré par ladite horloge est mesuré en référence auxdits cycles d'instruction de traitement de signaux.

9. Procédé selon la revendication 8 caractérisé en ce que

si ledit module (404 à 409) est traité dans une séquence (313) ultérieure, une comparaison est effectuée entre ledit temps antérieur de traitement réel et ledit temps ultérieur de traitement réel dudit module (404 à 409), et ledit temps réel de traitement dudit module (404 à 409) est mis à jour selon la plus grande de ces deux valeurs.

10. Procédé selon la revendication 10, caractérisé en ce que

une série de vecteurs d'échelle correspondant audit module (404 à 409) actif sont implantés, ce qui permet audit module (404 à 409) actif de fonctionner dans différentes représentations concrètes.

11. Procédé selon la revendication 10 dans lequel lesdits vecteurs d'échelle incluent une vitesse de séquence (313), un facteur d'échelle et une valeur de largeur de bande de traitement.

12. Procédé selon la revendication 11 caractérisé en ce que

il comprend en outre l'étape consistant à implanter un ou plusieurs vecteurs d'échelle correspondant audit module (404 à 409) pour calculer ledit temps de traitement dudit module (404 à 409), lesdits vecteurs d'échelle incluant une vitesse de séquence (313), un facteur d'échelle et au moins un compte ou des comptes d'accès à la mémoire correspondant au moins à un type de référence de mémoire.

13. Procédé selon la revendication 11, caractérisé en ce que

il comprend en outre l'étape consistant à implanter un ou plusieurs vecteurs d'échelle correspondant audit module (404 à 409) pour calculer ledit temps de traitement dudit module (404 à 409), ledit temps de traitement dudit module (404 à 409) étant déterminé selon la formule mx + b dans laquelle m correspond à une quantité incrémentale de temps correspondant au traitement d'un échantillon entré, b correspond à un temps inactif dudit système d'ordinateur (100), et x correspond à un nombre d'échantillons à traiter, lesdits vecteurs d'échelle incluant une vitesse de Séquence (313), un facteur d'échelle et des valeurs de m et b.

14. Procédé selon la revendication 11 caractérisé en ce que

une allocation de traitement dudit module (404 à 409) actif est modifiée dynamiquement en fonction de ladite disponibilité de temps de traitement à l'intérieur de ladite séquence (313).

15. Procédé selon la revendication 14 caractérisé en ce que

il comprend en outre l'étape consistant à mettre à jour ledit temps de traitement réel lorsque ladite tâche (316 à 321; 401 à 403) est déchargée et à mémoriser dans un moyen de mémorisation ledit temps de traitement mis à jour.

16. Procédé selon la revendication 15 caractérisé en ce que

ledit temps de traitement mis à jour est restitué et utilisé pour calculer ledit temps d'exécution de ladite liste de tâches.

17. Appareil inclus dans un système d'ordinateur (100), dans lequel des tâches sont traitées en temps réel sur une base de séquence (313), et servant à assurer qu'une tâche (316 à 321; 401 à 403) peut être complètement traitée à l'intérieur d'une séquence (313) d'une manière telle que ledit temps de traitement disponible de séquence (313) n'est pas dépassé, caractérisé en ce qu'il comprend: :

une liste de tâches servant à spécifier des tâches à traiter pendant ladite séquence (313);

un processeur (110) de signaux numériques couplé audit système d'ordinateur (100) pour exécuter ladite liste de tâches;

un système d'exploitation, couplé audit système d'ordinateur (100), qui détermine un temps de traitement disponible pour ladite séquence (313) en soustrayant d'un temps total de traitement de ladite séquence (313) un temps d'exécution servant à exécuter ladite liste des tâches, ladite tâche (316 à 321; 401 à 403) étant incluse dans ladite liste de tâches si le temps de traitement disponible est au moins aussi grand que ledit temps de traitement de ladite tâche (316 à 321), et ladite tâche (316 à 321; 401 à 403) n'étant pas incluse, dans le cas contraire, dans ladite liste de tâches.

18. Appareil selon la revendication 17 caractérisé en ce que

il comprend en outre un vecteur d'échelle servant à calculer ledit temps de traitement de tâche (316 à 321), ledit vecteur d'échelle incluant une vitesse de séquence (313), un facteur d'échelle et au moins un compte d'accès de mémoire correspondant à au moins un type de référence de mémoire.

19. Appareil selon la revendication 17 caractérisé en ce que

il comprend en outre un vecteur d'échelle servant à calculer ledit temps de traitement de tâche (316 à 321), ledit vecteur d'échelle incluant une vitesse de séquence (313), un facteur d'échelle, et des valeurs m et b, ledit temps de traitement de tâche (316 à 321; 401 à 403) étant déterminé selon la formule mx + b dans laquelle m correspond à une quantité incrémentale de temps de traitement d'un échantillon entré, b correspond à un temps inactif dudit système d'ordinateur (100), et x correspond à un nombre d'échantillons à traiter.

20. Appareil selon la revendication 17 caractérisé en ce que

il comprend en outre un premier drapeau correspondant à chaque tâche (316 à 321; 401 à 403) de ladite liste de tâches, l'état du premier drapeau déterminant si ladite tâche (316 à 321; 401 à 403) correspondante est active, des tâches actives de ladite liste de tâches étant traitées pendant ladite séquence (313) lorsque ladite liste de tâches est exécutée.

ledit temps d'exécution de liste de tâches est déterminé en ajoutant les uns aux autres tous les temps de traitement de chacune des tâches qui est installée dans ladite liste de tâches.

21. Appareil selon la revendication 20 caractérisé en ce que

22. Appareil selon la revendication 21 caractérisé en ce que

chaque tâche (316 à 321; 401 à 403) comprend en outre au moins un module (404 à 409).

23. Appareil selon la revendication 22, caractérisé en ce que

il comprend un deuxième drapeau associé audit module (404 à 409), l'état dudit deuxième drapeau déterminant si ledit temps de traitement dudit module (404 à 409) doit être inclus dans le calcul dudit temps de traitement de tâche (316 à 321), ledit temps de traitement de tâche (316 à 321; 401 à 403) étant la somme des temps totaux de traitement de chaque module (404 à 409) déterminé par ledit deuxième drapeau.

24. Appareil selon la revendication ~3, caractérisé en ce qu'il comprend en outre

un premier registre associé audit module (404 à 409) pour mémoriser le temps de traitement réellement mesuré dudit module (404 à 409);

un deuxième registre associé audit module (404 à 409) pour mémoriser un temps de traitement estimé dudit module (404 à 409);

un troisième drapeau qui détermine si ladite valeur de premier registre représente le pire des cas dudit temps de traitement de module (404 à 409), l'état desdits drapeaux dépendant de l'algorithme dudit module (404 à 409).

25. Appareil selon la revendication 24 caractérisé en ce que

l'algorithme dudit module (404 à 409) inclut l'un des trois types suivants: uniforme, fragmenté intelligent et fragmenté inintelligent.

26. Appareil selon la revendication 25, caractérisé en ce que

il comprend en outre une horloge servant à déterminer ledit temps réel de traitement du module (404 à 409), incluant toutes activités reliées du système.

27. Appareil selon la revendication 26 caractérisé en ce que

ladite horloge détermine ledit temps réel de traitement du module (404 à 409) en référence à un cycle d'instructions.

28. Appareil selon la revendication 27 caractérisé en ce que

ladite horloge mesure, chaque fois que ledit module (404 à 409) est traité, un temps réel de traitement dudit module (404 à 409), ledit premier registre est mis à jour à l'aide dudit temps mesuré de traitement si ledit temps mesuré de traitement est plus grand que la valeur actuelle dudit premier registre, et ledit premier registre n'est pas mis à jour dans le cas contraire.

29. Appareil selon la revendication 28 caractérisé en ce que

il comprend en outre une série de vecteurs d'échelle associés audit module (404 à 409), permettant audit module (404 à 409) d'exercer sa fonction dans une série de représentations.

30. Appareil selon la revendication 29 caractérisé en ce que

lesdits vecteurs d'échelle incluent une vitesse de séquence (313), un facteur d'échelle et une valeur de traitement.

31. Appareil selon la revendication 30 caractérisé en ce que

ledit temps de traitement estimé dudit module (404 à 409) est dérivé dudit vecteur d'échelle.

32. Appareil selon la revendication 30 caractérisé en ce que

le temps de traitement du module (404 à 409) est modifié dynamiquement en fonction de ladite disponibilité de temps de traitement à l'intérieur de ladite séquence (313).

33. Appareil selon la revendication 32 caractérisé en ce que

il comprend un moyen de mémorisation pour mémoriser des temps de traitement mis à jour.

34. Appareil selon la revendication 33 caractérisé en ce que

il comprend un moyen de calcul dudit temps d'exécution de ladite liste de tâches sur la base desdits temps de traitement mis à jour dans ledit moyen de mémorisation.

35. Procédé mis en oeuvre dans un système d'ordinateur (100) à base de séquences (313), incluant un processeur (110) de signaux numériques de traitement d'une tâche (316 à 321; 401 à 403) sur une base de temps partagé, et destiné à déterminer si ladite tâche (316 à 321; 401 à 403) peut être prise en charge de façon appropriée sur la base dudit temps partagé comprenant les étapes consistant à

déterminer un temps de traitement de chaque tâche (316 à 321), ladite tâche (316 à 321; 401 à 403) comprenant au moins un module (404 à 409), ledit temps de traitement de chaque tâche (316 à 321; 401 à 403) étant calculé en déterminant une utilisation des modules (404 à 409) de ladite tâche (316 à 321; 401 à 403) dans le pire des cas et en ajoutant les uns aux autres les temps de traitement de chaque module (404 à 409) correspondant à la situation du pire des cas;

déterminer une quantité de temps de traitement qui est disponible pour un traitement en temps partagé par séquence;

déterminer la fréquence à laquelle des tâches en temps partagé sont actuellement en cours d'exécution;

calculer une fréquence d'exécution de tâches en temps partagé lorsque ladite tâche (316 à 321; 401 à 403) est elle aussi installée;

comparer ladite fréquence de traitement de ladite tâche (316 à 321; 401 à 403) à la fréquence nécessaire de tâche (316 à 321).