Optimisation du développement logiciel pré-silicium

À l'ère de la technologie en évolution rapide d'aujourd'hui, l'approche la plus courante pour répondre aux besoins du marché est un système sur puce (SoC). Un SoC est essentiellement un processeur entouré d'accélérateurs de fonctions et de nombreuses E/S pour les périphériques associés qu'il prend en charge. Depuis la révolution des données mobiles en 2002, il est devenu indispensable d'utiliser des SoC pour faciliter les fonctionnalités clés qui définissent un smartphone. De la même manière, les SoC sont depuis devenus l'appareil incontournable pour créer des produits de consommation « intelligents » comme les téléviseurs, les voitures et le marché de l'Internet des objets (IoT) en constante expansion.

La demande croissante de SoC a créé un marché hautement concurrentiel. Pour cette raison, les SoC deviennent de plus en plus complexes, les périphériques des SoC évoluent en permanence et le délai de mise sur le marché diminue. Un élément crucial pour répondre aux complexités du développement de SoC est la disponibilité du logiciel. Il y a peu de place pour les erreurs et le logiciel doit être prêt dès que possible. Pour relever ce défi, le développement logiciel doit être initié avant la disponibilité de la partie SoC.

Développement de logiciels SoC

Traditionnellement, le développement du logiciel commençait après l'arrivée du premier échantillon de silicium de la fabrication. Lorsque les échantillons de SoC sont arrivés, les équipes de logiciels et de validation ont commencé leurs activités de développement, et un gros effort de mise en place de SoC a été lancé. Les équipes travaillant sur le SoC convergeraient du monde entier pour être sous un même toit pendant une durée limitée afin de prendre en charge la mise en place du SoC.

Le développement du logiciel prenait généralement des mois après l'arrivée du premier échantillon avant qu'il ne soit prêt pour la production. Pendant ce temps, la validation du silicium serait terminée, ce qui donnerait une confiance limitée pour lancer la production en série des produits associés.

Cependant, en raison de la complexité croissante de la conception du SoC, ce qui prendrait normalement des mois de développement logiciel peut désormais s'étendre sur des années avant que le logiciel ne soit prêt pour la production. Le nombre croissant de périphériques pris en charge et l'évolution de ces périphériques ont également créé des lacunes dans l'expertise en la matière. Les équipes logicielles seraient tenues de combler ces lacunes particulières en recrutant de nouveaux développeurs ayant une expertise dans ces domaines (audio, vidéo, USB, Ethernet, etc.).

Pour être en mesure de fournir un logiciel prêt pour la production au début du projet, le développement logiciel ne peut pas attendre que le premier échantillon de silicium soit disponible. Une approche décalée vers la gauche doit être adoptée lorsque le développement logiciel commence le plus tôt possible et, mieux encore, en même temps que commence la conception matérielle du SoC. Le développement de logiciels pré-silicium peut également aider à identifier les bogues de mise en œuvre du SoC et potentiellement réduire le coût des correctifs métalliques ou des masques complets. Plusieurs méthodologies sont envisagées pour répondre à ces exigences.

Approches de développement pré-silicium

Pour démarrer le développement de logiciels avant la sortie de bande SoC, les développeurs peuvent utiliser quelques approches telles que le prototypage logiciel, le banc de test RTL, les cartes FPGA, les émulateurs matériels, etc. Étant donné que ces approches se concentrent généralement sur des modules individuels, chacune de ces approches a ses propres défis puisque l'objectif est de développer un logiciel pour l'affichage de l'ensemble du SOC plutôt que des modules individuels. Si nous décomposons le problème en modules plus petits, la première chose nécessaire avant que le développement du pilote puisse commencer est la connaissance de chaque processeur, accélérateur ou périphérique en cours de développement.

Modèles du système C

Des modèles comportementaux C peuvent être construits pour chaque IP du SoC, et des pilotes logiciels autonomes peuvent être testés sur ces modèles comportementaux. Mais cette approche a quelques problèmes. Premièrement, un effort logiciel énorme est requis, ce qui signifie qu'une grande équipe de logiciel ou une équipe de modèle dédiée est nécessaire pour prendre en charge la mise en œuvre du modèle lui-même. Par conséquent, le développement de modèles ne serait pas rentable. Deuxièmement, la précision des modèles comportementaux dépend de l'interprétation du développeur. Tout écart de communication entre le propriétaire de la conception IP et le développeur du modèle peut entraîner un comportement inexact. Cela se traduit par beaucoup d'efforts inutiles pour résoudre les problèmes associés à une mauvaise interprétation de la conception.

banc de test RTL

