Brevet FR2917864A1 — publié le 20081226

PROCEDE DE CALCUL D'UN CODE DE REDONDANCE CYCLIQUE La présente invention concerne une méthode de calcul d'un code de contrôle de redondance cyclique, dit CRC (Cyclic Redundant Check), qui est un moyen de contrôle d'intégrité des données puissant, contenant des éléments redondants vis-à-vis de la trame, permettant de détecter la plupart des erreurs. Il est largement employé dans le domaine des télécommunications, pour vérifier l'intégrité des trames transmises. Il est aussi employé pour détecter des erreurs dans le stockage de données. La présente invention s'applique plus particulièrement au contrôle de l'intégrité de données transférées en mémoire vive (RAM) d'un processeur d'un calculateur numérique, typiquement à partir des données mémorisées en mémoire programme (ROM), dans une phase d'initialisation à la mise sous tension du processeur. La mémoire programme est habituellement une mémoire externe au processeur, qui contient notamment des données de code instruction à exécuter correspondant à un programme applicatif, que doit exécuter le processeur en mode opérationnel. La mémoire cache est une mémoire interne au processeur, à accès ultra-rapide (SRAM), mais de taille réduite, qui permet au processeur d'exécuter le programme en temps optimal et aussi de sauvegarder des données d'information sur lesquelles il travaille, de manière temporaire. Cette mémoire cache interne peut elle même être décomposée et comprend au moins une mémoire cache dite de premier niveau qui dissocie souvent le code exécutable, stocké dans un cache d'instruction et les données, stockées dans un cache de données, par opposition à d'autres mémoires caches, externes ou non au processeur, dites de deuxième voire troisième niveaux, qui ont d'autres fonctions et qui ne dissocient généralement pas instructions et données. Généralement dans l'état de l'art, les caches de niveau élevé ont une capacité de quelques centaines de KOctets tandis que la capacité des caches de premier niveau est plus faible (quelques dizaines de KOctets). D'une manière habituelle, la mise sous tension d'un calculateur numérique déclenche une phase de tests, qui a pour but de vérifier un certain nombre de conditions, et notamment déterminer si le processeur peut passer en mode applicatif ou doit passer dans un mode bloqué, en attente d'une opération de maintenance. Une telle phase de tests de démarrage à la mise sous tension, souvent appelée phase POST suivant l'acronyme anglo-saxon "Power on Safety Test", est notamment rencontrée dans tous les calculateurs utilisés dans des applications où la sécurité est en jeu, notamment dans le domaine de l'avionique, des télécommunications, ..., et où il est primordial de détecter si l'on est en mesure ou non de dérouler un programme correctement. Dans cette phase POST, on doit notamment transférer en mémoire vive (RAM), les données contenues en mémoire programme morte (ROM) et vérifier leur intégrité. L'intérêt d'un tel transfert est l'accélération de l'exécution ultérieure des programmes applicatifs en raison des meilleurs temps d'accès des composants RAM. La vérification de l'intégrité des données couvre à la fois l'intégrité du stockage des données et de leur transfert. Cette phase POST est habituellement très contrainte en temps. 15 Les cahiers des charges habituels imposent quelques secondes au maximum pour la réaliser. Dans ce contexte, on s'est intéressé aux techniques de calcul du code CRC sur un train de bits de grande longueur, correspondant à la taille du programme, et à leurs performances notamment en terme de temps de 20 calcul. On rappelle ci après quelques principes de base du code CRC. Le code CRC est basé sur des calculs basés sur l'arithmétique modulo 2 (arithmétique binaire) et un polynôme générateur, habituellement noté G(x), qui est connu et de l'émetteur et du récepteur des séquences binaires. Une séquence binaire de m bits est ainsi traitée comme un 25 polynôme binaire B(x) de degré maximal m-1, c'est à dire un polynôme dont les coefficients binaires correspondent à la séquence binaire. En pratique, le polynôme générateur d'ordre n est un polynôme diviseur de x"+1, et s'écrit G(x)=gnx" +gn-1x""1 + +g2x2 +g1x'+ go, où go et gn valent 1 et où g;, ;#o,n vaut 0 ou 1. 30 Le mécanisme de vérification de l'intégrité d'une séquence binaire consiste alors pour l'émetteur à effectuer un algorithme en arithmétique modulo 2, sur les bits de la séquence binaire, en utilisant le polynôme générateur afin de générer un code CRC, et de transmettre la séquence et ce code CRC concaténés au récepteur. Il suffit alors au récepteur d'effectuer 35 le même calcul sur la séquence reçue (c'est à dire la séquence binaire émise et son code CRC) : si le code CRC calculé par le récepteur est nul, c'est que les données sont intègres. En pratique, c'est la division polynomiale qui est mise en oeuvre. Le reste R(x) de la division de la séquence binaire par le polynôme générateur G(x) est le code CRC. Une description théorique de l'algorithme de calcul est ainsi la suivante : Soit B le message correspondant aux bits de la séquence binaire à envoyer ; et B ' le message transmis, c'est à dire le message B initial auquel aura été concaténé le code CRC de m bits. Le code CRC est tel que B'(x) que divise G(x) est égal à zéro : le code CRC est le reste de la division polynomiale de B(x) (auquel on aura préalablement concaténé m bits nuls correspondant à la longueur du CRC) par G(x). La qualité du code CRC en terme de détection d'intégrité est fonction du polynôme générateur G utilisé. On connaît différents polynômes générateurs qui donnent ainsi une fiabilité de près de 100% sur la vérification de l'intégrité de la trame, utilisés notamment dans les protocoles de transmission courants en télécommunication, qui permettent de détecter des erreurs sur 1 bit, 2 bits ou des erreurs en rafale. On peut en donner différents exemples bien connus, comme le polynôme générateur utilisé de manière courante sur les liaisons synchrones haut débit ("Ethernet"): x32+ x26+ x23+ x22+ x16+ x12+ x11+ x10+ x8+ x7+ x5+ x4+ x2+ x1+ 1 (polynôme de degré 32 (donné par l'exposant le plus élevé), codé sur 33 bits) fournissant un code CRC sur 32 bits; Ou encore le polynôme générateur utilisé en standard pour les trames X25 (protocole HDLP) : x16+ x12+ x5+ 1 (degré 16, codé sur 17 bits), fournissant un code CRC sur 16 bits. En pratique, la division polynomiale peut être réalisée bit à bit au moyen d'un registre de type LFSR (Linear Feedback Shift Register), c'est à dire un registre à décalage dans lequel à chaque décalage d'un bit, le bit entrant est obtenu par combinaison, au travers d'une chaîne de portes XOR (Ou exclusif), du bit suivant issu du train de données d'entrée dont on calcule le code CRC, et de plusieurs bits de rang judicieusement choisis, extraits du registre à décalage. Les rangs de ces bits judicieusement choisis correspondent à la définition du polynôme générateur diviseur G(x). Le principe est illustré sur la figure 1. Dans l'exemple, le polynôme générateur G(x) est d'ordre n=4 et s'écrit G(x)=g4x4 +g3x3 +g2x2 g1x1+ go. Dans la figure, les ronds figurent les portes ou exclusif (XOR) et les carrés, les bascules D du registre. L'ensemble constitue un registre à décalage série et parallèle, avec une boucle de rétroaction qui ramène sur les entrées parallèles des portes ou exclusif, l'information présente en sortie du registre. Il y a rétroaction (inversion du bit entrant) si g;=1, et pas de liaison (bit entrant inchangé) si g;=0. Les bits du message d'entrée sont rentrés en séquence dans le registre, les bits circulant dans l'exemple de la gauche vers la droite, le bit de poids le plus faible du message (LSB) entrant en premier. S'agissant de calculer le code CRC d'un train de données correspondant à un programme applicatif à exécuter, la séquence binaire à diviser est particulièrement longue, ce qui rend prohibitif en phases de test POST, le traitement bit à bit d'une telle séquence par un registre LFSR. Et une réalisation en logiciel d'un registre LFSR, exécutée par un processeur, n'est pas plus intéressante. Des méthodes plus efficaces et adaptées au traitement de grandes séquences binaires ont été développées, notamment pour répondre aux besoins en matière de réseaux de télécommunication. Ces méthodes s'appliquent à des séquences de longueur contrainte, correspondant aux structures des messages utilisés dans ces réseaux. Typiquement, cette longueur est une longueur égale à un nombre entier d'unités d'information, où unité d'information signifie un groupe de bits successifs de la séquence, en correspondance avec les architectures des bus de données, typiquement 8 bits. Une unité d'information correspond ainsi typiquement à 8 bits. Ces méthodes permettent de traiter le calcul du code CRC d'une séquence binaire par blocs, chaque bloc égal à un nombre entier multiple d'une unité d'information, soit typiquement 8bits (1 octet), 16 bits (1 mot), ou 32 bits (1 double mot). De façon succincte, ces méthodes connues se basent sur le fait que le contenu du registre à décalage est une combinaison du contenu précédent et des nouveaux bits introduits. Un perfectionnement de ces méthodes utilise une table précalculée du code CRC pour toutes les valeurs (binaires) possibles d'un bloc, qui remplace toutes les étapes de calcul correspondant à un traitement bit à bit : une table précalculée est une table de vérité d'une fonction logique, qui permet une conversion rapide de données. Si un bloc comprend n bits, pour traiter n bits en parallèle, il faut précalculer le résultat pour chaque combinaison possible de ces n bits, pour former cette table. Pour un code CRC à calculer de longueur m bits, calculé par blocs de n bits, la table précalculée aura ainsi 2" entrées de m bits de long, fournissant la valeur précalculée sur m bits du code CRC pour toute combinaison de n bits appliquée en entrée comme index ou adresse de la table. En d'autres termes, pour chaque valeur possible d'un mot de n bits, la table donne ainsi le reste de la division de ces n bits augmentés de m zéros. Si on prend n=8 bits et m=32 bits, cela implique une taille de table précalculée de 28.32 bits soit l Koctets. D'une manière simplifiée, la méthode de calcul avec une table précalculée est la suivante, pour une séquence B traitée par blocs de 8 bits, et un code CRC de 8 bits : après que le registre de calcul du code CRC ait été initialisé, les premiers 8 bits de donnée sont combinés (Ou exclusif) avec le contenu (8 bits) du registre de calcul. Le résultat est utilisé comme pointeur de la table précalculée, qui fournit en sortie une valeur 8 bits chargée dans le registre variable. Les 8 bits du bloc suivant de la séquence B sont combinés avec cette nouvelle valeur du registre de calcul ; le résultat est appliqué comme pointeur de la table précalculée, qui fournit en sortie une valeur 8 bits appliquée dans le registre de calcul, et ainsi de suite jusqu'à ce que toute la chaîne soit traitée. A la fin, le registre contient la valeur CRC de la séquence B. L'utilisation de telles tables précalculées dans des algorithmes de calcul de code CRC, appelées dans la littérature anglo-saxonne "table lookup", ou "table-driven" est bien connue et est décrite dans la littérature technique, avec des exemples d'algorithmes ou de tables donnés notamment en référence aux polynômes générateurs les plus couramment utilisés, dont on a cité deux exemples plus haut. Ces techniques ont été perfectionnées pour simplifier le calcul d'un code CRC de 16 ou 32 bits. Elles permettent de calculer le code CRC correspondant à l'accumulation d'un bloc de 16 ou 32 bits entrants de la séquence de bits, en prévoyant deux (CRC 16 bits) ou quatre étapes (CRC 32 bits) correspondant à la prise en compte de chacun des deux ou quatre octets du code CRC courant dans ce calcul, au moyen de deux ou quatre tables physiquement distinctes, chacune de 28.32 bits soit l Koctets. II pourrait sembler judicieux de diminuer le nombre d'étapes en traitant non pas 8 bits (un octet) du code CRC courant à chaque étape, mais l'ensemble des bits du bloc de données traité à chaque étape de ce code, dans une unique table, ou la moitié, avec deux tables. Si on prend l'exemple d'un code CRC sur 32 bits, et un calcul en une seule étape, cela conduit à une table précalculée de 16 Gigaoctets. Même si on prévoit plutôt un calcul en deux étapes en traitant à chaque fois 16 bits, cela conduit à prévoir deux tables de 256 Koctets. Ainsi, l'inconvénient principal de cette méthode à table(s) précalculée(s) est le volume mémoire requis si on cherche à traiter plus de bits de la séquence en même temps. Dans l'invention, on cherche à utiliser au mieux la mémoire cache du processeur pour réduire le temps de calcul du code CRC de la séquence des données de mémoire programme ROM transférées en mémoire RAM du processeur en phase POST. On a vu que les tables précalculées permettent d'aller plus vite. Mais si leur taille est trop grande, elles ne peuvent être mémorisées elle- même en mémoire cache de donnée de premier niveau, qui a un volume limité, généralement très inférieur à 256Koctets. Si l'on doit stocker ces mémoires dans des composants de mémoire externe, par exemple des mémoires EEPROM, le gain réalisé en temps de calcul est perdu dans le nombre de cycles horloge nécessaire pour lire ces mémoires externes. Pour un traitement optimum de la vérification des données de mémoire programme transférées en mémoire RAM, il faut ainsi assez d'espace de mémoire cache de donnée de premier niveau pour que cette mémoire contienne les tables précalculées et que le cache d'instruction de premier niveau contienne les instructions relatives au programme de calcul et vérification du code CRC, cette deuxième condition étant très aisément remplie en raison de la faible taille du programme de calcul de code CRC. L'invention a ainsi pour objet un procédé optimisé de calcul d'un code de redondance cyclique par blocs d'une séquence de bits de longueur contrainte transférée en mémoire RAM d'un processeur, permettant son exécution en utilisant le code contenu dans la mémoire cache d'instruction et les tables précalculées et entièrement contenues dans la mémoire cache de donnée du processeur, sans autres accès externes que ceux nécessaires à la prise en compte des données contrôlées résidant en mémoire externe. L'idée à la base de l'invention est de découper de façon judicieuse le registre de calcul CRC pour que les tables précalculées correspondantes puissent être préchargées en mémoire cache, de préférence en mémoire cache de donnée de premier niveau. L'invention concerne donc un procédé de calcul d'un code de redondance cyclique CRC, caractérisé en ce qu'il est exécuté en mémoire cache d'un processeur, pour effectuer un calcul par blocs du code de redondance cyclique CRC d'une séquence de bits, et en ce qu'il comprend un découpage d'un registre de calcul dudit code CRC en plusieurs tranches, au moins trois tranches, et un préchargement dans ladite mémoire cache de tables de précalcul, une table pour chaque tranche correspondante du registre, adressée par un pointeur de même longueur que ladite tranche, et le nombre de tranches et leurs longueurs respectives étant déterminés en fonction de la taille de mémoire cache du processeur, au moins deux tranches ayant une longueur comprise entre 8 et 16 bits, bornes exclues. D'autres avantages et caractéristiques de l'invention sont détaillés dans la description suivante en référence aux dessins illustrés d'un mode de réalisation de l'invention, donné à titre d'exemple non limitatif. Dans ces dessins : -la figure 1 illustre le calcul d'un code CRC par un registre LSFR; - la figure 2 illustre de façon schématique une architecture de calculateur 20 numérique à processeur à mémoire cache interne; - la figure 3 illustre le processus de découpage du registre de code CRC courant selon l'invention; et - la figure 4 est un organigramme d'une séquence d'initialisation POST à la mise sous tension, mettant en oeuvre un procédé de calcul selon l'invention. 25 La figure 2 illustre à titre d'exemple une architecture d'un calculateur numérique, comprenant sur un bus de données, un processeur 10 comprenant une mémoire cache 11, une mémoire programme 20, une mémoire vive 30, une mémoire EEPROM 40 auquel peut s'appliquer 30 l'invention. La mémoire programme ROM 20 contient un programme applicatif à dérouler par le processus en mode opérationnel. La mémoire EEPROM 40 contient par exemple des tables précalculées, dans l'exemple TLU1, TLU2, TLU3. Mais cet élément 40 n'est pas nécessaire, les tables pouvant également être contenues dans la mémoire programme ROM 20. La mémoire vive RAM 30 est typiquement utilisée en opérationnel par le processeur, pour stocker des données et des programmes en cours 5 d'exécution. A la mise sous tension du calculateur, et donc des différents éléments 10, 20, 30, 40, un signal d'initialisation Reset est activé qui provoque notamment : •un transfert en mémoire RAM 30 des données de la mémoire programme ~o (ROM 20); •un chargement des tables précalculées TLU;, en mémoire cache 11 du processeur; •le calcul par blocs du code de redondance cyclique CRC de la séquence de bits correspondante transférée, au moyen des tables de précalcul. 15 De préférence, la mémoire cache utilisée est la mémoire cache de premier niveau, avec les instructions correspondant au calcul du code en cache instruction, et les tables de calcul en cache de données. Lorsque la boucle de calcul du code CRC d'une séquence B de bits s'exécute, tous les accès instructions se font depuis le cache 20 d'instruction, et tous les accès aux tables se font depuis le cache de donnée. Dans un cache de premier niveau avec parties instruction et data indépendantes, les deux flux ne se gênent pas. Le seul flux en provenance de la mémoire externe est la lecture de la séquence binaire dont on calcule le code CRC. Pour cela on dispose de 100% de la bande passante 25 disponible du bus mémoire. Les tables de calcul sont de préférence préchargées et verrouillées en cache de données. Ainsi les tables de calcul ne sont pas susceptibles d'être remplacées par d'autres données lues ultérieurement par le processeur durant le calcul du code CRC. 30 Comme illustré sur la figure 3, le calcul du code CRC est ainsi réalisé en utilisant de façon optimale les instructions et les données présentes dans la mémoire cache interne 11 du processeur, et un procédé de calcul du code CRC selon lequel la séquence B de bits est traitée par blocs b de bits et un registre R de calcul de longueur correspondante, 35 contenant la valeur courante du code CRC et qui est découpé en tranches de bits R;, au moins trois. Le bloc b de bit correspond typiquement à une unité d'information. Dans l'exemple illustré, il correspond à un double mot (32 bits) b0-b31. Le registre R de même longueur a ainsi 32 bits c0-c31, et est découpé en trois tranches de bits : R1 (x0 à x10, correspondant à c0-c10), R2 (y0 à y9 correspondant à c11-c20), R3 (z0 à z10 correspondant à c21-c31). Chaque tranche Ri du registre de calcul est associée à une table précalculée propre TLU;, indexée par un pointeur pi de même longueur que la tranche associée R. La valeur courante du pointeur p; est fonction du contenu de la tranche correspondante Ri du registre de calcul et du contenu de la tranche de bits correspondante du bloc b de la séquence traité. Elle est le résultat de la combinaison par un ou exclusif parallèle (XOR) de la tranche de bits Ri, avec une tranche des bits b0 à b31 du bloc b de bits courant. Typiquement, dans l'exemple illustré, si on prend la première tranche R1, la valeur du pointeur pl est le résultat de la combinaison ou exclusif parallèle des bits b0 à b10 du bloc b traité avec les bits x0 à x10 de la tranche R1 du registre courant. Chaque table TLU; indexée par le pointeur pi associé à la tranche de bits Ri fournit en sortie une valeur v; qui est la contribution de cette tranche Ri du registre de calcul R, à l'accumulation du bloc b de bits b0 à b31 suivant de la séquence B : en d'autres termes la valeur v; est la nouvelle valeur de la tranche correspondante Ri du registre R, pour le traitement du bloc b suivant. Sur la figure 3, v1 vient ainsi remplir les bits c0ûc10 du registre R, correspondant à la tranche R1 (x0-x10) ; v2 vient ainsi remplir les bits c11ûc20 du registre R, correspondant à la tranche R2 (y0-y9) ; et v3 vient ainsi remplir les bits c21ûc31 du registre R correspondant à la tranche R3 (z0-z10). En pratique, ces tables peuvent être utilisées de différentes manières selon l'algorithme choisi, et les différentes options retenues, telles que l'ordre de présentation des bits, la valeur d'initialisation du registre R de calcul R.... La figure 3 n'est ainsi présentée qu'à titre d'illustration d'un procédé selon l'invention. Dans la détermination du nombre des tranches et de leur longueur 35 (nombre de bits), il est à remarquer que dans l'invention, on ne s'intéresse pas à un découpage correspondant à une unité d'information ou un multiple, telle qu'on l'a définit plus haut (octet, mot, double-mot), alors que le bloc b traité et le registre de calcul qui fournit le code CRC de la séquence sont typiquement un multiple de cette unité d'information, par exemple 32 bits. En effet, cela ne permet pas d'arriver à un algorithme de calcul optimal et à des tailles optimales de tables, au sens de la possibilité de leur intégration et leur verrouillage en mémoire cache de donnée de premier niveau. Aussi, une caractéristique de l'invention est d'obtenir un découpage en au moins 3 tranches, au moins deux tranches ayant une longueur comprise entre 8 et 16 bits, bornes exclues. La mémoire cache de premier niveau ayant une taille limitée, par exemple 32 Koctets pour le cache de données et 32 Koctets pour le cache instruction, le découpage en tranches est réalisé pour que la taille cumulée des tables précalculées soit inférieure au volume de mémoire cache de donnée de premier niveau disponible. Dans un exemple avantageux, pour le calcul d'un code CRC de 32 bits d'une séquence de bits traitée par blocs b de 32 bits, ce découpage est ainsi réalisé en trois tranches, deux tranches de 11 bits xO à x10 (RI), et zO à z10 (R3) et une tranche de 10 bits yO à y9 (R2). Les tables précalculées associées sont ainsi : -pour les tranches RI et R3 de 11 bits, les tables TLU1 et TLU3 comportant 211 mots de 32 bits soit un total de 16Koctets, fournissant pour chaque combinaison possible de 11 bits, une valeur de contribution correspondante (32 bits) pour l'accumulation du bloc b suivant. -pour la tranche de 10 bits, la table TLU2 comportant 210 mots de 32 bits soit 4Koctets, fournissant pour chaque combinaison possible de 10 bits, une valeur de contribution sur 32 bits correspondante pour l'accumulation du bloc b suivant. L'ensemble des tables occupant un volume de 20Koctets, elles 30 peuvent aisément être stockées dans un cache de donnée de premier niveau de 32 Koctets. L'invention qui vient d'être décrite permet de réduire le temps de calcul du code CRC, en permettant son exécution intégrale en mémoire cache. Tous les goulots d'étranglement lié aux accès mémoires étant 35 jugulés, le temps d'exécution de l'algorithme de calcul du code CRC dépend ainsi au premier ordre de la performance intrinsèque de la machine et de l'optimisation du codage sur l'architecture concernée, d'où l'intérêt de tirer partie des unités d'exécutions multiples si on en dispose, des possibilités de lecture de données en une seule instruction. Comme vu en relation avec la figure 3, l'accès à chacune des tables et les traitements associés ne sont pas dépendants les uns des autres. II n'y a pas de dépendance aux données dans la boucle de calcul du code CRC (pas de branchement dont la décision pourrait dépendre de la valeur d'une donnée). Les lectures peuvent être pipelinées (i.e. insérée dans une file avec traitement à la chaîne) sans rupture du pipeline. Aussi, dans une application utilisant un processeur à unités d'exécution multiples, on prévoit avantageusement que les accès aux trois tables et leur traitement associé, c'est à dire la combinaison OU exclusif avec un groupe correspondant du nouveau bloc de la séquence à traiter, sont exécutés en parallèle, l'architecture d'un tel processeur permettant de traiter plusieurs instructions élémentaires en parallèle, par exemple 5 instructions, ou 8 instructions, pour gagner encore en temps d'exécution. Ces processeurs à unités d'exécution multiples sont utilisés de manière connue dans des applications exigeantes en calcul, notamment dans les systèmes de télécommunication à haut débit, et ont une architecture particulière permettant de traiter de nombreuses instructions élémentaires en parallèle. REVENDICATIONS 1. Procédé de calcul d'un code de redondance cyclique CRC, caractérisé en ce qu'il est exécuté en mémoire cache (11) d'un processeur (10), pour effectuer un calcul par blocs (b) du code de redondance cyclique CRC d'une séquence (B) de bits, et en ce qu'il comprend un découpage d'un registre de calcul (R) dudit code CRC en plusieurs tranches (RI, R2, R3), au moins trois tranches, et un préchargement (100) dans ladite mémoire cache (11) de tables de précalcul (TLU1, TLU2, TLU3), une table pour chaque tranche correspondante du registre, adressée par un pointeur (p1, p2, p3) de même longueur que ladite tranche, et le nombre de tranches et leurs longueurs respectives étant déterminés en fonction de la taille de mémoire cache du processeur, au moins deux tranches ayant une longueur comprise entre 8 et 16 bits, bornes exclues. 2. Procédé selon la revendication 1 dans lequel la séquence (B) est traitée par blocs de 32 bits, pour calculer un code CRC de 32 bits, caractérisé en ce que ledit registre courant (R) est découpé en trois tranches, deux tranches (RI, R3) de 11 bits et une tranche (R2) de 10 bits, dans un ordre quelconque. 3. Procédé selon la revendication 1 ou 2, mis en œuvre dans un processeur du type à unités d'exécution multiples, caractérisé en ce que les accès aux tables associées aux tranches sont réalisés en parallèle. 4. Procédé selon l'un des revendications précédentes, dans lequel ladite mémoire cache (11) est une mémoire cache de premier niveau à cache instruction et cache de données séparés, les instructions correspondant au calcul du code étant en cache instruction et les tables de calcul verrouillées en cache de données. 5. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il est mis en oeuvre dans une phase de vérification (POST) déclenchée par la mise sous tension du processeur, pour vérifier l'intégrité d'un programme applicatif transféré (101) dans la mémoire vive RAM à ladite mise sous tension.