FR 2788357 A1 20000713 FR 9916599 A 19991228 MAINTENANCE D'UN MODELE D'UN SYSTEME La présente invention concerne la spécification et le développement de systèmes et de processeurs et en particulier la maintenance de données définissant un modèle de système. Les processus de conception classiques de processeurs et de systèmes impliquent la production d'une spécification architecturale sur laquelle se basent toute la conception et tout le développement. Cette spécification architecturale est typiquement, ou bien une spécification écrite, ou bien un modèle "d'or" exécutable écrit dans un certain langage de programmation. Le problème principal avec cette approche est que, quand on traite un tel système complexe, il est extrêmement improbable que la spécification soit bonne dès la première fois. Inévitablement, pendant une certaine durée du projet, des changements seront requis tandis que l'on reçoit des réactions entre autres des services commerciaux, des clients, des concepteurs de matériel et des développeurs de logiciels. Ceci nécessite des changements dans la spécification qui, une fois qu'ils sont acceptés, doivent être propagés vers tous les autres groupes se basant sur cette spécification, par exemple : la modélisation, la micro-architecture, la vérification, la chaîne d'outils, le système d'exploitation, les applications et la documentation. Ce processus de mise à jour surviendra de nombreuses fois dans la durée de vie d'un projet et est habituellement réalisé manuellement par chaque groupe, approche qui est lente, sujette à erreur et qui prend beaucoup de temps de travail. Un objet de l'invention est de réduire le temps, le coût et les erreurs associés avec la répétition des spécifications architecturales d'un dispositif. Selon un aspect de la présente invention, il est prévu un procédé d'actionnement d'ordinateur pour produire un ensemble de données électroniques définissant un modèle de système à partir d'une base de données architecturale qui a une configuration propre à maintenir dans un milieu d'enregistrement électronique des paramètres architecturaux, dans lequel chaque paramètre architectural est défini par un champ de clé primaire et un ensemble de champs contenant des données subsidiaires liées à la clé primaire, le procédé comprenant les étapes consistant à lire la clé primaire pour chaque paramètre architectural ; produire dans un milieu de mémorisation électronique une entrée de définition structurée du paramètre architectural sous un format lisible électroniquement, l'entrée de définition structurée étant associée à un champ d'identification définissant le paramètre ; et charger la clé primaire dans le champ d'identification et les données subsidiaires dans le fichier de définition structuré ; et dans lequel l'entrée de définition structurée prend la forme d'une définition de programmation du paramètre architectural dans un langage de modélisation. Selon un autre aspect de la présente invention, il est prévu un procédé de conception d'un processeur comprenant les étapes consistant à définir une spécification de processeur et produire à partir de la spécification de processeur des paramètres architecturaux mettant en oeuvre la spécification ; charger les paramètres architecturaux dans un milieu de stockage électronique pour produire une base de données architecturale qui est configurée pour stocker dans un milieu de mémorisation électronique des paramètres architecturaux, chaque paramètre architectural étant défini par un champ de clé primaire et un ensemble de champs stockant des données subsidiaires concernant la clé primaire ; créer dans un milieu lisible électroniquement un texte dans un format lisible par l'homme définissant les paramètres architecturaux dans un format de table structurée dans lequel un titre de table stocke une clé primaire pour chaque paramètre architectural ; modifier la spécification du processeur et réaliser manuellement une modification subséquente des paramètres architecturaux dans le texte ;et utiliser un outil de traduction sous la forme d'un programme exécuté par un ordinateur pour transférer automatiquement la modification dans la base de données en localisant toute table nouvelle ou modifiée dans le format de table et en chargeant le titre de table dans le champ de clé primaire et d'autres données de la table dans l'ensemble de champs de données subsidiaires de façon prédéterminée. Selon un autre aspect de l'invention, il est prévu un procédé de conception d'un processeur comprenant les étapes consistant à définir une spécification de processeur et produire à partir de la spécification de processeur des paramètres architecturaux mettant en oeuvre la spécification ; charger les paramètres architecturaux dans un milieu de stockage électronique pour produire une base de données architecturale qui est configurée pour stocker des paramètres architecturaux, chaque paramètre architectural étant défini par un champ de clé primaire et un ensemble de champs stockant des données subsidiaires concernant la clé primaire ; créer dans un milieu lisible électroniquement un texte dans un format lisible par l'homme définissant les paramètres architecturaux dans un format de table structurée dans lequel un titre de table stocke une clé primaire pour chaque paramètre architectural ; modifier la spécification du processeur et réaliser manuellement des modifications subséquentes des paramètres architecturaux dans la base de données architecturale ; et utiliser un outil de traduction sous la forme d'un programme exécuté par un ordinateur pour transférer automatiquement les modifications dans le texte à partir de la base de données en chargeant le contenu du champ de clé primaire et des champs de données subsidiaires selon le format de table structurée prédéterminé. Ainsi, les entrées de définition structurelle peuvent être des tables utilisées pour produire un test lisible ou des définitions de programmation pour produire des vues de modélisation. Le fait d'automatiser la distribution des données architecturales réduit considérablement l'impact des changements de la spécification sur les délais de réalisation d'un projet. Par exemple, en utilisant des vues appropriées, il est plus simple de maintenir la chaîne d'outils (compilateur, assembleur, créateur de lien et simulateur) en phase les uns avec les autres et avec la spécification. Comme il y a une réduction de la quantité de données architecturales reproduites manuellement produite dans différents groupes, les incohérences sont beaucoup moins susceptibles d'apparaître. La qualité de la spécification écrite doit s'améliorer pour de nombreuses raisons. Les outils de traduction peuvent être prévus pour effectuer des "vérifications sanitaires" sur les données architecturales circulant à partir de la spécification écrite ou vers celle-ci, réduisant ainsi les erreurs. La cohérence est améliorée tandis que l'automatisation assure que des types d'information similaires, par exemple des descriptions de registres, sont présentées de la même façon. La clarté peut être améliorée du fait qu'on est libre de présenter les mêmes informations de diverses façons sans qu'il soit possible que des incohérences surviennent. Par exemple, en donnant une information de codes opérationnels (opcode) en tant que partie d'une description d'instruction ainsi que dans une table de résumé d'opcode. Pour mieux comprendre la présente invention et présenter comment elle peut être mise en oeuvre, on se référa à titre d'exemple aux dessins joints parmi lesquels : la figure 1 est une vue schématique illustrant le concept sous-jacent de la présente invention ; la figure 2 est un schéma sous forme de blocs d'un système informatique incluant une base de données architecturale ; la figure 3 est un schéma d'une entrée de base de données dans la base de données architecturale ; la figure 4 est un organigramme illustrant la façon dont du texte dans un manuel d'architecture est produit à partir de la base de données architecturale ; la figure 5 est un exemple d'une entrée de texte dans le manuel d'architecture pour une instruction ; la figure 6 est un organigramme d'un processus de génération de texte ; la figure 7 est un organigramme montrant comment la base de données architecturale est produite à partir du texte dans le manuel d'architecture ; et la figure 8 illustre la génération de vues de modélisation. La figure 1 illustre schématiquement l'organigramme d'un processus de conception d'un système de circuit intégré et en particulier d'un processeur. Une spécification pour le processeur est établie et est définie comme un ensemble d'exigences fonctionnelles et d'exigences de performances. Ces exigences fonctionnelles et ces exigences de performances sont utilisées pour produire un ensemble de paramètres architecturaux qui seront utilisés pour concevoir le processeur. Les paramètres architecturaux sont conservés sous deux formats séparés. Le premier format est du texte sous forme lisible par l'homme qui est appelé ici la spécification écrite ou le manuel d'architecture AM. La spécification écrite peut être fournie sous forme imprimée mais est également généralement fournie sous forme électronique sur un milieu lisible électroniquement tel qu'un disque ou une mémoire. Ainsi, la référence AM en figure 1 désigne une mémoire qui stocke la spécification écrite qui peut être affichée ou imprimée dans un format lisible pour l'homme. L'autre mémoire centralisée est une base de données architecturale AD qui est également fournie sous forme électronique sur un disque ou sur une mémoire du système. Dans la base de données architecturale, les informations architecturales sont stockées sous forme canonique comme on l'indiquera à titre d'exemple ci-après. Les informations architecturales stockées dans la base de données architecturale AD peuvent ensuite être utilisées pour produire plusieurs vues différentes pour aider au processus de conception. Ainsi, par exemple une vue de modèle exécutable EMV dans un langage de modélisation, tel que le langage C, une vue de micro-architecture MV et une vue de vérification VV peuvent être produites. D'autres vues sont possibles. La génération de ces vues peut être automatisée dans la mesure où elles se basent sur des informations architecturales stockées dans la base de données architecturale AD comme cela est indiqué à titre d'exemple ci-après. Le manuel d'architecture AM et la base de données architecturale AD sont "liés" au sens où l'information qu'ils contiennent peut être maintenue compatible de façon automatisée. Selon le premier mode de réalisation, qui est préféré, la base de données architecturale AD est la source essentielle d'informations architecturales et est établie selon les paramètres architecturaux définis quand la spécification du processeur est produite. Le texte du manuel d'architecture AM peut être produit automatiquement à partir de la base de données architecturale en utilisant un outil de traduction TT1. De même, toute modification effectuée sur les paramètres architecturaux pendant le processus de conception et utilisée pour mettre à jour la base de données architecturale, mettra automatiquement à jour le manuel d'architecture AM par l'intermédiaire de l'outil de traduction TT1. Selon une variante de réalisation, le manuel d'architecture AM peut former la source essentielle d'informations pour les paramètres architecturaux, et être soumis aux modifications reflétant des changements de spécifications du processeur au cours du processus de conception. Ces modifications peuvent alors être apportées dans la base de données architecturale AD en utilisant un second outil de traduction TT2. On notera que le manuel d'architecture peut comprendre des données et des descriptions de la spécification du processeur qui ne sont pas incorporées dans base de données architecturale. La base de données architecturale stockera autant d'aspects de l'architecture que l'on peut en exprimer sous une forme formelle raisonnable. La génération des diverses vues, telles que représentées en figure 1, peut être réalisée en utilisant divers outils de génération GT1, GT2, GT3 etc. pour présenter des informations architecturales stockées dans la base de données architecturale sous une forme convenable pour cette vue particulière. Par exemple, la vue de micro-architecture MV destinée à un microarchitecte peut comprendre des détails des paramètres architecturaux sous forme d'un fichier VHDL d'en-tête. En comparaison, un compilateur utilisant une vue de modèle exécutable EMV peut s'attendre à une structure spécifique (two-specific) en langage C (.c) . Les paramètres architecturaux stockés dans la base de données architecturale peuvent appartenir à plusieurs classes différentes. Par exemple, ces classes peuvent comprendre : des instructions des codes opérationnels (opcodes) des registres de système des registres de commande. Toutes ces classes contiennent des éléments qui peuvent s'exprimer d'une façon raisonnablement systématique. Dans l'exemple ci-après, la structure d'une base de données d'un ensemble d'instruction est représentée. La figure 2 est un schéma sous forme de blocs d'un système d'ordinateur incluant une base de données architecturale AD sous forme d'une mémoire MEM stockant des entrées de base de données DE1, DE2, DE3 etc. On notera que la figure 2 est très schématique et qu'en pratique un grand nombre des entrées de données DE sera stocké dans la base de données architecturale et qu'elles peuvent être stockées sous tout format organisé. Dans le présent exemple, chaque entrée de données prend la forme d'un champ de clé primaire PKF et d'un ensemble de données subsidiaires SDF. Pour un ensemble d'instructions, le champ de clé primaire est ouvert par le signe : + =. Pour un ensemble d'instructions, le champ de clé primaire stocke la mnémonique d'instructions. Chaque champ subsidiaire est alors ouvert par le signe : +. La figure 2 représente également un dispositif d'entrée 2 couplé à un contrôleur 4 qui a accès à la mémoire MEM pour accéder à la base de données architecturale AD par un programme convenable P1. Ce programme peut par exemple être itcl qui est une extension orientée objet du langage d'écriture tcl et convient pour accéder à une base de données de ce type. La figure 3 représente plus en détail les champs de la base de données pour une entrée de base de données d'instructions. Le champ de clé primaire stocke la mnémonique d'instructions. Le premier champ de données subsidiaire SDF1 stocke le nom de l'instruction. Les deuxième, troisième et quatrième champs de données subsidiaires SDF2, SDF3, SDF4 sont associés à chaque opérande et sont respectivement appelés opl, op2 et op3. Ils contiennent pour chaque opérande des attributs tels que le caractère signé (s, us), la dimension, le type (registre, constant, quelconque) et le sens d'utilisation (src, dst). Le champ suivant SDF5 est appelé args et est utilisé pour donner des noms significatifs à tout opérande utilisé par l'instruction. Les trois champs suivants SDF6, SDF7 et SDF8 appelés pretext, traps (interruptions) et posttext prennent le comportement fonctionnel de l'instruction avant et après que toute vérification d'interruption soit réalisée. Des exemples particuliers de l'entrée de base de données pour des instructions add8s, leapngz sont donnés dans les annexes Ia, Ib. L'annexe II illustre un extrait du programme P1 en itcl pour accéder à la base de données architecturale de ce format. La sortie de cet accès est donnée dans l'annexe 3. La figure 4 est un organigramme illustrant l'utilisation de la base de données architecturale AD pour établir des entrées dans le manuel d'architecture AM. Dans cet exemple particulier, le format du manuel d'architecture est le format Framemaker, appelé .fm5. Il est converti en .MIF par un outil de conversion connu. MIF est une représentation texturée très structurée des contenus d'un document Framemaker et est connu en luimême. En particulier, le format en MIF est une structure arborescente dans laquelle des tables peuvent être représentées, chaque table étant identifiée par un titre de table. Un programme P2 exécutable sur un système d'ordinateur crée l'entrée du manuel d'architecture en évaluant les commandes données dans des champs de données subsidiaires choisis. Par exemple, dans le cadre de l'exemple de la figure 3, les commandes données dans les champs pretext, traps et posttext SDF6, SDF7 et SDF8 sont évaluées dans un environnement de procédure de génération de MIF. Par exemple, la séquence MIF produite pour l'instruction pretext est donnée en annexe IV. Le processus P2 insère également la représentation MIF de l'instruction à l'emplacement correct dans le manuel d'architecture AM en prévoyant les outils de comparaison et de substitution de motif pour les structures MIF. Ceci est effectué en identifiant de nouvelles tables dans la structure MIF qui requièrent l'achèvement de la base de données architecturale ou des tables qui ont été modifiées. Pour des tables nouvelles ou modifiées, une nouvelle table basée sur l'information dans la base de données architecturale courante AD est insérée dans le texte du manuel d'architecture. A titre d'exemple, la figure 5 représente l'entrée complète pour l'instruction add8s donnée à titre d'exemple en annexe 1. La figure 5 représente également les champs de données de l'entrée de base de données qui a été transférée dans l'entrée de table. Il est clair à partir de la figure 5 que, pour créer l'entrée de table, un traitement supplémentaire doit être effectué sur les champs opcode SDF2,3 et 4 pour produire à partir des attributs contenus dans ces champs les informations nécessaires pour les entrées de table concernées. La figure 6 est un organigramme relatif à la façon dont le programme P2 fonctionne pour mettre à jour le manuel d'architecture AM à partir de la base de données architecturale AD. On notera ici que la base de données architecturale comprend plusieurs classes de paramètres qui peuvent elles-mêmes constituer des bases de données architecturales individuelles. Par exemple, la base de données architecturale d'instructions peut constituer une entité séparée de la base de données architecturale d'opcode. A l'étape SI, les bases de données architecturales des classes concernées des paramètres architecturaux sont chargées. A l'étape S2, le fichier MIF est chargé en utilisant la commande de manipulation MIF "parsefile". Cette commande lit les contenus du fichier MIF et enregistre tout son contenu dans un arbre de syntaxe abstrait (AST) constitué à partir de structures en langage C. A l'étape S3, une procédure est définie qui accepte comme argument une représentation d'arbre ramifié MIF des entrées structurelles mémorisées dans les bases de données architecturales. Le corps de cette procédure extrait à partir de l'arbre ramifié le nom de l' instruction, puis utilise ce nom pour interroger les bases de données d'opcodes d'instruction (voir étapes S3a à S3c). A partir de ces bases de données, il obtient toutes les informations qui doivent être présentées dans la description de l'instruction puis convertit ces données brutes en MIF en insérant toute la structure requise et les informations de format (voir étape S3d). Enfin, la procédure supprime la description ancienne d'instruction de l'arbre de syntaxe abstrait et la remplace par le MIF nouvellement produit. A l'étape S4 de la procédure principale, un "filtre" de commande de manipulation MIF est alors obtenu et fournit comme arguments un motif qui s'adaptera à la structure de table utilisée pour décrire une instruction et le nom de la procédure définie à l'étape S3. La commande de filtre parcourt l'AST MIF en recherchant une correspondance entre l'arbre et le motif spécifié. Si une correspondance est trouvée, la procédure dont le nom a été passé comme argument à la commande est invoquée. On fournit à la procédure l'identité du sous-arbre correspondant plus les identités de tout sous-motif qu'elle contient. En outre, d'autres commandes de "filtre" peuvent être fournies pour mettre à jour les index, les résumés d'opcode, les résumés d'instruction, etc. A l'étape S5, la commande "writefile" amène l'AST modifié à être réécrit dans un fichier. Alors, la procédure est achevée. La figure 7 est un organigramme qui montre consent l'information est produite pour la base de données architecturale AD à partir du manuel d'architecture. Comme cela a déjà été mentionné, le manuel d'architecture est à titre d'exemple écrit en Framemaker, appelé .fm5 en figure 5. Ceci est converti en MIF. Alors, un programme P3 exécutable sur un ordinateur lit le texte en format MIF du manuel d'architecture et extrait les tables de ce texte pour former une base de données tabulaire intérimaire .tab. Dans cette base de données, les tables sont mémorisées comme entrées de table TE, avec le format d'entrées de données DE dans la base de données architecturale. Ainsi, un champ de clé primaire appelé += stocke le numéro de table et est associé à une pluralité de champs subsidiaires qui mémorisent par exemple le titre et les en-têtes de cette table. Un autre processus P4 extrait l'information de la base de données de table .tab et produit les paramètres d'architecture à partir de la base de données architecturale AD du format décrit ci-dessus. La figure 7 montre également à titre d'exemple l'utilisation d'un programme P5 pour produire à partir des paramètres d'architecture, un fichier d'en-tête .h et un fichier de mise en oeuvre .c. Ce processus peut être utilisé pour toutes les classes de paramètres architecturaux dans la base de données architecturale. Il est décrit ci-après en relation avec des registres de commande de système qui sont une classe de paramètres architecturaux maintenus dans la base de données architecturale. Tous les registres mappés de mémoire (système) dans le processeur sont spécifiés dans le manuel d'architecture AM en utilisant une forme tabulaire standard représentée par exemple au tableau 1. La représentation de document de trame du manuel d'architecture est convertie en MIF, par exemple en utilisant un programme appelé FMBATCH. Alors, le processus P3 convertit le fichier MIF en une base de données de table brute .tab au format de la base de données. Un identificateur de table est utilisé comme clé primaire pour chaque entrée dans la base de données de table, l'identificateur étant produit en utilisant le type de table plus un numéro spécifique à trois chiffres. L'identificateur de table est associé à trois champs subsidiaires appelés : titre en-têtes texte. Le programme P4 convertit alors la base de données de table en entrées de données dans la base de données architecturale AD. Il réalise également une "vérification sanitaire" de chaque table qui décrit un registre, en assurant par exemple que la plage de bits associée à un champ particulier est cohérente avec sa dimension. Dans le format de base de données décrit cidessus, le champ de clé primaire stocke le nom de registre suivi de champs appelés champ, dimension et adresse. Les champs sont décrits une fois par ligne en utilisant cinq paramètres : nom, bit de départ, largeur, attribut d'accès (RW/RO) et valeur initiale. Le champ de dimension est la largeur du registre en octets. L'adresse est spécifiée par rapport à l'adresse de base du processeur. Le format de la table dans la base de données de table .tab est illustré au tableau 2. L'entrée de données équivalente dans la base de données architecturale est représentée au tableau 3. A titre d'exemple, on va maintenant décrire la production d'une vue de modèle exécutable EMV par le processus P5. La technique utilisée est similaire à celle décrite ci-dessus pour produire le manuel d'architecture. Toutefois, au lieu que les champs pretext, posttext et traps, SDF6, SDF7 et SDF8 soient évalués dans un environnement de MIF produisant des commandes, l'environnement est un langage de modélisation tel que C++ qui produit une représentation propre à être utilisée dans un modèle exécutable. On se référé maintenant à la figure 8. Le processus P5 va être considéré de façon générale en deux parties telles que représentées schématiquement par la ligne en pointillés traversant l'ovale marqué P5. Selon la première partie, une liste de définitions DL et une liste de méthodes d'exécution EML sont produites comme instructions dans la base de données architecturale AD. Ceci est effectué de la façon suivante : i) lire la base de données d'instructions ; ii) obtenir une instruction à partir de la base de données ; iii) produire une définition de classe C pour l'insertion en incorporant des détails pour l'usage d'opérandes (les attri- buts src et dst qui sont maintenus dans les champs d'opé- randes SDF2, SDF3 et SDF4) ; iv) rattacher une nouvelle définition à la liste de définitions DL ; v) créer un procédé d'exécution C++ pour l'instruction en uti- lisant les informations d'usage d'opérandes et également les champs pretext, traps et posttext SDF6, SDF7 et SDF8 pour produire un code décrivant le comportement de l'instruc- tion ; vi) rattacher le nouveau procédé d'exécution à la liste de procédés d'exécution ; vii) répéter à partir de l'étape ii) jusqu'à ce que toutes les instructions soient traitées. Les définitions de classe C++ produites pour les instructions add8s et leapngz indiquées à titre d'exemple dans les annexes Ia et Ib sont illustrées aux annexes Va et Vb. La mise en oeuvre des procédés d'exécution est également donnée dans les annexes VIa et VIb. Une fois que la liste de définitions DL et la liste de procédés d'exécution EML ont été produites de cette façon, l'autre partie du processus P5 reçoit des gabarits pour un fichier d'en-tête et un fichier de mise en oeuvre. Pour produire un fichier d'en-tête .h, le repère de gabarit est remplacé par la liste de définitions. Pour produire un fichier de mise en oeuvre . c, le repère de gabarit est remplacé par une liste de procédés d'exécution. De cette façon, le fichier de mise en oeuvre .c et le fichier d'en-tête .h peuvent être reproduits. Dans les annexes V et VI, on se référera à une classe InstrState. Cette classe contient tout l'état associé à l'exécution d'une instruction, par exemple un réseau d'opérandes et un enregistrement de toute interruption provoquée par l'instruction. On se référera également à une classe d'entiers, qui contient des entiers à précision illimitée. Ceci peut être nécessaire car les résultats des expressions peuvent dépasser la dimension de l'opérande résultant et le dépassement peut devoir être vérifié en tant que partie de l'exécution de l'instruction. ANNEXE Ia +=add8s +name add 8-byte signed +opl dst, 8, s, register +op2 src, 8, s, register +op3 src, 8, s, any +args result, srcl, src2 +pretext result, srcl, src2 +pretext result [becomes] srcl + src2 +traps [exetrap OVERFLOW { result [lt] [power-2 63] [lor] [power 2 63] [lessequal] result }] +posttext ANNEXE Ib +=leapngz +name branch if not greater than zero +opl nul +op2 nul +op3 src, z, s, register +args condition +posttext [IF {condition [lessequal] 0} {[IPTR~] [becomes] [IPTR]} 1 +traps ANNEXE II package require Dbase Dbase iset iset read InstructionSet.db foreach m [iset entrylist] { puts "$m : : [iset entry name] } ANNEXE III add8s : : add 8-byte signed ANNEXE IV > # end of Font > # end of Font > # end of ParaLine ANNEXE Va class Instr~add8s : public Instr public: Instr~add8s() Instr("add8s" ,ArgUse(6),ArgUse(1)) {} void execute(InstrState &is ); } ANNEXE Vb class Instr~leapngz : public Instr public: Instr~leagngz () Instr("leapngz",ArgUse(1), ArgUse(0)) void execute(InstrState &istate); }; ANNEXE Via Instr~add8s :: execute(InstrState &is) { bool undef=! (is.op2[0] .is defined() && is.op3 [0],is~defined()); Integer result; Integer source 1 ( is . op2 [ 0 ] . as TI8 s ( ) ) ; Integer source2(is.op3[0].as~TI8s())' result = sourcel + source2; if (result is.opl [0) .undef(resuit.as~TI8us()); else is.opl[0] = result.as~TI8us() ; } ANNEXE VIb void Instr~leapngz::execute( InstrState &istate ) { bool undefined = ! (1 && istate.operands[0] () .get() .is~defined ()); Integer Ca1ditirn{istate.cperands [0] () .get () .as~Tr8s ( ) } ; if (condition ≤ 0) { istate . Izrime = istate.JPIRO;}; } TABLEAU 1 TDR/VCR 0x000000 Field Bits Size volatile? Synopsis Type perr~flags [0,7] 8 / R-port errer flags Varies HARD reset 0 merr~flags [8,15] 8 / TDR module errer flags Varies HARD reset 0 mod-vers [16,31] 16 - Module versicn RO HARD reset 0x0000 mod~id [32,47] 16 Module identity RO BARD reset 0x1005 bot~mb [48,55] 8 Bottom memory block RO HARD reset OxOA Top~mb [56,63] 8 Top memory block RO BARD reset OxOA TABLEAU 2.tab +=Table~001 +title TDR/VCR register description +headings TDR. VCR^^^^0x000000^ Field&Bits&Size&Volatile?&Syisis&Type +text perr~flags&[0,7]&8&3&P-port error flags&Varies &HARD reset&&0&& merr~flags&[8,15]^8^3^TDR module error flags&Varies ^HARD reset &&0&& mod~vers^[16,31]^16^ SMcdule versicn&RO &HARD reset &&0x0000&& mod~id^[32,47]^16^ Module identity&RO ^HARD reset&&0xl005&& bot~mb^[48,55] &8& &Bottan memory block&RO &HARD reset&&OxOA&& tcp~mb&[56,63]&B& &Ttp rrarory block&RO &HARD reset&&OxOA&& TABLEAU 3 AD +=TDR. VCR +fields err snt 1 1 RW 0 bad addr 2 1 RW 0 unsol~resp 3 1 RW 0 opc~err 8 1 RW 0 len err 9 1 RW 0 mod~vers 16 16 RO 0 ncd~id 32 16 RO 0x1005 bot~mb 48 8 RO 0xA top~mb 56 8 RO OxA +size 8 +address 0 REVENDICATIONS 1. Procédé de production automatique d'un ensemble de données de conception définissant un modèle de système à partir d'une base de données architecturale qui a une configuration propre à maintenir dans un milieu d'enregistrement électronique des paramètres architecturaux, dans lequel chaque paramètre architectural est défini par un champ de clé primaire et un ensemble de champs contenant des données subsidiaires liées à la clé primaire, le procédé comprenant les étapes suivantes : lire la clé primaire pour chaque paramètre architectural ; produire dans un milieu de mémorisation électronique une entrée de définition structurée du paramètre architectural sous un format lisible électroniquement, l'entrée de définition structurée étant associée à un champ d'identification définissant le paramètre ; et charger la clé primaire dans le champ d'identification et les données subsidiaires dans le fichier de définition structurée, et dans lequel l'entrée de définition structurée prend la forme d'une définition de programmation du paramètre architectural dans un langage de modélisation. 2. Procédé selon la revendication 1, comprenant en outre l'étape consistant à produire un fichier de définition pour les entrées de définition structurée du paramètre architectural. 3. Procédé selon la revendication 2, dans lequel le fichier de définition est une vue exécutable du modèle. 4. Procédé selon la revendication 2, dans lequel le fichier de définition est une vue de micro-architecture. 5. Procédé selon la revendication 2, dans lequel le fichier de définition est une vue de vérification. 6. Procédé selon l'une quelconque des revendications précédentes dans lequel, la base de données architecturale stocke une pluralité de classes différentes de paramètres architecturaux et dans lequel l'entrée de définition structurée diffère pour chaque classe. 7. Procédé selon la revendication 6, dans lequel l'une des classes consiste en des instructions. 8. Procédé selon la revendication 6, dans lequel l'une des classes consiste en des opérandes. 9. Procédé selon la revendication 6, dans lequel l'une des classes consiste en des registres systèmes. 10. Procédé selon la revendication 6, dans lequel l'une des classes consiste en des registres de commande. 11. Procédé de conception d'un processeur comprenant les étapes suivantes : définir une spécification de processeur et produire à partir de la spécification de processeur des paramètres architecturaux mettant en oeuvre la spécification ; charger les paramètres architecturaux dans un milieu de stockage électronique pour produire une base de données architecturale qui est configurée pour stocker dans un milieu de mémorisation électronique des paramètres architecturaux, chaque paramètre architectural étant défini par un champ de clé primaire et un ensemble de champs stockant des données subsidiaires concernant la clé primaire ; créer dans un milieu lisible électroniquement un texte dans un format lisible par l'homme définissant les paramètres architecturaux dans un format de table structurée dans lequel un titre de table stocke la clé primaire pour chaque paramètre architectural ; modifier la spécification du processeur et réaliser manuellement une modification subséquente des paramètres architecturaux dans le texte ; et utiliser un outil de traduction sous la forme d'un programme exécuté par un ordinateur pour transférer automatiquement la modification dans la base de données en localisant toute table nouvelle ou modifiée dans le format de table et en chargeant le titre de table dans le champ de clé primaire et d'autres données de la table dans l'ensemble de champs de données subsidiaires de façon prédéterminée. 12. Procédé de conception d'un processeur comprenant les étapes suivantes : définir une spécification de processeur et produire à partir de la spécification de processeur des paramètres architecturaux mettant en oeuvre la spécification ; charger les paramètres architecturaux dans un milieu de stockage électronique pour produire une base de données architecturale qui est configurée pour stocker des paramètres architecturaux, chaque paramètre architectural étant défini par un champ de clé primaire et un ensemble de champs stockant des données subsidiaires concernant la clé primaire ; créer dans un milieu lisible électroniquement un texte dans un format lisible par l'homme définissant les paramètres architecturaux dans un format de table structurée dans lequel un titre de table stocke une clé primaire pour chaque paramètre architectural ; modifier la spécification du processeur et réaliser manuellement des modifications subséquentes des paramètres architecturaux dans la base de données architecturale ; et utiliser un outil de traduction sous la forme d'un programme exécuté par un ordinateur pour transférer automatiquement les modifications dans le texte à partir de la base de données en chargeant le contenu du champ de clé primaire et des champs de données subsidiaires selon le format tabulaire prédéterminé.