Brevet FR2819090A1 — publié le 20020705

La présente invention concerne un procédé d'enregistrement d'un paquet de données dans une mémoire divisée en plusieurs blocs de mémoire. L'invention concerne un procédé caractérisé en ce qu'il comprend les étapes suivantes: - l'enlèvement de l'entête du paquet de données, - la division du restant des données du paquet en des fragments de pa- quet, - l'enregistrement de chaque fragment de paquet dans un bloc mémoire respectif avec une entête respective et - on met un drapeau " début de paquet " dans l'entête du bloc mémoire contenant le fragment de paquet correspondant au début du restant du paquet de données. La présente invention sera décrite ci-après à l'aide de modes de réalisation représentés à titre d'exemple dans le dessin annexé dans lequel: - l'unique figure montre un système gestionnaire de files d'attente pour quatre utilisateurs de file d'attente. L'unique figure montre un système gestionnaire de files d'attente 10 reliée à quatre utilisateurs de files d'attente 11-14 (ler... 4ème utilisateur) avec respectivement quatre interfaces 15-18. Le système ges- tionnaire de files d'attente 10 comporte un gestionnaire central câblé de files d'attente 19. Ce gestionnaire central est commandé par programme par l'intermédiaire d'une interface de programme 20. Le gestionnaire cen- tral de files d'attente 19, est relié à chacune des interfaces de files d'attente 15-18 par l'un des quatre portails 21-24 et par un bus commun (non représenté). L'interface de programme 20 est responsable de la création et de la destruction des files d'attente, du re-dimensionnement des files d'attente et de l'envoi des blocs de mémoire dans les files d'attente. La tâ- che principale du gestionnaire central de files d'attente 19 est de ré- attribuer les " blocs utilisés " vers la partie arrière des files d'attente. Le gestionnaire central de files d'attente 19 comporte un arbitre de bus (non représenté) qui détermine comment et quand les fonctions de circuits pa- rallèles et de programmes peuvent accéder au bus (non représenté). Les portails de files d'attente 21-24 assurent l'accès aux fi- les d'attente. Chaque portail de files d'attente 21-24 se compose de deux parties. Une partie peut servir à inscrire dans la file d'attente et l'autre partie peut servir à lire dans une file d'attente (chaque partie ac- cède à différentes files d'attente). Bien que l'on ait représenté quatre por- tails de files d'attente 21-24, il n'y a pas de limite au nombre de portails que l'on peut utiliser. La contrainte principale du nombre de portails est celle du bus le plus mauvais pour la largeur de bandes. Chaque utilisateur de files d'attente 11-14 demande un portail de files d'attente 21-24. L'utilisateur de files d'attente 11-14 peut accéder à de multiples files d'attente et en même temps, il peut lire dans l0 une file d'attente pendant qu'il écrit dans une autre file d'attente. Dans ce cas, les tâches sont simultanées mais les accès au bus se font séquentiel- lement sous la commande de l'arbitre de bus. Toutefois, chaque fois qu'un utilisateur de files d'attente 11-14 veut lire ou inscrire dans une file diffé- rente, il doit l'indiquer au portail de files d'attente 21-24 pour décharger les pointeurs courants de files d'attente et charger de nouveaux pointeurs. Chaque utilisateur de files d'attente 11-14 est un composant, une fonction normalisée avec une possibilité d'accès direct à la mémoire (DMA) . C'est pourquoi cet utilisateur de files 11-14 demande à son interface d'utilisateur de files d'attente 15-18 de traduire sa requête DMA et les si- gnaux d'accusé de réception en enjeu normal de signaux reconnus par les portails de files d'attente 21-24. Dans certaines applications, il s'agit d'une simple traduction de signal alors que dans d'autres applications, l'interface 15-18 ajoute ou supprime des données pour les traduire d'une application à une application avec un format de paquet de données spéci- fique. Le bloc de construction de base des files asynchrones est un bloc de mémoire vive (RAM). Cette mémoire n'est pas représentée. La quantité de mémoire RAM disponible pour le système de gestion de files d'attente10 est divisée en des lots de petits blocs de mémoire de même dimension pour éviter de surcharger le stockage de la taille de bloc de chaque bloc de mémoire. En variante, on peut utiliser différentes files d'attente avec différentes tailles de bloc de mémoire bien que cela compli- querait le programme qui crée et redimensionne les files d'attente. Dans ce mode de réalisation, les blocs de mémoire ont une longueur de 64 octets. Chaque bloc de mémoire commence par une liaison de champ qui est un pointeur dirigé sur l'adresse de la liaison champ du bloc de mémoire sui- vant. La mémoire utilisée par la file se compose d'un nombre de blocs de mémoire que l'on peut répartir n'importe o dans la mémoire vive RAM et ces blocs sont liés par des champs de liaison. Le système de gestion de files d'attente 10 utilise seulement des champs de liaison unidirectionnels de sorte que le système de gestion de files QMS peut seulement chercher en avant à travers les blocs. Si le bloc courant est le dernier maillon de la chaîne, son champ de maillons ou de liaison contient des états (1=1). En variante, on peut utiliser des champs de maillons ou de liaison bidirec- tionnels bien que cela augmente la complexité et réduise l'efficacité de la mémoire. Il y a également deux contraintes dépendant de la réalisa- tion. La première est que tous les blocs de mémoire (et c'est pourquoi les champs de liaison) commencent à une limite paire d'octets. La seconde contrainte est que la taille maximale de la mémoire RAM est de 64 K oc- tets. Ces deux contraintes signifient que le champ de maillons ou de liai- son peut être lu ou recevoir une inscription dans un cycle de bus. Immédiatement après le champ de liaison, on a un champ " commande de bloc ". Il contient une indication de longueur de champ, c'est-à-dire le nombre d'octets d'informations stocké couramment dans les blocs et quatre bits de commande. Les quatre bits les plus significatifs (MSB) du champ de commande de bloc constituent les bits de commande indiquant les limites du flux de données. Le champ de longueur est enre- gistré dans les bits les moins significatifs (LSB) du champ de commande de bloc. Un bloc de mémoire est présenté dans le tableau 1 ci- apres: Champ de lien Commande (4 bits) | Longueur (12 bits) Données (Octets hauts, Octets bas) Tableau 1 De nombreux systèmes de communication traitent les pa- quets de données plutôt qu'un flux continu de données. Le système de gestion de file 10 identifie les multiples types de frontières de paquets en utilisant les quatre drapeaux de commande de chaque bloc de mémoire. Ces drapeaux de commande sont les quatre bits les plus significatifs MSB du champ de commande du bloc. Si le bit de commande le plus significatif est mis, cela signifie que le premier octet d'informations du bloc de mé- moire commence un paquet. Les trois autres bits de commande restants indiquent d'autres types de frontières. Le bit suivant le plus significatif MSB indique les frontières du paquet de transport et le bit suivant indique les frontières du paquet de l'application. Si l'on utilisait les trois bits les moins significatifs LSB sans les bits les plus significatifs MSB, le système ne pourrait pas indiquer o se trouve la frontière du bloc mémoire. Si lorsqu'un utilisateur de files d'attente 11-14 inscrit dans son portail de files 21-24, il inscrit le bit MSB des drapeaux de commande et le portail de files d'attente arrête l'inscription du bloc de mémoire cou- rant; il fait avancer ses pointeurs (non représentés) vers le champ de liai- son du bloc de mémoire suivant. Lorsqu'un utilisateur de files 11-14 demande à un portail 21-24 combien d'octets de données sont disponi- bles, l'utilisateur 11-14 fournit également le nombre requis d'octets et ap- plique un masque au champ de commande. Le portail de files d'attente 2124 cherche alors à travers la file jusqu'à ce qu'il atteigne le jeu des drapeaux de commande identifié par le masque; il trouve le nombre re- quis d'octets ou il se porte à la fin des données disponibles, quelles que soient celles qui arrivent en premier lieu. Le mécanisme permet d'inclure l'information de commande dans le flux de données du début et du paquet de données. L'interface d'utilisateur de files 15-18 qui ensuite lit les données dans la file peut ex- traire l'information de commande. Si le flux de données est un flux de données continu, les drapeaux de commande ne sont pas utilisés, c'est-à-dire qu'ils sont tous à l'état zéro. Une file asynchrone normalisée comporte un nombre défini de blocs de mémoire qui lui sont attribués. Si les données sont consom- mées plus rapidement qu'elles sont ajoutées à la file d'attente, la file peut se vider. Les blocs attribués à la file ne sont pas utilisés mais disponibles pour d'autres files. Entre temps, une autre file d'attente peut recevoir trop de données. La file se remplira puis l'émetteur doit soit arrêter l'envoi, soit les données seront perdues. Ce type de file est appelé " unique ". L'avantage de ce type de file est que les ressources disponibles pour la file sont définies. Dans un système qui ré-attribue de manière dynamique les blocs de mémoire, à la demande, lorsqu'une file est lente à se vider, il peut utiliser tous les blocs de mémoire disponibles. Dans ce cas, toutes les au- tres files d'attente peuvent être arrêtées parce qu'il n'y a pas d'autres blocs de mémoire disponibles. Le système de gestion de file 10 assiste l'attribution dyna- mique de mémoire en utilisant des " files d'attente groupées ". Une file d'attente groupée se compose d'un certain nombre " d'éléments de files " et une file de ressource. Les éléments de files sont les mêmes que les files simples sauf qu'il y a une différence de nombres de blocs réservés attri- bués à chaque élément de file. Les données sont lues et inscrites dans les éléments de files. La file de ressource est en effet une liste liée de blocs de io mémoire de réserve. Tous les éléments des files d'une file groupée servent de blocs de mémoire de même taille. Lorsque des blocs de mémoire sont enlevés de la tête d'une file simple, ils sont ré-attribués à la queue de la même file sauf s'il y a une demande de réduction de taille pour cette file d'attente. Lorsque des blocs de mémoire sont enlevés de la tête d'un élément de file, ils sont générale- ment attribués à la file de ressource. Lorsqu'un élément de file n'est pas chargé pour l'enregistrement, il ne comporte pas de bloc vide. La queue de l'élément de file pointe sur le même bloc de mémoire que le dernier " inscription effectuée " pointe. Lorsqu'un portail de files 21- 24 charge un élément de file pour inscrire, la file de ressource est liée à la queue de l'élément de file rendant disponibles tous les blocs de la file de ressource. Lorsqu'un portail de files 21-24 décharge un élément de file (à ce moment il élimine), tous les blocs de mémoire de réserve sont enlevés de l'élément de file et sont ré-attribués à la file de ressource. La contrainte principale de ce système est qu'un seul élé- ment d'une file groupée peut recevoir une inscription à la fois car toute la file de ressource est ajoutée à l'élément actif. Dans la plupart des cas, un seul portail de files 21-24 inscrit dans la file groupée et c'est pourquoi il n'y a seulement pas toujours un élément de la file qui est chargé pour l'inscription. C'est pourquoi, en théorie il n'y a pas de limite au nombre de files simples ou groupées que l'on peut créer. La contrainte principale est celle des ressources de mémoire nécessaire. L'autre type de file est une file isochrone (ISO). Une donnée isochrone est une donnée critique dans le temps telle qu'une donnée de conversation téléphonique. Une file ISO utilise différents mécanismes de commande gérés par différents circuits. Un mécanisme d'une file d'attente de commande ISO peut être un composant additionnel ou un composant alternatif d'un portail de files d'attente 21-24. Une file d'attente ISO utilise un unique bloc contiguë de mémoire plutôt que des blocs mémoire liés utilisés par des files asynchrones. Cette zone de mémoire est de manière caractéristique relativement petite, par exemple elle correspond à 32-256 octets. Une file ISO constitue un petit espace tampon pour isoler les utili- sateurs de files d'attente qui génèrent/ou utilisent des données de manière non ordonnée. Lorsqu'une file iso est pleine, la donnée la plus ancienne est disponible pour une surscription (pour être effacée par une inscription qui la remplace). Ce type de files d'attente est le plus utilisé si l'intégrité des données est un facteur important. Lorsque la file d'attente 0o est vide ou est effectivement vide, la donnée la plus récente lue dans la file est de nouveau lue. D'une manière caractéristique, une donnée asynchrone est une donnée à modulation par impulsions codées (un système PCM ou MIC) qui comporte des échantillons d'un signal analogique tel qu'un enre- gistrement d'un signal vocal. Dans ce cas, la donnée est lue de nouveau dans la file d'attente, elle se compose d'un certain nombre d'octets de données qui sont reconstruites sous la forme d'un signal audio ou de son, analogue ou identique aux sons qui viennent directement avant ou après ce signal. Un tel effet est moins perceptible qu'un blanc dans un signal audio. Si la donnée synchrone est une donnée telle qu'une donnée à modulation delta à pente variable continue (CVSD), on réalise un mon- tage spécial pour assurer que la moyenne du signal reconstruit reste égale à zéro puisque sinon il y aurait saturation ou débordement numérique. Ce type de données ou des types similaires à celui-ci peut être traités de l'une des deux façons. En premier lieu, la donnée lue est traitée de nouveau pour assurer un décalage zéro. Il est à remarquer qu'il y a plusieurs fa- çons de réaliser cela. En second lieu, on peut générer la donnée qui cor- respond à une séquence d'incréments et de décréments alternés, c'est-à- dire un signal sinusoïdal de faible amplitude que l'on génère à la place des données que l'on veut relire. Comme indiqué ci-dessus, de nombreux blocs de mémoire sont liés pour former une chamne de blocs contenant une séquence de données. Un descripteur de files est un ensemble de pointeurs et de champs de commande qui détermine comment utiliser et gérer les chaînes de blocs. Les descripteurs de files sont stockés à un endroit différent de la mémoire. Lorsque l'interface de programme va créer une file, elle crée également un descripteur de files. Une file est identifiée par l'adresse de départ du descripteur de files correspondant. Lorsqu'un utilisateur de files 11-14 accède à une file d'attente par un portail de files d'attente 21-24, il fournit l'adresse de départ du descripteur qui est ensuite mis sous la forme d'identificateur de files AID. Les files simples et les éléments de files utilisent des des- cripteurs de files similaires. Ce type de descripteur de files se compose d'un certain nombre de sous-descripteurs et de bits de commande d'accès. La file de ressource utilise une version simplifiée d'un descripteur de files. Les bits de commande d'accès des descripteurs de files assurent qu'à l0 n'importe quel instant seulement un portail de files ou une interface de programme 20 est autorisé à modifier un champ dans le descripteur. Les tableaux de données ci-après explicitent les champs des descripteurs de files simples et d'éléments de files; le champ est enregistré en mémoire pour une file asynchrone: ts Tableau 2 Adresse Bit de ver- Octet haut Octet bas rouillage QID 0 I RmW Blocs à enlever Commande de verrou QID + 2 --- KI du bloc (12 bits) QID + 4 Blocs de queue Blocs vides QID + 6 RmW Blocs non utilisés (u ds (seuil d'utilisation) QID + 8 1 Type (simple = 1 élément / élément = RID) QID + 10 1 Bloc de queue attribué QID + 12 1 --- Décalage de queue attribué (12 bits) QID + 14 2 Bloc de tête courant QID + 16 2 --- Décalage de tête courant (12 bits) QID + 18 2 Bloc de tête attribué QID + 20 2 --- Décalage de tête attribué (12 bits) QID + 22 2 Bloc à évacuer Le tableau 3 illustre les champs d'un descripteur de files de ressource dans lequel RID est l'identificateur de files de ressource. Tableau 3 Bit de ver- Adresse Bit de ver- Octet haut Octet bas rouillage RID 0 [ Blocs à enlever Commande de verrou RID + 2 2 Tête des blocs RID + 3 1 Queue des blocs RID + 4 RmW Blocs vides (12 bits) Dans le descripteur de files de ressource, le champ de commande de verrouillage est un champ d'une largeur d'un octet conte- nant des bits pour commander la permission d'inscription dans les autres champs du descripteur. Le circuit comprend une séquence non interrup- tible, lecture-modification-inscription qui assure que seulement une fonc- tion (portail 21-24 ou interface de programme 20) peut changer la valeur de verrouillage à l'instant donné. La colonne de bits de verrouillage dans les deux tableaux indique les bits qui commandent les accès et les champs concernés. Le bit de verrouillage zéro concerne le champ des " blocs à éliminer ". Le champ de commande de verrouillage peut être mo- difié lorsque le bit zéro est mis. Le champ " bloc à éliminer " est un champ d'une largeur d'un octet indiquant le nombre de blocs de mémoire qu'il faut enlever de la file d'attente. Cela nécessite un accès de commande de verrou puisqu'il y a deux fonctions qui peuvent modifier la valeur. L'interface de programme peut modifier la valeur pour demander la longueur de file à re- dimensionner et la fonction de ré-attribution décrémente alors la valeur lorsque les blocs éliminés. Le champ " blocs à éliminer " est seulement valable pour les files simples et les files de ressource, c'est-à-dire que pour les descrip- teurs d'éléments de queue, ce champ n'est pas utilisé. Si les blocs sont enlevés d'une file groupée, l'interface de programme 20 demande qu'ils soient enlevés de la file de ressource plutôt que des éléments de queue. Si le champ " blocs à enlever " est mis sur l'état 255, tous les blocs de la file sont à enlever et passent par une ré-attribution. Ainsi la valeur " blocs à enlever " ne sera pas réduite. Le champ " KI de bloc " est un champ à 12 bits, c'est-à-dire excluant les quatre bits de commande qui indiquent combien d'octets d'informations peuvent être inscrits dans les blocs de mémoire utilisés par la file. Le champ " KI de bloc " est modifié seulement lorsqu'on crée la file. Lorsque la file est active, le champ " KI de bloc " est seulement lu et c'est pourquoi il ne nécessite pas de verrou. Les descripteurs d'éléments de files définissent la file de ressource " KI de bloc " qui est la même pour tous les éléments dans une file groupée. A la place du champ " taille de blocs ", les files de ressource ont un champ " tête de blocs " d'une largeur de mots correspondant à deux octets. Le champ " tête de blocs " contient l'adresse du bloc de mé- moire à la tête de la chaîne des blocs non utilisés. Lorsqu'un portail de files 21-24 charge un élément de file, il verrouille le champ " tête de blocs" de la file de ressource associée. Cela garantit qu'un n'importe quel instant seulement un élément de file peut être utilisé en association avec la file de ressource. Le portail de files lie alors la file de ressources à l'élément de queue. Le champ " tête de blocs " de la file de ressource ayant des états 1 (= 1), cela indique que la file de ressource est vide. Si la file de ressource est vide, le portail de file libère immédiatement la file de ressource en dé- verrouillant le champ " tête de blocs ". Si la file de ressource n'est pas vide, lorsque l'élément de la file est chargé, un portail de files 21- 24 met à jour le champ " tête de blocs " et libère le verrouillage lorsqu'il décharge une file. Lorsque la file est déchargée, le champ " tête de blocs " est chargé avec des états 1 (=1) s'il n'y a pas de blocs de mémoire de réserve. Le champ " queue de blocs " dans une file simple est un champ d'une largeur d'un mot contenant l'adresse du dernier bloc de mé- moire ajouté à la file. La fonction de ré-attribution de bloc utilise ce champ pour identifier o les blocs dégagés doivent être accrochés de nouveau sur la queue de la file. Le champ " queue de blocs " pointe sur le champ de liaison dans le bloc de mémoire à la queue de la file d'attente. Comme la fonction de ré-attribution est la seule fonction qui modifie le champ " queue de blocs ", le verrouillage de la commande n'est pas nécessaire. Comme toutes les files simples doivent contenir au moins un bloc de mé- moire, le champ " queue de blocs " est toujours valide. Le champ " queue de blocs " est une queue de ressource analogue à celle de " queue de blocs " dans une queue simple. Toutefois une queue de ressource peut se vider, ce qui rend invalide le champ " queue de blocs ". Le descripteur de queue de ressource inclut pour cela un bip de commande d'accès pour le champ " queue de blocs ". Lorsqu'un portail de files d'attente 21-24 veut décharger un élément de queue, il ver- rouille d'abord le champ " queue de blocs " dans un descripteur de la file de ressource associée, puis il poursuit par la procédure de déchargement. Si la procédure de déchargement ne comporte pas de blocs de réserve pour repasser dans la file de ressource, elle inscrit des états 1 partout (= 1) à la fois pour la " queue de blocs " et pour la " tête de blocs ". Puis le por- s tail de files d'attente déverrouille à la fois les champs " tête de blocs " et " queue de blocs ". La ré-attribution fonctionne toujours pour verrouiller le champ " queue de blocs " avant de ré-attribuer des blocs à la file de res- source. Le champ " bloc vide " est un champ d'une largeur d'un oc- tet indiquant le nombre de blocs de réserve (non utilisés) à la queue d'une file simple (bien que certains des blocs puissent être utilisés par un procé- dé d'inscription non attribué qui est toujours chargé). Une file simple con- tient au maximum 255 blocs autorisant l'accès ensemble au champ " blocs vides" et " blocs utilisés ". La valeur de " bloc vide " multipliée " taille de blocs " donne une vague approximation de la capacité de stock- age RAM couramment disponible bien que cela exclut toute place disponi- ble dans le bloc qui pointe vers " bloc de queue attribué ". Les champs " blocs vides " et " blocs utilisés ", sont modifiés en utilisant une séquence non interruptible lecture - modification - écri- ture, plutôt qu'un bit de verrouillage. Lorsqu'un portail de file d'attente 21-24 attribue une inscription, il augmente la valeur du champ " blocs utilisés " par le nombre de blocs attribués et il diminue la valeur du champ " blocs vides " du même montant. Si la fonction de réattribution ajoute un bloc à une file, elle incrémente la valeur dans le champ " blocs vides ". Le champ " blocs vides " des descripteurs d'élément de file est appelé " seuil de blocs utilisés ". Lorsqu'un élément de file est chargé du mot écriture, la file de ressource est habituellement liée à l'élément de file. Toutefois, si la valeur du champ " blocs utilisés " est supérieure à la valeur du champ " seuil de blocs utilisés ", la file de ressource n'est pas accrochée à l'élément de file d'attente. Le champ " seuil de blocs utilisés " peut servir pour éviter qu'un élément de file groupée n'utilise tous les blocs mémoire de réserve. Le seuil est uniquement appliqué lorsque la file d'attente est chargée. Si un élément de file d'attente est chargé avec la file de ressource, il peut attribuer un nombre quelconque de blocs jusqu'au nombre de blocs de la file de ressource. Les blocs attribués sont ajoutés au champ " blocs utilisés " même si le résultat est supérieur à celui des "seuils de blocs utilisés ". Dans les files d'attente groupées, un comptage unique " blocs vides " est maintenu dans la file de ressource. Le champ " blocs vides " dans un élément de file est utilisé pour enregistrer le champ " seuil de blocs utilisés ". Comme la file groupée peut avoir besoin de garder une trace de plus de blocs de réserve pour répondre à de multiples éléments de files d'attente, le champ " blocs vides " des descripteurs de files de res- source a une longueur de 12 bits au lieu de 8 bits. Le champ " blocs vides " est mis à jour en utilisant une sé- quence non interruptible lecture - modification - écriture. Lorsqu'un por- tail de files d'attente attribue une inscription, il augmente la valeur du champ " blocs utilisés" du descripteur de l'élément de file du nombre de blocs attribués et il diminue le champ " blocs vides " du descripteur de fi- les de ressource, de la même valeur. Si la fonction de ré-attribution ajoute un bloc à une file, elle incrémente la valeur dans le champ " blocs vides " du descripteur de files de ressources. Le champ " blocs utilisés " est un champ d'une largeur d'un octet qui indique le nombre de blocs de mémoire de la file d'attente conte- nant des données à lire et à attribuer. Lorsqu'un portail de file d'attente attribue une inscription il augmente l'état de comptage du champ " blocs utilisés " du nombre de blocs supplémentaires ajoutés (en utilisant une séquence non interruptible lecture - modification écriture). Lorsqu'un portail de file d'attente attribue une lecture, le nombre de blocs libérés est soustrait de la valeur du champ " blocs utilisés ". L'état de comptage " blocs utilisés" n'est pas utilisé directement par le système gestionnaire de files d'attente 10. L'état de comptage " blocs utilisés " est maintenu pour que les fonctions de commandes externes puissent commander et contrôler le nombre de données stockées dans une file d'attente. Avec les éléments de files, on rencontre une complication en ce que la file de res- source peut fournir plus de 255 blocs à un élément de file. Cela produit le dépassement de l'état de comptage " blocs utilisés " dépassant le maxi- mum autorisé. Le champ " type " est un champ d'une largeur d'un mot qui se distingue entre les files simples et les éléments de files. Le champ " types " pour les files simples est avec par tous les états 1 (=1), n'importe quelle autre valeur du champ " type " indique que la file d'attente est un élément de file d'attente. Pour les éléments de files, le champ " type " con- tient l'adresse de l'identificateur de ressource associée (RID). Le champ " type " traité comme faisant partie du sous des- cripteur " écriture ", n'a de sortie verrouillée lorsqu'un portail defiles d'attente 21-24 charge la file pour l'écriture. Il y a deux cas dans lesquels le champ reçoit une inscription. Lorsque la file d'attente est créée, l'interface de programme 10 met à jour le champ " type ". Si l'interface de programme 20 veut détruire une file groupée, elle détruit tous les élé- ments de files sauf l'un des éléments. Puis avec le dernier élément de file, 1o il rattache la file de ressource à l'élément de file et transmet cet élément de file en une file simple. La file de ressource n'existe plus et la nouvelle file simple créée peut être détruite de la même manière que l'on détruit les autres files simples. Le champ " bloc de queue, attribué " est un champ d'une taille d'un mot qui fait partie du pointeur identifiant l'endroit de la der- nière inscription attribue. Le champ " bloc de queue, attribué " contient l'adresse de départ du bloc de mémoire dans lequel se trouve l'écriture at- tribuée. Le champ est verrouillé lorsqu'un portail de files d'attente 2124 charge une file pour l'écriture. Le portail de files d'attente 21-24 charge le pointeur attribué dans un registre courant de pointeur de queue qui est seulement valide pendant le chargement de la file d'attente. Pendant que s'effectue l'écriture, le pointeur de queue, courante est mis à jour mais le pointeur de queue attribué n'est pas affecté. Si le portail de files d'attente doit effectuer une attribution donnée inscrite, il charge le pointeur de queue courante dans le pointeur de queue attribué. Si le portail de files d'attente doit éliminer les données inscrites, il charge le pointeur de queue attribué dans le pointeur de queue courant. Lorsque le portail de queue transfert un sous descripteur d'écriture, il effectue toujours d'abord une opération d'attribution ou d'élimination. Puis, lorsque le sous descripteur d'écriture est déchargé, le bit de commande d'accès d'écriture est déver- rouillé. Le champ " décalage de queue attribué ", qui est la seconde partie du pointeur de queue attribué est un champ à 12 bits correspon- dant à un décalage par rapport au début du " bloc de queue attribué " sauf définition autre, il s'agit des quatre bits les plus significatifs MSB qui sont annulés. Le champ " décalage de queue attribué " est essentiellement le même que le champ " longueur de bloc de mémoire ". Chaque fois que le champ " longueur de bloc de mémoire " est mis à jour, il est chargé avec le décalage de queue, courant. Le champ " décalage de queue attribué " a une résolution d'octets et comprend les quatre octets d'information de commande au début du bloc de mémoire. L'adresse o se trouve la der- nière écriture attribuée est donnée par: champ " bloc de queue attribué " + quatre, + champ " décalage de queue attribué ". Tous les pointeurs de files du système de gestion files 10 sont pré incrémentés de sorte que les pointeurs sont dirigés vers la dernière position d'écriture plutôt que vers la position d'écriture suivante en état statique. Le champ " bloc de tête courant " a une largeur d'un mot lo qui fait partie du sous-descripteur de lecture. Contrairement au sous- descripteur d'écriture, le sous descripteur de lecture peut être déchargé sans opération d'attribution/élimination puisqu'il ne participe plus à la réaction pour indiquer les données transférées avec succès hors du sys- tème de gestion de files d'attente 10. Ainsi l'information reçue est écrite dans le système de gestion de file d'attente 10, le contrôle d'intégrité des données fait généralement partie du flux des données et ainsi le contrôle se fait immédiatement après la réception du bloc de données. C'est pour- quoi le pointeur de tête, courant, est enregistré ainsi que le pointeur de tête attribué. Le champ " bloc de tête courant " contient l'adresse de dé- part du bloc de mémoire dans lequel s'est faite la dernière lecture. Lorsqu'un portail de files charge une file pour la lecture, il verrouille le bit de commande d'accès de lecture au sous-descripteur. Puis, il charge le pointeur de tête, courant, dans un registre. Toutes les opérations de lecture remettent à jour seulement la valeur du registre et non la valeur stockée dans la mémoire RAM. Lorsqu'une attribution de lecture est faite; les contenus du registre de pointeur de tête, courant, sont copiés dans le pointeur de tête attribué dans la mémoire RAM. Lors- qu'on élimine une lecture, le pointeur de tête attribué dans la mémoire RAM est copié dans le registre de pointeur de tête courant. Si la file est déchargée, le registre de pointeur de tête, courant, est copié dans le poin- teur de tête courant dans la mémoire RAM et le bit de commande d'accès au sous-descripteur de lecture est débloqué. Une attribution de lecture se fait lorsque la confirmation est reçue indiquant la réussite du transfert des données; dans le cas contraire, on élimine la lecture. Le champ " décalage de tête courant " est la seconde partie du pointeur de tête courant. Il s'agit d'un champ d'une largeur de 12 bits décalé par rapport au début du " bloc de tête courant ". Le champ de dé- calage peut être courant avec une résolution de l'ordre de l'octet. Quatre octets de l'information de commande au début du bloc de mémoire sont éliminés. L'adresse correspondant à la dernière opération de lecture est donnée par: champ " bloc de tête courant " + quatre, + champ " décalage de tête courant ". Le champ " bloc de tête attribué " est un champ d'une lar- geur d'un mot faisant partie du sous-descripteur de lecture. Le champ " bloc de tête attribué " contient l'adresse de départ du bloc de mémoire à laquelle se produit la dernière lecture attribuée. Lorsqu'un portail de files * io d'attente attribue une lecture, au moins un bloc de mémoire peut être li- béré et la procédure de libération est déclenchée. La procédure de libéra- tion charge l'identificateur de files d'attente et la valeur dans le nombre de blocs du champ à libérer au début de la section de données du bloc mé- moire désigné par le champ du bloc de tête attribué. L'adresse du champ du bloc de tête attribué rejoint alors la file des blocs libérés, prête pour être ré-attribuée. La procédure d'attribution de lecture se termine alors par la copie du pointeur de tête, courant, dans le pointeur de tête attribué. Lorsqu'une lecture a été éliminée, le pointeur de tête attribué est copié dans le pointeur de tête courant. Le champ " décalage de tête attribué " est la seconde partie du pointeur de tête attribué. Ce champ a une largeur de 12 bits décalé par rapport au début du bloc de tête attribué. Le champ a une résolution de l'ordre de l'octet et contient quatre octets d'information de commande au début d'un bloc de mémoire. L'adresse à laquelle a été attribuée la der- nière lecture est donnée par: champ " bloc de tête attribué " plus quatre, plus champ " décalage de tête attribué ". Le champ " bloc à libérer " a une largeur d'un octet conser- vant la trace du nombre de blocs que l'on peut dégager lorsqu'il y a une attribution de lecture. Le champ est transféré dans un registre lorsque la file d'attente est chargée. Si une opération de lecture fait avancer le poin- teur de tête courant à un nouveau bloc de mémoire, le registre de libéra- tion de bloc est incrémenté. Lorsqu'une lecture est attribuée et est effectuée, on utilise le registre des blocs à libérer par cette procédure de libération. A la fin d'une opération d'attribution d'élimination, le regis- tre des blocs à libérer est remis à zéro. Lorsque la file est déchargée, le re- gistre des blocs à libérer est remis à zéro et il est copié dans le champ des blocs à libérer, dans la mémoire RAM. Le mécanisme de segmentation et de ré-assemblage dans le gestionnaire (QMS) 10 comprend un moyen pour indiquer les frontières du paquet à la différence du niveau du protocole de communication. En enre- gistrant l'information sous un format générique efficace, les dispositifs s utilisant les fils d'attente permettent de prendre des décisions concernant la réunion et la division des paquets sans connaître les différents formats des paquets. Les quatre bits les plus significatifs (MSB) du champ " commande de bloc " servent pour indiquer les frontières du flux des données. Ces bits seront désignés ci-après comme guide de commande ou drapeaux. La fonction principale du gestionnaire QMS 10 transférer d'un dispositif vers un autre, par exemple d'une interface hôte (non repré- sentée) de bus série universelle USB vers un module émetteur-récepteur radio (non représenté). L'interface hôte USB peut constituer l'utilisateur de file A, 11 et le module radio peut constituer l'utilisateur de file d'attente B, 12. Un ordinateur PC, hôte (non représenté) ou un quelconque dispositif hôte sont relié à l'interface hôte USB 11. A l'interface hôte USB 11, la donnée arrive sur la section de chargement payant du paquet L2CAP ayant le format suivant: Connexion ID à 2 octets Protocole 2 octets / multiplex heure de service 0 à 65533 octets de données de chargement payant Le paquet L2CAP est mis par l'interface hôte USB 11 dans un ou plusieurs paquets " interface contrôleur hôte" à HCI, et le paquet HCI a le format suivant: poignée de connexion 12 bits, + frontière paquet 2 bits, + type d'émission 2 bits Champ de longueur 2 octets 0 à 65533 octets de données de chargement payant Chaque paquet HCI est transformé en un ou plusieurs pa- quets USB et chaque paquet USB comprend: 1 jeu de transfert de données à 8 bits indiquant la di- rection des données Adresse 7 bits + point final 4 bits pour identifier la con- nexion des données "dans le dent le bleu" Centre de contrôle 5 bits Déclenchement transfert de données 8 bits (pour garan- tir l'absence de perte de données) Données à chargement payant (fragment HCI) Somme de contrôle 16 bits L'information extra USB est utilisée pour garantir le trans- fert des données correctes à partir de l'hôte. Mais cette information n'est pas mémorisée. L'information USB extra est extraite par l'interface hôte USB 1 1 qui transfert le chargement payant USB restant dans l'interface d'utilisateur de file 15. Si le chargement payant USB est le début d'un pa- quet HCI, l'interface d'utilisateur de file 15 extrait des quatre premiers octets de l'entête du paquet HCI puis transfère le restant de la charge payante dans le gestionnaire QMS 10. Si un paquet USB est le début d'un i0 paquet HCI, les deux premiers octets du paquet HCI sont utilisés par l'interface d'utilisateur de file 1 1 pour décider la file qui doit recevoir les données à enregistrer. Les deux des premiers octets ont 2 bits indiquant si le paquet HCI est le début ou la suite d'un paquet L2CAP. S'il s'agit du début du paquet L2CAP, le bit 2 du champ du drapeau à 4 bits maintenu par le gestionnaire QMS 10 est mis par l'interface d'utilisateur de file 1 1. Le gestionnaire QMS 10 est informé du début de paquets différents par l'interface hôte USB en utilisant des codes d'instruction prédéfinis. Si le paquet USB contient le début du paquet HCI, le bit 3 du champ de dra- peau à 4 bits maintenu par le gestionnaire QMS 10 est mis à l'écart. Si le paquet USB contient une continuation d'un paquet HCI, aucun drapeau n'est mis. Les drapeaux sont formés de 4 bits adjacents aux champs de tailles de blocs dans les blocs mémoire qui forment la file. Pendant le transfert des paquets USB, la charge payante (contenant les 4 octets de chaque entête de paquet HCI) est stockée dans la file. A la fin de chaque transfert de paquet USB, réussi, la donnée de la file est attribuée. Si le transfert de données n'est pas réussi, la donnée est éliminée. Du côté du module radio 12 de la file, le départ d'un mes- sage L2CAP est le début d'un paquet radio. Toutefois, les limites du pa- quet HCI n'ont pas à être maintenues. C'est pourquoi un paquet radio peut être informé par un fragment d'un paquet HCI, ou encore il peut contenir des multiples paquets HCI. Un paquet radio commence par un champ à 2 bits qui indique s'il s'agit du début ou de la poursuite d'un pa- quet L2CAP. On a ensuite un débit 2 bits (indiquant si la radio peut rece- voir les données) et un champ de 5 ou de 9 bits de longueur suivant le type de paquet utilisé. Bien que le module radio 12 ne soit pas concerne l0 par les frontières du paquet HCI, il compte le nombre de paquets HCI qui ont été envoyés avec succès et informe le PC hôte par le gestionnaire QMS en lui indiquant combien de paquets en plus peuvent être transférés. Du fait des drapeaux à la limite des paquets, gérés par le système de ges- tion de file 10, le module radio ne nécessite pas de moyens pour décoder l5 les paquets HCI et L2CAP. Lorsque le module radio 12 reçoit des paquets, il met le bit 3 du champ du drapeau à 4 bits maintenu par le gestionnaire QMS 10 pour indiquer le début d'un paquet radio générant le code d'instruction approprié. Si l'entête du paquet indique qu'il s'agissait du début d'un pa- quet L2CAP, le bit 2 est également mis. Le champ de longueur du paquet radio est éliminé par le module radio. La donnée de chargement prépayé est stockée dans la file associée au lien ou au canal par lequel a été reçu le paquet. Le côté hôte de la file d'attente ignore les frontières entre les paquets radio et crée des paquets HCI jusqu'à une frontière de paquets L2CAP. Pour cela, l'hôte a une taille de paquet maximale préréglée HCI. L'hôte demande au gestionnaire QMS 10 combien de données le séparent du pointeur courant, soit vers la fin de la queue, soit vers le point suivant auquel est mis le bit 2 du champ à 4 bits ou risque d'avoir suffisamment de données pour remplir la taille du paquet HCI. Puis l'hôte construit une en tête de paquet HCI en utilisant une poignée de connexion associée à la file d'attente et des drapeaux L2CAP de début ou de continuation, en fonction des drapeaux de commande et de la longueur du champ reposant sur la donnée maintenant la plus disponible. Pour une interface USB, les paquets HCI sont en outre clas- sés en paquets USB et tous les paquets de données utilisent la même adresse USB et le même point final. REVENDICATIONS 1 ) Procédé d'enregistrement d'un paquet de données dans une mémoire divisée en plusieurs blocs de mémoire, procédé caractérisé en ce qu' il comprend les étapes suivantes: - l'enlèvement de l'entête du paquet de données, - la division du restant des données du paquet en des fragments de pa- quet, - l'enregistrement de chaque fragment de paquet dans un bloc mémoire respectif avec une entête respective et - on met un drapeau " début de paquet " dans l'entête du bloc mémoire contenant le fragment de paquet correspondant au début du restant du paquet de données. 2 ) Procédé d'enregistrement d'un paquet de données selon la revendica- tion 1, caractérisé en ce que l'entête comporte un ensemble de drapeaux " début de paquet ".