FR 3005178 A1 20141031 FR 1300976 A 20130426 SYSTEME ET PROCEDE DE CHARGEMENT DE DONNEES DANS UN COMPOSANT PROGRAMMABLE L'objet de l'invention concerne un système et un procédé pour le chargement et/ou la mise à jour de données telles qu'un fichier de configuration ou Bitstream de circuits programmables plus connus sous l'acronyme anglo-saxon FPGA (Field Programmable Gate Array) via une liaison standard, telle qu'une liaison Ethernet et un ordinateur ou PC. Le procédé peut s'appliquer dans toutes les cartes utilisant un 10 FPGA avec un/des périphériques de type Ethernet à travers lesquels on souhaite pouvoir mettre à jour le fichier de configuration du FPGA. Les circuits pré diffusés sont des circuits partiellement préfabriqués. Ils contiennent un ensemble d'éléments, tels que des 15 transistors, des diodes, des résistances, des capacités, etc., qui ne sont pas interconnectés entre eux. Contrairement aux circuits prédiffusés conventionnels, les circuits prédiffusés programmables ne demandent pas de fabrication spéciale en usine, ni de matériels de développement coûteux. La mise à jour ou la reconfiguration dynamique des FPGAs consiste à changer 20 la programmation des circuits logiques programmables. Un FPGA est un composant programmable comprenant des ressources logiques configurables, de types LUT (acronyme anglo-saxon de Look-Up Table), bascules, par exemple, et interconnectables entre elles. La définition de ces configurations et interconnexions fait l'objet du Bitstream qui 25 est logé dans une mémoire interne au composant FPGA. La grande majorité des FPGA sont de technologie SRAM donc volatile. Ainsi, il est nécessaire que le système électronique équipé de ce FPGA dispose d'une mémoire non volatile, de type mémoire rapide ou mémoire FLASH par exemple, afin de stocker ce Bitstream lorsque le système n'est plus alimenté. Suite à la mise 30 sous tension du système, ce fichier de configuration est téléchargé automatiquement au sein du FPGA. Différentes solutions existent pour configurer et re-configurer les circuits logiques programmables sans en interrompre le fonctionnement. Une première façon de procéder, schématisée à la figure 1, consiste à utiliser une liaison JTAG connue de l'Homme du métier (abrégé anglo-saxon de Joint Test Action Group). Cette technique utilise une sonde JTAG et des outils de programmation sur un ordinateur ou PC fournis habituellement par le fabricant du circuit. La sonde JTAG fait appel à un boitier JTAG 7 relié à un PC 9 grâce à une liaison USB/Ethemet 8 et au FPGA 3 via une liaison JTAG 6, un connecteur JTAG 5, une liaison carte JTAG 4. Le FPGA 3 est en liaison 2 avec une mémoire non volatile 1 stockant le Bistream du FPGA. Cette technique présente comme inconvénient de mettre en oeuvre des outils spécifiques, une sonde de programmation, et d'avoir accès à la liaison de debug JTAG de la carte. Les débits sont de quelques centaines de Kbits/s limités par la bande passante de la liaison JTAG, par exemple il faut compter 15 minutes pour un Bitstream de 10 Mo. Une deuxième manière de procéder, illustrée à la figure 2, consiste à utiliser une liaison Ethernet 21 via un microcontrôleur 14 embarqué au sein du FPGA. Le FPGA 13 est en liaison avec la mémoire non volatile 11 de stockage de Bitstream via une interface 12 de configuration du FPGA. Le micro-contrôleur 14 embarqué au FPGA est en liaison 15 avec une mémoire logicielle 16. Le PC 22 est en liaison avec le micro-contrôleur embarqué au FPGA via une liaison Ethernet constituée d'un composant PHY, 18 et d'un connecteur RJ45, 20, connu de l'Homme du métier. Les limitations de l'utilisation d'un micro-contrôleur embarqué au sein du FPGA sont notamment les suivantes : il est nécessaire d'avoir un FPGA disposant d'un micro-contrôleur embarqué avec des contrôleurs Ethernet et Flash. Or, tous les micro-contrôleurs ne sont pas facilement portables sur toutes les familles des FPGA. Certains sont spécifiques du fabricant FPGA (Microblaze® de la société Xilinx, NIOS® de la société Altera, Mico32® développé par la société Lattice, par exemple). De plus, ces micro- contrôleurs sont gourmands en ressource FPGA, quelques milliers de LUTs et bascules. Les débits de téléchargement de Bitstream, atteints par cette solution sont de quelques Mbits/s, soit 1 minute pour un Bitstream de 10 Mo. Cette technique nécessite aussi l'exécution d'un logiciel par le micro- contrôleur embarqué. L'exécution de ce logiciel peut nécessiter l'utilisation d'une mémoire externe spécifique de type SRAM ou DDR par exemple. Malgré tous les avantages qu'elles offrent, les techniques développées par l'art antérieur sont limitées par leur utilisation d'outils spécifiques sur un PC distant, l'obligation de développer des spécificités dans les FPGA, et les débits de téléchargement des Bistreams qui sont de quelques Mbits/s au maximum. Un des objectifs de la présente invention est de résoudre au moins l'un des problèmes des techniques connues de l'art antérieur, d'augmenter le débit de téléchargement, d'offrir un outil plus générique. L'objet de l'invention concerne un système pour le chargement et/ou la mise à jour de données au sein d'un composant programmable comprenant au moins une mémoire non volatile, à partir d'un calculateur, d'une liaison standard de type Ethernet et d'une fonction CBETH caractérisé en ce que la fonction CBETH comporte au moins les éléments suivants : - un premier module de gestion de protocole de la liaison standard entre le calculateur et le composant programmable, - un deuxième module comprenant un premier module de contrôle du format des données transmises par le calculateur, un deuxième module adapté à gérer les étapes du début de téléchargement des données, un troisième module mémorisant les données avant leur transmission dans la mémoire non volatile connecté au composant programmable et un quatrième module d'acquittement des messages. Le composant programmable est, par exemple, un composant programmable de type FPGA (Field Programmable Gate Array). Le deuxième module peut implémenter le protocole TFTP. Selon un mode de réalisation, la fonction CBETH est codée en langage de description matériel, destinée à représenter le comportement ainsi que l'architecture d'un système électronique numérique, connu sous l'acronyme anglo-saxon HDL pour Hardware Description Language. Le premier module de gestion de protocole est, par exemple, adapté à gérer le protocole UDP/IP et le deuxième module de contrôle de téléchargement comprend un premier sous-module adapté à analyser les datagrammes UDP reçus du module de gestion des protocoles UDP/IP, un deuxième sous-module de supervision de requête d'écriture, un bloc mémoire, un quatrième sous-module de validation ou non du format des données. Le calculateur du système est, par exemple, un PC. L'invention concerne aussi un procédé pour le chargement et/ou la mise à jour des données dans une mémoire non volatile connectée à un composant programmable comprenant des ressources logiques configurables interconnectables entre elles, en utilisant un calculateur et une liaison de type Ethernet caractérisé en ce qu'il utilise pour le chargement et/ou la mise à jour une fonction CBETH implémentée au sein du composant, ladite fonction comprenant un premier sous-module de gestion des protocoles et un deuxième sous-module, en exécutant au moins les étapes suivantes : a) transmettre les données à charger en mémoire non volatile, connectée au composant programmable, via la liaison de type Ethernet à un premier module de contrôle du format des données, b) si le format des données est correct, alors transmettre les données à une mémoire de stockage, dans le cas contraire, transmettre un message d'erreur vers le calculateur. Selon une variante du procédé on charge des données dans la mémoire connectée à un composant programmable FPGA. Le procédé utilise, par exemple, le protocole TFTP pour contrôler le téléchargement des données. La fonction CBETH est, par exemple, codée dans un langage de description matériel, destinée à représenter le comportement ainsi que l'architecture d'un système électronique numérique, connu sous l'acronyme anglo-saxon HDL pour Hardware Description Language pour coder les données. D'autres caractéristiques et avantages du dispositif selon l'invention apparaîtront mieux à la lecture de la description qui suit d'un exemple de réalisation donné à titre illustratif et nullement limitatif annexé des figures qui représentent : - la figure 1, un exemple de mode de téléchargement selon l'art antérieur utilisant une liaison JTAG, - la figure 2, une représentation du mode de téléchargement utilisant un micro-contrôleur embarqué au sein d'un FPGA, - la figure 3, un synoptique général du contexte d'utilisation de la fonction selon l'invention, - la figure 4, une illustration de la répartition des protocoles gérés et utiles par rapport à la fonction de l'invention, - la figure 5, un synoptique détaillé de la fonction selon l'invention, - la figure 6, un exemple de séquencement du téléchargement de la fonction. L'exemple qui suit est donné pour la mise à jour à distance, via une liaison standardisée Ethernet, du fichier de configuration, nommé Bitstream d'un composant de type FPGA d'un système électronique. La figure 3 illustre un synoptique général d'utilisation d'une fonction adaptée à mettre à jour le Bitstream d'un FPGA. Le système de chargement et/ou de mise à jour selon l'invention comprend, par exemple, une mémoire non volatile de stockage de Bitstream FPGA, 31 qui est reliée via une interface de configuration 32 à un contrôleur flash 33 de l'application FPGA 30. L'application FPGA intègre la fonction CBETH de mise à jour selon l'invention. Cette fonction CBETH comprend un module 34 de contrôle de téléchargement et un module 35 de gestion des protocoles en liaison via une interface 36 standard. Le module de gestion des protocoles est en liaison, via une interface standard 37, avec un module d'accès MAC 38 qui fait partie du FPGA. Le module d'accès MAC 38 est relié via une interface physique 39 à une couche physique 40 en liaison 41 avec un connecteur 42 reliant un calculateur 43 tel qu'un PC via le réseau Ethernet 45. La fonction CBETH s'appuie, par exemple, sur le protocole standardisé de transfert de fichier plus connu sous l'acronyme anglo-saxon TFTP pour Trivial File Transfert Protocol. Ceci implique que le système électronique gère les protocoles connus de l'Homme du métier, Ethernet, ARP, IPv4 et UDP bien connus dans le standard OSI. La figure 4 illustre la répartition des protocoles gérés et utiles à la fonction CBETH. La fonction CBETH implémente les protocoles TFTP, UDP protocole de datagramme utilisateur, IP protocole Internet, le protocole de résolution d'adresse ou ARP Address Resolution Protocol et une partie du protocole Ethernet/MAC (Medium Access Control). La seconde partie Ethernet/MAC est réalisée par une IP fournie par le fabricant du FPGA. La couche physique PHY est réalisée par un composant matériel, à l'extérieur du FPGA, généralement présent sur la carte électronique sur lequel se trouve le FPGA. La figure 5 donne un synoptique détaillé de la fonction CBETH. La fonction CBETH est décomposée en deux sous-ensembles comme il a été indiqué ci-dessus, le module 35 « UDP/IP » et le module 34 « Ctrl Telech » qui communique entre eux via des liaisons classiques 60, 61. La fonction est par exemple codée en langage de description matériel, destinée à représenter le comportement ainsi que l'architecture d'un système électronique numérique, connu sous l'acronyme anglo-saxon HDL pour Hardware Description Language. Le module UDP/IP a notamment pour fonction de gérer les protocoles IP, ARP et UDP. Il réalise également un complément de gestion du protocole Ethemet/MAC, non réalisé par les IP Ethernet/MAC fournis par les fabricants de FPGA. Il permet au module de contrôle « ctrl Telech » de pouvoir échanger de datagrammes UDP avec le PC distant. Le fonctionnement du module UDP/IP ne sera pas détaillé car il est connu de l'Homme du métier. Le module de contrôle de téléchargement des données « Ctrl Telech », 34, comporte quatre sous-modules détaillés ci-après. Un premier sous-module, 51, « TFTP Rx » travaillant en réception a notamment pour fonction d'analyser les datagrammes UDP reçus du module de gestion des protocoles UDP/IP. Les datagrammes implémentant des données d'un protocole autre que TFTP sont supprimés. Ce sous-module, 51, « TFTP Rx » interprète uniquement les messages de requête d'écriture et de données d'écriture du protocole TFTP. A chaque requête d'écriture reçue, ce premier sous-module « TFTP Rx » informe un deuxième sous-module de supervision, 52, « Supervision Telech » de la requête d'écriture. A chaque message de données d'écriture, à transmettre vers un bloc mémoire IF mémoire, 53, pour le chargement du bitstream, le premier sous-module « TFTP Rx » informe le sous-module de supervision « Supervision Telech » et met à disposition du sous-module « IF Mémoire » les données utiles. En fonction des données reçues par le sous-module « TFTP Rx », le deuxième sous-module « Supervision Telech » commande le troisième sous-module, 53, « IF Mémoire » et un quatrième sous-module de validation ou non du format des données, 54, « TFTP Tx » adapté notamment à valider le format des données reçues, ou à émettre des messages d'erreurs, via une liaison 60, vers le PC. Si les données reçues sont jugées valides (port correct, numéro de bloc cohérent, CRC, ...), alors le deuxième sous-module de supervision, 52, « Supervision Telech » donne l'ordre d'acquitter la trame courante au sous-module « TFTP Tx », ainsi que l'ordre, au bloc « IF Mémoire)> 5 d'envoyer, via son interface AXI4, avec le contrôleur mémoire, les données utiles du Bitstream. Dans le cas contraire, il configure le sous-module « TFTP Tx » pour envoyer un message d'erreur, conformément au protocole TFTP. Le quatrième sous-module, 54, « TFTP Tx » envoie les messages d'erreurs ou d'acquittement en fonction des requêtes reçues du sous-module 10 « Supervision Telech ». Sur ordre du deuxième sous-module « Supervision Telech », le troisième sous-module « IF Memoire » transmet, sur son interface standardisée de type AXI4 (abrégé anglo-saxon de Advanced eXtensible Interface), les données utiles, le Bitstream, issu des messages de données 15 d'écriture du protocole TFTP. La figure 6 illustre dans un diagramme temporel, le séquencement du téléchargement du Bitstream et les activités sur les interfaces de la fonction CBETH. La requête en écriture, 60, indique le début du téléchargement du 20 Bitstream, l'acquittement de la requête en écriture, 61, après contrôle du format des données, déclenche le chargement des données dans le bloc IF Memoire. Le schéma indique une séquence de téléchargement des données en mémoire par une succession de chargement de données 62, 64, 66, d'acquittement de données 63, 65, 67, tant que toutes les données n'ont pas 25 été chargées dans la mémoire non volatile. Le procédé selon l'invention présente l'avantage de ne pas nécessiter l'utilisation d'outils spécifiques sur un ordinateur distant pour l'envoi du Bitstream, les client TFTP intégrés au OS Windows ou Linux 30 suffisent. Il n'est pas nécessaire de développer une architecture spécifique au sein du FPGA. Il suffit d'intégrer dans l'Application FPGA la fonction CBETH et de la connecter à un périphérique de type Ethernet. Le débit de téléchargement des Bitstreams dépend uniquement de la bande passante de la mémoire de stockage du Bitstream en fonctionnement normal. Ils peuvent atteindre plusieurs dizaines de Mbits/s. REVENDICATIONS1 - Système pour le chargement de données au sein d'un composant programmable (30) comprenant au moins une mémoire non volatile (31), à partir d'un calculateur (43), d'une liaison standard de type Ethernet et d'une fonction CBETH caractérisé en ce que la fonction CBETH comporte au moins les éléments suivants : - un premier module (35) de gestion de protocole de la liaison standard entre le calculateur (43) et le composant programmable (30), - un deuxième module (34) comprenant un premier module (51) de contrôle du format des données transmises par le calculateur (43), un deuxième module (52) adapté à gérer les étapes du début de téléchargement des données, un troisième module (53) mémorisant les données avant leur transmission dans la mémoire non volatile connecté au composant programmable et un quatrième module (54) d'acquittement des messages. 2 - Système selon la revendication 1 caractérisé en ce que le composant programmable (30) est un composant programmable de type FPGA (Field 20 Programmable Gate Array). 3 - Système selon l'une des revendications 1 ou 2 caractérisé en ce que le deuxième module (34) implémente le protocole TFTP. 25 4 - Système selon l'une des revendications 1 ou 2 caractérisé en ce que la fonction CBETH est codée en langage de description matériel, destinée à représenter le comportement ainsi que l'architecture d'un système électronique numérique, connu sous l'acronyme anglo-saxon HDL pour Hardware Description Language. 30 5 - Système selon l'une des revendications 1 à 4 caractérisé en ce que le premier module (35) de gestion de protocole est adapté à gérer le protocole UDP/IP et en ce que le deuxième module (34) de contrôle de téléchargement comprend un premier sous-module (51) adapté à analyser les datagrammes UDP reçus du module de gestion des protocoles UDP/IP, un deuxième sous-module de supervision (52) de requête d'écriture, un bloc mémoire ( 53), un quatrième sous-module de validation ou non du format des données (54). 6 - Système selon l'une des revendications précédentes caractérisé en ce que le calculateur (43) est un PC. 7 - Procédé pour charger des données dans une mémoire non volatile connectée à un composant programmable comprenant des ressources logiques configurables interconnectables entre elles, en utilisant un calculateur (43) et une liaison de type Ethernet caractérisé en ce qu'il utilise pour la mise à jour une fonction CBETH implémentée au sein dudit composant programmable (30), ladite fonction CBETH comprenant un premier sous-module (35) de gestion des protocoles et un deuxième sous-module, en exécutant au moins les étapes suivantes : a) transmettre les données à charger en mémoire non volatile connectée au composant programmable via la liaison de type Ethernet à un premier module de contrôle du format des données, b) tester si le format des données est correct, et si oui transmettre les données à une mémoire de stockage, dans le cas contraire, transmettre un message d'erreur vers le calculateur (43). 8 - Procédé selon la revendication 7 caractérisé en ce que l'on charge des données dans la mémoire connectée à un composant programmable FPGA. 9 - Procédé selon l'une des revendications 7 à 8 caractérisé en ce qu'il utilise le protocole TFTP pour contrôler le téléchargement des données. 10 - Procédé selon l'une des revendications 7 à 9 caractérisé en ce que l'on utilise un langage de description matériel, destinée à représenter le comportement ainsi que l'architecture d'un système électronique numérique, connu sous l'acronyme anglo-saxon HDL pour Hardware Description Language pour coder les données.