FR 3155930 A1 20250530 FR 2313251 A 20231129 Procédé de conception automatique d’un processeur spécialisé pour exécuter au moins un programme, comprenant des étapes au cours desquelles : a. on accède (110) au code source ou à un exécutable binaire du programme, b. on réalise (120) une analyse du code source ou de l’exécutable binaire pour obtenir des paramètres de conception de processeur, c. on encode (140) les paramètres de conception dans une structure de données de paramètres de conception et on enregistre (150) la structure de données de paramètres de conception, et d. on génère (160) une topologie de processeur à partir de la structure de données des paramètres de conception par l’intermédiaire d’un modèle d’apprentissage automatique. Figure pour l’abrégé : Fig 1 Procédé de conception automatique de processeurs L’invention a pour domaine technique la conception de processeurs, et plus particulièrement la conception automatique de processeurs. Techniques antérieures Les processeurs actuels comprennent une importante collection d’éléments de traitement pour supporter une diversité d’applications. Ces processeurs sont typiquement conçus et testés lors de procédés multi-étapes impliquant plusieurs étapes de conception et plusieurs ingénieurs spécialisés. Une modularité complète de la conception du processeur est généralement difficile à obtenir sans impliquer une variété d’éléments de conception, propriétaires ou open source. Les concepteurs de processeurs implémentent généralement une architecture de jeu d’instructions ISA (acronyme anglophone pour « Instruction Set Architecture ») dans un langage de description de matériel HDL (acronyme anglophone pour « Hardware Description Language ») de bas-niveau ou dans un langage de construction de matériel HCL (acronyme anglophone pour « Hardware Construction Language ») de haut-niveau. On rappelle qu’un langage de description de matériel HDL est un langage informatique spécialisé utilisé pour décrire la structure et le comportement de circuits électroniques, et notamment de circuits logiques digitaux. Malgré la disponibilité de logiciels de conception électronique par ordinateur EDA (acronyme anglophone pour « Electronic Design Automation ») tant commerciaux qu’Open Source, la conception de processeurs personnalisés pour au moins une application demande généralement des temps particulièrement longs à des équipes d’ingénieurs spécialisés. Il existe donc un besoin pour une conception de processeur adapté à une application logicielle ne faisant pas appel à une équipe d’ingénieurs spécialisés et présentant des temps de traitement significativement plus courts. La réduction des couts et des durées de conception d’un processeur est cruciale pour un prototypage rapide, permettant de réaliser des tests et des itérations de conception rapides afin de réduire la durée avant commercialisation tant de processeurs génériques que spécialisés. Il existe également un besoin pour que la conception de processeur soit rendue accessible à un utilisateur non expert. Il existe enfin un besoin pour une finesse d’adaptation d’un processeur lors de la conception. Un objet de l’invention est un procédé de conception automatique d’un processeur spécialisé pour exécuter au moins un programme, comprenant des étapes au cours desquelles : a. on accède au code source ou à un exécutable binaire du programme, b. on réalise une analyse du code source ou de l’exécutable binaire pour obtenir des paramètres de conception de processeur, c. on encode les paramètres de conception dans une structure de données de paramètres de conception et on enregistre la structure de données de paramètres de conception, et d. on génère une topologie de processeur à partir de la structure de données des paramètres de conception par l’intermédiaire d’un modèle d’apprentissage automatique. Pour analyser le code source ou l’exécutable binaire, on peut réaliser des étapes au cours desquelles : a. on utilise un désassembleur d’exécutable binaire pour obtenir le code assembleur à partir d’un exécutable binaire, l’exécutable binaire étant directement disponible ou obtenu par l’intermédiaire d’une étape de compilation d’un code source, b. on obtient des métriques d’exécution et des statistiques d’exécution d’un logiciel de simulation appliqué à l’exécutable binaire, et c. on convertit les métriques d’exécution et/ou les statistiques d’exécution obtenues en paramètres de conception de processeur puis on les formate dans une structure de données. Pour réaliser la génération de topologie de processeur, on réalise des étapes au cours desquelles : a. on génère une première topologie d’un processeur à partir de l’analyse du code source ou de l’exécutable binaire et des paramètres de conception de processeur et on initialise le nombre d’itérations de conception d’une topologie de processeur, b. on détermine les paramètres de conception pour la topologie de processeur générée par inférence d’un réseau de neurones d’un module d’apprentissage automatique entrainé sur une base de données prédéterminée, c. on détermine si la topologie du processeur n’est pas satisfaisante au vu d’une consigne de performance prédéfinie et si le nombre d’itérations de conception d’une topologie de processeur est inférieur à un nombre limite d’itérations d. si tel est le cas, on détermine des paramètres de retour supplémentaires par l’intermédiaire du module d’apprentissage automatique appliqué aux paramètres de conception de processeur de l’utilisateur, on enregistre les paramètres de retour dans la base de données d’entrainement du réseau de neurones du module d’apprentissage automatique, on entraine de nouveau le réseau de neurones avec la base enrichie puis on génère une nouvelle topologie de processeur basée sur les paramètres de retour et le procédé reprend à l’étape de détermination de paramètres de conception pour la nouvelle topologie de processeur générée, e. si tel n’est pas le cas, la topologie du processeur est conservée. Le processeur peut être généré à travers une implémentation en langage de description matérielle. Lorsque l’on détermine que la topologie du processeur n’est pas satisfaisante au vu d’au moins une consigne de performance prédéfinie, et que la consigne de performance n’est pas une consigne de conception de l’utilisateur, on peut procéder à une étape d’exploration de l’espace de conception, au cours de laquelle on détermine au moins deux topologies de processeur avec différentes consignes de PPA, puis l’utilisateur choisit une topologie. Pour générer une première topologie d’un processeur, on peut réaliser les étapes suivantes : a. on accède à la structure de données des paramètres de conception encodés b. on détermine des valeurs de paramètres de conception du processeur en parcourant les paramètres de conception encodés, c. on convertit ensuite les valeurs des paramètres de conception en des valeurs des paramètres d’entrée d’un générateur de processeur, d. on génère une structure de données de routage-placement du processeur à partir de valeurs des paramètres d’entrée déterminés. Pour générer des paramètres de retour supplémentaires, on peut réaliser les étapes suivantes : a. on génère un kit de développement logiciel à partir de la structure de données de niveau de routage-traçage du processeur, b. on génère une structure de données d’émulation d’un réseau de portes programmables in situ à partir de la structure de données de niveau de routage-traçage du processeur et du kit de développement logiciel, c. on génère un plan de test basé sur les paramètres de conception et sur au moins un critère d’acceptance fonction de la consigne de performance prédéfinie, d. on obtient des paramètres de retour supplémentaires comme des résultats de test selon le plan de test. La consigne de performance prédéfinie peut comprendre un critère de performance de traitement du processeur spécialisé, un critère de puissance consommée par le processeur spécialisé et un critère de surface occupée par le processeur spécialisé, le au moins un critère d’acceptance correspondant à un seuil d’au moins un des critères de la consigne de performance ou un critère d’une combinaison algébrique d’au moins deux des critères de la consigne de performance. Le module d’apprentissage automatique peut être de type à apprentissage supervisé. Le module d’apprentissage automatique supervisé peut comprendre un réseau de neurones en graphe, notamment un réseau de neurones en graphe pré-élagué. Les topologies de processeur peuvent être générées à travers une implémentation en langage de description matérielle. D’autres buts, caractéristiques et avantages de l’invention apparaîtront à la lecture de la description suivante, donnée uniquement à titre d’exemple non limitatif et faite en référence aux dessins annexés sur lesquels : La figure FIG. 1 illustre les principales étapes d’un procédé de conception selon l’invention, Les figures FIG. 2 et FIG. 2 illustrent les principales sous-étapes d’une analyse de code source ou d’exécutable binaire afin d’obtenir des paramètres de conception de processeur. La figure FIG. 3 illustre les principales sous-étapes de de génération de processeur, La figure FIG. 4 illustre les principales sous-étapes de génération d’une première topologie d’un processeur, et La figure FIG. 5 illustre les principales sous-étapes associées à la détermination de données de paramètres supplémentaires. Description détaillée Les systèmes et méthodes de génération automatique d’architecture de processeurs à partir d’un code source ou d’un exécutable binaire permettent à un unique utilisateur de générer une architecture et d’itérer sur cette architecture en spécifiant des paramètres de conception de processeurs. Même un utilisateur qui n’est pas un expert en architecture logicielle peut utiliser ces systèmes et méthodes afin de développer une architecture de processeur. Le système automatise ainsi tant la conception de processeurs que la vérification des processeurs ainsi obtenus par l’intermédiaire d’outils de conception électronique par ordinateur EDA (acronyme anglophone pour « Electronic Design Automation ») tant commerciaux qu’Open Source. Cette automatisation de l’utilisation d’outils de conception électronique assistée par ordinateur permet d’accomplir en quelques heures ou minutes ce qui prenait des temps considérablement plus longs à des équipes d’ingénieurs spécialisés muni d’outils EDA spécialisés. La figure FIG. 1 illustre les principales étapes d’un procédé de conception automatique de processeur selon l’invention. Au cours d’une première étape 110, on accède au code source ou à un exécutable binaire d’un programme. Par exemple, le code source d’un programme peut être écrit en langage de haut niveau tel que du Python, ou dans des langages de bas niveau tels que les langages C/C++. L’exécutable binaire peut être généré avec un compilateur produisant un exécutable portable PE (acronyme anglophone pour « portable executable »), un exécutable simple, un exécutable au format extensible et liable (acronyme « ELF » en langue anglaise), un exécutable au format objet-mach (« Mach-O » en langue anglaise) ou des formats d’exécutables similaires. Au cours d’une deuxième étape 120, on réalise une analyse du code source ou de l’exécutable binaire pour obtenir des paramètres de conception de processeur. L’analyse de code source peut être automatisée avec des outils open source tels que Capstone ou avec des outils commerciaux tels que Binary Ninja. L’analyse de code source ou d’exécutable binaire est décrite plus en détail en relation avec les figures FIG. 2 et FIG. 2 . Au cours d’une troisième étape 130, on accède à des paramètres de conception de processeur. Dans un mode de réalisation particulier, les paramètres de conception du processeur sont des paramètres de conception du processeur de l’utilisateur. Par exemple, un utilisateur peut sélectionner des paramètres de conception spécifiques parmi un jeu de paramètres de conception (en d’autres termes, un paramètre de conception est une instruction exécutable par un processeur ou un composant de microarchitecture). Un paramètre de conception spécifique peut également être un plan de conception (par exemple, une puissance consommée à ne pas dépasser, une performance à atteindre, ou une surface occupée par le processeur à ne pas dépasser). La sélection des paramètres est réalisée notamment par l’intermédiaire d’une interface graphique ou d’une interface web. On encode ensuite les paramètres de conception dans une structure de données de paramètres de conception au cours d’une étape 140. Les paramètres de conception peuvent être encodés au format JSON (acronyme anglophone pour « JavaScript Object Notation ») ou une représentation de données similaires. Au cours d’une étape 150, on enregistre la structure de données de paramètres de conception, localement sur un support de données volatiles, sur un support de données non volatiles, ou à distance sur un serveur ou dans un environnement distant délocalisé de type dans le nuage (« in the cloud » en langue anglaise). Au cours d’une étape 160, on génère une topologie de processeur à partir de la structure de données des paramètres de conception. La figure FIG. 2 illustre un premier mode de réalisation de l’étape 120 d’analyse de code source ou d’exécutable binaire afin d’obtenir des paramètres de conception de processeur. Dans ce mode de réalisation, un code source est disponible en entrée de l’étape 120. L’étape 120 comprend alors une première sous étape 210a au cours de laquelle on compile le code source, par l’intermédiaire d’outils de compilation traditionnellement utilisés tels que GCC ou LLVM. Il est à noter que ce mode de réalisation est avantageux par rapport au deuxième mode de réalisation illustré par la figure FIG. 2 dans la mesure où il est possible d’extraire davantage d’informations sur le contexte d’exécution du programme ou de l’applicatif. Il est par conséquent possible de générer un processeur plus adapté à un applicatif donné (meilleur ratio performance/consommation/surface). Ces informations peuvent également être utilisées en complément de l’entrée de la sous-étape 230. La figure FIG. 2 illustre un deuxième mode de réalisation de l’étape 120 d’analyse de code source ou d’exécutable binaire afin d’obtenir des paramètres de conception de processeur. Dans ce mode de réalisation, un exécutable binaire est disponible en entrée de l’étape 120. L’étape 120 comprend une alors première sous-étape 210b au cours de laquelle on obtient un code source lisible à partir d’un exécutable binaire par l’intermédiaire d’un décompileur d’exécutable binaire. Un exemple de décompileur d’exécutable binaire est la bibliothèque d’exécutable au format extensible et liable LIEF (acronyme anglophone pour « library to instrument executable formats ») qui est une bibliothèque permettant décompiler un grand nombre de formats d’exécutables, notamment ELF, PE, Mach-O. Une telle bibliothèque permet de parcourir l’exécutable binaire et d’accéder à son contenu, c’est-à-dire aux sections qu’il comprend. Quel que soit le mode de réalisation, l’étape 120 se poursuit par les sous-étapes suivantes. Au cours d’une deuxième sous-étape 220, on utilise un désassembleur d’exécutable binaire pour obtenir le code assembleur du code source compilé lors de la première étape 210a dans le premier mode de réalisation ou de l’exécutable binaire parcouru lors de la première sous-étape 210b dans le deuxième mode dé réalisation. On citera notamment le logiciel Capstone comme exemple d’un tel désassembleur d’exécutable binaire. D’autres logiciels peuvent bien entendu être employés. Au cours d’une troisième sous-étape 230, on obtient des métriques d’exécution et des statistiques d’exécution d’un logiciel de simulation appliqué à l’exécutable binaire. Un tel logiciel de simulation peut être notamment Quick Emulator (« acronyme QEMU »), Spike ou riscvOVPsim. D’autres logiciels de simulation peuvent être bien entendu utilisés. Le logiciel de simulation peut être configuré pour utiliser un profileur logiciel déterministe (dans une approche de traçage) ou pour utiliser un profileur statistique (dans une approche d’échantillonnage). Pour réaliser cela, le profileur logiciel Prof5 peut notamment être employé. Les métriques et statistiques d’exécution peuvent également comprendre des informations issues de l’analyse du code source préalablement compilé lors de l’étape 210a. Au cours d’une quatrième sous-étape 240, les métriques d’exécution et/ou les statistiques d’exécution obtenues sont converties en paramètres de conception de processeur et formatés dans une structure de données. Les métriques/statistiques sont des paramètres qui sont codées au format de fichier d’échange de données (JSON). Elles sont directement utilisées comme paramètres génériques du code RTL du processeur pour en générer sa topologie. Cela peut (selon les classes d’applicatifs) réduire d’autant la surface silicium du processeur, sa consommation, tout en augmentant potentiellement sa fréquence de fonctionnement, et cela sans réduire ses performances calculatoires. Il est à noter que cela n’altère en aucun cas la sémantique du programme. Le code source obtenu à la sous-étape 210 permet de contextualiser l’exécution du programme. Les métriques/statistiques d’exécution d’un applicatif indiquent typiquement les instructions utilisées, leur fréquence d’apparition, leur enchainement. On manipule le programme dans le but de supprimer, substituer ou réordonner les instructions pour en réduire les instructions et/ou les transactions mémoires nécessaires à l’exécution du programme. La figure FIG. 3 illustre les principales sous-étapes de l’étape 160 de génération de processeur. Un module d’apprentissage automatique (également appelé « machine learning » en langue anglaise) comprenant un modèle d’apprentissage automatique est notamment employé pour itérer sur une topologie de processeur initiale afin d’en affiner les paramètres en fonction des paramètres de conception choisis. Le module d’apprentissage automatique peut être notamment de type à apprentissage supervisé. Il peut s’agir notamment d’un réseau de neurones en graphe GNN (acronyme anglophone pour « Graph Neural Network »). Un tel réseau de neurones en graphe peut être réalisé à partir de bibliothèques open source telles que PyTorch et/ou TensorFlow. L’entrainement du module d’apprentissage s’effectue à l’aide d’une base de données dynamique. Cette base évolue avec les paramètres de conception (éventuellement les paramètres de conception de l’utilisateur, le code source du processeur ou le routage du processeur) et les paramètres de conception déterminés lors des itérations successives qui sont destinées à converger vers un optimum local ou global d’une topologie de processeur. L’entrainement du réseau de neurones est effectué de façon optimisée, c’est-à-dire à partir du GNN pré-élagué pour réduire la densité des matrices. La réduction du nombre de paramètres du modèle GNN s’accompagne d’un stockage efficace par compression des matrices d’adjacence du graphe. Par exemple, le format Yale Sparse Matrix peut être employé dans ce but. Les réseaux de neurones de type GNN utilisent des graphes denses et cette optimisation permet de limiter l’impact de l’entrainement du réseau de neurones en termes de ressources calculatoires et d’utilisation mémoire Le module d’apprentissage automatique peut nécessiter des informations additionnelles telles que des consignes de plans de conception (par exemple, PPA) pour un ou plusieurs paramètres. Lors d’une première sous-étape 310, on génère une première topologie d’un processeur à partir de l’analyse du code source ou de l’exécutable binaire et des paramètres de conception de processeur de l’utilisateur déterminés lors des étapes 120 et 130. La génération de la topologie d’un premier processeur est décrite plus en détail en relation avec la figure FIG. 4 . On initialise également le nombre d’itérations de conception d’une topologie de processeur. Au cours d’une deuxième sous-étape 320, on détermine les paramètres de conception pour la topologie de processeur générée à l’étape précédente. La détermination des paramètres de conception s’effectue par l’inférence du réseau de neurones du module d’apprentissage appliqué à la topologie de processeur générée. Au cours d’une troisième sous-étape 325, on détermine si la topologie du processeur est satisfaisante au vu d’au moins une consigne de performance prédéfinie. Dans sa forme la plus élémentaire, la consigne de performance est définie comme une valeur spécifique (seuil) à atteindre ou à ne pas dépasser pour au moins l’un des critères du PPA. Par exemple, le processeur généré ne doit pas dépasser une consommation de 100 milliwatts. Il peut également s’agir d’une consigne multicritères. Par exemple, on recherche un processeur présentant une consommation de 50 mW au maximum, d’une surface de 0.1 mm² au maximum et d’une fréquence de fonctionnement de 100 MHz au moins. Dans un mode de réalisation particulier, si cette consigne n’est pas définie par l’utilisateur, on procède à une étape d’exploration de l’espace de conception, c’est-à-dire une proposition d’un ensemble d’architectures de processeur avec différentes consignes de PPA. Par exemple, on propose un processeur faible consommation, haute fréquence, faible surface, etc.. La sélection finale de l’architecture qui convient le mieux est faite par l’utilisateur. Les processeurs sont typiquement synthétisés (code RTL vers description en portes logique), placés et routés sur une technologie FPGA et/ou ASIC à l’aide d’un ensemble d’outils spécifiques (open source ou commerciaux). Ces outils ne convergent pas nécessairement vers un optimum en une seule itération. Après chaque itération, on extrait les résultats d’intérêt (métrique) des rapports générés par des outils. On compare également le nombre d’itérations de conception d’une topologie de processeur à un nombre limite d’itérations. Si la topologie n’est pas satisfaisante au vu de la au moins une consigne de performance prédéfinie et si le nombre d’itérations de conception d’une topologie de processeur est inférieur à un nombre limite d’itérations, le procédé se poursuit par une quatrième sous-étape 330, au cours de laquelle on détermine des paramètres de retour supplémentaires par l’intermédiaire d’un module d’apprentissage automatique appliqué aux paramètres de conception de processeur de l’utilisateur. Le procédé se poursuit par une cinquième sous-étape 340 au cours de laquelle on génère une nouvelle topologie de processeur basée sur les paramètres de retour déterminés à la quatrième sous-étape 330. La nouvelle topologie est déterminée de manière similaire à la détermination de la première topologie obtenue à l’issue de la première sous-étape 310, en utilisant le module d’apprentissage automatique. La base de données (« dataset » en langue anglaise) du module d’apprentissage automatique est enrichie avec les paramètres de conception de processeur générés à chaque itération. Le réseau de neurones du module d’apprentissage automatique est ensuite de nouveau entrainé avec cette base de données enrichie. Les inférences (les traitements de données par le réseau de neurones) successives bénéficient alors de ce nouvel entrainement. Dans un mode de réalisation particulier, on modifie les consignes de conception lorsque l’utilisateur souhaite faire une exploration de l’espace de conception pour se voir proposer des compromis portant sur les consignes de PPA, ou lorsque les consignes de l’utilisateur ne permettent pas au réseau de neurones de converger vers la solution souhaitée. Le procédé reprend alors à la deuxième étape sous-étape 320 appliquée à la nouvelle topologie de processeur obtenue à l’issue de la cinquième sous-étape 340. Si on a déterminé, au cours de la troisième sous-étape 325, que la topologie du processeur est satisfaisante au vu de la au moins une consigne de performance prédéfinie ou si le nombre d’itérations de conception d’une topologie de processeur n’est pas inférieur à un nombre limite d’itérations, le sous-procédé se termine par une sixième sous-étape 350, et la topologie du processeur est conservée. La figure FIG. 4 illustre les principales sous-étapes comprises dans l’étape 310 de génération d’une première topologie d’un processeur à partir de l’analyse du code source ou de l’exécutable binaire et des paramètres de conception de processeur de l’utilisateur. Cette génération implique la création d’une structure de données de type RTL (Acronyme anglophone pour « Register Transfer Level », niveau de routage-traçage en langue française) permettant de définir le comportement d'un circuit en termes d'envois de signaux ou de transferts de données entre registres. Elle permet de définir également les opérations logiques effectuées sur ces signaux. Au cours d’une première sous-étape 410, on accède à la structure de données des paramètres de conception encodés déterminée lors l’étape 140. Au cours d’une deuxième sous-étape 420, on détermine des valeurs de paramètres de conception du processeur en parcourant les paramètres de conception encodés. On convertit ensuite les valeurs des paramètres de conception en des valeurs des paramètres d’entrée d’un générateur de processeur, lors d’une troisième sous-étape 430. On obtient une structure de données du code source RTL du processeur en appliquant un générateur de processeur aux valeurs des paramètres d’entrée déterminés, lors d’une quatrième sous-étape 440. Il est à noter que les logiciels HCL (acronyme anglophone pour « Hardware Control Language ») tels que Migen génèrent du code RTL sans hiérarchie (c’est-à-dire sans relation visible entre les différents composants du processeur). Un tel code source RTL est « difficile à comprendre » voir ininterprétable par un ingénieur. Par contraste, le générateur de processeur proposé ici, utilise comme entrée un code source Python de manière similaire à Migen mais génère un processeur entièrement lisible et modifiable aisément par un ingénieur du domaine. Le code source RTL généré est également hiérarchique et permet une intervention lors des étapes de positionnement précis des composants du processeur (terme anglophone « floorplanning »). Le processeur peut être généré à travers une implémentation HCL travers des logiciels tel Migen ou assimilés. Par exemple, la génération de la structure de données du code source RTL peut comprendre d’exécuter un code Python pour lire la structure de données de paramètres de conception et générer dynamiquement un graphique de conception de processeur. La figure FIG. 5 illustre les principales sous-étapes associées à la détermination de paramètres de retour supplémentaires de la quatrième sous-étape 330. On génère ensuite un kit de développement logiciel SDK (acronyme anglophone pour « Software Development Kit ») à partir du processeur RTL, lors d’une première sous-étape 510. Le SDK est généré de façon automatique après analyse du code source (s’il est disponible), de l’exécutable binaire et du code source RTL du processeur. Le kit de développement logiciel peut comprendre un compilateur, un assembleur, au moins un fichier d’entête, au moins une bibliothèque, au moins un chargeur d’amorce, au moins un pilote de noyau, une couche d’abstraction matérielle HAL (acronyme anglophone pour « Hardware Abstraction Layer ») et/ou d’autres outils pour un environnement de traitement totalement fonctionnel. On génère une structure de données d’émulation d’un réseau de portes programmables in situ FPGA (acronyme anglophone pour « Field Programmable Gate Array ») à partir du processeur RTL et du kit de développement logiciel SDK, lors d’une deuxième sous-étape520. On pourra notamment utiliser des outils tels que Yosys pour la synthèse de la structure de données du code source RTL, Verilator pour la simulation de la structure de données du code source RTL, nextpnr pour le placement-routage, OpenFPGA loader pour charger le flux binaire FPGA sur un FPGA cible. Pour rappel, le placement-routage est une étape de conception d’un processeur visant à déterminer le placement des différents composants électroniques en fonction du résultat logique attendu décrit dans les données du code source RTL. Au cours d’une troisième sous-étape 530, on génère un plan de test basé sur les paramètres de conception et sur au moins un critère d’acceptance. Un critère d’acceptance est défini en fonction d’au moins un des paramètres utilisateurs. A titre d’exemple, la fréquence de fonctionnement du processeur peut être un critère d’acceptance, comme la surface silicium utilisée, la consommation énergétique et/ou les performances calculatoires du processeur. On réalise ensuite des tests basés sur le plan de test, lors d’une quatrième sous-étape 540. Les résultats des tests peuvent être employés en tant que paramètres de retour additionnels pour le module d’apprentissage automatique lors de la sous-étape 340. Ces tests permettent de nouveau d’extraire des métriques à la fois de conception et d’exécution du programme sur le processeur généré. Ces métriques enrichissent la base de données (« dataset ») d’entrainement du réseau de neurones employé par l’apprentissage automatique. Par exemple, le plan de test pour la conception de processeur peut comprendre d’utiliser des FPGA. Procédé de conception automatique d’un processeur spécialisé pour exécuter au moins un programme, comprenant des étapes au cours desquelles : on accède au code source ou à un exécutable binaire du programme, on réalise une analyse du code source ou de l’exécutable binaire pour obtenir des paramètres de conception de processeur, on encode les paramètres de conception dans une structure de données de paramètres de conception et on enregistre la structure de données de paramètres de conception, et on génère une topologie de processeur à partir de la structure de données des paramètres de conception par l’intermédiaire d’un modèle d’apprentissage automatique. Procédé de conception automatique d’un processeur spécialisé selon la revendication 1, dans lequel, pour analyser le code source ou l’exécutable binaire, on réalise des étapes au cours desquelles : on utilise un désassembleur d’exécutable binaire pour obtenir le code assembleur à partir d’un exécutable binaire, l’exécutable binaire étant directement disponible ou obtenu par l’intermédiaire d’une étape de compilation d’un code source, on obtient des métriques d’exécution et des statistiques d’exécution d’un logiciel de simulation appliqué à l’exécutable binaire, et on convertit les métriques d’exécution et/ou les statistiques d’exécution obtenues en paramètres de conception de processeur. Procédé de conception automatique d’un processeur spécialisé selon la revendication 1 ou 2, dans lequel, pour réaliser la génération de topologie de processeur, on réalise des étapes au cours desquelles : on génère une première topologie d’un processeur à partir de l’analyse du code source ou de l’exécutable binaire et des paramètres de conception de processeur et on initialise un nombre d’itérations de conception d’une topologie de processeur, on détermine des paramètres de conception pour la topologie de processeur générée par inférence d’un réseau de neurones d’un module d’apprentissage automatique entrainé sur une base de données prédéterminée, on détermine si la topologie du processeur n’est pas satisfaisante au vu d’une consigne de performance prédéfinie et si le nombre d’itérations de conception d’une topologie de processeur est inférieur à un nombre limite d’itérations si tel est le cas, on détermine des paramètres de retour supplémentaires par l’intermédiaire du module d’apprentissage automatique appliqué aux paramètres de conception de processeur de l’utilisateur, on enregistre les paramètres de retour dans la base de données d’entrainement du réseau de neurones du module d’apprentissage automatique, on entraine de nouveau le réseau de neurones avec la base enrichie puis on génère une nouvelle topologie de processeur basée sur les paramètres de retour et le procédé reprend à l’étape de détermination de paramètres de conception pour la nouvelle topologie de processeur générée, si tel n’est pas le cas, la topologie du processeur est conservée Procédé de conception automatique d’un processeur spécialisé selon la revendication 3, dans lequel, lorsque l’on détermine que la topologie du processeur n’est pas satisfaisante au vu d’au moins une consigne de performance prédéfinie et que la consigne de performance n’est pas une consigne de conception de l’utilisateur, on procède à une étape d’exploration de l’espace de conception, au cours de laquelle on détermine au moins deux topologies de processeur avec différentes consignes de performance prédéfinie, puis l’utilisateur choisit une topologie. Procédé de conception automatique d’un processeur spécialisé selon la revendication 3 ou 4, dans lequel, pour générer une première topologie d’un processeur, on réalise les étapes suivantes : on accède à la structure de données des paramètres de conception encodés on détermine des valeurs de paramètres de conception du processeur en parcourant les paramètres de conception encodés, on convertit ensuite les valeurs des paramètres de conception en des valeurs des paramètres d’entrée d’un générateur de processeur, on génère une structure de données de routage-placement du processeur à partir de valeurs des paramètres d’entrée déterminés. Procédé de conception automatique d’un processeur spécialisé selon la revendication 5, dans lequel, pour générer des paramètres de retour supplémentaires, on réalise les étapes suivantes : On génère un kit de développement logiciel à partir de la structure de données de niveau de routage-traçage du processeur, On génère une structure de données d’émulation d’un réseau de portes programmables in situ à partir de la structure de données de niveau de routage-traçage du processeur et du kit de développement logiciel, on génère un plan de test basé sur les paramètres de conception et sur au moins un critère d’acceptance fonction de la consigne de performance prédéfinie, on obtient des paramètres de retour supplémentaires comme des résultats de test selon le plan de test. Procédé de conception automatique d’un processeur spécialisé selon la revendication 6, dans lequel la consigne de performance prédéfinie comprend un critère de performance de traitement du processeur spécialisé, un critère de puissance consommée par le processeur spécialisé et un critère de surface occupée par le processeur spécialisé, le au moins un critère d’acceptance correspondant à un seuil d’au moins un des critères de la consigne de performance ou un critère d’une combinaison algébrique d’au moins deux des critères de la consigne de performance. Procédé de conception automatique d’un processeur spécialisé selon l’une quelconque des revendications 3 à 7, dans lequel le module d’apprentissage automatique est de type à apprentissage supervisé. Procédé de conception automatique d’un processeur spécialisé selon la revendication 8, dans lequel le module d’apprentissage automatique supervisé comprend un réseau de neurones en graphe, notamment un réseau de neurones en graphe pré-élagué. Procédé de conception automatique d’un processeur spécialisé selon l’une quelconque des revendications 1 à 9, dans lequel, les topologies de processeur sont générées à travers une implémentation en langage de description matérielle.