Dans le développement des systèmes sur puce (SoC), la plupart des problèmes détectés en fin de cycle ne sont pas dus à des IP défectueuses ou à une logique RTL incorrecte. Ils résultent d’hypothèses d’intégration qui échouent silencieusement lorsque le logiciel commence à s’exécuter sur du matériel réel.
Il ne s’agit pas d’une observation marginale, mais d’une réalité récurrente dans tous les projets SoC. À mesure que la complexité des conceptions augmente, la vérification du matériel en isolation ne suffit plus. Un système sur puce ne devient fonctionnel qu’une fois que le logiciel en prend le contrôle ; l’interaction entre le matériel et le logiciel doit donc être vérifiée de manière explicite et précoce.
C’est précisément l’objectif de la co-vérification matériel-logiciel.
La réflexion au niveau ASIC ne s’applique pas à la vérification des systèmes sur puce
La vérification ASIC et la vérification des systèmes sur puce traitent des problèmes fondamentalement différents.
Un ASIC est généralement conçu pour remplir une fonction unique et clairement définie. Le logiciel, lorsqu’il est présent, joue un rôle minime. La vérification peut donc se concentrer principalement sur l’exactitude du RTL, la conformité au protocole et les cas limites au niveau des blocs. Le champ d’application de la vérification est bien délimité.
Un système sur puce bouleverse complètement ce modèle. Il intègre des processeurs, des mémoires, des interconnexions et des périphériques dans un système qui ne fonctionne pas sans logiciel. La vérification ne consiste plus à s’assurer que les blocs individuels se comportent correctement de manière isolée. Il s’agit de s’assurer que l’ensemble du système se comporte correctement lorsqu’il est contrôlé par un logiciel embarqué.
Considérer un SoC comme un grand ASIC est l’une des erreurs de vérification les plus courantes, et cela conduit presque toujours à des surprises lors de la mise en service.
Deux approches de vérification et leurs limites pratiques
La vérification au niveau système commence généralement par des stimuli générés par un banc de test. Les transactions sont générées en externe. Les IP de vérification injectent du trafic dans l’interconnexion du SoC tandis que le CPU est contourné. Cette approche est intéressante car elle est plus simple à mettre en œuvre et plus rapide en simulation, et elle permet de réutiliser des scénarios de test existants au niveau IP.
Au cours des premières phases d’intégration, cette approche est utile. Cependant, ses limites sont bien connues. Dès que le comportement du système dépend de l’exécution du CPU, des séquences de démarrage, de la gestion des interruptions ou de la logique des pilotes, les stimuli générés par le banc de test cessent d’être représentatifs. La couverture de vérification peut sembler bonne, alors que des comportements clés au niveau système restent totalement non testés.
C’est là que les stimuli pilotés par logiciel deviennent essentiels. En exécutant un véritable logiciel embarqué sur le CPU, le SoC est testé d’une manière qui reflète fidèlement son cas d’utilisation final. Les flux de démarrage peuvent être vérifiés et les interruptions peuvent être déclenchées. Les interactions complexes entre le logiciel et les périphériques peuvent être validées.
La simulation devient plus lente et le débogage plus complexe, mais cette complexité reflète la réalité du système. L’éviter n’élimine pas les problèmes d’intégration ; cela ne fait que les repousser.
Ce que signifie réellement la co-vérification hardware-software
La co-vérification hardware-software ne consiste pas à vérifier le matériel et le logiciel séparément. Il s’agit plutôt de vérifier leur interaction en tant que système unifié, dès les premières étapes du cycle de développement.
En validant le fonctionnement du logiciel embarqué sur le matériel RTL lors de la simulation, les équipes peuvent détecter les problèmes d’intégration avant que la conception ne soit figée sur silicium ou contrainte par des prototypes FPGA. Ce cycle de rétroaction précoce constitue la principale valeur ajoutée de la co-vérification.
Dans la pratique, la co-vérification hardware-software permet également un développement en parallèle. Pendant que les ingénieurs matériel finalisent le RTL, les ingénieurs logiciels peuvent déjà écrire et valider le micrologiciel et les pilotes par rapport à un modèle de système réaliste. Les risques d’intégration sont traités en continu plutôt que d’être découverts à la fin.
Les principes fondamentaux qui ne peuvent être considérés comme des détails
Une co-vérification hardware-software efficace repose sur des bases solides en matière d’embarqué.
Le flux de compilation, depuis le code source C jusqu’au prétraitement, à la compilation, à l’assemblage et à la liaison, détermine directement la manière dont le processeur exécute les instructions. Les choix relatifs à la segmentation de la mémoire ont une incidence sur le comportement au démarrage, la gestion des interruptions et le débogage. Ces aspects ne sont pas des détails d’implémentation logicielle ; ils font partie intégrante de l’architecture du système.
Le code de démarrage est un élément critique de cette architecture. Exécuté immédiatement après la réinitialisation, il initialise le pointeur de pile, les registres, la mémoire et les vecteurs d’interruption avant de transférer le contrôle au logiciel principal. Si le code de démarrage est incorrect, le processeur peut ne jamais atteindre l’application. Les défaillances sont alors souvent interprétées à tort comme des problèmes matériels.
Les scripts de l’éditeur de liens jouent un rôle tout aussi important. Ils définissent la disposition de la mémoire du système. De même ils établissent la correspondance entre les tables d’adresses matérielles et le placement logiciel. L’expérience montre que de nombreux problèmes rencontrés lors des premières phases de mise en service proviennent de configurations incorrectes de l’éditeur de liens plutôt que de bogues au niveau du RTL.
Chargement du logiciel et observation des tests
Une fois le logiciel compilé, le fichier binaire généré doit être chargé en mémoire. Dans les environnements de co-vérification, cela peut se faire à l’aide d’un chargeur d’amorçage, d’une interface JTAG, de circuits intégrés de vérification (IP) ou d’un accès direct à la mémoire via une porte dérobée. Au cours des premières phases de simulation, le chargement via une porte dérobée est souvent privilégié. Il est en effet déterministe et indépendant de l’infrastructure non vérifiée.
Une fois l’exécution du logiciel lancée, les résultats des tests doivent être observables depuis le banc de test. Il est risqué de s’appuyer trop tôt sur des interfaces telles que UART ou GPIO. Ces IP peuvent ne pas avoir encore été vérifiées.
C’est pourquoi de nombreuses équipes s’appuient sur un mécanisme de porte dérobée basé sur la mémoire. Le logiciel écrit des informations d’état telles que des codes de réussite, d’échec ou d’erreur, à des emplacements spécifiques de la mémoire. Le banc de test accède directement à ces emplacements via une porte dérobée et évalue le résultat. Cette approche permet des tests entièrement automatisés et auto-vérifiables sans dépendance vis-à-vis d’interfaces externes.
Débogage de logiciels dans une simulation RTL
Le débogage de logiciels exécutés dans une simulation RTL nécessite une approche différente de celle du débogage sur du matériel physique. Les débogueurs traditionnels ne sont souvent pas disponibles, mais la simulation offre une visibilité complète sur les signaux du processeur.
En surveillant le compteur de programme, les registres à usage général et les registres de contrôle/état dans la forme d’onde, et en corrélant les valeurs du compteur de programme avec le désassemblage généré à partir du fichier ELF, les ingénieurs peuvent déterminer exactement quelles instructions sont exécutées et pourquoi. Cette méthode nécessite de l’expérience, mais elle fournit des informations qu’il est souvent impossible d’obtenir sur du silicium réel.
Les équipes qui développent ces compétences en débogage traitent généralement les problèmes d’intégration plus rapidement, et non plus lentement.
La simulation et les FPGA sont complémentaires
La simulation reste la plateforme de référence pour la co-vérification hardware-software. Elle offre en effet une observabilité complète et un contrôle précis sur l’exécution du système. Les plateformes basées sur des FPGA complètent la simulation lorsque la vitesse d’exécution ou l’interaction avec du matériel réel devient nécessaire.
Les stratégies de vérification efficaces utilisent les deux plateformes au moment opportun plutôt que de les considérer comme des alternatives.
Conclusion
La co-vérification hardware-software combine la vérification RTL et la vérification des logiciels embarqués afin de valider le comportement du système sur puce (SoC) au niveau système. Elle permet de détecter rapidement les problèmes d’intégration et facilite la validation de cas d’utilisation réalistes. Elle accélère le développement en permettant aux équipes matériel et logiciel de travailler en parallèle.
À mesure que la complexité des SoC ne cesse de croître, la vérification du matériel seul ne suffit plus. Vérifier l’interaction entre le matériel et le logiciel est le véritable objectif, et la co-vérification hardware-software est le moyen le plus efficace d’y parvenir.