Lorsque j'étais dans l'industrie de l'EDA en tant que technologue, mon rôle comportait trois parties principales. La première consistait à informer les clients des nouvelles technologies en cours de développement et des extensions d'outils qui apparaîtraient dans la prochaine version. Il s’agissait de fonctionnalités qu’ils pourraient trouver utiles à la fois dans les projets qu’ils entreprenaient aujourd’hui et, plus encore, s’appliqueraient aux projets futurs. Deuxièmement, j'essayais de découvrir quels nouveaux problèmes ils rencontraient ou où les outils n'offraient pas les capacités dont ils avaient besoin. Cela alimenterait la planification du développement des outils. Et enfin, je prendrais les fonctionnalités sélectionnées par l'équipe marketing pour la mise en œuvre et j'essaierais de trouver la meilleure façon de les mettre en œuvre si cela n'était pas évident pour les équipes de développement.

La tâche de loin la plus difficile parmi les trois consistait à répondre aux nouvelles exigences des clients. La plupart des ingénieurs ont la tête baissée et se concentrent sur la sortie de leur dernière puce. Lorsque vous leur posez des questions sur les nouvelles fonctionnalités, la seule chose qu'ils proposent sont leurs problèmes actuels. Ceux-ci impliquent généralement des fonctionnalités ou des bogues incrémentiels, pour lesquels la solution de contournement n'est pas appréciée ou des performances insuffisantes.

Il y a trente ans, lorsque j'ai commencé à occuper ce poste, il existait des groupes de méthodologie dédiés au sein des grandes entreprises dont la tâche consistait à développer des flux et des méthodologies pour les projets futurs. Cela semble être la personne idéale à qui s'adresser, mais dans de nombreux cas, ils étaient tellement déconnectés de l'équipe de développement que ce qu'ils demandaient ne serait jamais réellement utilisé par l'équipe de développement. Ces groupes étaient des idéalistes qui voulaient inculquer des changements révolutionnaires, alors que les équipes de développement voulaient des outils évolutifs. La plupart de ces développements sont allés plus loin que des projets pilotes qui ne sont jamais devenus courants.

Il semble que l’industrie ait besoin d’une meilleure voie pour faire respecter les exigences des entreprises EDA. Auparavant, cela était défini par l'ITRS, qui anticipait et projetait les nouvelles capacités qui seraient requises et les délais pour celles-ci. Cela n'existe plus. Aujourd’hui, les normes sont imposées par les fabricants de semi-conducteurs. C'est un changement par rapport au passé, où l'on voyait les sociétés EDA diriger les développements réalisés au sein de groupes comme Accellera. Lorsque je regarde leurs initiatives récentes, la plupart d’entre elles sont motivées par les utilisateurs finaux.

La création d'un groupe de normalisation aujourd'hui se produit assez tard dans le processus. Cela implique un besoin immédiat, mais ne laisse pas vraiment le temps d’élaborer des solutions à l’avance. Il semble qu'un groupe de réflexion soit nécessaire, où l'industrie pourrait discuter des questions et des problèmes pour lesquels le développement de nouveaux outils est nécessaire. Cela peut ensuite être intégré aux feuilles de route de l’EDA afin que la technologie soit disponible lorsqu’elle est nécessaire.

L’un de ces domaines est l’analyse du pouvoir. J'ai écrit des histoires sur l'importance de la puissance et de l'énergie et qui pourraient bientôt devenir des limites pour bon nombre des conceptions les plus complexes. Certaines des questions que je pose toujours sont :

• Quels outils sont développés pour effectuer une analyse de puissance des logiciels ?
• Comment calculer l’énergie consommée pour une fonction donnée ?
• Comment les utilisateurs peuvent-ils optimiser une conception en termes de puissance ou d’énergie ?

J’obtiens rarement des réponses claires à l’une de ces questions. Au lieu de cela, on me donne souvent de vagues idées sur la manière dont un utilisateur pourrait procéder manuellement, compte tenu des outils actuellement disponibles.

Je commençais à penser que je me trompais d’arbre et peut-être que ces préoccupations n’étaient pas légitimes. Ma raison a été restaurée par un commentaire sur l’une de mes récentes histoires liées au pouvoir. Allan Cantle, chef du sous-projet OCP HPC à l'Open Compute Project Foundation, a écrit : « Bien qu'il soit formidable de voir des articles comme celui-ci souligner la nécessité pour nous tous de nous concentrer sur l'informatique centrée sur l'énergie, la triste nouvelle est que nos outils ne rendent pas compte l'énergie de manière évidente pour montrer les erreurs architecturales stupides que nous commettons souvent du point de vue de la consommation d'énergie. Nous résolvons tous les problèmes dans une perspective ascendante en rapprochant les choses. Bien que cela apporte d’énormes avantages en matière d’efficacité énergétique, cela crée également une densité énergétique considérablement croissante. Il y a tellement de fruits à portée de main issus d’une approche d’architecture système descendante que l’industrie manque parce que nous devons sortir des sentiers battus et au-delà de nos silos.

Cantle a poursuivi en disant : « Une amélioration triviale des outils qui signalent la consommation d'énergie comme mesure de premier ordre nous permettra de comprendre et de rectifier beaucoup plus facilement les erreurs que nous commettons lorsque nous construisons de nouveaux ordinateurs centrés sur l'énergie et spécifiques à un domaine pour chaque candidature. Alternativement, les dieux du silicium qui dirigent notre industrie feraient bien de faire un pas en arrière et de réfléchir au problème du point de vue des systèmes.

Je ne pourrais être plus d’accord et je trouve frustrant qu’aucune société EDA ne semble écouter. Je suis sûr qu'une partie du problème réside dans le fait que les gros clients travaillent sur leurs propres solutions internes et estiment que cela leur procurera un avantage concurrentiel. Jusqu'à ce qu'il devienne clair que tous leurs concurrents proposent des solutions similaires et qu'ils n'en tirent plus d'avantages, ils chercheront alors à transférer ces solutions aux sociétés EDA afin de ne pas avoir à les maintenir. Les sociétés d'EDA vont alors commencer à se battre pour faire de la solution qu'elles ont acquise le standard. Tout cela prend beaucoup de temps.

Pour défendre partiellement les sociétés d'EDA, elles sont confrontées à tellement de nouveaux problèmes ces jours-ci qu'elles sont très dispersées face aux nouveaux nœuds, 2.5D, 3D, shift left, multi-physique, algorithmes d'IA – pour n'en nommer que quelques-uns. Elles dépensent déjà plus en R&D que la plupart des entreprises technologiques en pourcentage de leurs revenus.

Peut-être qu'Accellera pourrait commencer à inclure des forums de discussion dans des événements comme DVCon. Cela permettrait une discussion ouverte sur les problèmes qu’ils doivent résoudre. Peut-être pourraient-ils commencer à produire l’équivalent EDA de l’ancienne feuille de route ITRS. Cela permettrait certainement d’économiser beaucoup de temps et d’énergie (jeu de mots).