Brevet FR2828295A1 — publié le 20030207

mémoire EPROM et d'une mémoire EEPROM. r 1 2828295 Domaine de l' invention La présente invention concerne le domaine de générer une image en mémoire morte (ROM). L'invention est particulièrement utile pour générer un fichier image pour programmer des mémoires ROM ou autres dispositifs de mémoire tels que des mémoires ROM programmables (PROM), des mémoires ROM programmables effaçables (EPROM) et des mémoires ROM reprogrammables effaçables électriquement (EEPROM) qui contiennent le micro- programme dans un système. Arrière-plan de l'invention Un microprogramme est un code qui opère pour un système informatique et qui est rarement changé. Certains microprogrammes opèrent au moment de la mise sous tension jusqu'au moment o un processeur appelle le processus d'amorçage. D'autres micro programmes contiennent un code d'opération en temps réel qui fait opérer différents périphériques ou poursuit d'une autre façon un traitement pour le système informatique. Un microprogramme peut par exemple tester la bonne santé d'un système informatique dans lequel il réside. Ce microprogramme réside souvent à l'intérieur d'une mémoire, telle qu'une ou plusieurs mémoires ROM, une mémoire ROM programmable (PROM), une mémoire ROM programmable effaçable (EPROM) et/ou une mémoire ROM programmable effaçable électriquement (EEPROM). La mémoire ROM contient de s fichi ers exécutables et de s données associées parfois désignés sous le nom d'images. Ces images sont écrites en mémoire ROM ou, sinon, mémorisées sous forme de processus de " construction ". Une image en mémoire ROM est un fichier ou autre code exécutable et/ou des données mémorisées en mémoire, telle qu'une mémoire ROM, une mémoire EPROM ou une mémoire EEPROM. L'image en mémoire ROM contient une ou plusieurs images de données qui sont compilées et lices pour créer image en mémoire ROM. Les images de données peuvent être une section d'un code exécutable, des donnces pour emploi par un programme compilé, un signal de sortie d'un programme compilé, une section de données ou 2 2828295 d'un code qui peut être transférée sur un dispositif programmable, une section d'un code ou de données pour emploi par un système ayant une configuration spécifique, ou un autre code ou d'autres données utilisables pour le fonctionnement des systèmes informatiques. Chaque image de données dans la construction a une adresse de début et une dimension initiale en mémoire. Toutefois, au cours de la vie du système informatique, la dimension d'une ou plusieurs images de données dans l'image en mémoire ROM peut augmenter. Ceci peut survenir par exemple si le code écrit sur 1'image de données augmente ou est autrement modifiée si des bogues sont réparés, si des caractéristiques additionnelles sont ajoutées au système ou si le microprogramme est modifié autrement. Dans des systèmes antérieurs, des images en mémoire ROM étaient construites manuellement par fixation d' une série d' adresses pour des images de données à placer dans l'image en mémoire ROM. Du fait que l' image de données peut augmenter de taille, des jeux étaient laissés entre les images de données pour prévoir leur expansion. Si la dimension de l'image de données augmentait trop fortement de façon qu'elle nécessite de l'espace déjà pris par une autre image de données, alors cette image de données expansée ainsi que d'autres images de données étaient déplacées manuellement pour compenser l'expansion de leur dimension. Ce mouvement manuel d'images de donnces prenait du temps et était sujet à erreur. En outre, dans l'art antérieur, une unique somme de contrôle ou un unique contrôle cyclique par redondance (CRC) existait pour la totalité de l'image en mémoire ROM. Par conséquent toutes les images de donnces se trouvant dans une mémoire ROM programmée avec l'image en mémoire ROM devaient être vérifiées de façon que la somme de contrôle ou le contrôle cyclique par redondance CRC puisse être calculé, même si une ou plusieurs images de données ou une portion de la mémoire ROM n'étaient pas utilisées dans l'exécution du microprogramme. Pour une mémoire ROM importante ceci ajoutait un temps significatif pour amorcer le système. 3 2828295 Par conséquent des nouveaux systèmes et de nouveaux procédés sont nocessaires pour réduire les problèmes associés avec la validation des images de données, I'image en mémoire ROM et une mémoire ROM programmée avec l'image en mémoire ROM, de façon à réduire le temps d'amorçage. En outre de nouveaux systèmes et de nouveaux procédés sont nécessaires pour écrire facilement des images de données sur une image en mémoire ROM et confirmer ensuite les dimensions et les adresses de ces images de données. En outre de nouveaux systèmes et de nouveaux procédés sont nécessaires pour fournir des validations, tels que des sommes de contrôle ou des contrôles cycliques par redondance CRC pour les images de données sélectionnées et les images en mémoire ROM. Résumé de l' invention Sous un premier aspect, la présente invention concerne un système pour générer une image en mémoire ROM comportant au moins une construction d'une image de donnces. Le système comporte un identificateur d'image configuré pour traiter un fichier d'entrée pour identifier au moins une image de données pour une construction d'image en mémoire ROM et pour générer un fichier d'objets comportant au moins un objet pour l'image de données. Le système comprend en outre un constructeur d' image de données configuré pour traiter l'image de données avec son fichier d'objets associé pour crécr la construction d'une image de données. Le système inclut également un constructeur d' image en mémoire ROM configuré pour générer une signature validant une construction d'une image de données pour la construction d'une image de données, pour écrire sur l 'image en mémoire ROM la construction de l'image de données et la signature de validation de la construction de l'image de données et pour générer pour l'image en mémoire ROM une signature validant l'image en mémoire ROM. Sous un autre aspect, la présente invention concerne un système pour générer une image en mémoire ROM comportant au moins une construction d'une image de données. Le système comporte au moins un identificateur d'image configuré pour traiter un fichier d'entrce pour générer un fichier d'objets et un fichier 4 2828295 d'objets temporaire, le fichier d'objets et le fichier d' objets temporaire représentant chacun des objets pour chaque image de données identifice dans le fichier d'entrée. Le système inclut en outre un constructeur d' image en mémoire ROM configuré pour comparer le fichier d'objets avec le fichier d'objets temporaire et, si ce sont les mêmes, pour générer une signature validant l'image de données pour chaque image de données. En outre le constructeur d' image en mémoire ROM est configuré pour écrire sur l'image en mémoire ROM chaque image de donnces et chaque signature validant chaque image de données et, ensuite, générer une signature distincte, validant l'image en mémoire ROM, pour l 'image de données. Sous un autre aspect encore, la présente invention concerne un système pour générer une image en mémoire ROM en utilisant des entrées provenant d'un fichier d'entrée. Le système comporte une mémoire configurée pour mémoriser une image en mémoire ROM, un générateur d' image en mémoire ROM et un processeur. Le générateur d'image en mémoire ROM est configuré pour identifier une pluralité d'images de données à placer dans l'image en mémoire ROM sur la base des entrées provenant du fichier d'entrée, pour générer une signature validant l'image de données pour chaque image de données avec chaque entrée associée et pour écrire à l'adresse de début de l'image en mémoire ROM chaque image de données et chaque signature validant l'image de donnces. Ensuite le générateur d'image en mémoire ROM peut générer pour l'image en mémoire ROM une signature validant l'image en mémoire ROM.Au moins zéro, ou davantage, adresses de début sont allouées dynamiquement par le générateur d'image en mémoire ROM. Le processeur est configuré pour traiter le générateur d'image en mémoire ROM et pour transmettre en mémoire, pour mémorisation en tant qu'image en mémoire ROM, les images de données avec les signatures validant l' image de données. Brève description des dessins 2828295 La figure I est un diagramme par blocs illustrant un système générant une image en mémoire ROM conformément à une forme de réalisation de la présente invention. La figure 2 est un ordinogramme illustrant la génération d'une image en mémoire ROM conformément à une forme de réalisation de la présente invention. La figure 3 est un ordinogramme illustrant la génération d'une image en mémoire ROM conformément à une autre forme de réalisation de la présente invention. La figure 4 est un ordinogramme illustrant un processus de paramétrage d' image de données conformément à une forme de réalisation de la présente invention. La figure 5 est un ordinogramme illustrant un processus de conflit d'adressage d'image conformément à une forme de réalisation de la présente invention. La figure 6 est un ordinogramme illustrant un processus de conflit d'adressage de début d'image de données conformément à une forme de réalisation de la présente invention. La figure 7 est un ordinogramme illustrant une opération d' écriture d' image de données conformément à une forme de réalisation de la présente invention. La figure 8 est un ordinogramme illustrant un processus de validation en mémoire ROM en accord avec une forme de réalisation de la présente invention. Description détaillée des formes de réalisation préférées Dans une première forme de réalisation, la présente invention propose des systèmes et des procédés pour construire une image en mémoire telle qu'une image en mémoire morte (ROM), dans laquelle se trouvent une ou plusieurs images de données, des adresses associées, des dimensions associées de multiplets de données et de s résultats de validation. C ette forme de réal isati on automatise la création d'une image en mémoire ROM et réduit le temps d'amorçage de l' image en mémoire ROM en réduisant le temps nécessaire pour valider chaque image de données se trouvant dans 1'image en mémoire ROM. 6 2828295 Une image en mémoire ROM est un fichier ou autre code exécutable et/ou des données mémorisées en mémoire, telle qu'une mémoire ROM, une mémoire EPROM ou une mémoire EEPROM. Une image en mémoire ROM peut être vue sous forme d'un fichier S binaire qui est programmé dans un dispositif de mémoire programmable tel qu'une mémoire permanente ou semi-permanente. Un système de programmation est un système pour transférer I'image en mémoire ROM dans une mémoire ROM, une mémoire EPROM, une mémoire EEPROM et/ou une autre mémoire. Les images de données sont compilées et liées pour créer l'image en mémoire ROM. Les images de données peuvent être chacune une section d'un code exécutable, des données pour emploi par un code exécutable, un programme compilé, une section de données ou de codes qui peut être transférée dans un dispositif programmable tel qu'un code de configuration d'un tableau de portes programmable sur le champ (FPGA). Une section de code ou de données pour emploi par un système ayant une configuration spécifique, ou un autre code ou d'autres données utilisables pour le fonctionnement d'un système informatique. Le terme " ROM " peut inclure ou être remplacé par une mémoire, telle qu'une ou plusieurs mémoires PROM, EPROM et/ou EEPROM Un utilisateur peut changer un fichier de configuration pour ajouter ou supprimer des images de données pour une image en mémoire ROM. Comme telle, l' invention peut être configurée pour ajouter un code à une image en mémoire ROM, pour enlever un code d'une image en mémoire ROM ou pour ne pas ajouter un code à une image en mémoire ROM, sur la base des demandes d'un utilisateur ou autres demandes identifiées dans un fichier de configuration. Des adresses de début d'images de données peuvent être désignces à 1'intérieur de l' image en mémoire ROM. Les adresses de début peuvent être fixées, ou bien la dimension d'une image de données peut être calculée et une adresse de début peut être générée dynamiquement pour cette image de données. Dans la forme de réalisation préférée, I' invention translate automatiquement une image de donnces dans une image en mémoire 7 2828295 ROM, là o elle est nécessaire, et génère automatiquement une nouvelle adresse de début pour l'image de données. Elle peut également écrire automatiquement l'image de données sur l'image en mémoire ROM. Une image de données peut être déplacée ou modifiée au fur et à mesure que 1' image de donnces grandit et par ailleurs l'image de données peut recevoir des ajouts, si nécessaire, par conséquent il n'est pas nécessaire d'avoir des jeux entre les images de données. Ceci se traduit par une économie d'espace en mémoire ROM et assure une meilleure efficacité de mémorisation, de récupération et d'exécution de 1'image en mémoire ROM. En outre il n'est pas nécessaire de calculer ou d'exécuter des sommes de contrôle ou autres signatures de validation pour un espace vide. L'invention peut être configurée pour ajouter des multiplets à une extrémité d'une image de données de façon que l'image de 1S données corresponde à un multiple pair d'une valeur spécifiée de multiplets. Par exemple un fichier de configuration peut spécifier que des images de données doivent se terminer sur une limite à quatre multiplets. Par conséquent un ou plusieurs multiplets seront ajoutés, si nécessaire, à une image de donnces de façon qu'elle se termine sur une limite à quatre multiplets et qu'elle soit ainsi d'une longueur égale à un multiple pair de quatre multiplets. Ceci procure certains avantages pour exé cuter comp lètement de s somme s de contrôle et d'autres algorithmes qui nécessitent une longueur de mot particulière. L'invention peut également créer un fichier d'objets. Le fichier d'objets est généralement une chaîne de texte contenant des données qui peuvent être utilisées au cours de la construction d'une image en mémoire ROM. Le fichier d'objets peut inclure une liste d'objets tels qu'une somme de contrôle, des images de données de la mémoire ROM et/ou d'autres données. Dans la forme de réalisation préférée, l' invention utilise des signatures de validation telles que des sommes de contrôle. La signature de validation est par exemple un calcul basé sur des donnces contenues dans une image, par exemple une somme de contrôle, un contrôle cyclique par redondance (CRC) ou un autre 8 2828295 processus de validation. Une signature de validation peut également être calculée sur la base à la fois des donnces contenues dans l'image et d'une clé d'identification telle que connue dans l'art des documents signés par voie numérique, telle qu'une clé privée pour emploi avec un algorithme de cryptage de clé publique. Dans certaines formes de réulisation, une portion de la signature de validation peut être masquée ou ignorée. Par exemple une signature de validation calculée peut être de 64 bits. Dans cet exemple, les 32 bits supérieurs de cette signature de 64 bits peuvent être masqués de sorte que ce sont les 32 bits inférieurs qui sont utilisés pour la validation. La figure 1 représente une forme de réalisation, prise à titre d'exemple, d'un système générateur d'image en mémoire ROM de la présente invention. Le système générateur d'image 102 de la figure 1 comporte une mémoire morte (ROM) 104, un processeur 106 et un générateur d'image en mémoire ROM 108. Le système générateur d'image 102 peut inclure un dispositif 110. La mémoire ROM 104 est par exemple un support numérique en mémoire, un ensemble de puces ou un autre dispositif de mémorisation non volatil. La mémoire ROM 104 peut être une mémoire programmable, effaçable, électriquement effaçable ou un autre type de mémoire ROM ou d'autres mémoires. Le processeur 106 est un processeur configuré pour traiter le générateur d'image en mémoire ROM 108. Le processeur 106 peut être configuré pour commander d'autres dispositifs internes ou externes associés au système générateur d'image 102. Par exemple le processeur 106 peut être configuré pour traiter un dispositif d'entrée/sortie ou un dispositif programmable. Le générateur d'image en mémoire ROM 108 est configuré pour identifier des images de données pour une construction d'image en mémoire ROM. L'image en mémoire ROM est alors construite sur la base des images de données. Le dispositif 110 est un dispositif interne ou externe associé au système générateur d'image 102. Le dispositif 110 peut étre par exemple un dispositif de lecture ou d'écriture sur support, tel 9 2828295 qu'une mémoire ROM sur disque compact (CD), une mémoire volatile, une mémoire non volatile, un dispositif programmable, un dispositif d'entrée, un dispositif de sortie ou un autre dispositif. La figure 2 représente une forme de réalisation, prise à titre d'exemple, d'un processus 108a de générateur d'image en mémoire ROM opérant avec un processus 202 de construction d' image de données. Le processus 108a de générateur d'image en mémoire ROM et le processus 202 de constructeur d'image de données peuvent utiliser un fichier d'entrée 204, des objets 206 pour construire une image et une signature de validation 208 pour chaque image de données. Un fichier d'entrée 204 est communiqué à un processus identificateur d'image à l'étape 210 pour identifier des images de données pour une construction. Les objets 206 pour construire I'image sont ajoutés et chaque image de données est construite par un processus constructeur de l'image de données à l'étape 202. À l'étape 212 une signature de validation 208 pour chaque image de données est ajoutée et une image en mémoire ROM 214 est construite par un processus constructeur de l' image de données. Chaque processus comporte un ou plusieurs modules de programme associés configurés pour exécuter le processus. C'est ainsi que le processus 108a générateur d'une image en mémoire ROM, le processus 202 constructeur d'une image de données, le processus 210 identificateur d'image et le processus 212 constructeur d'une image en mémoire ROM comportent un constructeur d' image en mémoire ROM associé, un constructeur d' image de données, un identificateur d'image et un constructeur d'image en mémoire ROM, respectivement. On se rendra compte de ce que plus qu'un seul module de programme peut être associé à chaque processus. Par exemple le processus 210 identificateur d' image peut avoir un premier identificateur d' image et un second identificateur d'image associés dans lesquels un ou plusieurs des processus identificateurs d'image sont exécutés. Une explication des formes de réalisation du fichier d'entrée 204, des objets pour construire 1'image 206, et de la signature de 1 0 2828295 validation 208 se trouve immédiatement ci-dessous, suivie par une description plus extensive du processus 1 08a générateur d'une image en mémoire ROM à chacune de ses étapes pour une forme de réalisation. Il existe d'autres formes de réalisation. Le fichier d'entrée 204 peut être un fichier de configuration identifiant des objets ou autres signaux d'entrée pour chaque construction. Le fichier d'entrée contient l'information nécessaire pour construire une image en mémoire ROM 214 pour différentes configurations. Par conséquent l'information qui se trouve dans un fichier d'entrée peut varier pour une construction particulière 212 d'une image en mémoire ROM. Dans une forme de réalisation, le fichier d'entrée contient une adresse de début d'une image en mémoire ROM, une dimension de l'image en mémoire ROM, la dimension d'une somme de contrôle, un contrôle cyclique par redondance CRC ou une autre signature de validation, un masque pour la signature de validation, un identificateur de programme pour la signature de validation et/ou un motif de remplissage pour des positions non utilisées dans l'image en mémoire ROM. L'identificateur de programme pour signature de validation peut être un nom de fichier d'un programme utilisé pour calculer la signature de validation. La signature de validation peut être une somme de contrôle, un contrôle cyclique par redondance CRC, un résultat d'un algorithme de cryptage à base d'une clé ou une autre signature de validation. Un motif de remplissage peut identifier un procédé pour lequel une image de données peut être alignée. L'image de données peut avoir une valeur d'alignement, telle qu'un pavé d'alignement spécifiant le nombre de multiplets qu'il faut ajouter à une image de données pour qu'elle soit alignée, comme demandé, avec le motif de remplissage. En variante, la valeur d'alignement peut spécifier la valeur, exprimée en multiplets, à laquelle l'image de données doit se terminer. Par exemple le motif de remplissage peut spécifier qu'une image de données doit contenir un multiple pair de la longueur, ou d'une portion définie de la longueur, du motif de remplissage. En variante, une valeur d'alignement fixée peut être définie pour chaque image de données. Par exemple la valeur d'alignement peut alors être définie à deux multiplets et ce sont alors zéro ou un multiplet qu'il faudrait ajouter à l'image de donnces pour faire en sorte qu'elle occupe un nombre pair de deux multiplets. Le motif de remplissage et la valeur d'alignement facilitent le calcul en temps réel d'une signature de validation de sorte que l'algorithme d'exécution puisse faire des hypothèses sur la dimension d'une image de données. Par exemple un algorithme de somme de contrôle peut supposer que la dimension d'une image de données est un multiple de mots de 64 bits. En outre le fichier d'entrée 204 peut contenir une information validant chaque image de données à placer dans l'image en mémoire ROM. L' information pour chaque image de données peut contenir 1S un nom de fichier, une adresse de début, à l'intérieur de l' image en mémoire ROM, à laquelle l'image de données peut être écrite, une adresse ou autre position à l'intérieur de l'image en mémoire ROM à laquelle une signature de validation peut être mémorisée, une position dans l'image en mémoire ROM à laquelle une adresse de début de l'image de données est mémorisée, la dimension et/ou le masque de la signature de validation et/ou une valeur d'alignement pour une image de données. L' adresse de début à l' intérieur de l'image en mémoire ROM peut être fixe ou dynamiquement identifiée. Si l'adresse de début est dynamiquement identifiée, un identificateur dynamique présentant une valeur particulière telle que " -1 " peut être spécifié dans le fichier d'entrée. Si une signature de validation n'est pas demandée, alors un identificateur de signature de validation nulle peut être utilisé, tel que " -1 ". Si l'adresse de début d'une image de donnces doit être ignorée, alors un identificateur d'adresse de début nulle, tel que " -2 " peut être utilisé. En ce qui concerne la dimension et/ou le masque de la somme de contrôle, après que la somme de contrôle ou autre signature de validation ait été calculée pour l'image de donnces, un masque peut faire l'objet d'une opération OU exclusif ou d'une opération ET avec la somme de 1 2 2828295 contrôle. L'homme de l'art se rendra compte de ce que d'autres identificateurs, tels que des identificateurs dynamiques, des identificateurs de signature et des identificateurs de l'adresse de début peuvent être utilisés sans s'écarter de l'objet de l'invention. Des objets 206 pour construire une image de données peuvent provenir d'un fichier d'entrée ou d'une autre source. Un objet 206 pour construire une image peut comporter une ou plusieurs adresses physiques de début pour l' image en mémoire ROM, la dimension de l'image en mémoire ROM, une valeur, exprimée en multiplets, des positions non utilisées de 1'image en mémoire ROM et/ou l'adresse de la signature de validation globale de l'image en mémoire ROM telle que la somme de contrôle de l'image en mémoire ROM. D'autres objets peuvent inclure l'adresse à laquelle l'adresse de début de l'image en mémoire ROM est mémorisée, l'adresse à laquelle la dimension d'une image de données est mémorisée, une adresse à laquelle une signature de validation pour une image de donnces est mémorisée, une dimension d'une signature de validation, un masque pour une signature de validation et/ou une dimension de mot de données lu par un processeur lors de la validation d'une image de donnces en fonction d'une signature de validation. Les objets 206 de construction de l'image sont générés dans un fichier d'objets ou dans un fichier d'objets temporaire. La signature de validation 208 est utilisée pour valider chaque image de données. L'identificateur de signature de validation peut identifier un algorithme utilisé pour générer la signature de validation. Une somme de contrôle ou un algorithme de contrôle cyclique par redondance CRC peut être utilisé pour générer la signature de validation dans des formes de réalisation particulières. En se référant à nouveau à la figure 2, on va maintenant décrire de façon plus expansive, pour une forme de réalisation préférée, les étapes du processus générateur de l'image en mémoire ROM. À l'étape 210, l'identificateur d'image traite un fichier d'entrée pour identifier des images de données pour une construction d'image en mémoire ROM. Le fichier d'entrée 204 identifie les obj ets 206 qui spécifient les images de données à inclure dans l'image en mémoire ROM. Pour chaque image de donnces le fichier d'entrée 204 spécifie si, oui ou non, le processus 108A générateur de l'image en mémoire ROM doit identifier dynamiquement l' adresse de début. Si l' adresse de début de l'image de données est fixe, le fichier d'entrée identifie l'adresse de début. En outre, le fichier d'entrce peut identifier des paramètres optionnels spécifiés ci-dessus. Lorsque le fichier d'entrée est traité, le fichier d'objets contenant les objets 206 pour chaque image de données à mettre dans l'image en mémoire ROM sera créé. Dans l'étape 202 de construction de I'image de données, le constructeur de l'image de données construit chaque image de données en utilisant les objets 206 identifiés dans le fichier d'objets pour cette image de données. L'étape 202 de construction de l'image de données comporte le fait de compiler et de lier chaque image de donnces en utilisant les objets identifiés. À l'étape 212 l'image en mémoire ROM se construit en plaçant chaque image de données présentant une position de début assignée à cette position dans l'image en mémoire ROM. À chaque image de données à laquelle n'a pas été assignce une position de début, est assignée une position libre dans l'image en mémoire ROM. Si une adresse de début, une dimension, ou une signature de validation est nécessaire pour l'une quelconque des images de données, elles sont également placées dans l'image en mémoire ROM. Par conséquent chaque image de données et l'image en mémoire ROM peuvent avoirdes processus de validation distincts qui peuvent étre définis par une entrée, par l'utilisateur, de programmes de signature de validation qui vont calculer les signatures de validation 208. Aux étapes 210 et 212, I'identificateur d'image et le constructeur de l' image en mémoire ROM valident l'image en mémoire ROM 214 en testant qu'il n'y ait pas de recouvrement entre les images de données. Par conséquent, après construction de toutes les images de données et de l'image en mémoire ROM 214, le 1 4 2828295 processus 108a générateur de 1'image en mémoire ROM se répète de préférence pour confirmer que l'image en mémoire ROM 214 a été construite de façon précise. Lors de la seconde exécution, un fichier d'objets temporaire est créé et comparé au fichier d'objets qui avait été créé dans la première exécution. Si le fichier d'objets et le fichier d'objets temporaire sont les mémes, I'image en mémoire ROM a été construite de façon précise comme cela sera décrit plus complètement ci-dessous. La seconde exécution valide également que les objets pour chaque image de données sont compatibles et elle calcule les signatures de validation pour chaque image de données si cela est spécifié, ou pour la totalité de l'image en mémoire ROM 214. Dans une première forme de réalisation, I' image en mémoire ROM 214 est validée en utilisant une signature de validation 208 générée à 1'étape 212. Toutefois du fait qu'un espace blanc ne fait pas partie de l'image en mémoire ROM 214, il n'est pas nécessaire de valider la totalité de l'image en mémoire ROM. Bien plutôt, seul ce qui est utilisé en mémoire ROM est validé, ce qui permet à l'image en mémoire ROM de crotre et sauvegarde l'exécution en temps d'exécution. On se rendra compte de ce que plus d'un module de programme peut étre associé à chaque processus. Par exemple à l'étape 210 un premier identificateur d'images peut générer le fichier d'objets et un second identificateur d' images peut générer le fichier d'objets temporaire. Les processus et les modules peuvent être distribués ou combinés selon différentes formes de réalisation. La figure 3 représente une forme de réalisation, prise à titre d'exemple, d'un autre processus 1 08b générateur d'une image en mémoire ROM. Dans cette forme de réalisation, le processus 108b générateur de 1'image en mémoire ROM est appelé deux fois. Le premier appel s'achève avant la construction de l'image en mémoire ROM et il est utilisé pour créer un fichier d'objets pour construire l'image en mémoire ROM. Le second appel s'achève après la construction de l'image en mémoire ROM et il est utilisé pour créer un fichier d' obj ets temporaire. Le fichier d' obj ets est comparé au 1 5 2828295 fichier d'objets temporaire pour confirmer la précision de l'image en mémoire ROM et garantir que les images de données qui sont dans l' image en mémoire ROM sont compatibles avec ce qui est attendu. Par exemple, si l'image en mémoire ROM est bâtie, et si un fichier de configuration pour l'image en mémoire ROM est modifié alors que l' image en mémoire ROM est en cours de génération, alors l'image en mémoire ROM ne pourrait pas identifier avec précision des images de données pour l'image en mémoire ROM. Dans ce cas, le fichier d'objets sera différent du fichier d'objets temporaire du fait que le fichier d'objets sera créé avant que le fichier de configuration soit modifié tandis que le fichier d' objets temporaire sera créé après que le fichier de configuration soit modifié. Si le fichier d'objets n'est pas le même que le fichier d'objets temporaire, le processus peut être configuré pour sortir et redémarrer. En variante, le processus peut être configuré pour redémarrer sans sortir. Le processus 108b générateur de 1' image en mémoire ROM de la figure 3 peut être modifié de façon qu'un seul appel soit effectué. Toutefois le processus à deux appels garantit une image en mémoire ROM précise. Lorsqu'un fichier d'objets ou un fichier d'objets temporaire est créé, les données provenant du fichier d'entrée sont lues et écrites dans le fichier d'objets ou dans le fichier d'objets temporaire. Les données qui sont dans le fichier d'objets sont utilisées pour construire l'image en mémoire ROM. Par exemple, si la construction de l'image en mémoire ROM est basée sur un fichier source en code C, le fichier d'objets comporte un fichier d'en-tête contenant des #définitions utilisées pour lister les paramètres. Le processeur l 08b générateur de l'image en mémoire ROM vérifie l'existence des #définitions pour ajouter ou enlever le code pendant le temps d'exécution lorsque l'image en mémoire ROM est construite. Le processus 1 08b générateur de l'image en mémoire ROM peut également utiliser les #définitions pour déterminer par exemple les positions des images de données, les sommes de 16 2828295 contrôle et les dimensions des images de données qui sont dans l'image en mémoire ROM. En se reportant au processus représenté sur la figure 3, le processus 108b générateur de l'image en mémoire ROM traite un fichier d'entrée à 1'étape 302. Le fichier d'entrée est lu pour obtenir une information d'entrée pour construire l' image en mémoire ROM. L' information fournie par le fichier d'entrée peut inclure l' adresse de début de l'image en mémoire ROM, la dimension de l'image en mémoire ROM, un motif de remplissage et une valeur d'alignement, une dimension d'une somme de contrôle pour l'image en mémoire ROM et un identificateur de la somme de contrôle. Un masque pour une somme de contrôle peut également étre inclus. Le fichier d'entrée est lu pour chaque image de données pour déterminer le nom du fichier de l'image de données, I'adresse de début de l'image 1S de données à l'intérieur de l'image en mémoire ROM, la position dans l'image en mémoire ROM pour mémoriser la somme de contrôle pour cette image de données, la position dans l'image en mémoire ROM pour mémoriser l'adresse de l'image de données, la dimension de la somme de contrôle pour l'image de données et la valeur d' alignement pour l ' image de données. L'étape 304 détermine si un fichier d'objets devrait étre créé pour la construction de l' image en mémoire ROM. Si c'est le premier appel du processus 108b générateur de l'image en mémoire ROM de sorte que l'image en mémoire ROM n'a pas encore été construite, un fichier d'objets 306 est créé à 1'étape 308. Le processus passe à l'étape 310 et 1'image en mémoire ROM est construite. Si c'est le second appel du processus 108b générateur de l' image en mémoire ROM, c'est-à-dire si l' image en mémoire ROM a déjà été construite, alors un fichier d'objets temporaire 312 est créé à l'étape 314. Une fois que le fichier d'objets 306 et le fichier d'objets temporaire 312 sont crcés, la construction de I'image en mémoire ROM débute par une comparaison du fichier d' objets 306 et du fichier d'objets temporaire 312 à 1'étape 316. Si le fichier d'objets 306 et le fichier d'objets temporaire 312 correspondent, alors la 1 7 2828295 construction originale de l'image en mémoire ROM et la détermination actuelle du fichier d'objets sont les mêmes. Par conséquent aucune image de données n'a été ajoutée, modifiée ou effacce et aucun autre changement n'a été effectué, tel qu'un fichier de configuration. Si le fichier d'objets et le fichier d'objets temporaire ne correspondent pas, alors une image de données a été ajoutée, modifiée ou supprimée ou une autre modification est survenue après la construction. Si le fichier d'objets et le fichier d'objets temporaire ne correspondent pas à l'étape 316, le processus sort avec une erreur à l'étape 318. En option un message d'erreur peut être généré pour un dispositif de sortie. Si le fichier d'objets et le fichier d'objets temporaire correspondent à l'étape 316, chaque image de données est traitée à l'étape 320 pour déterminer la dimension de l'image de données et valider l' image de données, par exemple avec une somme de contrôle ou un contrôle cyclique par redondance CRC. Une valeur d'alignement peut être ajoutée (étape non représentée) à l'image de données de façon qu'un algorithme de validation puisse estimer les limites de dimension sur l'image de données lors du calcul de la signature de validation. La figure 4 représente une forme de réalisation, prise à titre d'exemple, d'un processus de paramétrage d' image de données. Des conflits d'adresses sont vérifiés à l'étape 322 pour déterminer si la position et la dimension de l'adresse de l'image de données sont en conflit avec d'autres images de données. Les paramètres de l'image de données sont comparés à toutes les autres images de données et à leurs paramètres associés pour déterminer si une position dans l'image en mémoire ROM est occupée par plus qu'une image de donnces ou par les paramètres associés à cette image de données. Si une position dans l'image en mémoire ROM est en fait utilisée par plus d'une image de données à un instant, une erreur existe. Par conséquent si un conflit d'adresses existe à l'étape 322, le processus sort avec une erreur à 1'étape 324. La figure 5 décrit une forme de réalisation, prise à titre d'exemple, d'un processus de vérification d'un conflit d'adresses. 1 8 2828295 Si aucun conflit d'adresses n'existe à l'étape 322, les images de donnces qui n'ont pas une adresse de début définie sont affectées d'une adresse de début à l'étape 326. Ces adresses sont affectées par voie itérative à travers chaque combinaison de positions non utilisées dans l'image en mémoire ROM et en affectant une position jusqu'à ce que soit une correspondance soit détectée soit aucune combinai son ne so it trouvée. La fi gure 6 représente une forme de réalisation, prise à titre d'exemple, d'un processus d'affectation d'adresse. Si aucune combinaison n'est trouvée à l'étape 326, les adresses sont évaluées au point de vue risque de conflit à l'étape 328. Si un conflit existe, le processus sort avec une erreur à l'étape 330. Si une combinaison est trouvée à l'étape 326, alors aucun conflit d'adresse n'est trouvé à l'étape 328 et les images de données sont écrites sur 1'image en mémoire ROM à l'étape 332. Lorsque les images de données sont écrites sur 1' image en mémoire ROM, un fichier de sortie de l'image de données est ouvert et le premier multiplet du fichier de sortie est à la même position que le premier multiplet de l'image en mémoire ROM. Le processus fait une itération en boucle à travers chaque multiplet de l'image en mémoire ROM et les données appropriées pour chaque image de données sont écrites sur l'image en mémoire ROM. Ces données pour image de données peuvent inclure l'image de données elle- même, la dimension de l'image de données, la position de l'image de données et/ou la somme de contrôle de l'image de données. D'autres données pour les images de données peuvent inclure un code exécutable pour un dispositif programmable, des données utilisces dans l'exécution de l'image en mémoire ROM ou d'autres données. Si une position non occupée par des données est découverte, le motif de remplissage avec la valeur d'alignement est écrit sur l'image en mémoire ROM. En variante, un motif de remplissage avec une valeur d'alignement peut être écrit sur l' image en mémoire ROM et les données appropriées pour chaque image de données peuvent étre écrites sur l'image en mémoire ROM. Le fichier de sortie est fermé lorsque le dernier multiplet de l'image en 19 2828295 mémoire ROM est traité. Une forme de réalisation, prise à titre d'exemple, du processus d'écriture de l'image de données est représentée sur la figure 7. Après que le fichier de sortie est fermé, la somme de contrôle pour la totalité de l' image en mémoire ROM est calculée à l'étape 334 et écrite sur 1'image en mémoire ROM. Le processus sort alors à l'étape 310. Un système de programmation, tel que le dispositif de la figure 1, peut être configuré pour transférer 1'image en mémoire ROM dans une mémoire telle qu'une mémoire ROM, PROM, EPROM ou EEPROM. La figure 4 décrit une forme de réalisation, prise à titre d'exemple, d' un processus de paramétrage d' une image de données. Le processus 320A de paramétrage de l'image de données exécute une itération en boucle à travers chaque image de données pour générer les paramètres de 1'image de données à 1'étape 402. La dimension de chaque image de données est calculée à l'étape 404. Chaque dimension de l'image de données est garnie d'une valeur d'alignement pour aligner l'image de données à la limite demandée à l'étape 406 (si demandé et/ou si nécessaire). La somme de contrôle, le contrôle cyclique par redondance CRC ou autre signature de validation de l'image de données avec la valeur d'alignement ajoutée, s'il y a lieu, sont déterminés à l'étape 408. En option, la somme de contrôle est masquée à l'étape 410. Si c'est le masque qui est choisi, par exemple, les 32 bits supérieurs de la somme de contrôle peuvent être masqués. D'autres processus de masquage peuvent être utilisés. Le processus 320A revient alors pour exécuter une itération en boucle à travers l'image de données suivante à l'étape 402. La figure 5 décrit une forme de réalisation, prise à titre d' exemple, d' un processus de vérification d' un conflit d' adresse. Le processus 322A de vérification de conflit d'adresse effectue une boucle d'itération à travers chaque image de données à l'étape 502. Si l'adresse de début d'une image de données est en conflit avec l'adresse de début d'une autre image de données à l'étape 504, le conflit est identifié à l'étape 506. Si la position de la somme de 2828295 contrôle d'une image de données est en conflit avec la position de la somme de contrôle d'une autre image de données à l'étape 508, un conflit est identifié à l'étape 506. Si la position d'adresse d'une image de données est en conflit avec la position d'adresses d'une autre image de données à 1'étape 510, un conflit est identifié à l'étape 506. Si la position de dimension d'une image de données est en conflit avec la position de dimension d'une autre image de données à l'étape 512, un conflit est identifié à 1'étape 506. Si aucun conflit n'est identifié aux étapes 502, 508, 510 ou 512, le processus 322A effectue une boucle d'itération à travers l'image de données suivante à l'étape 502. La figure 6 décrit une forme de réalisation, prise à titre d' exemple, d'un processus d' affectation de l 'adresse d'une image de données. Le processus 326A d' affectation d' une adresse effectue une itération en boucle à travers chaque image de données à 1'étape 602. Le processus est achevé pour les images de données auxquelles une adresse de début est allouée dynamiquement. À l'étape 604, lorsqu'une section de mémoire est ouverte dans l'image en mémoire ROM, et si cette section de mémoire n'est pas repérée comme déjà essayée, alors cette position de mémoire est affectée à 1'image de données à l'étape 606. Une section de mémoire dans l'image en mémoire ROM est ouverte si n'y sont actuellement mémorisés ni images de données ni paramètres associés. Une section de mémoire n'est pas repérée comme essayée si le processus d'affectation d'adresse n'a pas déjà essayé de sélectionner cette position de mémoire pour mémorisation. Si la position de mémoire n'est pas suffisante pour contenir l'image de données sélectionnée ou le paramètre sélectionné, ou si cette position de mémoire est repérée comme déjà essayée pour I' image de données sélectionnée à l' étape 604, le processus 3 26A détermine à l'étape 608 si cette adresse de début est affectée à une autre image de données précédente. Du fait que les positions d'adresse sont sélectionnées séquentiellement avant que le processus passe à l'étape 608, tout bloc de mémoire ouvert et disponible sera sélectionné. Toutefois ce processus itératif se 21 2828295 produit à l'étape 604 et le passage à l'étape 608 suppose qu'aucun autre bloc ouvert à l'intérieur de l'image en mémoire ROM n'est suffisant. À l'étape 608 il est déterminé si une adresse de départ actuelle de 1'image en mémoire ROM est affectée à une image de données précédente et si l'image de données actuelle va tenir dans l'espace identifié par l'adresse de début actuelle. Dans ce cas, l'adresse de début actuelle de I'image en mémoire ROM est désaffectée pour l'image de données précédente, l'adresse de début actuelle est affectée à l'image de données actuelle et 1'adresse de début actuelle est repérée comme déjà essayée pour l'image de données précédente à l'étape 610. Le processus 326A effectue une boucle d'itération à l'étape 604 pour essayer de faire tenir 1'image de données précédente à une nouvelle adresse de début. À l'étape 608, si 1'adresse de début actuelle n'est pas affectée à l'image de données précédente, et si la dernière adresse de début de l'image en mémoire ROM n'a pas été sélectionnée (pour déterminer si l'image de données actuelle va y tenir) à l'étape 612, la plus proche adresse précédente est sélectionnce à l'étape 614. Le processus d'itération se poursuit à 1'étape 608 jusqu'à ce que la dernière adresse disponible de l'image en mémoire ROM apparaisse à l'étape 612. Si le processus passe à la dernière image précédente ayant la dernière adresse de début précédente à l'étape 612 et si cette adresse de début ne peut pas étre affectée à l'image de donnces actuelle, le processus 326 va sortir avec une erreur à I'étape 616. La figure 7 décrit une forme de réalisation prise à titre d'exemple d'une opération d'écriture sur l'image de données. L'opération 332A d'écriture sur l'image de données effectue une itération en boucle à travers chaque multiplet se trouvant dans l'image en mémoire ROM à l'étape 702. Si une position du multiplet se trouvant dans I'image en mémoire ROM en cours de traitement est la même que la position d'un paramètre d'une image de donnces sélectionnée, l'opération 332A d'écriture sur l'image de données écrit la position du paramètre sur le multiplet en cours de 22 2328295 traitement. Les positions de paramètre peuvent inclure une position de somme de contrôle, une position de dimension, une position de mémoire à laquelle est mémorisée la position de début d'une image de données, une position de début, ou d'autres paramètres. En se reportant à la figure 7, si la position du multiplet se trouvant dans l'image en mémoire ROM est la même que la position de la somme de contrôle de 1' image de données, la position de la somme de contrôle est écrite sur ce multiplet à l'étape 706. Le multiplet se trouvant dans l'image en mémoire ROM, en cours de traitement, est actualisé par la dimension des données qui viennent d'être écrites dans le fichier de sortie à l'étape 708. Le processus effectue alors une itération en boucle à travers le multiplet suivant se trouvant dans 1'image en mémoire ROM à 1'étape 702. Si la position du multiplet n'est pas la même que la position de la somme de contrôle pour l'image de données à l'étape 704, mais que la position du multiplet est la même que la position de dimension de l'image de données à l'étape 710, alors la dimension de l'image de données est écrite sur ce multiplet à I'étape 712. Le multiplet se trouvant dans l'image en mémoire ROM est actualisé à l'étape 708 et le processus 332A effectue une itération en boucle à travers le multiplet suivant se trouvant dans l'image en mémoire ROM à l'étape 702. Si la position du multiplet n'est pas la même que la position de dimension de l'image de données à l'étape 710, mais que la position du multiplet est la même que là o la position de début de l'image de données (DISL) est mémorisée à l'étape 714, la position de l'image de données est écrite sur l' image en mémoire ROM à l'étape 716. Le multiplet se trouvant dans l'image en mémoire ROM est actualisé à l'étape 708 et le processus effectue une itération en boucle à travers le multiplet suivant se trouvant dans 1'image en mémoire ROM à l'étape 702. Si la position du multiplet n'est pas la même que là o la position de début de l'image de données est mémorisée à l'étape 714, mais que la position du multiplet est la même que la position de début de l'image de données à l'étape 718, alors l'image de 23 2828295 données est écrite dans le fichier à l'étape 720. Une valeur d'alignement d'un motif de remplissage sélectionné est écrite sur l'image en mémoire ROM à l'étape 722, si nécessaire et si demandé. Le multiplet se trouvant dans l'image en mémoire ROM est actualisée à l'étape 708 et le processus effectue une itération en boucle à travers le multiplet suivant se trouvant dans l'image en mémoire ROM à l'étape 702. Si la position du multiplet n'est pas la même que la position de début de I' image de données à I'étape 718, alors une valeur d' alignement d'un motif de remplissage est écrite sur l 'image en mémoire ROM à l'étape 724. Le multiplet se trouvant dans l' image en mémoire ROM est actualisé en 708 et le processus effectue une itération en boucle à travers le multiplet suivant se trouvant dans l' image en mémoire ROM à l'étape 702 jusqu' à achèvement. La figure 8 représente une forme de réalisation, prise à titre d'exemple, d'un processus de validation en mémoire ROM. Le processus 802 de validation en mémoire ROM peut être utilisé pour valider une image en mémoire ROM mémorisce en mémoire ROM. Par exemple le processus 802 de validation en mémoire ROM peut étre utilisé pour valider une image en mémoire ROM ou une ou plusieurs image de données après que l'image en mémoire ROM est mémorisée dans la mémoire ROM, par exemple après utilisation d'un système de calcul. En variante ou en supplément, le processus 802 de validation en mémoire ROM peut être utilisé pour valider séparément une ou plusieurs images de données dans 1'image en mémoire ROM. On se rendra compte de ce que le processus 802 de validation en mémoire ROM a un module de validation en mémoire ROM associé. Le processus de validation en mémoire Rom démarre à l'étape 804 en faisant effectuer une itération en boucle à une première image de données, sélectionnée, de l'image en mémoire ROM. Bien que, typiquement, la première image de données sélectionnée ait une adresse de début au premier multiplet des image de données dans l'image en mémoire ROM, n'importe quelle image de données peut être sélectionnée. 24 2828295 La totalité de l'image en mémoire ROM peut ne pas demander de validation. Dans certains cas seule une portion de l'image en mémoire ROM va demander la validation et une ou plusieurs images de données seulement nécessiteront la validation. Ceci peut se produire lorsque seules des images de données sélectionnées sur l'image en mémoire ROM sont nécessaires pour faire fonctionner un système informatique ou un autre système. Par exemple une image en mémoire ROM peut contenir trois sections, chacune contenant un code pour une opération différente. Dans un exemple particulier, il est possible que deux des trois sections seulement puissent être nécessaires pour l'opération. Par conséquent le processus 802 de validation en mémoire ROM peut valider sélectivement, ou ne pas valider, une ou plusieurs des sections de l'image en mémoire ROM, c'est-à-dire une ou plusieurs des images de données, ce qui accélère la validation. L'adresse de début et la longueur de l'image de données sont lues à l'étape 806 et la signature originale de validation de l'image de données est lue à l'étape 808. D'autres paramètres de l'image de donnces peuvent être lus sous d'autres formes de réalisation. Par exemple le type de signature de validation peut être identifié en tant que paramètre de l'image de données. Toutefois, en l'absence de spécification, le type de signature de validation est déterminé à l'étape 808. Dans certaines formes de réalisation, la signature de validation pour l'image de données peut être une somme de contrôle, un contrôle cyclique par redondance CRC ou le résultat d'un algorithme de cryptage à base d'une clé, par exemple une clé privée pour emploi avec un algorithme de cryptage d'une clé publique. D'autres types de signatures de validation existent. Un algorithme de validation de l'image de données est sélectionné pour générer une nouvelle signature de validation de l'image de donnces à l'étape 810. L'algorithme de validation de l'image de données est sélectionné sur la base du type de signature de validation de l'image de données identifié à l'étape 808. La nouvelle signature de validation de l'image de données est générée à 1'étape 812 et la nouvelle signature de validation de 1'image de 2828295 données est comparce avec la signature originale de validation de l'image de données provenant de l'image en mémoire ROM à l'étape 814. Si la nouvelle signature de validation de l'image de données ne correspond pas à la signature originale de validation de l'image de données à 1'étape 814, le processus 802 sort avec une erreur à l'étape 816. En variante, le processus 802 peut être configuré pour redémarrer ou répéter les étapes 806-814 ou un sous-ensemble de ces étapes, si la signature originale et la nouvelle signature de validation de l'image de données ne correspondent pas. En variante le processus 802 peut être configuré pour noter que la signature originale et la nouvelle signature de validation de I'image de données ne correspondent pas, sauter cette image de données et effectuer une itération en boucle pour la nouvelle image de données à l'étape 804. Des mesures correctives peuvent être prises pour I'image de données sautée. Si la signature originale et la nouvelle signature de validation de l'image de données ne coincident pas à l'étape 814 et si l'image de données que l'on vient de traiter n'était pas la dernière image de données dans l'image en mémoire ROM à l'étape 818, le processus 802 effectue une itération en boucle pour l'image de données suivantes se trouvant dans l'image en mémoire ROM à l'étape 804. Si l'image de données que l'on vient de traiter était la dernière image de données se trouvant dans l'image en mémoire ROM à l'étape 818, le processus passe à l'étape 820. À l'étape 820 la signature originale de validation pour l'image en mémoire ROM est lue. Le type de signature de validation peut être spécifié comme paramètre optionnel. Toutefois s'il n'est pas spécifié le type de signature de validation est déterminé à l'étape 820. Dans certaines formes de réalisation, la signature de validation pour 1'image en mémoire ROM peut être une somme de contrôle, un contrôle cyclique par redondance CRC, ou le résultat d'un algorithme de cryptage à base de clé, tel qu'une clé privée pour emploi avec un algorithme de cryptage à clé publique. D'autres types de signature de validation existent. 26 2828295 Un algorithme de validation est sélectionné pour générer une nouvelle signature de validation de l'image en mémoire ROM à l'étape 822. L'algorithme de validation de l'image en mémoire ROM est sélectionné sur la base du type de signature de validation de 1'image en mémoire ROMidentifié à l'étape 820. La nouvelle signature de validation de l'image en mémoire ROM est générée à l'étape 824 et la nouvelle signature de validation de 1'image en mémoire ROM est comparée avec la signature originale de validation de l'image en mémoire ROM, provenant de l' image en mémoire ROM, à l'étape 826. Si la nouvelle signature de validation de l'image en mémoire ROM ne correspond pas avec la signature originale de validation de l'image en mémoire ROM à l'étape 826, le processus 802 sort avec une erreur à l'étape 816. Si la nouvelle signature de validation de l'image en mémoire ROM correspond à la signature originale de validation de l'image en mémoire ROM à l'étape 826, 1'image en mémoire ROM est validée à l'étape 828 et le processus sort à l'étape 830. Les processus identifiés aux étapes 820-830 sont optionnels. En outre les processus des étapes 820-830 peuvent étre dans un processus distinct ou un module distinct provenant des étapes 804- 818. Si les processus des étapes 820-830 sont un processus ou un module distincts ou ne sont pas inclus d'autre façon, le processus 802 de validation de la mémoire ROM se termine après que la dernière signature de validation de l'image de données pour la dernière image de données soit déterminée en 818. D'autres formes de réalisation pour le processus 802 de validation de la mémoire ROM existent. L'homme de l'art se rendra compte que des variantes par rapport aux formes de réalisation spécifiques décrites ci-dessus sont envisagées par 1'invention. L'invention ne doit donc pas étre limitée aux formes de réalisation ci-dessus, mais doit étre mesurée *par les revendications qui suivent. 27 2828295 Revendications 1. Système pour générer une image en mémoire ROM (214) comprenant: un identificateur d'image (210) configuré pour traiter un fichier d'entrée (204) pour générer un fichier d'objets (206) représentant des objets pour chaque image de données identifiée dans le fichier d'objets (206), un constructeur d' image de données configuré pour traiter chaque image de données avec son fichier d'objets associé pour créer la construction d'image de données (202) pour chaque image de données, et un constructeur d'image en mémoire ROM (212) configuré pour générer une signature de validation d' image de données pour chaque image de données pour écrire chaque image de données et sa signature de validation d'image de données pour chaque construction d'image de données sur l' image en mémoire ROM (214) et pour générer une signature de validation de l'image en mémoire ROM (208) pour l'image en mémoire ROM. 2. Le système de la revendication 1 dans lequel le constructeur (212) de l'image en mémoire ROM est configuré pour aligner chaque image de données dans chaque construction d' image de données, si nécessaire, en utilisant un motif de remplissage et une valeur d'alignement (406) avant de générer la signature de validation de chaque image de données. 3. Le système de la revendication 1 dans lequel le constructeur (212) de l'image en mémoire ROM est configuré pour affecter dynamiquement une adresse de début dans l' image en mémoire ROM à au moins une image de données (306). 4. Le système de la revendication 1 dans lequel une première position de mémoire dans l'image en mémoire ROM (214) est affectée à une première image de données et dans lequel le constructeur (212) de l'image en mémoire ROM est configuré pour réaffecter dynamiquement la première position de la 28 2328295 mémoire à une seconde image de données et pour affecter une nouvelle position de mémoire à la première image de donnces. 5. Le système de la revendication 1 dans lequel la signature de validation de l'image de données comporte au moins un élément d'un groupe constitué d'une somme de contrôle (334) et d'un contrôle cyclique par redondance. 6. Le système de la revendication 1 dans lequel: I'identificateur d'images est en outre configuré pour traiter le fichier d'entrée (206) pour générer un fichier d'objets temporaire (312), le fichier d'objets temporaire représentant les objets pour chaque image de données identifiée dans le fichier d'entrée (302); et le constructeur (212) d'image en mémoire ROM est en outre configuré pour comparer le fichier d'objets (206) avec le fichier d'objets temporaire (312) et, si ce sont les mémes, pour traiter alors chaque image de donnces avec son fichier d'objets associé pour créer l'image en mémoire ROM (214). 7. Le système de la revendication 6 dans lequel 1'identificateur d'image (210) comporte un premier identificateur d'image configuré pour générer le fichier d'objets (206) et un second identificateur d' image configuré pour générer le fichier d'objets temporaire (312). 8. Le système de la revendication 1 dans lequel le constructeur (212) de l'image en mémoire ROM est configuré pour masquer au moins une signature de validation d'une image de données (410). 9. Le système de la revendication 1 dans lequel le constructeur (212) de l'image en mémoire ROM comporte un organe d'écriture de l'image de données configuré pour effectuer une itération en boucle à travers chaque multiplet de l'image en mémoire ROM (702) et, si une position du multiplet de l'image en mémoire ROM est la méme qu'une position d'un paramètre d'une image de données sélectionnée, écrire la position du paramètre sur le multiplet de l'image en 29 2828295 mémoire ROM en cours de traitement. 10. Le système de la revendication I comportant un système de programmation configuré pour transférer l'image en mémoire ROM (214) sur au moins un élément d'un groupe constitué d'une mémoire morte/ROM, d'une mémoire morte programmable/PROM, d'une mémoire morte programmable et effaçable/EPROM et d'une mémoire morte programmable