Couverture ElectroniqueS n°127

Combiner carte de prototypage à base de FPGA, émulateur matériel et débogueur logiciel facilite la phase de vérification de SoC à c&oelig;urs de processeurs et logiciels embarqués. La société Eve illustre les apports de cette approche dans le cadre de la vérification d'un décodeur Mpeg-4 sur un processeur Xtensa de Tensilica. Les systèmes sur silicium (ou Soc pour system-on-chip) sont au c&oelig;ur de la majorité des appareils électroniques grand public (téléphone portable, appareil photo numérique, caméscope), mais aussi des matériels de l'informatique professionnelle comme les routeurs Internet. Ces circuits ne sont plus conçus comme les Asic du passé, purement à base de logique spécialisée, mais sont constitués de plus en plus fréquemment de blocs de propriété intellectuelle (IP) achetés à divers fournisseurs. Le ou les blocs « roi » dans ces SoC sont le ou les processeurs embarqués qui introduisent une dimension logicielle sans laquelle la puce ne saurait fonctionner. Cette situation nouvelle oblige les équipes de développement logiciel à se rapprocher de leurs collègues électroniciens, bien que cela ne soit pas toujours facile (encadré), afin de mettre au point et vérifier ensemble le composant avant qu'il ne soit envoyé en fabrication.Un bon exemple de ce défi à relever est la mise au point d'un SoC réalisant la fonction d'un décodeur Mpeg-4 de basse consommation. Dans cette application, l'objectif est de pouvoir regarder des bandes annonces de films sur son téléphone portable. Pour ce faire, il fallait concevoir un circuit de taille réduite, consommant très peu d'énergie, tout en étant compatible avec une norme aussi complexe que Mpeg-4. La méthode employée pour la conception a été de prendre comme base de départ un code C de référence pour la norme Mpeg-4, développée dans le cadre du projet MoMuSys (Mobile multimedia systems) et publiée par l'OSI (Open source initiative). En utilisant un processeur configurable Xtensa de la société Tensilica, des optimisations appropriées ont été ajoutées au processeur pour le spécialiser dans le décodage de flux Mpeg-4. Les principaux ajouts ont porté sur un accélérateur iDCT (inverse Discrete cosine transform ou transformée de cosinus discrète inverse), des instructions vectorielles SIMD (Simple instruction multiple data), des instructions de manipulation et d'extraction de bits (bitstream) et des algorithmes de conversion de formats de couleur YCbCr et RVB.Le résultat de la conception est le suivant : un composant réutilisable d'environ 120 000 portes incluant un processeur exécutant un programme de 200 000 lignes de code C. La fréquence de fonctionnement du CPU au sein du téléphone portable est de 200 MHz. A cette vitesse, le code de décodage Mpeg-4 n'utilise que 12 % de la puissance de calcul du processeur, ce qui permet à ce dernier de gérer bien d'autres tâches en parallèle. Avec ce SoC, on est ainsi capable d'obtenir un décodage en temps réel d'une vidéo au format QCIF (Quarter common intermediate format) à 15 images par seconde.Reste que la vérification d'un tel composant est loin d'être triviale. Juste un chiffre pour s'en convaincre : visualiser la bande annonce complète d'un film comme « Monstres et Cie » correspond à l'analyse d'environ un milliard de cycles. Or, jusqu'à aujourd'hui, aucune solution de vérification ne couvre de façon satisfaisante à la fois les besoins des développeurs logiciels et des concepteurs électroniciens.A la chasse au bogue critiqueEn conclusion, si le système ZeBu apparaît sur le papier comme la solution idéale pour la covérification matériel-logiciel, a-t-il vraiment été efficace en pratique pour détecter, isoler et corriger des bogues ? Un bon exemple de la puissance de l'outil est la vitesse à laquelle nous avons pu trouver une erreur de conception dans un contrôleur mémoire périphérique. En effet, lors de certaines séquences de lectures et écritures consécutives, ce contrôleur mélangeait deux données. Le symptôme du problème, qui avait échappé aux tests unitaires, était qu'après deux millions de cycles l'image décodée devenait zébrée, un peu comme une image Canal+ sans décodeur. Nous avons alors utilisé une combinaison de trois fonctionnalités de ZeBu pour analyser le problème : des points d'arrêt dans le code C pour comprendre ce que le code exécute (côté logiciel), une capture du contenu des mémoires pour visualiser immédiatement les mots mémoire incorrects et enfin l'affichage des registres internes au contrôleur mémoire (côté matériel). Sans la possibilité de mélanger simultanément mise au point matérielle et logicielle, ce bogue n'aurait jamais pu être corrigé à temps et aurait nui à la réussite du projet.(*) L'écriture de ces transacteurs fait actuellement l'objet d'une normalisation auprès de l'organisme Accelera sous l'appellation SCE-MI (Standard emulation modeling interface) dont la version 1.0 a été définitivement adoptée en juin dernier.EveDiplômé de Supelec et de l'université de l'Illinois, Alain Raynaud est responsable du Centre technique de la société Eve, basé aux Etats-Unis à San Jose. Il était auparavant chef de projet à la division Emulation de Mentor Graphics.Alain RaynaudDéveloppeurs et électroniciens : un dialogue de sourdsLa petite histoire qui suit est authentique. Un développeur de logiciel embarqué est en train de mettre au point le code qui pilote un périphérique. Après dix millions de cycles, un bus se bloque et provoque le « plantage » du circuit. La première réaction du développeur logiciel est d'aller voir son collègue électronicien : « Il y a un bogue dans le hard ». Au passage, on peut noter que le développeur logiciel suppose immédiatement que le problème est matériel et non logiciel. L'ingénieur électronicien, de bonne volonté, accepte cependant d'étudier le problème et demande simplement au développeur de lui fournir un chronogramme de ce qui s'est passé. « Impossible », répond le développeur. En effet, en utilisant une connexion Jtag sur une plate-forme de prototypage rapide, il ne dispose d'aucune visibilité sur les signaux internes du circuit. L'ingénieur en est donc réduit à essayer de reproduire le problème en réalisant une simulation VHDL. Première difficulté : exécuter dix millions de cycles prend un temps certain. Mais surtout, comment reproduire le scénario exact qui a causé le blocage ? « J'étais dans telle fonction de mon code, puis j'ai avancé de quelques instructions » précise le développeur. Mais, lorsque l'ingénieur matériel montre le simulateur RTL au développeur, celui-ci se récrie : « Je ne sais pas utiliser ça, je ne connais que gdb ». Même si cette petite histoire ressemble à un sketch, la réalité est bien là : ingénieurs logiciels et matériels ne parlent vraiment pas le même langage et perdent un temps précieux… à ne pas se comprendre !

La covérification d’un décodeur Mpeg-4 réalisée à pleine vitesse

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

La covérification d’un décodeur Mpeg-4 réalisée à pleine vitesse

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure