Co-simulation pour designs Zynq SoC : accélérer la vérification matériel-logiciel

Les dispositifs System-on-Chip (SoC) hétérogènes tels que les Xilinx Zynq-7000 et Zynq UltraScale+ MPSoC fusionnent un système de traitement haute performance avec une logique programmable de pointe. Cette intégration permet aux concepteurs de construire des systèmes équilibrant contrôle piloté par CPU et pipelines faible latence basés sur PL — idéaux pour traitement d'image, automatisation industrielle, et traitement de signal temps réel.

La connexion PS-vers-PL repose sur une suite de liens Advanced eXtensible Interface (AXI) memory-mapped supportant rôles master et slave, permettant une communication bidirectionnelle robuste entre logiciel s'exécutant sur les cœurs ARM et logique personnalisée dans le tissu FPGA.

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

Quand le PS gère la configuration ou le contrôle, un AXI Master général sur le processeur écrit dans des registres à l'intérieur des cœurs IP PL, pilotant leur comportement. Pour les tâches intensives en données — comme le streaming de trames vidéo de PL vers mémoire PS — des interfaces AXI haute performance sont utilisées, exigeant un logiciel plus sophistiqué pour configurer les transferts DMA et gérer la cohérence des tampons.

Vérifier les interactions PS-PL est notoirement difficile. Une enquête Embedded Markets 2015 a mis en avant le débogage comme défi de conception majeur et souligné le besoin de meilleurs outils de vérification. Si les modèles bus-fonctionnels peuvent fournir un contrôle de santé initial, ils manquent souvent de la profondeur requise pour valider de vrais drivers logiciels et applications. Les modèles fonctionnels complets existent mais peuvent être prohibitivement chers.

La vérification traditionnelle sépare le flux : chaque bloc est validé isolément, et seulement après l'arrivée du premier matériel le PS et le PL sont assemblés. L'équipe logicielle vérifie généralement que le noyau Linux embarque les drivers et entrées device-tree nécessaires en exécutant QEMU, un hyperviseur open-source qui émule l'architecture ARM. Inversement, l'équipe logique séquence des commandes qui imitent les transactions initiées par logiciel pour confirmer la fonctionnalité PL.

Les deux approches manquent la vraie poignée de main PS-PL, rendant les bugs d'intégration subtils difficiles à repérer et coûteux à corriger plus tard dans le cycle. Bien qu'une carte de développement puisse fournir un palliatif, le débogage sur matériel réel exige l'insertion de logique d'instrumentation, la régénération du bitstream, et risque une dérive comportementale.

La co-simulation matériel-logiciel offre une solution proactive : elle permet une vérification concurrente avant l'existence de cartes de production, réduisant dramatiquement le temps et coût de débogage. Elle donne aussi aux concepteurs une visibilité complète sur les états de registres et le trafic inter-domaine, accélérant la détection de défauts.

Co-simulation HW & SW

La co-simulation requiert que le simulateur logique communique avec une plateforme d'émulation logicielle. Aldec's Riviera-PRO (2017.10) a introduit un pont connectant Riviera-PRO à QEMU, permettant au logiciel Zynq basé Linux de s'exécuter dans le même cycle de simulation que le HDL.

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

Le pont exploite le SystemC Transaction-Level Modelling (TLM) pour exposer les canaux AXI entre QEMU et Riviera-PRO, permettant l'échange de données bidirectionnel. Les ingénieurs peuvent alors employer des techniques de débogage avancées comme points d'arrêt HDL, traçage flux de données, et analyse de couverture de code dans Riviera-PRO, tandis que le côté logiciel utilise GDB pour pas-à-pas dans le code noyau et drivers dans QEMU.

Puisque le même noyau Linux qui tournera sur le dispositif cible est exercé dans QEMU, les développeurs confirment tôt que tous les modules et fichiers de configuration nécessaires sont présents, réduisant les surprises en fin de cycle.

Exemple PWM

Pour illustrer le workflow, considérons un cœur IP PWM placé dans PL et connecté au PS via une interface AXI général. Le logiciel configure un registre pour définir le duty cycle entre 0 % et 100 %, puis déclenche le cœur. Vérifier le cœur en isolation manque le chemin de contrôle initié par PS ; la co-simulation complète assure que la largeur d'impulsion est générée correctement quand l'application Linux s'exécute.