L’optimisation d’un système n’est plus possible en considérant le matériel et les logiciels séparément, selon une analyse publiée par Brian Bailey, rédacteur spécialisé dans les technologies EDA chez Semiconductor Engineering. Les charges logicielles évoluent à un rythme plus rapide que les cycles de développement des puces, tandis que l’énergie, les performances et la température sont devenues des facteurs interdépendants qui imposent une collaboration précoce entre les équipes logicielles et matérielles, plutôt qu’un transfert de la conception d’une équipe à l’autre après l’achèvement de chaque étape.
L’analyse examine le regain d’intérêt pour ce que l’on appelle la conception conjointe du matériel et des logiciels, mais dans des conditions différentes de celles qui prévalaient il y a environ 30 ans. À cette époque, les technologies disponibles n’étaient pas capables de faire une grande différence, et l’industrie s’est donc orientée vers l’assemblage et l’intégration de blocs IP préalablement documentés. Certains vestiges de l’approche précédente subsistent, comme la modélisation virtuelle et les modèles SystemC non temporisés ou approximativement temporisés, mais ces outils ne sont pas considérés comme suffisants à eux seuls pour représenter les charges de travail réalistes actuelles.
De la séparation des équipes aux modèles virtuels
Steve Roddy, directeur marketing chez Quadric, affirme que l’époque où l’équipe matérielle concevait son produit avant de le remettre à l’équipe des logiciels embarqués a pris fin il y a plus de deux décennies. La modélisation virtuelle s’est étendue au cours de la dernière décennie pour inclure les entrées physiques et les interfaces des capteurs, dans le cadre de ce que l’on appelle la modélisation du jumeau virtuel.
Mais le défi actuel est plus complexe : les systèmes sont devenus beaucoup plus grands et sont conçus pour des charges de travail définies par les logiciels, alors que l’itération logicielle est plus rapide que le développement matériel. La conception conjointe devient ainsi un processus dans lequel le matériel rattrape en permanence les logiciels. Arvind Srinivasan de Normal Computing estime que les couches d’abstraction qui séparaient historiquement les parties de la pile logicielle des parties de la pile matérielle ont contribué à gérer la complexité et à améliorer l’efficacité ainsi que la fiabilité du développement, mais que la nécessité d’extraire le maximum d’optimisation de chaque maillon de la chaîne d’outils, en particulier pour les charges de travail d’intelligence artificielle sensibles aux performances, modifie cet équilibre.
Pour traiter le problème, il faut comprendre plus largement le mot « architecture ». Celui-ci ne désigne pas uniquement la structure générale du système, ni l’architecture micro-architecturale et le jeu d’instructions, mais englobe également l’architecture logicielle et la charge qui sera effectivement exécutée. Andy Meier de Siemens EDA affirme que le choix de l’architecture doit partir de l’application ou de la charge de travail, ainsi que de la manière dont cette charge influe sur la structure du système, les instructions et les différents éléments qu’il contient.
Le retour de la spécialisation sous l’impulsion de l’énergie
L’analyse s’appuie sur une observation de Tsugio Makimoto, qui occupait le poste de directeur technique chez Sony au cours des années 1990, concernant l’évolution de l’industrie par vagues entre spécialisation et généralisation. Après une période durant laquelle les processeurs généralistes ont dominé de vastes secteurs, les exigences du calcul en périphérie, puis des centres de données, ont commencé à pousser vers des solutions plus spécialisées.
Dans les appareils périphériques, la motivation est liée à l’allongement de l’autonomie de la batterie dans les limites de puissance disponibles. Dans les centres de données, la densité énergétique et la chaleur limitent désormais les options disponibles pour exécuter les charges de travail d’intelligence artificielle. Par conséquent, les unités de traitement généralistes, à elles seules, ne constituent plus la réponse ; il devient nécessaire de disposer de centres de données hétérogènes intégrant plusieurs types de puces, avec une répartition ou une agrégation des charges selon les caractéristiques de chaque puce.
Patrick Coles, scientifique en chef chez Normal Computing, indique que les unités de traitement graphique ne sont peut-être pas l’aboutissement de l’évolution du calcul, alors que les indices attestant l’élargissement du rôle des ASIC se multiplient. Frank Schirrmeister de Synopsys explique également que les entreprises de calcul hyperscale développent leurs propres puces et accélérateurs afin d’optimiser conjointement des indicateurs clés de performance, comme les performances et la consommation énergétique, plutôt que de se concentrer uniquement sur la vitesse.
La spécialisation n’est toutefois pas seulement une décision technique. Il faut déterminer le niveau de personnalisation qui justifie son coût économique et vérifier s’il apportera des gains suffisants en matière de performances et d’énergie. Purna Mohanty, directeur général de SignatureIP, indique que la complexité des spécifications peut rendre le client lui-même incapable d’exprimer précisément ce qu’il souhaite. Cela impose un alignement continu entre le fournisseur d’IP et les besoins des clients, tout en équilibrant les avantages des solutions prêtes à l’emploi et les gains liés au développement de nouvelles fonctionnalités.
RISC-V, exemple d’une personnalisation liée à la charge de travail
RISC-V apparaît dans l’analyse comme un exemple de l’orientation vers les « puces conçues pour la charge de travail ». Les entreprises développent des extensions personnalisées pour les cœurs afin d’améliorer les performances ou la consommation énergétique, mais ces extensions nécessitent également des éléments de l’écosystème, comme les compilateurs et les outils d’intégration logicielle.
Andrea Gallo, directrice générale de RISC-V International, explique que l’utilisation d’instructions personnalisées fait supporter à l’entreprise l’intégralité du coût total de possession, y compris la chaîne d’outils et l’intégration logicielle. Cette approche peut constituer un moyen rapide d’innover, mais l’entreprise peut ensuite chercher à transformer l’extension en norme, de sorte que le coût de sa maintenance soit réparti au sein de l’écosystème plus large. L’analyse indique également que la connaissance préalable de la charge logicielle permet d’adapter les éléments de traitement à l’application, tandis que les moteurs de calcul généralistes et évolutifs restent importants pour l’exécution de logiciels inconnus ou changeants.
L’énergie et la chaleur élargissent le champ de la conception conjointe
L’impact de la conception conjointe ne se limite pas aux performances. Les ingénieurs logiciels peuvent comprendre l’importance de l’énergie, mais ils ne disposent pas toujours des outils leur permettant de mesurer suffisamment tôt l’impact de leurs décisions. Les équipes travaillent donc à fournir des données de consommation énergétique pendant le développement des logiciels, en parallèle du matériel, et à améliorer des indicateurs tels que les TOPS par watt, plutôt que les seuls TOPS bruts.
La difficulté s’accroît dans les applications hétérogènes qui comprennent plusieurs niveaux de mémoire cache, ainsi que d’autres fonctions comme le test intégré de la conception DFT, car l’énergie et les performances doivent également être analysées dans le cadre d’une charge réaliste incluant ces fonctions. Lorsque l’analyse s’étend à la thermique, aux interférences électromagnétiques et aux aspects multiphysiques, la réunion des équipes matérielles et logicielles devient une nouvelle unité à laquelle s’ajoutent des analyses multiphysiques.
Certains participants à l’analyse envisagent la possibilité d’utiliser l’intelligence artificielle pour comprendre les relations complexes entre le matériel, les logiciels, l’énergie et les performances. Cela nécessite toutefois des données décrivant la quantité d’énergie consommée par les logiciels à différents niveaux, de la puce et du serveur jusqu’au rack, au véhicule et au centre de données. En attendant la disponibilité de solutions matures pilotées par l’intelligence artificielle, il pourrait continuer à être nécessaire de combiner des IP et de choisir différents degrés de spécialisation.
La discussion sur les extensions matricielles de RISC-V montre qu’une solution unique ne convient pas à tous les usages : une petite extension peut réduire la consommation énergétique, tandis qu’un ensemble plus large de registres, d’opérations et d’accumulateurs offre un débit plus élevé, au prix toutefois d’une plus grande surface de silicium et d’une consommation énergétique accrue. Le choix dépend finalement de la manière dont les cœurs, les accélérateurs et la charge cible sont répartis. L’analyse conclut que la voie vers l’intégration verticale est encore loin d’être achevée, mais qu’elle est devenue une orientation nécessaire pour aligner la conception sur les logiciels, l’énergie et les performances dans les systèmes modernes.