Pour résoudre ce problème d'inexactitude, une autre approche qui pourrait être adoptée consiste à utiliser un banc de test Verilog. Le banc d'essai est généralement développé et maintenu par l'équipe de conception du SoC à des fins de vérification. Le banc de test Verilog est basé sur la spécification du langage de transfert de registre (RTL) du SoC, représentant le SoC complet, et pas seulement quelques blocs IP. Par conséquent, il est précis d'un cycle à l'autre. Au fur et à mesure que le RTL se développe, le banc d'essai évolue au même rythme que lui. Cela garantit qu'il s'agit de la représentation la plus à jour et la plus précise du SoC en cours de développement. À des fins de développement logiciel, le banc de test Verilog peut également être utilisé pour développer des pilotes logiciels.

Le logiciel développé à l'aide de cette méthode est précis et peut aider à réduire le temps d'installation du logiciel lorsque les échantillons de SoC arrivent après le processus de fabrication. Mais il y a un problème avec cette approche. Parce que le banc d'essai Verilog est précis en termes de cycle, il est très lent. Le développement de logiciels dans un tel environnement est possible, mais il sera extrêmement lent à développer et à déboguer. Cela peut prendre des mois pour développer un pilote avec cette méthodologie. Le banc de test Verilog peut être utilisable en commençant beaucoup plus tôt - augmentant essentiellement le temps nécessaire dans le pré-silicium pour tenir compte de la vitesse lente de la solution (mais dépend de la disponibilité du banc de test). Dans une approche alternative, une autre équipe logicielle peut utiliser cette méthodologie (ne travaillant que sur le développement pré-silicium) - essentiellement en augmentant le nombre de ressources nécessaires, ne supprimant ainsi pas ce problème similaire au problème avec la méthode du modèle comportemental C.

En pratique, nous ne pouvons pas accepter des cycles de développement inexacts ou longs, ni accepter les coûts supplémentaires nécessaires pour dupliquer ou augmenter le nombre de ressources pour maintenir un calendrier de cycle de conception normal. Par conséquent, nous devons envisager une autre approche du développement de logiciels pré-silicium. Cette approche impliquerait l'émulation de chaque bloc IP SoC sur un FPGA (field-programmable gate array).

Prototypes FPGA

Les FPGA modernes sont assez rapides et, comme les FPGA sont construits à partir de RTL, ils sont précis d'un cycle à l'autre. Avec une complexité de conception croissante, les blocs IP ont beaucoup plus de portes qu'il y a quelques années. Il y a des années, les FPGA étaient limités par le nombre de portes ASIC, ce qui signifiait qu'il n'était pas possible d'intégrer des blocs logiques plus gros dans un seul FPGA. Il est désormais possible de créer un FPGA pour chaque bloc et de développer un pilote sur celui-ci qui est rapide et précis.

Cette méthodologie est plus rapide et ne nécessite pas que les équipes logicielles consacrent leur temps tôt. Parce qu'elle fonctionne avec chaque bloc IP séparé plutôt qu'avec l'ensemble de la conception SoC intégrée, cette approche empêche le logiciel d'effectuer un développement complet au niveau du SoC. Il omet les détails d'intégration sur la façon dont les différents blocs IP fonctionnent ensemble. Par conséquent, bien que cette méthode réduise l'effort de mise en place, des lacunes existent toujours car elle manque des détails d'intégration SoC pertinents. Cette méthode pourrait être une approche acceptable pour les SoC dérivés, qui ont un nombre limité de modifications, mais n'ont pas la couverture complète souhaitée requise pour le développement de logiciels SoC.

cliquez pour agrandir l'image

Figurine. Synopsis des solutions de développement logiciel pré-silicium. (Source :Nitin Garg)

Émulateurs SoC

Pour résoudre le problème de la précision, de la vitesse et de la couverture, une approche plus robuste pourrait être adoptée, qui utilise des émulateurs SoC. Il existe de nombreux émulateurs SoC disponibles dans le commerce, qui peuvent émuler des SoC très volumineux et complexes. Les émulateurs SoC sont basés sur RTL, ils sont donc précis et 100 fois plus rapides que Verilog testbench, ce qui le rend bien meilleur pour le développement de logiciels. Comme ils sont assez rapides, le portage complet du système d'exploitation et le développement de pilotes peuvent être effectués dans un délai raisonnable. Les émulateurs de SoC peuvent faire évoluer l'ensemble du SoC, de sorte que le développement logiciel est mieux adapté au SoC de production final.

