Génération automatique des interfaces VHDL-C pour la
3.6 Génération d'interf aces de cosimulation VHDL-C
3.7.1 Le Videotéléphone C odec
L'outil de génération de l'interface VHDL-C (VCI) a été utilisé dans un projet de SGS-Thomson : une nouvelle conception du Videotéléphone Codec (le STi1100 [108]). La cosimulation C-VHDL est employée pour valider la fonctionnalité du logiciel embarqué (embedded software), qui sera ensuite compilé dans le code binaire en utilisant un compilateur multi-cible. La même source C doit être utilisée pour la cosimulation et pour l'implémentation. Cette méthodologie a été utilisée pour deux processeurs du système. Les résultats ont prouvé que cette validation fonctionnelle permet de réduire la durée du cycle de conception. Plus de details sur cette application se trouvent dans [151].
Architecture du système
Le Videotéléphone Codec prend comme entrée un flux continu d'images, exécute le compactage et le codage de celles-ci. Il émet des chaînes de bits (bits-streams) sur la ligne téléphonique. En parallèle, des chaînes de bits sont reçues de la ligne téléphonique, décodée et décompressé, puis affichée sur l'écran. Le système (représenté par la figure 3.13) regroupe un ensemble d'opérateurs. Ces opérateurs communiquent par un bus de commande et un bus de données (contrôlé par un contrôleur de mémoire). unframer unframer VLC-1VLC-1 reconstruction Q-1 DCT-1 reconstruction Q-1 DCT-1 grabber grabber estimateurde mouvement estimateur de mouvement codage DCT Q formatage codage DCT Q formatage VLC trameur VLC trameur MCC contrôleur de mémoire MCC contrôleur de mémoire interface serveur interface serveur VIP VIP ROM ROM MSQ MSQ ROM ROM bus de données bus de commande Interface de commande d'affichage Interface de commande d'affichage
affichage données adresse bus hôte
VRAM @
chaînes de bits images chaînes de bits
figure 3.13 : Schéma fonctionnel du Videotéléphone Codec
Le bus de commande est contrôlé par un processeur programmable (MSQ). Le contrôleur de mémoire (MCC) arbitre l'accès des différents opérateurs à la mémoire RAM de la vidéo (VRAM). Tous les opérateurs en rapport avec le bus central utilisent le même protocole de communication. Certains de ces opérateurs sont des blocs matériels (DCT, I-DCT, contrôleur d'affichage et estimateur de mouvement), d'autres sont les processeurs d'application spécifique (les processeurs MSQ et VIP). Une description détaillée de la fonctionnalité de la puce est donnée dans [109].
Flot de conception
La figure 3.14 représente le flux de conception pour les parties logicielles du Videotéléphone Codec. Des algorithmes C pilotent les deux ASIPs, le MSQ, MCC et le VIP (processeur d'image Vliw). Ils sont compilés en micro-code en utilisant un compilateur multi-cible (retargetable compiler) [82].
Le code d'application C (exécutable) est compilé sur le poste de travail et cosimulé avec le modèle VHDL du reste du système (on ne prend pas en compte le modèle du processeur). On utilise seulement l'interface du processeur. Une fois la fonctionnalité du logiciel validée, le même code C est compilé dans le code de la mémoire ROM en utilisant un compilateur multi-cible. Le code produit est
chargé dans la mémoire ROM du modèle VHDL du processeur, pour ensuite être simulé avec le reste du système au niveau RT. VHDL C VHDL modèle VHDL du processeur ROM executable cosimulation synthèse compilateur compilateur cible logiciel matériel niveau élevé RT-level
figure 3.14 : Flux de conception pour un processeur encastré et son logiciel
Configuration de l'utilisateur
La cosimulation concerne l'application C et le modèle VHDL du reste du système. Etant donné la spécification de l'interface du processeur, l'outil VCI produit automatiquement l'interface C-VHDL pour la cosimulation. Ensuite, le code généré est joint au code d'application et compilé sur le poste de travail [151].
Pour préserver des contraintes de la réalisation du système, l'utilisateur a été amené à encapsuler l'interface de cosimulation produite par l'outil VCI. Du côté matériel, le bus du système exécute un mécanisme de communication spécifique. Ce bus (contrôlé par deux signaux d'horloge) inclut les types VHDL définis par l'utilisateur et les modules VHDL développés par plusieurs concepteurs. Du côté logiciel, le processeur cible utilise une fonction d'E/S de bibliothèque appelée "io_transaction". Cette fonction aurait deux types de contenu : le premier sera utilisé pour la cosimulation et le second pour la cosynthèse.
Fonction d'adaptation C
Dans la partie C, il est nécessaire de définir une syntaxe stricte pour que les fonctions d'E/S gardent un code C simple pour la cosimulation et la compilation sur le processeur cible. Ces fonctions doivent être traduites pour la cosimulation et compilées en assembleur (tracé sur la mémoire RAM) pour le processeur cible. Par conséquent, pour la cosimulation on a introduit la fonction "io_transaction" pour faire appel aux primitives d'E/S produites par VCI (MSQSendOUT et
MSQReceiveIN). Ces fonctions font l'écriture et lecture des ports de l'interface à chaque opération
d'E/S.
Bloc de connexion VHDL
Dans la partie VHDL, le système utilise une interface générique qui fait abstraction des ports d'E/S du processeur. Cette abstraction est exigée pour préserver le système des modifications postérieures du processeur cible en développement. Cette interface générique doit se conformer aux conditions de synchronisation du bus du système. Par conséquent, l'interface est reliée au bus du système par un bloc de connexion [151].
Synchronisation
La synchronisation entre les programmes C et le simulateur VHDL a été mise en application par un protocole de communication alterné synchrone fondé sur l'échange continu des mises à jour. Les échanges réguliers de données C-VHDL sont commandés à l'aide d'une horloge d'évaluation (clk_eval), dérivée de l'horloge principale. Le transfert de données se fait alternativement sur chaque front du signal d'horloge. Pour mettre en application ce mécanisme de synchronisation, la sensibilité n'a été seulement placée que sur les front de l'horloge d'évaluation (dans le fichier d'entrée VCI). Les autres ports ne sont pas sensibles. La figure 3.15 représente la synchronisation entre les parties C et VHDL. Il s'agit du modèle similaire au décrit précédemment dans la section 3.6.4.
Clk_Eval VHDL C X X W L W données et synchronization X X E X execution E ecriture L lecture W attente W L E OUT IN X
figure 3.15 : Synchronisation personnalisée C-VHDL
La transaction s'effectue en deux étapes. A un moment donné, l'application C engage une transaction en appelant une fonction spécifique appelée c_transaction. Celle-ci envoie une mise-à-jour de tous les ports de sortie et se bloque en attente de lecture de mise-à-jour des ports d'entrée. Le simulateur VHDL, qui était en attente de lecture, lit alors les mise-à-jours de sortie. Après avoir fait la mise-à-jour des signaux internes, il reprend la simulation pour un demi cycle. Au demi cycle suivant, le simulateur envoie les mise-à-jour des ports d'entrée et reprend la simulation. Cela débloque l'application C qui était en attente de lecture, qui peut alors mettre à jour ses propres variables et reprendre son exécution interne jusqu'à la prochaine entrée-sortie.
Afin d'optimiser la fréquence des transactions entre les simulateurs, un second mode de synchronisation a été implémenté. Il permet de modifier la fréquence des transactions pendant la cosimulation selon l'avancement de celle-ci. Ce mode est particulièrement adapté aux applications où la communication n'est pas très fréquente ou pas constante durant l'ensemble de la cosimulation [151].
3.7.2 Résultats expériment aux
L'application de cette méthodologie de cosimulation à un grand projet industriel permet de mesurer la méthode au niveau de la durée du cycle de conception et de la vitesse de la simulation.
Nous comparons la cosimulation C-VHDL à la simulation entièrement effectuée en VHDL (modèle du processeur cible avec le programme chargé dans la mémoire ROM). Le délai d'exécution de la simulation (simulation runtime) est défini comme suit :
• pour la cosimulation C-VHDL, le délai d'exécution de la simulation est l'ajout du temps passé pour exécuter l'algorithme C compilé (y compris la communication Unix), et le temps passé pour simuler le reste du système dans VHDL ;
• pour la simulation VHDL avec le modèle du processeur, le délai d'exécution de la simulation est le délai d'exécution du simulateur VHDL (modèle du processeur cible et de son environnement). Cette expérience a été faite pour six algorithmes différents [151]. La figure 3.16 correspond à une comparaison entre le délai d'exécution de la cosimulation et le délai d'exécution de la simulation
VHDL obtenue pour les différents algorithmes. Les algorithmes sont placés sur l'axe des abscisses dans un ordre croissant de complexité.
40 10 complexité des algorithmes Temps de simulation minutes 1 2 3 4 5 6 simulation VHDL pure cosimulation C-VHDL 13 37 25
figure 3.16 : Simulation RTL contre la cosimulation
La cosimulation est toujours plus rapide que la simulation VHDL pure, et cette différence s'accroît avec la complexité des algorithmes. Deux raisons peuvent expliquer ces résultats :
• le simulateur VHDL dépense beaucoup de temps pour simuler le comportement du processeur pour chaque instruction d'assemblage, tandis que l'instruction C équivalente est simplement exécutée sur le poste de travail ;
• le code supplémentaire dû à la couche de communication IPC devient négligeable comparé au code d'application, à mesure que la complexité de l'algorithme augmente.
Ces résultats dépendent de la configuration de la plate-forme de cosimulation. En dépit du fait d'utiliser seulement un canal Unix par chaque module logiciel, la cadence de la propagation des données entre les simulateurs dépend du genre de canal Unix choisi (IPC ou socket). La vitesse de cosimulation dépend également du mode de synchronisation des simulateurs et du nombre de processeurs employés par la plate-forme de cosimulation. Ces variables affectent la vitesse et l'exactitude de la simulation. Cependant, les résultats sont tout à fait importants dans le domaine des systèmes embarqués. L'environnement de cosimulation permet d'utiliser les outils de développement standard du langage C (debugger, profiler, browser) pour valider le code du logiciel bien avant de concevoir le processeur cible, et rapidement modéliser et valider l'interface du processeur. La conception simultanée du code du logiciel et du processeur réduit considérablement la durée du cycle de conception.