INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Dans un cycle d'écriture (figure 3), le contrôleur de DRAM place le signal RW/ au niveau logique bas. II place d'abord le numéro de ligne sur le bus d'adresses 5. Quelques nanosecondes plus tard, il descend le signal RASL Sur le front descendant de RAS/, la DRAM 2 enregistre numéro de ligne. Le contrôleur de DRAM place ensuite le numéro de colonne le bus d'adresses 5 ainsi que la donnée à mémoriser sur le bus de données 4, puis descend le signal CAS/. Sur le front descendant de CAS/, la DRAM enregistre le numéro de colonne et mémorise à l'adresse adéquate la donnée présente sur le bus de données 4. Un certain temps après, le microcontrôleur remonte les signaux RAS/, CAS/ et cesse de fournir la donnée sur le bus de données 4.
La mémorisation de l'information dans une memoire dynamique de type DRAM n'est assurée que si le contenu de la mémoire est réécrit régulièrement. Un moyen semi-automatique est prévu pour cela : les cycles de rafraîchissement ( refresh ). II suffit d'effectuer un cycle de rafraîchissement à intervalles réguliers (généralement de l'ordre de 15 microsecondes) pour que l'intégrité des données soit assurée. Le cycle de rafraichissement (figure 4) peut être caractérisé par le niveau bas du signal CAS/ alors que RAS/ est au niveau haut, puis par la mise au niveau bas de RASL Ce mécanisme est appelé CAS before RAS . Cette séquence ne se produit pas dans les cycles de lecture ou d'écriture des figures 2 et 3.
Les mémoires asynchrones sont largement utilisées dans diverses applications où elles fonctionnent avec des microcontrôleurs ou d'autres systèmes de traitement numérique.
Mais on observe actuellement une certaine obsolescence des mémoires dynamiques asynchrones utilisées dans les équipements électroniques à base de microcontrôleurs. Le marché DRAM est dominé par l'application aux ordinateurs personnels (PC), qui représente près de 70%. Le remplacement progressif des DRAM asynchrones, par des technologies synchrones (SDRAM) et autres, est confirmé par les annonces successives des principaux fournisseurs. Malgré l'existence attendue d'un marché résiduel destiné à couvrir les besoins en DRAM asynchrones, on peut s'attendre à une hausse sensible de leurs coûts et à une ifficulté d'approvisionnement croissante. Les principales technologies de remplacement sont les suivantes - la SDRAM classique , qui est la plus mûre ; - la technologie Rambus DRAM (ou Direct Rambus ), qui semble être le choix d'évolution de plusieurs constructeurs ; - les technologies dérivées de la SDRAM (telles qu Double-Data-Rate SDRAM ) proposées par certains fournisseurs de DRAM.
Ces deux dernières technologies, très récentes, restent coût élevé, et leur compatibilité avec les microcontrôleurs récents les plus répandus (par exemple les types PowerQuicc I et II de la société Motorola) n'est pas assurée.
Une première solution, pour le remplacement de la technologie de mémoire obsolescente par des SDRAM, consiste à utiliser un nouveau microcontrôleur pourvu des interfaces appropriées avec les nouvelles mémoires, en utilisant éventuellement un contrôleur de mémoire externe pour se protéger d'une obsolescence future. Cette solution garantit sans doute le maintien, voire l'accroissement, des performances, ainsi qu'une pérennité maximale. Elle est malheureusement la plus lourde en termes de développement matériel et logiciel.
Une seconde solution consiste à conserver le microcontrôleur existant et à insérer un composant entre le microcontrôleur et les nouveaux boîtiers de mémoire, pour remplacer totalement le contrôleur mémoire intégré du microcontrôleur par un contrôleur externe, plus souple, et permettant gérer la nouvelle mémoire. Ainsi, la partie contrôleur interne du microcontrôleur n'est pas utilisée, et ce dernier fonctionne alors en microprocesseur. La transparence logicielle n'est plus assurée. En conséquence, cette solution, qui peut sembler a priori compatible avec le maintien des performances initiales, comporte un fort impact logiciel, qui rend la nouvelle plate-forme matérielle à coup sûr incompatible avec le logiciel utilisé.
La présente invention a pour but de résoudre le problème d'obsolescence des mémoires DRAM asynchrones, et leur remplacement progressif par des mémoires synchrones (SDRAM), tout en conservant la compatibilité logicielle de la nouvelle plate-forme matérielle.
Selon l'invention, il est proposé un circuit de commande d'au moins une mémoire synchrone, comprenant des moyens pour traduire des premiers signaux de commande issus d'un système de traitement numérique en seconds signaux de commande synchronisés sur des fronts actifs d'un signal d'horloge et destinés à la mémoire synchrone, ces moyens de traduction comprenant des moyens logiques pour recevoir les premiers signaux de commande sous la forme de signaux de commande non synchronisés produits par un contrôleur de mémoire asynchrone du système de traitement numérique, et pour effectuer leur traduction en seconds signaux de commande synchronisés.
On insère donc un composant d'adaptation entre le microcontrôleur existant et les nouveaux boîtiers de mémoire SDRAM, relayant les signaux d'accès du contrôleur de mémoire intégré au microcontrôleur, pour adapter à la nouvelle technologie. Le circuit peut être réalisé sous forme d'un composant programmable (de type EPLD, FPGA ou analogue), ou avec une technologie masquée (ASIC, prédiffusé, etc.).
L'invention réalise un bon compromis entre un effort de développement modéré et un maintien acceptable des performances. Elle permet résoudre le problème d'obsolescence tout en pouvant présenter complète transparence au logiciel du microcontrôleur.
Le système de traitement numérique auquel est associé le circuit selon l'invention est typiquement un coeur de processeur associé à un contrôleur de mémoire asynchrone. II peut notamment être un microcontrôleur comme indiqué précédemment. Mais il est à noter qu'il pourrait être de nature différente selon l'architecture retenue dans chaque application particulière, par exemple microprocesseur avec contrôleur de DRAM externe, ou ASIC avec contrôleur de DRAM interne ou externe.
D'autre part, le circuit selon l'invention peut être réalisé sous forme d'un composant externe au système de traitement numérique, ou sur la même puce qu'une partie au moins du système de traitement numérique. Ce dernier cas peut être celui d'une nouvelle version de microcontrôleur rendue compatible avec les nouveaux types de mémoires DRAM avec un impact modéré sur l'organisation du composant.
D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels - la figure 1, précédemment commentée, est un schéma classique d'un mïcrocontrôleur associé à une DRAM asynchrone ; - les figures 2 à 4, précédemment commentées, sont des chronogrammes respectifs d'exemples de cycles de lecture, d' " iture et de rafraîchissement dans la mémoire de la figure 1 ; - la figure 5 est un schéma synoptique d'un microcontroleur du type représenté sur la figure 1, associé à une SDRAM au moyen d'un circuit d'adaptation selon l'invention ; et - la figure 6 est un chronogramme montrant un cycle de lecture et un cycle d'écriture dans la mémoire de la figure 5.
L'utilisation d'un amorceur-contrôleur apporte l'avantage d'obtenir d'office le rapport optimal SFR/Z = 1,0.
EXEMPLE 2 (Comparatif) Polymérisation de l'éthylène à 170 MPa et à 230 C avec le système d'amorçage DTBP + TEMPO On procède comme à l'Exemple comparatif 1, excepté que la charge d'éthylène est de 17,9 g, que l'on conduit la réaction à une température de 230 C au lieu de 250 C, et sous une pression de 170 MPa au lieu de 250 MPa, et que l'on remplace le système BPO + TEMPO par le système suivant : - 0, 005 g de DTBP (106 ppm molaire de radicaux libres par rapport à l'éthylène) ; et - 0,011 g de TEMPO.
Le rapport molaire TEMPO/DTBP est de 2,0, ce qui correspond à un rapport SFR/Z de 1.
On obtient les conversions suivantes au cours du temps :
Temps Conversion ln(l/(l-conversion)) (min.) (%) 0 0 0 15 2,7 0,027 30 8,5 0,089 45 15, 2 0,165 ii ::l 60 21,2 0,238
La vitesse moyenne de polymérisation est de 0,0951 min-1.
EXEMPLE 3 Polymérisation de l'éthylène à 170 MPa et à 230 C avec l'amorceur-contrôleur hexyl-TEMPO On reprend les conditions opératoires de l'Exemple 2, excepté que l'on remplace le système BPO + TEMPO par le composé "amorceur-contrôleur" suivant : 0,016 g d'hexyl-TEMPO (104 ppm molaire de radicaux libres par rapport à l'éthylène). Le rapport SFR/Z est de 1,0.
Temps Conversion ln(1/(1-conversion)) (min. ) (%) 0 0 0 15 10,9 0,115 30 21 0,236 45 28,2 0,331 60 34,7 0,426
La vitesse de polymérisation, qui est ici de 0,1224 min-1 est plus élevée que pour l'Exemple comparatif 2 (soit 23% de plus), alors que les conditions opératoires sont les mêmes : pression, température et quantité de radicaux par rapport à l'éthylène. En outre, la courbe ln (1/(1-conversion)) en fonction du temps est une droite, ce qui indique un bon contrôle de la polymérisation.
Des mesures de spectrométrie paramagnétique électronique sur l'hexyl-TEMPO montrent de plus qu'il est nécessaire d'élever la température au-delà de 200 C pour voir apparaître un signal. Cela signifie que la liaison C-0 ne se rompt qu'à partir de cette température.
Or, la liaison entre la chaîne de polyéthylène et le TEMPO (-CH2-TEMPO) est de même nature. Il est donc nécessaire de chauffer au-delà de 200 C pour pouvoir rompre la liaison entre le TEMPO et le polymère. Les conditions du procédé de la présente invention sont donc différentes de celles du procédé selon WO 99/03894, pour laquelle la température ne doit pas dépasser 180 C, sous peine de perdre le contrôle de la polymérisation.
EXEMPLE 4 (comparatif) Polymérisation de l'éthylène à 200 MPa et 220 C avec le système d'amorçage DTBP + CXA 5415 On reprend les conditions opératoires de l'Exemple 1, excepté que la charge d'éthylène est de 18,3 g, que l'on conduit la réaction à une température de 220 C au lieu de 250 C et à 200 MPa au lieu de 250 MPa, et que l'on remplace le système BPO + TEMPO par le système suivant : - 0,0045 g de DTBP (94 ppm molaire de radicaux libres par rapport à l'éthylène) ; et0,016 g de CXA 5415.
Le rapport molaire CXA 5415/ DTBP est de 1,0, ce qui équivaut à un rapport SFR/Z de 1,0.
Temps Conversion ln(l/(l-conversion)) (min. ) (%) 0 0 0 15 0,3 0,003 30 0,7 0,007 45 2,2 0,022 60 4,7 0,048
Aux dessins annexés, donnés à titre d'exemples non limitatifs : - la figure 1 illustre schématiquement des réseaux de communication adaptés à mettre en #uvre la présente invention ; - la figure 2 est un graphe illustrant schématiquement un système d'objets distribués ; - la figure 3 est un diagramme bloc illustrant un ordinateur adapté à mettre en #uvre l'invention ; - la figure 4 est un diagramme illustrant la traduction directe et inverse d'un objet informatique, d'un langage de programmation vers un langage de communication ; - la figure 5 est un diagramme bloc illustrant deux ordinateurs adaptés à mettre en #uvre la présente invention ; - la figure 6 est une représentation schématique d'un espace mémoire adapté à mémoriser une table d'associations ; - la figure 7 est un algorithme illustrant un procédé de traduction d'un objet informatique conforme à un premier aspect de l'invention ; - la figure 8 est un algorithme illustrant un procédé de transfert d'un objet informatique conforme à un second aspect de l'invention ; - la figure 9 est un algorithme illustrant un procédé de mise à jour à distance d'un objet informatique conforme à un troisième aspect de l'invention ; et - la figure 10 est un algorithme illustrant un procédé de suppression d'un objet informatique.
La présente invention dont un mode de réalisation va être décrit cidessous, s'applique en général aux réseaux de communication informatique.
Ici, à titre d'exemple, le réseau R1 comporte deux ordinateurs C1, C2 ; le réseau R2 comporte un seul ordinateur C3 ; etle réseau R3 comporte trois ordinateurs C4, C5 et C6.
En outre, l'exigence imposée par le procédé de vérification objet de la présente invention selon laquelle la pile doit être vide à chaque instruction de branchement ou de cible de branchement, garantit que la pile est dans le même état, vide, après exécution du branchement et avant exécution de l'instruction à laquelle le programme s'est branché. Ce mode opératoire garantit que la pile est dans un état cohérent, quel que soit le chemin d'exécution suivi à travers le code du sous-programme ou de l'appliquette considéré. La cohérence de la pile est ainsi garantie, même en présence de branchement ou de cible de branchement. Contrairement aux procédés et aux systèmes de l'art antérieur, dans lesquels il est nécessaire de conserver en mémoire vive le type de la pile à chaque cible de branchement, ce qui nécessite une quantité de mémoire vive proportionnelle à TpxNb, produit de la taille maximale de pile d'exécution utilisée et du nombre de cibles de branchement dans le code, le procédé de
vérification, objet de la présente invention, n'a besoin que du type de la pile d'exécution lors de l'instruction en cours de vérification et il ne conserve pas en mémoire le type de cette pile à d'autres points du code. En conséquence, le procédé objet de l'invention se contente d'une quantité de mémoire vive proportionnelle à Tp mais indépendante de Nb, et par conséquent de la longueur du code du sous-programme ou de l'appliquette.
L'exigence selon le critère C4, selon lequel un registre donné doit être utilisé avec un seul et même type dans tout le code d'un sous-programme, garantit que le code précité n'utilise pas un registre de manière incohérente, par exemple en y écrivant un entier short à un point du programme et en le relisant comme une référence d'objet à un autre point du programme.
Dans les processus de vérification décrits dans l'art antérieur, en particulier dans la spécification Java intitulée "The Java Virtual Machine Specification" éditée par Tim LINDHOLM et Frank YELLIN, déjà citée, pour garantir la cohérence des utilisations précitées à travers les instructions de branchement, il est nécessaire de conserver en mémoire vive une copie du tableau des types de registres à chaque cible de branchement. Cette opération nécessite une quantité de mémoire vive proportionnelle à TrxNb où Tr désigne le nombre de registres utilisés par le sous-programme et Nb le nombre de cibles de branchement dans le code de ce sousprogramme .
Au contraire, le processus de vérification objet de la présente invention, opère sur un tableau global de types de registres en l'absence de conservation en mémoire
vive de copie à différents points du code. En conséquence, la mémoire vive nécessaire pour réaliser le processus de vérification est proportionnelle à Tr mais indépendante de Nb et donc de la longueur du code du sous-programme considéré.
La contrainte selon laquelle un registre donné est utilisé avec le même type en tous points, c'est-à-dire en toute instruction du code considéré, simplifie sensiblement et de manière significative la vérification des sous-programmes. Au contraire, dans les processus de vérification de l' art antérieur, en l'absence d'une telle contrainte, le processus de vérification doit établir que les sous-programmes respectent une discipline de pile stricte et doit vérifier le corps des sous-programmes de manière polymorphe en ce qui concerne le type de certains registres.
En conclusion, le processus de vérification objet de la présente invention vis-à-vis des techniques de l'art antérieur permet, d'une part, de réduire la taille du code du programme permettant de conduire le procédé de vérification, et, d'autre part, de réduire la consommation de mémoire vive lors des opérations de vérification, le degré de complexité étant de la forme O(TP+Pr) dans le cas du processus de vérification objet de la présente invention, au lieu de (0 (Tp+Tr) xNb) pour ce qui concerne les processus de vérification de l'art antérieur, en offrant toutefois les mêmes garanties vis-à-vis de la sûreté de l'exécution du code vérifié.
Enfin, le processus de transformation d'un code classique d'origine en un code normalisé est réalisé par transformation localisée du code en l'absence de
transmission d'informations supplémentaires à l'organe vérificateur, c'est-à-dire à la carte à microprocesseur ou au système informatique embarqué.
En ce qui concerne le procédé de réallocation des registres tel que décrit en figures 4b et 5b, ce procédé se distingue des procédés connus de l'art antérieur décrits notamment par le brevet US 4,571,678 et par le brevet US 5,249,295, par le fait : - que la réallocation de registre assure qu'un même registre ne peut être attribué à deux intervalles possédant des types principaux différents, ce qui garantit ainsi qu'un registre donné est utilisé avec le même type dans tout le code ; et - que les algorithmes d'allocations de registres existants et décrits dans les documents précités supposent un nombre fixe de registres et tentent de minimiser les transferts désignés par "spills" en langage anglo-saxon, entre registres et pile, alors que la réallocation des registres conformément à l'objet de la présente invention opère dans un cadre où le nombre total de registres est variable, en conséquence de quoi il n'y a pas lieu d'effectuer des transferts entre registres et piles alors qu'un processus de minimisation du nombre total de registres est mis en #uvre.
ANNEXE S TABLEAU Tl Code de la méthode en cours de vérification aload 0 aload 1 sconst 3 -"Pointeur sur l'instruction saload en cours de vérification putfield C.f return I reg2 -- - - -- -- -- j Pointeur Pointeur reg2 short reg2 --- ---- short pile de tvpes regl short[] short C3 PJ types regO C ~~~C~~~ Tableau de types de registres Pile de types
TABLEAU T2 PSEUDO-CODE DU MODULE VERIFICATEUR Variables globales utilisées : Tr nombre de registres déclaré par la méthode courante Tp taille maximale de pile déclarée par la méthode courante tr[Tr] tableau de types de registres (402 dans la figure 4) tp[Tp] type de pile (403 dans la figure 4) pp pointeur de pile (404 dans la figure 4) chg drapeau indiquant si tr a changé Initialiser pp # 0 Initialiser tp[O] ... tp[n - 1] à partir des types des n arguments de la méthode Initialiser tp[n] ... tp[Tr - 1] à # Initialiser chg à vrai Tant que chg est vrai: Remettre chg à faux Se positionner sur la première instruction de la méthode Tant que la fin de la méthode n'est pas atteinte: Si l'instruction courante est la cible d'une instruction de branchement: Si pp = 0, échec de la vérification Si l'instruction courante est la cible d'un appel de sous-routine: Si l'instruction précédente continue en séquence, échec Prendre tp[0]# retaddr et pp ± 1 Si l'instruction courante est un gestionnaire d'exceptions de classe C: Si l'instruction précédente continue en séquence, échec Fairetp[O] Si l'instruction courante est une cible de sortes différentes: Échec de la vérification Déterminer les types al,...,an des arguments de l'instruction Si pp Pour i = 1,...,n: Si tp[pp-n-i-1] n'est pas sous-type de a; , échec Faire pp r- pp - n Déterminer les types r1,...,rm des résultats de l'instruction Si pp+m#Tp, échec (débordement de pile) Pouri = 1,...,m, faire tp[pp+i-1] # ri Faire pp # pp # m Si l'instruction courante est une écriture dans un registre r: Déterminer le type t de la valeur écrite dans le registre Faire tr[r] # borne inférieure(t, tr[r]) Si tr[r] a changé, faire chg # vrai Si l'instruction courante est un branchement: Sipp # 0, échecde la vérification Avancer à la prochaine instruction Renvoyer un code de succès de la vérification
TABLEAU T3 static short[] meth(short [] tableau) short[] résultat = null; if (tableau.length ≥ 2) résultat = tableau; return tableau; } TABLEAU T4 Première itération sur le code de la méthode: Code de la méthode Tableau des types des registres Type de la pile 0 : n aconst null 1 |rO: short [] jri: ! aconst~null 1 .........1 short ri:.l null 1 : aoTel 1 1 rO short[] ! rl: 1 null astore 1 '#####' 2: aload 0 r0. short ri null j 1 #####-###-# 'fr0 short G rinull! ! short [] 3 : arraylength .........1 rO: short [] ri: null ! short 4 : sconst 2 shorts null short J~~~~~ : if~scmplt 9 -------r0: short ri: null 1 1 short short scmpit -# ' #####'##### aload 0 ')r0 short: [] rinn! ! aload 0 ' 8 : o astore 1 - -r0: short [] ! ri: # null ' I short ==-> [] 9 : aload 1 7 -tr0 ~ short tri: short in' 9 : aload 1 --)r0 short ri: short short 0 ! 10-: areturn --, short (J 1 ri: short short 10 : areturn ########'########' #####' Seconde itération sur le code de la méthode: 0 : I aconst null -|rO: '# short [J! ri shon[) 1 aconst null r0: short rl: short .1 rQ: short 1 ri: short () 1 null 1:1 astore 1 .)r0 short Q) ri sho "i null ..1 rO: short 1 ri: short aload 0 .fr0 short Url short j~~~~~~ 3 : arraylength r0: short ri: short Q ! ! short [] arraylength lllIIZZIZirriZIZZZZZZZr arraylength short 1 ri: short [] ) short 1 4: sconst 2 r0: short ] rl: short ] short #~~~~~ 5 : if~scmplt 9 -(r0: short [) 1 ri: short short short 7 aload 0 r0: sho U|rl:iho7iI I 8 : astore 1 -jr0 short 1 ri: short (J short [] 9 : aload 1 7 'IrQ: short rl: short []) 10 : areturn -(r0: short [] 1 ri: short [] short ]
TABLEAU T5 (a) Violation des contraintes de types sur les arguments d'une instruction: a : aload 0 ..1 Object 1 aload ##! r0 Object | I 1 : sconst 1 " rO: abject 1 abject sconst # # | rO: Obiect J t=r=d I Obiect I 2 : sadd --- rO: abject Object short 3 : areturn Erreur: le type de la pile ne correspond pas à ce qu'attend l'instruction (short, short) (b) Utilisation incohérente d'un registre: a : sload 0 -')rO: short! sload ###! rO: short ############--rO: short short 1 : ifeq 6 ###{ r0: short short 4 : aconsCnull V" r0: short ~~~~~ 5 : astore 0 - pro: short null astore -IZZm- ##### 6: Z-0 /...j-0: aload rot ~~~~~.
....... r0: T Iii T areturn s Erreur: le type de la pile ne correspond pas à ce qu'attend l'instruction (Object) (c) Branchements introduisant des incohérences au niveau de la pile: 0 : sload 0 -"" r0: short! ! 1 : ifeq $ short short 1 : iieq8 ## 1 rO: short short 4 : sconst 1 - r0: short sconst -rimr# ~~~~~ ############r0: short short 5 : goto 9 ' rO: short short 9 : areturn #*# / > Erreur: pile non vide à un point de branchement areturn -<# (d) Débordement de pile à l'intérieur d'une boucle: : sload 0 r0: short 0:1 sloadO -<- r : Sh rt ' ' ############short short 1 : ifeq 11 # J\ ' r : short 1 short : sconst 1 r0: short sconst puinniizir: ############r0: short short 0 sine 0 -1 irzizzrzzr: rn=zr : goto 0 r0: short short goto 0 T/ / I rO: short I short return r** , , 11 : return Erreur: pile non vide à un point de branchement
connus de l'homme du métier. Ces deux procédés font intervenir la polymérisation de l'éthylène par voie radicalaire sous haute pression, généralement comprise entre 100 et 350 MPa et à des températures supérieures à la température de fusion du polyéthylène en formation. Le procédé tubulaire fait intervenir la polymérisation dans un réacteur tubulaire. Un réacteur tubulaire comprend des cylindres dont le diamètre interne est généralement compris entre 1 et 10 cm et dont la longueur va généralement de 0,1 à 3 km. Dans un réacteur tubulaire, le milieu réactionnel est animé d'une grande vitesse linéaire, généralement supérieure à 2 mètres par seconde et des temps de réaction courts, pouvant par exemple être compris entre 0,1 et 5 min.
La pression dans le réacteur tubulaire peut par exemple être comprise entre 200 et 350 MPa, de préférence entre 210 et 280 MPa, par exemple entre 230 et 250 MPa. La température dans le réacteur tubulaire peut aller de 120 à 350 C et de préférence de 150 à 300 C.
Le procédé autoclave fait intervenir la polymérisation dans un autoclave dont le rapport longueur/ diamètre va généralement de 1 à 25 dans le cas d'un réacteur à zone unique. Dans le cas d'un réacteur à zones multiples, le rapport longueur de chaque zone / diamètre va généralement de 0,5 à 6, étant entendu que le milieu réactionnel s'écoule dans le sens de la longueur.
La pression dans le réacteur autoclave peut par exemple être comprise entre 100 et 250 MPa, de préférence entre 120 et 180 MPa, par exemple entre 140 à 170 MPa. La température dans le réacteur autoclave peut aller de 180 à 300 C de préférence de 240 à 290 C.