Les dispositifs électroniques modernes sont souvent de nature hétérogène. Ceci est dû aux limitations imposées par la technologie actuelle qui nous empêche de pousser les fréquences d'horloge au-delà d'une certaine limite et nous motive ainsi à se doter de processeurs polyvalents et de spécialiser l'architecture afin d'obtenir l'ajustement optimal. En particulier, il n'est pas rare de voir des cartes qui couplent un processeur ARM avec un FPGA. Le premier s'occupe habituellement d'opérations standard, telles que l'exécution d'un système d'exploitation et l'interface avec l'utilisateur, tandis que le dernier prend en charge les tâches dépendantes de l'application qui peuvent ainsi profiter de l'énorme parallélisme qu'il peut offrir. Un exemple notable de telles cartes est représenté par la récente Zynq SoC (voir figure 1), mais l'acquisition récente d'Altera par Intel soutient l'hypothèse que ces architectures vont devenir la nouvelle norme dans un avenir proche.


Figure 1: Structure de Xilinx Zynq-7000 SoC (source: Xilinx press release).

Bien que la stratégie mentionnée ci-dessus permette des gains de performance impressionnants, la complexité du système global augmente considérablement: non seulement la programmation des deux parties nécessite des compétences différentes (et donc le développement est généralement effectué par deux équipes distinctes), mais les interactions entre eux ne sont pas nécessairement définies, testées et déboguées. De ce fait, la frontière entre eux est l'un des points les plus critiques dans la conception du système.
Il n'est pas rare d'entendre les ingénieurs des groupes susmentionnés discuter de la question afin de savoir si un problème donné dans leur système doit être recherché dans la conception du logiciel de l'UC, dans la conception FPGA ou dans la façon dont les deux parties communiquent.
En dépit de bonnes pratiques bien définies, le manque d'outils appropriés rend la norme de tester la conception du logiciel de l'UC en utilisant un ensemble de cas de test qui sont censés imiter le comportement attendu du FPGA et en même temps tester le FPGA sur un test qui devrait simuler toutes les interactions possibles avec la partie CPU. Comme exemple extrême de cette pratique, ARM a été utilisé pour une simulation VHDL du processus de démarrage Linux afin de valider la conception de nouveaux processeurs. Ces techniques sont loin d'être la solution optimale et impliquent une quantité importante de travail à double.
Nous prétendons que, dans le contexte de systèmes hétérogènes composés d'un CPU et d'un FPGA, d'énormes avantages découlent d'une co-simulation complète des deux parties. En effet, une telle simulation permet une visibilité totale sur les deux systèmes internes au cours de leur interaction, ce qui permet de repérer les incongruités, les erreurs dans la conception de l'interface et les erreurs logiques métier. En outre, il permet de tester les deux composants tout en réalisant des interactions réelles et de fonctionner sur des données réalistes, au lieu de s'appuyer sur des bancs de test maquillés.
Une tentative en ce sens est représentée par le projet RABBITS (http://tima.imag.fr/sls/research-projects/rabbits). Ce cadre propose une simulation au niveau système basée sur QEmu et SystemC. Cependant, si l'approche et les résultats préliminaires sont extrêmement intéressants, le choix de SystemC comme langue de travail a un impact majeur sur l'applicabilité des méthodologies. En effet, alors que SystemC est encore une technologie prometteuse, il n'est pas encore pris en charge par les flux de travail standards adoptés dans l'industrie.
Un autre projet connexe est SimXMD (www.eecg.toronto.edu/~willenbe/simxmd), qui met l'accent sur l'utilisation de GDB pour piloter la simulation d'un processeur. Ceci est similaire à ce que nous aimerions réaliser, mais nous voudrions généraliser l'approche adoptée en laissant GDB (ou QEmu, dans notre cas) prendre le contrôle de la simulation et interagir avec elle.

L'approche

Dans le cadre de ce projet, nous développons un système qui interconnecte QEmu (http://www.qemu.org) - l'un des émulateurs de machine les plus renommés - avec ModelSim / QuestaSim (www.mentor.com/products/fv/modelsim, deux environnements de simulation HDL standard en plusieurs langues par Mentor Graphics. Un croquis de notre système est présenté à la Fig. 2.
Le code source du système est disponible sur GitHUB à l'adresse: https://github.com/reds-heig/FSS

Figure 3: Circuit utilisé dans notre exemple de preuve de concept, composé de deux ports UART reliés entre eux par leur série broche.


​Figure 2: FSS est une interface entre la simulation d'un processeur (obtenu à l'aide de QEmu) et un simulateur HDL (dans cette image, QuestaSim).

Un exemple introductif

Comme une preuve de concept, nous avons conçu le système représenté par la Fig. 3, composé de deux ports UART simplifiés décrits en VHDL et pris sur le réseau, interconnectés par leurs interfaces série. Le but dans cet exemple est de créer un canal de communication bidirectionnel entre deux instances QEmu différentes, utilisant chacune l'une des bornes parallèles du circuit susmentionné. Le système complet est représenté sur la Fig. 4, alors qu'un instantané de l'état du système pendant une simulation est montré à la Fig. 5.

Figure 4: Croquis complet du circuit utilisé dans notre exemple de preuve de concept, où les instances QEmu sont utilisées pour les ports UART via les interfaces FSS.

Figure 5: Instantané des états des signaux dans QuestaSim pendant une simulation, avec les terminaux correspondant aux deux instances QEmu. Dans cet exemple, la première instance QEmu a écrit au canal de communication le texte "C'est", alors qu'en même temps la deuxième instance QEmu a répondu "un exemple!".

Regardez-le en action:

Code source

Le code source du système est disponible sur GitHUB à l'adresse:
https://github.com/reds-heig/FSS

Publications

[1] X. Ruppen, R. Rigamonti, A. Dassatti, “TCCF: Tightly-Coupled Co-simulation Framework for RISC-V Based Systems” - RISC-V Workshop, 2018.

​