Co-simulation pour les conceptions basées sur Zynq

Les dispositifs système sur puce (SoC) hétérogènes comme le Xilinx Zynq 7000 et le Zynq UltraScale+ MPSoC associent des systèmes de traitement hautes performances à une logique programmable de pointe. Cette combinaison permet au système d'être architecturé pour fournir une solution optimale. Les interfaces utilisateur, la communication, le contrôle et la configuration du système peuvent être traités par le système de processeur (PS). Pendant ce temps, la logique programmable (PL) peut être utilisée pour mettre en œuvre des fonctions déterministes à faible latence et des pipelines de traitement qui exploitent sa nature parallèle, telles que celles utilisées par le traitement d'images et les applications industrielles.

La communication entre le PS et le PL est assurée par plusieurs interfaces mappées en mémoire. Ces interfaces utilisent l'interface extensible avancée (AXI) pour fournir à la fois des communications maître et esclave dans chaque direction.

Figure 1. Architecture Zynq montrant l'interconnexion AXI entre le PS et le PL (Source :Xilinx)

Dans les cas où les fonctions de configuration et de contrôle sont exécutées par le PS, l'interface générale AXI Master est utilisée du PS vers le PL. Cela permet au logiciel (SW) de configurer les registres et donc le comportement souhaité des cœurs IP dans la PL. Dans des opérations plus complexes, il peut y avoir un désir de transférer de grandes quantités de données du PL vers l'espace mémoire du PS pour un traitement ou une communication ultérieurs. Ces transferts utiliseront les interfaces hautes performances, ce qui nécessitera un logiciel beaucoup plus complexe à configurer et à utiliser.

La vérification des interactions entre le PS et le PL présente des défis pour l'équipe de conception. L'enquête sur les marchés intégrés de 2015 a identifié le débogage comme l'un des principaux défis de conception rencontrés par les équipes d'ingénierie et a également identifié un besoin d'outils de débogage améliorés. Si des modèles fonctionnels de bus peuvent être utilisés dans un premier temps, ces modèles sont souvent simplifiés et ne permettent pas de vérifier en même temps les pilotes SW développés et l'application. Des modèles entièrement fonctionnels sont disponibles, mais ceux-ci peuvent être prohibitifs. Lors de la mise en œuvre d'une conception de SoC hétérogène, il doit y avoir une stratégie de vérification qui permet aux éléments PL et PS d'être vérifiés ensemble le plus tôt possible.

Traditionnellement, la vérification a d'abord été effectuée pour chaque élément (bloc fonctionnel) de la conception de manière isolée ; la vérification de tous les blocs ensemble se produit lorsque le premier matériel arrive. L'équipe d'ingénierie logicielle qui développe les applications à exécuter sur le PS doit s'assurer que le noyau Linux contient tous les modules nécessaires pour prendre en charge son utilisation et dispose de l'arborescence de périphériques appropriée ; ceci est normalement vérifié à l'aide de QEMU (abréviation de Quick Emulator), qui est un hyperviseur hébergé gratuit et open source qui effectue la virtualisation matérielle.

Pendant ce temps, afin de vérifier correctement la conception PL, l'équipe de vérification logique doit générer et séquencer des commandes telles que celles émises par le logiciel d'application pour vérifier que la logique fonctionne comme requis. Cependant, ces deux approches ne capturent pas la véritable interaction du logiciel avec le matériel, ce qui rend les erreurs associées à cette interaction très difficiles à détecter. Cela retarde le calendrier de développement et augmente les coûts de développement, car les problèmes soulevés plus tard dans le processus de développement sont toujours plus coûteux à résoudre et à corriger.

Il est possible d'utiliser une carte de développement comme étape intermédiaire pour vérifier l'interaction HW et SW avant l'arrivée du matériel final. Cependant, le débogage sur du matériel réel peut être compliqué, nécessitant l'insertion d'une logique d'instrumentation supplémentaire dans le matériel. Cette insertion prend un temps supplémentaire car le fichier de bits doit être régénéré pour inclure la logique d'instrumentation. Bien sûr, ce changement dans l'implémentation peut également avoir un impact sur le comportement sous-jacent de la conception, masquant ainsi des problèmes ou introduisant de nouveaux problèmes qui ne se manifestent que dans les versions de débogage.

Être capable de vérifier à la fois les conceptions SW et HW en utilisant la co-simulation offre donc plusieurs avantages importants. Il peut être effectué plus tôt dans le cycle de développement et ne nécessite pas d'attendre l'arrivée du matériel de développement, réduisant ainsi le coût et les impacts du débogage. En outre, une telle approche offre également plus de visibilité en ce qui concerne les registres et les interactions entre le PS et le PL, ce qui facilite la découverte et la suppression des bogues plus tôt dans le processus.

Co-simulation HW &SW

La co-simulation entre SW et HW nécessite l'outil de simulation logique utilisé pour vérifier la conception HW pour pouvoir interagir avec un environnement d'émulation de simulation SW.

La sortie de Riviera-PRO d'Aldec (2017.10) permet justement cette co-simulation matérielle et logicielle en fournissant un pont entre Riviera-PRO et QEMU, permettant ainsi l'exécution du logiciel développé pour les développements Zynq basés sur Linux.

Figure 2. Relier les environnements de vérification HW et SW (Source :Aldec)

Ce pont a été créé en utilisant SystemC Transaction Level Modeling (TLM) pour définir les canaux de communication entre QEMU et Riviera-PRO. La vérification simultanée du SW et du HW est facilitée par la capacité du pont à transférer des informations dans les deux sens.

Dans cet environnement de simulation intégré, l'équipe d'ingénierie est en mesure d'utiliser des méthodologies de débogage standard et avancées pour résoudre tout problème pouvant survenir au cours de la vérification. Dans le cas de Riviera-PRO , cela inclut des capacités telles que la définition de points d'arrêt dans le HDL , l'examen du flux de données et même l'analyse de la couverture de code et des chemins qui sont exercés par l'application SW s'exécutant dans QEMU . Dans le cas de QEMU , l'équipe SW peut utiliser Gnu DeBugger (GDB ) pour instrumenter à la fois le noyau et le pilote pour parcourir le code à l'aide de points d'arrêt.

Cette approche de co-simulation a l'avantage non seulement de fournir une plus grande visibilité et capacité de débogage dans l'environnement de simulation matérielle, mais elle permet également d'utiliser le même noyau Linux développé pour le matériel cible dans QEMU. Encore une fois, cela permet de vérifier plus tôt que le noyau contient correctement tous les packages et éléments requis pour prendre en charge l'application en cours de développement.

Exemple PWM

Afin de démontrer cet environnement de co-simulation, un exemple simple a été créé. Cet exemple place un cœur IP dans le PL et le connecte au PS Zynq via une interface AXI à usage général. Lorsqu'il est activé par un accès AXI à son espace de registre, le noyau IP génère une sortie de signal modulée en largeur d'impulsion (PWM). La durée du signal PWM est sélectionnable dans une plage de 0 à 100 % et est à nouveau définie par un registre dans l'espace de registre du noyau IP. Un cas d'utilisation typique de ce cœur nécessite donc un logiciel exécuté dans le Zynq PS pour activer et configurer le cœur IP. La simple simulation du cœur IP de manière isolée n'entraînera pas la démonstration adéquate du fonctionnement souhaité du cœur. Pour vérifier correctement le noyau IP, nous devons être en mesure d'activer et d'exercer la largeur d'impulsion de sortie du PS lors de l'exécution d'un système d'exploitation Linux.