L'utilisation d'émulateurs SoC pour le développement et la conception de logiciels pré-silicium réduit le temps et les efforts de mise en place du logiciel, car elle peut éliminer ou réduire les écarts de développement globaux. Le logiciel peut également être débogué à l'aide d'outils JTAG standard sur un émulateur SoC. Les émulateurs peuvent être utilisés pour plusieurs tâches telles que le développement et la vérification de la ROM, le développement du micrologiciel et du système d'exploitation et la vérification au niveau IP ou SoC. Une autre caractéristique intéressante des émulateurs SoC est qu'ils peuvent interfacer le SoC avec des composants réels tels que ceux présentés sur une carte de développement. Par exemple, il est possible de connecter un périphérique NAND réel ou virtuel au SoC dans un émulateur et de développer une ROM, des pilotes de système d'exploitation, etc.

Les émulateurs SoC offrent bien plus de possibilités que les autres approches de développement logiciel. Les émulateurs peuvent interfacer le SoC simultanément avec UART, I2C, divers écrans, périphériques de stockage, périphériques PCIe, périphériques de connectivité comme Ethernet et Wi-Fi et capturer des périphériques comme des caméras et des capteurs. En d'autres termes, les émulateurs SoC peuvent représenter une véritable carte de développement, de sorte que l'on peut créer un framework complet comme Android et exécuter un cas d'utilisation complet avant d'enregistrer le SoC. Par exemple, le démarrage d'Android et le décodage de quelques images de vidéo sur l'émulateur SOC peuvent prendre quelques heures, mais peuvent être très utiles pour analyser les performances du SOC.

En raison de la disponibilité croissante des périphériques sur un SoC, l'émulation SoC est également très utile pour l'analyse comparative des performances, qui peut mettre en évidence les faiblesses de la conception avant la sortie de bande. Cette fonctionnalité peut réduire les risques ou les effacements ultérieurs associés à des défauts de performances non identifiés dans le SoC. Les émulateurs SoC permettent également d'interfacer le SoC avec un FPGA tiers ou un modèle logiciel si nécessaire pour une IP tierce.

Le débogage d'un problème après l'arrivée de l'exemple de SoC est également utile avec un émulateur, étant donné qu'il exécute le même système d'exploitation, les mêmes pilotes et le même framework que le matériel réel. Il est souvent nécessaire de reproduire les problèmes observés dans le silicium vers les émulateurs, afin qu'ils puissent être étudiés au niveau du signal. L'utilisation du même logiciel entre l'émulateur et le silicium permet une reproduction plus rapide et plus précise des problèmes, donnant un accès complet aux détails à l'intérieur de la puce.

En comparant les différentes approches de développement de logiciels SoC, l'utilisation d'émulateurs SoC est un meilleur choix du point de vue du développement pré-silicium et du débogage post-silicone. Le coût pour les équipes logicielles d'exécuter des émulateurs SoC peut sembler élevé. Mais les contributions apportées par les émulateurs SoC en rendant les logiciels de production disponibles plus tôt et en aidant à réduire les risques et les coûts, peuvent s'avérer inestimables lorsque l'on considère l'impact sur les objectifs de mise sur le marché. D'autres approches de développement logiciel n'ont pas la même couverture, ce qui est risqué et peut nécessiter des ressources plus importantes pour l'équipe logicielle. Tous facteurs pris en compte, l'utilisation d'approches de développement logiciel autres que les émulateurs SoC peut s'avérer beaucoup plus coûteuse en comparaison.

Figure 2. Vitesse d'exécution comparative de chaque solution. (Source :Nitin Garg)

Selon la loi de Moore, le nombre de transistors double tous les deux ans dans un circuit intégré (CI) en raison de la fonctionnalité accrue du CI. La plupart des SoC 64 bits basés sur ARM ont aujourd'hui 100 à 300 millions de portes logiques. Parmi les approches de développement logiciel SoC actuelles, les émulateurs SoC se sont avérés capables d'évoluer et de répondre aux besoins des équipes de développement logiciel confrontées aux défis associés à la complexité croissante des SoC sur le marché concurrentiel d'aujourd'hui.

Références

1. Trimberger, Stephen M. « Trois âges des FPGA ». PDF en texte intégral IEEE Xplore : 2015, ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413.
2. BRUNET, JEAN-MARIE. "Pourquoi les conceptions de SoC modernes adoptent l'émulation." Conception informatique embarquée , 5 septembre 2018, Embedded-computing.com/embedded-computing-design/why-modern-soc-designs-embrace-emulation.
3. « Émulation sociale ». Émulation sociale , 2019, www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation–soc-emulation.
4. « Cramper plus de composants sur des circuits intégrés ». http://www.cs.utexas.edu/ , 2006, cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf.