FR 3155928 A1 20250530 FR 2313253 A 20231129 Procédé de conception assistée par ordinateur d’un processeur spécialisé conçu pour exécuter une application spécifique en fonction d’une requête de performance du processeur spécialisé définie par un utilisateur, comprenant les étapes suivantes : a. on accède (101,102) au code source de l’application spécifique et du banc de test logiciel, c. on accède (103,104) à des paramètres de conception du processeur spécialisé et à la requête de performance, e. on génère (110) un rapport comprenant un jeu d’instructions optimal et des paramètres de performance, de puissance consommée et de surface associés, f. on génère (130) un jeu d’instructions optimal final et un rapport sur les paramètres de performance, de puissance consommée et de surface du processeur spécialisé associés à ce jeu d’instructions optimal final, et g. on génère (150) un outil de compilation et un outil de conversion, h. on conçoit le processeur spécialisé en fonction du jeu d’instructions optimal final, et on génère un fichier binaire final. Figure pour l’abrégé : Fig 1 Procédé de conception d’un processeur spécialisé assisté par ordinateur 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. Un processeur généraliste peut comprendre un jeu d’instructions complexe. On parle alors d’architecture CISC (acronyme anglophone pour « complex instruction-set computer »). Lorsqu’une application est exécutée sur un tel processeur généraliste, beaucoup d’instructions comprises dans ce processeur ne sont pas utilisées. En effet, de tels processeurs sont conçus pour pouvoir exécuter tout type d’applications sur une empreinte mémoire minimale et doivent donc comprendre une large sélection d’instructions adaptées à ces différents types d’applications. Cela implique que l’occupation du processeur est supérieure à celle d’un processeur spécialisé ne comprenant que les instructions nécessaires à l’application exécutée. Cela a également un impact sur la puissance consommée par le processeur, qui est plus importante pour garder accessibles ces instructions inutilisées. Cette occupation du processeur inutilement plus grande implique aussi un chemin critique plus grand et naturellement une limitation de la fréquence d’utilisation et donc une performance dégradée. C’est sur ce constat qu’a été développée l’architecture RISC (acronyme anglophone pour « Reduced Instruction Set Computer »), dans laquelle un nombre d’instructions de l’architecture CISC ont été supprimées pour être remplacées par des instructions émulées logiciellement à partir d’instructions plus simples. Dans le cas d’une architecture RISC-V, les instructions sont regroupées en extensions, chaque extension prenant en charge certaines opérations comme la multiplication, l’addition, la compression de code ou encore la manipulation de bits pour n’en citer que quelques-unes. Toutes les instructions peuvent être émulées à partir de quelques instructions I et deux instructions A. La conception d’un processeur implique une étape d’optimisation entre la performance, la puissance consommée et la surface occupée. La performance d’un processeur permet de déterminer sa capacité de traitement ou de calcul, et est généralement exprimée en opérations en virgule flottante par seconde (acronyme anglophone « FLOPS » pour « floating-point operations per second »). Elle dépend également de l’efficacité des instructions et/ou du type d’instructions compris dans le jeu d’instructions du processeur (acronyme anglophone ISA, « Instruction set Architecture »). La puissance consommée permet de déterminer l’énergie nécessaire au fonctionnement du processeur ainsi que ses besoins en refroidissement et est généralement exprimée en Watts. La surface occupée illustre la taille du processeur, et, indirectement son coût. En effet, les processeurs sont gravés sur des galettes de silicium (« wafers » en langue anglaise). Le coût de fabrication de processeurs, pour un procédé de fabrication donné, est calculé par galette de silicium. Toutefois, le nombre de processeurs par galette de silicium et donc le coût de revient par processeur dépend de la surface occupée par chaque processeur. Plus le processeur occupe une surface faible, plus le nombre de processeurs par galette de silicium augmente et plus le coût unitaire diminue. Ces trois grandeurs sont dépendantes les unes des autres. Par exemple, la puissance peut être augmentée en ajoutant des instructions. Cependant, cela augmente la puissance consommée et la surface occupée. Par opposition, lorsque certaines instructions sont émulées logiciellement, on peut réduire la surface occupée, et, dans certains cas, réduire la puissance consommée. Cependant, une telle émulation consomme des cycles de calcul, ce qui diminue la puissance du processeur. Plusieurs centaines de sélections différentes d’instructions peuvent exister pour un même algorithme, ce qui rend le choix de la combinaison d’instructions particulièrement compliqué en lui-même. Une fois combiné à la prise en compte de la puissance consommée et de la surface occupée, le nombre de possibilités devient colossal. 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 afin de déterminer le compromis performance, puissance consommée, surface occupée, dit compromis PPA (acronyme anglophone pour « Performance, Power, Area »). Il existe donc un besoin pour une conception de processeur adaptée à 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. 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. L’invention a pour objet un procédé de conception d’un processeur spécialisé assisté par ordinateur, ledit processeur spécialisé comprenant un jeu d’instructions optimisé et étant conçu en fonction d’une requête de performance définie par un utilisateur pour exécuter une application spécifique de manière optimisée, comprenant les étapes suivantes : a. on accède au code source de l’application spécifique, b. on accède au code source de banc de test logiciel, c. on accède à des paramètres de conception du processeur spécialisé, d. on accède à la requête de performance définie par l’utilisateur, e. on génère un rapport comprenant un jeu d’instructions optimal à implémenter dans le processeur spécialisé pour l’application considérée ainsi que les paramètres de performance, de puissance consommée et de surface du processeur spécialisé correspondant à ce jeu d’instructions optimal en fonction des paramètres de conception du processeur spécialisé et des exigences de performance, de puissance consommée et de surface du processeur spécialisé définies dans la requête de performance définie par l’utilisateur, f. si le rapport sur les paramètres de performance est satisfaisant, on peut considérer le jeu d’instructions optimal comme un jeu d’instructions optimal final, g. si le rapport sur les paramètres de performance n’est pas satisfaisant, le procédé reprend à l’étape d’accès aux exigences de performance, de puissance consommée et de surface du processeur spécialisé définies par l’utilisateur, avec de nouvelles exigences, h. on génère ensuite une chaine de compilation et un outil de conversion permettant de convertir les instructions d’une application prévues pour être exécutée sur un processeur généraliste en instructions compréhensibles par le processeur spécialisé, i. on conçoit le processeur spécialisé en fonction du jeu d’instructions optimal final, et j. on génère un fichier binaire final compatible avec le processeur spécialisé afin d’exécuter des applications. On peut accéder à un fichier binaire initial en lieu et place du code source, et on accède alors à un fichier d’édition de lien en même temps que l’on accède au fichier binaire initial, le fichier binaire final étant alors généré sur la base du fichier binaire initial, du fichier d’édition de lien et de l’outil de conversion. Pour générer un rapport, on peut réaliser les sous-étapes suivantes : a. on génère un dictionnaire associant à un jeu d’instructions la performance, la puissance consommée, la surface occupée déterminés par simulation et les éléments logiques partagés avec une autre instruction, le dictionnaire étant initialisé avec des valeurs alliant en entrée au moins deux jeux d’instructions réparti pour contenir à la fois des familles d’instructions presque complètes et presque vides, b. à l’aide du dictionnaire, on réalise une optimisation linéaire pour déterminer des localisations des zones avec les meilleurs jeux d’instructions donnant des paramètres de performance, de puissance consommée et de surface du processeur spécialisé satisfaisant au mieux la requête de performance définies par l’utilisateur, c. on enrichit le dictionnaire avec des entrées supplémentaires déterminées à l’issue de l’optimisation linéaire et situées dans les zones avec les meilleurs jeux d’instructions, d. on réalise un apprentissage machine sur le dictionnaire enrichi afin d’estimer le jeu d’instructions optimal, puis on réalise une simulation des paramètres de performance, de puissance consommée et de surface occupée en fonction du jeu d’instructions optimal et on enrichit le dictionnaire avec les paramètres de performance, de puissance consommée et de surface occupée déterminés, e. si un seul jeu d’instructions optimal a été déterminé, le procédé reprend à l’étape d’enrichissement du dictionnaire, si tel n’est pas le cas on détermine si le au moins un jeu d’instructions optimal ont suffisamment convergé par rapport à au moins un seuil de convergence prédéterminé fonction d’un critère à maximiser parmi la performance, la puissance consommée et la surface occupée dont la contrainte est à privilégier sur les autres, le critère à maximiser étant compris dans la requête de performance, et f. Si tel est le cas, on retient le jeu d’instructions comme jeu d’instructions optimal final et on génère un rapport comprenant le jeu d’instructions optimal final et les paramètres de performance, de puissance consommée et de surface du processeur spécialisé ajustés par une simulation précise. Pour déterminer si les jeux d’instructions optimaux du dictionnaire ont suffisamment convergés au vu de la requête de performance de l’utilisateur, on peut réaliser les étapes suivantes : on compare le critère à maximiser actuel avec le au moins un critère à maximiser de la au moins une occurrence précédente, on détermine l’écart du critère à maximiser actuel avec le critère à maximiser de l’occurrence précédente et on détermine la dérivée de l’écart du critère à maximiser par rapport au numéro d’itérations, puis on considère avoir trouvé le jeu d’instructions optimal lorsque l’écart du critère à maximiser actuel avec le critère à maximiser de l’occurrence précédente est inférieur à un seuil de convergence prédéterminé et lorsque la dérivée de l’écart du critère à maximiser par rapport au numéro d’itération est négative ou nulle. La requête de performance définie par l’utilisateur peut comprendre au moins une exigence parmi une exigence de performance, une exigence de puissance consommée et/ou une exigence de surface occupée, chaque exigence étant exprimée soit comme une valeur limite définissant une gamme de valeurs ouverte bornée d’un côté par la valeur limite, comme une gamme de valeurs délimitée par deux valeurs limites. La requête de performance définie par l’utilisateur comprend une relation mathématique fonction d’au moins deux exigences parmi une exigence de performance, une exigence de puissance et/ou une exigence de surface occupée. Après avoir déterminé un jeu d’instructions optimal final et avant de générer une chaine de compilation et un outil de conversion, on peut déterminer au moins un jeu d’instructions optimal alternatif, en insérant au moins une variation dans la requête de performance définie par l’utilisateur, et en exécutant de nouveau les étapes du procédé de conception automatique d’un processeur spécialisé jusqu’à l’étape de génération une chaine de compilation et un outil de conversion, cette étape n’étant pas réalisée, la détermination du jeu d’instructions optimal final tenant compte du même critère à maximiser que lors de la détermination du jeu d’instructions optimal final, puis on soumet le jeu d’instructions optimal final et le au moins un jeu d’instructions optimal alternatif à l’utilisateur pour choix, l’utilisateur étant alors en mesure de décider si un compromis sur une des exigences de sa requête de performance permet d’obtenir un résultat inattendu préférable au résultat obtenu avec le jeu d’instructions optimal final. 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 d’un processeur spécialisé assisté par ordinateur selon l’invention, et la figure FIG. 2 illustre les principales sous-étapes comprises dans la génération d’un rapport comprenant un jeu d’instructions optimal à implémenter dans un processeur spécialisé pour l’application considérée ainsi que les paramètres de PPA correspondant à ce jeu d’instructions optimal. Description détaillée La figure FIG. 1 illustre un procédé de conception d’un processeur spécialisé assisté par ordinateur permettant de générer un fichier binaire compatible avec un jeu d’instructions optimisé définissant un processeur spécialisé et conçu pour exécuter une application spécifique en fonction d’une requête de performance de l’utilisateur comprenant des exigences de performance, de puissance consommée et de surface du processeur spécialisé. La requête de performance définie par l’utilisateur comprend au moins une exigence parmi une exigence de performance, une exigence de puissance consommée et/ou une exigence de surface occupée. Chaque exigence comprise dans la requête est exprimée soit comme une valeur limite définissant une gamme de valeurs ouverte bornée d’un côté par la valeur limite, comme une gamme de valeurs délimitée par deux valeurs limites. On peut ainsi limiter la puissance consommée par le processeur spécialisé mais laisser les exigences de performance de calcul et de surface occupée, libres de prendre toute valeur. On peut également définir une gamme de valeurs au moins une des exigences. Par exemple, on peut définir une gamme de valeurs pour la puissance consommée et la surface occupée, tout en laissant la performance prendre n’importe quelle valeur. On comprend évidement que, quand une valeur n’est pas associée à une exigence, le procédé de conception tentera d’obtenir la meilleure valeur possible. Pour la puissance consommée et la surface occupée, cela implique d’obtenir la valeur la plus faible possible. Pour la performance de calcul, il s’agira d’obtenir la valeur la plus importante possible. La requête de performance peut comprendre également une fonction mathématique ayant comme paramètre au moins deux des exigences parmi une exigence de performance de traitement du processeur spécialisé, une exigence de puissance consommée par le processeur spécialisé et une exigence de surface occupée par le processeur spécialisé. Lorsque la requête de performance comprend une telle fonction mathématique, elle peut elle-même être associée à une valeur limite ou à une gamme de valeurs. Au cours d’une première étape 101, on accède au code source d’une application pour laquelle on cherche à concevoir un processeur spécialisé. Au cours d’une deuxième étape 102, on accède au code source de banc de test logiciel dont l’exécution fournit les indicateurs clés de performance. Le banc de test logiciel est un code en C/C++ pour évaluer les performances du processeur. Ce logiciel peut évaluer par exemple le nombre de cycles d’horloge nécessaires pour exécuter un traitement lourd prédéfini. Au cours d’une troisième étape 103, on accède à des paramètres de conception du processeur spécialisé. Les paramètres de conception du processeur spécialisé peuvent comprendre, le protocole de cache, la taille du cache, le nombre de niveaux de cache. Chacun de ces paramètres a un impact sur les performances, la puissance consommée ou la surface occupée du processeur correspondant. Au cours d’une quatrième étape 104, on accède aux requêtes de performance définies par l’utilisateur. Par requêtes de performance définies par l’utilisateur, on entend des requêtes PPA (Performance, Puissance consommée, Surface occupée), c’est-à-dire une requête comprenant une exigence de performance, une exigence de puissance consommée et/ou une exigence de surface occupée. Les requêtes PPA peuvent concerner au moins une exigence parmi une exigence de performance, une exigence de puissance consommée et/ou une exigence de surface occupée. Chaque exigence peut être exprimée comme une valeur limite définissant une gamme de valeurs ouverte bornée d’un côté par la valeur limite. Chaque exigence peut également être exprimée comme une gamme de valeurs délimitée par deux valeurs limites. Enfin, les requêtes PPA peuvent également être définies comme une relation mathématique entre au moins deux exigences parmi une exigence de performance, une exigence de puissance et/ou une exigence de surface occupée. Dans tous les cas, on définit en plus un critère à maximiser parmi la performance, la puissance consommée et surface occupée dont la contrainte est à privilégier sur les autres. Les étapes 101 à 104 peuvent être réalisées partiellement ou totalement de façon séquentielle et/ou parallèle. Le procédé se poursuit ensuite par une cinquième étape 110, au cours de laquelle on génère un rapport comprenant un jeu d’instructions optimal à implémenter dans le processeur spécialisé pour l’application considérée ainsi que les paramètres de PPA correspondant à ce jeu d’instructions optimal. L’étape 110 est illustrée par la figure FIG. 2 et décrite plus en détail plus loin dans la présente description. Au cours d’une étape 115, l’utilisateur détermine si le rapport est satisfaisant en comparant les paramètres de PPA correspondant à ce jeu d’instructions optimal à la requête de performance définie par l’utilisateur. Dans un mode de réalisation particulier, à la lumière des résultats (rapport obtenu à l’issue de l’étape 110) déjà fournis, l’utilisateur peut rapidement évaluer un autre compromis PPA. Si le rapport n’est pas satisfaisant, le procédé reprend à l’étape 104 avec la soumission d’une nouvelle requête de performance par l’utilisateur. Si le rapport est satisfaisant, le procédé se poursuit à l’étape 120 au cours de laquelle on considère que le jeu d’instructions optimal déterminé à l’étape 110 est satisfaisant. On considère alors le jeu d’instructions optimal comme le jeu d’instructions final. Au cours d’une étape 130, on génère ensuite une chaine de compilation et un outil de conversion permettant de convertir les instructions d’une application prévues pour être exécutée sur un processeur généraliste en instructions compréhensibles par le processeur spécialisé. En d’autres termes, l’outil de conversion permet de faire correspondre les instructions de l’application à des instructions équivalentes comprises dans le jeu d’instructions final. Au cours d’une étape 150, on génère le fichier binaire final définissant le processeur spécialisé à partir du code source fourni à l’étape 101 et de la chaine de compilation générée à l’étape 130. Dans un mode de réalisation particulier, un fichier binaire initial est utilisé en lieu et place du code source lors de la première étape 101. On accède alors à un fichier d’édition de lien en même temps que l’on accède au fichier binaire initial lors de la première étape 101. Le fichier binaire final est alors généré sur la base du fichier binaire initial, du fichier d’édition de lien et de l’outil de conversion généré à l’étape 130. On considère que le processeur spécialisé est conçu sur la base du jeu d’instructions optimal final. Le processeur spécialisé peut être fabriqué sur la base de ce jeu d’instructions optimal final. La figure FIG. 2 illustre les principales sous-étapes comprises dans l’étape 110 de génération d’un rapport. Au cours d’une première sous-étape 220, on génère un dictionnaire sous la forme d’un tableau associatif avec en entrée ou clé un jeu d’instructions. L’entrée du tableau associatif (sa clé) est un jeu d’instruction. Les paramètres PPA, c’est-à-dire la performance, la puissance consommée, la surface occupée du processeur et les identificateurs des ressources logiques élémentaires communes utilisées par les instructions de même famille sont les valeurs (sorties) associées à chaque clé. Les ressources logiques élémentaires sont par exemple un additionneur, un comparateur, un registre à décalage. Elles sont très souvent communes à plusieurs instructions. Par exemple, l’additionneur est utilisé par toutes les instructions d’addition mais aussi par les instructions de branchement. Pour chaque entrée correspondant à un jeu d’instructions, on associe en sortie, les paramètres PPA de performance, de surface, et de consommation issus d’une simulation précise avec un outil externe. Pour chaque entrée, les paramètres PPA en sortie sont complétés avec une liste identifiant les unités de traitement générique utilisées, comme par exemple un additionneur ou un registre à décalage. Le dictionnaire ne contient pas un ensemble exhaustif de tous les jeux d’instructions possibles. En effet, l’obtention d’un tel ensemble exhaustif représenterait une quantité de données extrêmement importante nécessitant un temps de calcul significativement plus long que la durée de commercialisation des processeurs personnalisés obtenus, au vu des moyens de calculs actuels. Le choix des jeux d’instruction est réalisé afin de couvrir l’ensemble des jeux d’instructions de manière volontairement éparse. Au lieu de proposer toutes les combinaisons possibles à l’instruction près, pour chaque instruction similaire (comme les multiplications, les divisions, ...), on choisira un sous-jeu d’instructions très fragmentaire et un sous-jeu d’instructions presque complet. On remplira le dictionnaire avec toutes les combinaisons possibles de présence de ces sous-jeux d’instructions. Avec comme clé un jeu d’instructions réduit, on aura une surface faible, une performance faible et une consommation faible alors que pour un jeu d’instructions complet, on aura un résultat contraire (surface importante, performance importante et consommation importante). Au cours d’une deuxième sous-étape 240, on réalise une optimisation linéaire pour déterminer les meilleures combinaisons d’instructions donnant des paramètres de PPA satisfaisant au mieux la requête de performance définie par l’utilisateur auxquelles on a accédé lors de l’étape 104. A l’aide des paramètres PPA associés aux jeux d’instructions compris dans le dictionnaire, et de la liste identifiant les unités de traitement génériques utilisées pour chaque jeu d’instructions du dictionnaire, on peut, avec une régression linéaire, estimer les paramètres PPA de toutes les combinaisons possibles de jeux d’instruction ne se trouvant pas dans le dictionnaire. Avec un algorithme classique d’optimisation linéaire ou par méthode du simplexe, on peut rapidement évaluer les zones dans lesquelles les paramètres PPA seront optimaux selon les exigences de performance définis par l’utilisateur. Comme ceci est réalisé par approximation sans réaliser de simulations plus précises, ces résultats seront approximatifs et devront être ajustés par des simulations avec un outil externe. Au cours d’une troisième sous-étape 260, on enrichit le dictionnaire avec des entrées supplémentaires trouvées lors de la sous-étape 240. Au cours d’une quatrième sous-étape 270, on réalise un apprentissage machine afin de déterminer le jeu d’instructions optimal. Pour réaliser cela, l’apprentissage utilise le dictionnaire enrichi à l’issue de la troisième sous-étape 260 et estime le critère à maximiser, de manière plus précise qu’une optimisation linéaire. On complète le dictionnaire avec les nouvelles entrées trouvées par l’apprentissage machine en réalisant des simulations avec un outil externe. Au cours d’une sous-étape 275, on détermine si les jeux d’instructions optimaux du dictionnaire au vu de la requête de performance de l’utilisateur ont suffisamment convergé. Pour réaliser cela, on compare le critère à maximiser actuel avec le au moins un critère à maximiser de la au moins une occurrence précédente. On considère avoir trouvé le jeu d’instructions optimal lorsque l’écart du critère à maximiser est inférieur à un seuil de convergence prédéterminé et la dérivée de l’écart du critère à maximiser par rapport au numéro d’itérations est négative ou nulle. Si tel n’est pas le cas, le procédé reprend alors après l’étape 260 d’enrichissement. Si tel est le cas, le procédé se poursuit par une sixième sous-étape 280, au cours de laquelle on retient le jeu d’instructions comme jeu d’instructions optimal final et on génère un rapport comprenant le jeu d’instructions optimal final et les paramètres de PPA ajustés déterminés à la troisième sous-étape 260. Dans un mode de réalisation particulier, après avoir déterminé un jeu d’instructions optimal final, on détermine au moins un jeu d’instructions optimal alternatif, en insérant au moins une variation dans la requête de performance définie par l’utilisateur, en exécutant de nouveau l’intégralité des étapes du procédé. La détermination du jeu d’instructions optimal final tient compte du même critère à maximiser que lors de la détermination du jeu d’instructions optimal final. Le jeu d’instructions optimal final et le au moins un jeu d’instructions optimal alternatif sont alors soumis à l’utilisateur pour choix. L’utilisateur est alors en mesure de décider si un compromis sur une des exigences de sa requête de performance permet d’obtenir un résultat inattendu préférable au résultat obtenu avec le jeu d’instructions optimal final. Procédé de conception d’un processeur spécialisé assisté par ordinateur, ledit processeur spécialisé comprenant un jeu d’instructions optimisé et étant conçu en fonction d’une requête de performance définie par un utilisateur pour exécuter une application spécifique de manière optimisée, comprenant les étapes suivantes : on accède (101) au code source de l’application spécifique, on accède (102) au code source d’un banc de test logiciel, on accède (103) à des paramètres de conception du processeur spécialisé, on accède (104) à la requête de performance définie par l’utilisateur, on génère (110) un rapport comprenant un jeu d’instructions optimal à implémenter dans le processeur spécialisé pour l’application considérée ainsi que les paramètres de performance, de puissance consommée et de surface du processeur spécialisé correspondant à ce jeu d’instructions optimal en fonction des paramètres de conception du processeur spécialisé et des exigences de performance, de puissance consommée et de surface du processeur spécialisé définies dans la requête de performance définie par l’utilisateur, si le rapport sur les paramètres de performance satisfait la requête de performance définie par l’utilisateur, on considère le jeu d’instructions optimal comme un jeu d’instructions optimal final, si le rapport sur les paramètres de performance ne satisfait pas la requête de performance définie par l’utilisateur, le procédé reprend à l’étape d’accès aux exigences de performance, de puissance consommée et de surface du processeur spécialisé définies par l’utilisateur, avec de nouvelles exigences, on génère (150) ensuite une chaine de compilation et un outil de conversion permettant de convertir les instructions d’une application prévues pour être exécutée sur un processeur généraliste en instructions compréhensibles par le processeur spécialisé, on conçoit le processeur spécialisé en fonction du jeu d’instructions optimal final, et on génère un fichier binaire final compatible avec le processeur spécialisé afin d’exécuter des applications. Procédé de conception d’un processeur spécialisé assisté par ordinateur selon la revendication 1, dans lequel on accède à un fichier binaire initial en lieu et place du code source de l’application, et on accède alors à un fichier d’édition de lien en même temps que l’on accède au fichier binaire initial, le fichier binaire final étant alors généré sur la base du fichier binaire initial, du fichier d’édition de lien et de l’outil de conversion. Procédé de conception d’un processeur spécialisé assisté par ordinateur selon la revendication 1 ou 2, dans lequel, pour générer un rapport, on réalise les sous-étapes suivantes : on génère (220) un dictionnaire associant à un jeu d’instructions la performance, la puissance consommée, la surface occupée déterminés par simulation et les éléments logiques partagés avec une autre instruction, le dictionnaire étant initialisé avec des valeurs alliant en entrée au moins deux jeux d’instructions réparti pour contenir à la fois des familles d’instructions comprenant au moins une instruction émulée logiciellement, et des familles d’instructions comprenant au moins une instruction qui n’est pas émulée logiciellement, à l’aide du dictionnaire, on réalise (240) une optimisation linéaire pour déterminer des localisations des zones avec des jeux d’instructions donnant des paramètres de performance, de puissance consommée et de surface du processeur spécialisé dont l’écart avec la requête de performance définie par l’utilisateur est le plus faible, lesdits jeux d’instructions présentant l’écart le plus faible étant considérés comme les meilleurs jeux d’instructions, on enrichit (260) le dictionnaire avec des entrées supplémentaires déterminées à l’issue de l’optimisation linéaire et situées dans les zones avec les meilleurs jeux d’instructions, on réalise (270) un apprentissage machine sur le dictionnaire enrichi afin d’estimer le jeu d’instructions optimal, puis on réalise une simulation des paramètres de performance, de puissance consommée et de surface occupée en fonction du jeu d’instructions optimal et on enrichit le dictionnaire avec les paramètres de performance, de puissance consommée et de surface occupée déterminés, si un seul jeu d’instructions optimal a été déterminé, le procédé reprend à l’étape d’enrichissement du dictionnaire, si tel n’est pas le cas, on détermine (275) si le au moins un jeu d’instructions optimal est considéré comme ayant convergé par rapport à au moins un seuil de convergence prédéterminé fonction d’un critère à maximiser compris dans la requête de performance et dont la contrainte est à privilégier sur les autres, ladite contrainte étant choisie parmi la performance, la puissance consommée et la surface occupée, et si tel est le cas, on retient (280) le jeu d’instructions comme jeu d’instructions optimal final et on génère un rapport comprenant le jeu d’instructions optimal final et les paramètres de performance, de puissance consommée et de surface du processeur spécialisé ajustés par une simulation précise. Procédé de conception d’un processeur spécialisé selon la revendication 3, dans lequel, pour déterminer si les jeux d’instructions optimaux du dictionnaire sont considérés comme ayant convergé au vu de la requête de performance de l’utilisateur, on compare le critère à maximiser actuel avec le au moins un critère à maximiser de la au moins une occurrence précédente, on détermine l’écart du critère à maximiser actuel avec le critère à maximiser de l’occurrence précédente et on détermine la dérivée de l’écart du critère à maximiser par rapport au numéro d’itérations, puis on considère avoir trouvé le jeu d’instructions optimal lorsque l’écart du critère à maximiser actuel avec le critère à maximiser de l’occurrence précédente est inférieur à un seuil de convergence prédéterminé et lorsque la dérivée de l’écart du critère à maximiser par rapport au numéro d’itération est négative ou nulle. Procédé de conception d’un processeur spécialisé selon l’une quelconque des revendications 1 à 4, dans lequel la requête de performance définie par l’utilisateur comprend au moins une exigence parmi une exigence de performance, une exigence de puissance consommée et/ou une exigence de surface occupée, chaque exigence étant exprimée soit comme une valeur limite définissant une gamme de valeurs ouverte bornée d’un côté par la valeur limite, comme une gamme de valeurs délimitée par deux valeurs limites. Procédé de conception d’un processeur spécialisé selon l’une quelconque des revendications 1 à 5, dans lequel la requête de performance définie par l’utilisateur comprend une relation mathématique fonction d’au moins deux exigences parmi une exigence de performance, une exigence de puissance et/ou une exigence de surface occupée, la requête de performance définie par l’utilisateur. Procédé de conception d’un processeur spécialisé selon l’une quelconque des revendications 3 à 6, dans lequel, après avoir déterminé un jeu d’instructions optimal final et avant de générer une chaine de compilation et un outil de conversion, on détermine au moins un jeu d’instructions optimal alternatif, en insérant au moins une variation dans la requête de performance définie par l’utilisateur, et en exécutant de nouveau les étapes du procédé de conception automatique d’un processeur spécialisé jusqu’à l’étape de génération une chaine de compilation et un outil de conversion, cette étape n’étant pas réalisée, la détermination du jeu d’instructions optimal final tenant compte du même critère à maximiser que lors de la détermination du jeu d’instructions optimal final, puis on soumet le jeu d’instructions optimal final et le au moins un jeu d’instructions optimal alternatif à l’utilisateur pour choix, l’utilisateur étant alors en mesure de décider si un compromis sur une des exigences de sa requête de performance permet d’obtenir un résultat inattendu préférable au résultat obtenu avec le jeu d’instructions optimal final.