lm02.html créé par Yann Guidon, mer nov 21 23:48:28 GMT 2001 version dim déc 2 19:09:57 GMT 2001 (passage rapide au format HTML à la main, lire le source du fichier peut aider aussi) version jeu déc 6 02:35:33 GMT 2001 (ajout du serveur web en VHDL) illustrations : - testbench.eps - rop2.eps - f-cpu_logo.eps - http://www.f-cpu.de/epf2001/l5.png fichiers joints : - fanout.vhdl - test_fanout.vhdl - fanout_linear.vhdl - f-cpu_config.vhdl - rop2_unit.vhdl - rop2_xbar.vhdl - test_rop2.vhdl
La situation de Linux dans le monde de l'EDA ("Electronic Design Automation", terme américain désignant les outils de CAO électronique) change lentement, sous la pression de plusieurs facteurs économiques et stratégiques. Les PC commencent à remplacer les stations SUN, en particulier parce que la RAM pour PC coûte beaucoup moins cher que pour les stations propriétaires. Et il faut souvent beaucoup, beaucoup de mémoire. Linux s'intègre relativement bien dans l'environnement UNIX existant, la réticence des directeurs techniques cèdant lentement grâce au support croissant des distributeurs comme RedHat ou SuSE.
Bien que Linux occupe la place que Windows NT convoitait il y a plusieurs années, le Logiciel Libre n'a pas gagné pour autant : les plateformes propriétaires de SUN et HP sont indétronables dès que les PC ont atteint leurs limites. Quant aux logiciels d'EDA, en dehors de quelques logiciels issus du monde universitaire, rares sont ceux distribués sous GPL.
Malgré les efforts de nombreux volontaires, dès le début des années 80 (date de l'émergence de cette industrie), il n'existe pas encore de "Linux" de l'EDA. Nous allons voir comment concevoir tout de même des circuits numériques à l'aide de logiciels gratuits disponibles sous GNU/Linux. Cependant, le manque de logiciels libres ou même gratuits est encore plus flagrant dans le domaine de la vérification, de la synthèse ou de l'extraction temporelle (étapes nécessaires à la conception d'un circuit intégré). La méthodologie de conception en est affectée mais doit rester aussi rigoureuse que dans l'industrie, sinon plus, de nombreuses étapes devant être effectuées le plus en amont possible.
Puissant comment ? VHDL n'est pas Perl ni C ni Eiffel... Au départ prévu uniquement pour décrire et simuler des circuit (avant de devenir le langage d'entrée des synthétiseurs logiques), VHDL a toutefois été doté dès le début de fonctionnalités qui me surprennent encore, comme par exemple la possibilité d'initialiser une constante avec le résultat d'une fonction, qui peut elle-même lire aussi bien un fichier (pourquoi pas /dev/random ?) qu'effectuer des calculs sur des grandeurs physiques ou des chaines de caractères... Marius Vollmer, un passionné, enfonce actuellement le clou en concevant une couche de compatibilité POSIX pour certains logiciels commerciaux répandus. Vous croyiez avoir tout lu dans Linux Mag ? Il existe un serveur HTTP écrit en VHDL sous GPL !
Au-delà de l'aspect "gadget", cela prouve que VHDL est un langage bien terre-à-terre. L'extension POSIX est une des nombreuses manières de lier la simulation à des phénomènes réels et de tester le comportement du programme dans des conditions opérationnelles, avant de compiler le circuit. Pour en arriver là, il faut beaucoup d'efforts, mais je comparerais celà à un véhicule extra-terrestre : on a du mal avec les manettes, mais il n'y a pas mieux pour faire un tour dans l'espace !
- Les "synthétiseurs" (outils qui transforment le VHDL en "netlist" optimisées) ne "comprennent" qu'un sous-ensemble spécifique du langage, ce qui réduit la complexité (syntaxique et sémantique) des sources du coeur. Ce dernier est codé principalement en style "RTL" alors que les bancs de test de chaque unité (qui ne sont pas implantés dans le circuit) utilisent le style "haut niveau" pour simplifier le codage des vecteurs de test. De plus, les sources devant être utilisables dans n'importe quelle chaine d'outils, les extensions propriétaires ne sont donc pas supportées.
- VHDL permet de couvrir les étapes de spécification, de synthèse et de vérification/test avec un seul langage, donc en réutilisant la plupart des fichiers pour toutes les étapes de la conception. Il n'y a besoin que d'un seul langage pour tous les fichiers, à l'exception des scripts en langage shell qui permettent d'automatiser la compilation.
- Une bonne méthodologie de conception sépare les différentes difficultés afin de ne traiter qu'un problème à la fois. F-CPU est conçu de manière très modulaire et sur plusieurs niveaux, il permet à chacun de s'exercer et de participer selon ses compétences.
Toutefois, la puissance de VHDL peut tourner la tête des débutants qui découvrent de nouvelles fonctionalités ou des concepts séduisants au détour d'une page d'un manuel ouvert pour résoudre un problème. Dans d'autres cas, il est nécessaire de recourir à certaines formes complexes pour résoudre des problèmes liés aux limites du langage. Ces circonstances sont toujours expliquées dans les commentaires du code source.
VHDL étant dérivé d'ADA, les sources sont assez lisibles et peu condensés, contrairement à des programmes en C ou en shell. Le plus gros effort sera donc fourni dans la "sémantique" du source, plus particulièrement lors du choix d'une forme de codage (ou d'une autre) en fonction de ce que le programmeur désire et de la fonction du code (selon que le source est destiné à la synthèse ou la simulation comportementale par exemple).
Le but de cet article n'est pas de donner des cours de VHDL (de nombreux livres et sites web existent pour cela) mais de permettre aux débutants de lever les premières difficultés pratiques du VHDL sous Linux et de découvrir les étapes initiales de la conception d'un circuit intégré. Nous espérons que cela peut susciter l'intérêt de futurs débutants et les motivera lors de l'apprentissage de VHDL. Peut-être même contribueront-ils ensuite au projet F-CPU ?
Pour illustrer l'utilisation des outils suivants, nous allons implémenter une partie de l'unité logique du F-CPU, appelée "ROP2". Elle permet d'effectuer toutes les opérations booléennes à 2 entrées, leur combinaison sur 8 bits par AND ou OR, ou la sélection d'un bit parmi deux en fonction d'un troisième. C'est certainement la partie la plus simple et régulière du F-CPU. Nous allons nous concentrer sur la partie opérative de l'unité, car elle nécessite aussi un étage de pipeline pour amplifier et décoder certains signaux de contrôle (voir la moitié inférieure du schéma).
Nous allons aussi nous limiter à la partie "combinatoire" du circuit, les registres de pipeline sont implémentés plus haut dans la hiérarchie des fichiers afin d'uniformiser la stratégie de conception des registres (chaque contributeur pouvant décrire les registres de manière différente, le code risquerait ensuite de devenir plus difficile à maintenir). De plus, lors du test de l'unité, il n'est pas nécessaire de prendre en compte le délai d'un cycle induit par les registres.
Il nous reste dans le fichier source une description des opérations effectuées par l'étage de pipeline. Les règles de conception du F-CPU précisent que le chemin le plus long entre deux registres ne doit pas traverser plus de 6 portes logiques : l'unité ROP2 est la plus simple et respecte ce critère permettant de réduire la complexité des étages. Grâce à cette règle, on évite les mauvaises surprises lors de l'extraction des caractéristiques du circuit pour déterminer sa fréquence de fonctionnement. Pour donner un ordre de grandeur, la "granularité" de tous les étages du coeur F-CPU est proche de celle du pipeline entier du Pentium 4 dans la partie cadencée localement à fréquence double. Un coeur F-CPU peut donc atteindre des performances "honnorables" en utilisant des technologies lentes (FPGA ou en CMOS "économique").
Les "packages" communs sont générés par des scripts qui utilisent le macroprocesseur "m4" pour mettre à jour les fichiers communs .vhdl, .h ou Verilog, si une version est écrite dans ces langages. De cette manière, les différentes versions du coeur restent dépendantes d'un seul fichier texte contenant les paramètres choisis par l'utilisateur (unités à implémenter, tailles des bus, ...). Pour notre exemple, nous utiliserons une version modifiée à la main du package principal.
Le deuxième point crucial dans la conception d'un circuit numérique en VHDL est que chaque entité, unité, ou partie active doit être accompagnée d'un autre fichier VHDL pour en effectuer le test. Une fois que toutes les unités sont assemblées, il est trop tard pour comprendre d'où vient le "bug" qui ne manque jamais de se produire. Cela n'est pas une habitude courante dans le monde logiciel, mais c'est justifié car une erreur de conception peut coûter très cher en électronique. Dans l'industrie, la vérification des circuits peut prendre 70% des ressources d'un projet. L'utilisation anticipée et systématique d'un "banc de test" ("testbench" en anglais) permet de circonscrire les erreurs et d'illustrer l'utilisation de l'unité si elle est réutilisée dans un autre projet. Voilà une bonne habitude à utiliser aussi en C !
Ensuite, la procédure de compilation et de simulation varie peu selon les outils, en ligne de commande ou non. Comme pour un autre langage de programmation, il faut d'abord compiler les packages de base et remonter la hierarchie des dépendances jusqu'au(x) fichier(s). Le dernier fichier est le banc de test qui instancie l'unité à tester. La simulation va donc vérifier que l'unité fonctionne comme prévu, d'abord en instanciant toutes les unités nécessaires et en revérifiant que toutes les règles sémantiques sont respectées (lors de la phase d'"élaboration"), puis en simulant le comportement de chaque porte.
J'allais oublier le point le plus crucial : la documentation ! Les commentaires sont parfois plus longs que le code dans les fichiers sources afin de clarifier les intentions du codeur. Le projet F-CPU a eu la chance de commencer par l'écriture de la documentation (contrairement à de nombreux projets où les codeurs ne songent à documenter qu'une fois le code écrit). A tel point qu'à un moment, F-CPU n'existait plus que par sa documentation (300 pages impossibles à tenir à jour), mais la situation s'inverse actuellement.
Une grande partie des projets listés est inutilisable : certains n'ont même pas de code ou de binaire disponible, puisqu'ils viennent à peine d'être annoncés. D'autres ne fonctionnent pas dans le contexte du projet, le reste ne correspond pas aux besoins. Parmi les outils utilisables ou suffisamment avancés, nous avons principalement évalué les suivants :
La description et l'URL de ces projets sous GPL se trouve à http://www.opencollector.org. J'en oublie certainement plusieurs, en particulier j'attends que Savant 2 se stabilise. Avec beaucoup d'efforts, il serait peut-être possible d'utiliser les meilleures parties de chacun de ces projets mais cela représente un effort tel qu'il sort du cadre du projet F-CPU.
D'autres outils sont disponibles "gratuitement" (avec une licence plus ou moins restrictive). D'abord, les "versions d'évaluation" d'outils commerciaux, aux possibilités limitées soit dans le temps ou en capacité. Il n'est pas question de les utiliser pour le F-CPU car ils impliquent à la fois une dépendance envers la "technologie" du fournisseur et une limitation des sources.
Certains vendeurs de FPGA proposent aussi gratuitement des outils professionnels qui ont été modifiés pour un usage particulier. Bien que leur utilisation soit possible, elle est déconseillée pour les mêmes raisons. De plus les résultats pourraient varier d'un vendeur à l'autre, par exemple pour l'évaluation de la fréquence ou de la consommation.
Nous allons voir maintenant deux outils "gratuits" sous Linux, disponibles uniquement sous forme binaire. Leur licence est compatible avec les contraintes du développement de sources sous GPL et leur utilisation est suffisamment aisée pour que les débutants ne soient pas trop effrayés lors des premiers contacts.
L'utilisation de ces outils n'est pas exclusive, au contraire : leur utilisation simultanée garantit que les sources compatibles avec les deux outils sont suffisamment portables. Les subtilités du langage VHDL peuvent être interprétées légèrement différemment d'un outil à l'autre et les sources doivent être compilés et simulés avec tous les logiciels disponibles, pour vérifier que nous n'écrivons pas de code "ambigu". Des contributeurs du projet F-CPU arrivent de temps en temps à confirmer la validité du code en utilisant des outils industriels sur leur lieu de travail.
Quelques autres caractéristiques de base :
Pour la méthodologie, Simili repose entièrement sur des testbenches utilisant les quelques fonctions d'entrée/sortie orientées caractère de VHDL. Il n'y a pas de commande de pas à pas dans le simulateur, le banc de test en VHDL doit donc être prévu pour tous les cas de figure, ce qui parfois le rend plus complexe. Toutefois cette méthode est saine car elle est entièrement portable et oblige à travailler sérieusement sur les tests. De plus, Simili est maintenant capable d'écrire ou de lire des fichiers en mode binaire comme le fait Vanilla VHDL.
Simili 2 fonctionne avec RedHat 7.1 et Mandrake 8.0. La page de chargement contient des informations à jour détaillant les librairies nécessaires si elles sont absentes. Seules les plateformes Linux/x86 et Windows sont suppportées. Une page du site web de SymphonyEDA est dédiée aux outils gratuits qui ont été développés par des tierces personnes autour de Simili.
Sonata est une interface graphique en Tcl/tk qui vient d'apparaître dans Simili mais la vraie bonne nouvelle est qu'il n'est plus nécessaire de configurer wine ! Les versions précédentes étant des applications Win32 en ligne de commande, l'exécution des programmes était pénalisée par le temps de configuration de wine, ce qui obligeait, pour perdre un minimum de temps, à mettre un maximum de noms de fichiers en paramètre du compilateur.
L'auteur de Simili a permis aux contributeurs F-CPU d'essayer la nouvelle version avant sa sortie officielle. Le portage de ce logiciel sous GNU/Linux a paraît-il été assez difficile mais le résultat est à la mesure de l'attente. L'installation et l'utilisation sont beaucoup plus faciles qu'au temps où il fallait jongler avec les fichiers de configuration et les limites imposées par les chemins de fichiers au format DOS. Une grande partie du HOWTO que j'ai écrit à ce sujet est donc caduc. On remarque cependant l'apparition d'un système de clés (le système de la société GlobeTrotter, FlexLM, est utilisé par la plupart des sociétés d'EDA) qui nécessite une carte Ethernet si Sonata est utilisé.
Simili supporte presque toutes les spécifications de VHDL'93 et 87, sauf celles spécifiées dans la documentation incluse dans la distribution (Doc/vhdl93_readme.html). D'un autre côté, toutes les extensions ne sont pas utiles si Vanilla VHDL ne les accepte pas.
L'installation se résume aujourd'hui aux étapes suivantes :
En comparaison, la procédure d'installation était dix fois plus longue en utilisant wine et Simili15b17. Les scripts de compilation du F-CPU doivent être modifiés mais ce n'est que du nettoyage.
Lors de la première exécution de Sonata, un assistant d'inscription créera une clé temporaire. Cette étape d'enregistrement n'est pas nécessaire et est plus complexe car elle requiert à la fois un accès à Internet (pour générer la clé en contactant le serveur de SymphonyEDA) et une carte Ethernet (pour verrouiller la clé au poste). Je n'aborderai pas cette partie du logiciel puisque les outils en ligne de commande suffisent.
L'utilisation est simple, en deux passes, mais le répertoire de travail est créé automatiquement, contrairement à Vanilla VHDL.
$> vhdlp fanout_tree.vhdl f-cpu_config.vhdl rop2_xbar.vhdl rop2_unit.vhdl test_rop2.vhdl(un répertoire nommé work.sym sera créé)
$> vhdle test_rop2
Si on échappe au problème des librairies manquantes, peut-on faire encore plus simple ?
Les exécutables existent en 2 versions : vv87 (un petit shell) est compilé avec la libc5 en statique, les autres exécutables nécessitent la librairie libc5 en dynamique. Cela peut poser des petits problèmes sur Debian par exemple, où il faudra penser à installer le package de compatibilité. C'est la seule contrainte d'installation connue et si elle n'est pas résolue, vv87 permet encore d'accéder à toutes les fonctions disponibles.
L'installation comporte les étapes suivantes :
$> export PATH=$PATH:~/vanilla4) vérifier que les fichiers suivants s'exécutent correctement : mkvlib, va87, vs87 et vv87 (on peut renommer vanman.ps en Vanman.ps si l'autocomplétion de "va" vous gêne)
Si les exécutables liés dynamiquement ne peuvent pas fonctionner, il est possible
d'exécuter la fonction correspondante en passant par vv87 et en détournant stdin :
$> vv87 < echo "ma commande"Les commandes peuvent être groupées dans un fichier et envoyées de la même manière :
$> vv87 < commandes.scriptLes autres exécutables sont des sortes de "wrappers" de vv87 que l'on peut appeler directement depuis la ligne de commande ou par un script. vv87 est un "shell interactif" qui est plus destiné au développement.
Comme d'autres distributions, Vanilla propose un exemple d'utilisation, décrit dans le manuel au format Postscript (vanman.ps) et accompagné du source de l'exemple dans le fichier mux.v. Un autre exemple simple en anglais peut être trouvé en ligne à http://www.dickinson.edu/~braught/courses/cs251f01/classes/class08.html. Nous allons nous intéresser à un exemple de programmation "réelle" avec le F-CPU.
Pour compiler les sources VHDL, les opérations suivantes doivent être exécutées :
$> mkvlib work3) Compiler les sources :
$> va87 -x fanout_tree.vhdl f-cpu_config.vhdl rop2_xbar.vhdl rop2_unit.vhdl test_rop2.vhdlL'option -x active les quelques extensions VHDL'93 disponible. Si mkvlib n'a pas été appelé, va87 se plaindra d'une librairie introuvable.
$> vs87 work.test_rop2Le programme entre en mode interactif. La commande "run" lance la simulation et "quit" termine le programme. Pour vérifier si le programme est correct, lancer
$> echo run | vs87 work.test_rop2
Vanilla est utilisé autant que Simili pour le projet F-CPU. Son minimalisme restreint certains choix de codage mais il nécessite moins de ressources et s'installe assez facilement. La difficulté vient principalement du fait que deux modes d'utilisation existent, selon la configuration de l'installation. Une configuration standard à base de RedHat 7.1 contient les librairies nécessaires mais dans le doute, les scripts de compilation du F-CPU savent reconnaitre si l'outil fonctionne statiquement pour lui envoyer les bonnes commandes.
La syntaxe supportée par Vanilla VHDL est un peu limitée, ce qui signifie aussi que les sources développés avec Vanilla seront compris par la majorité des outils VHDL. La petite documentation fournie dans la distribution liste les fonctionalités disponibles. Certaines sont implémentées de manière simpliste alors que d'autres sont absentes. Les limites embarassantes identifiées sont (liste non exhaustive) :
- Les fonctions de type "impure" ne sont pas supportées (il faut donc pouvoir éviter les cas où cela est nécessaire).
- Il n'est pas possible d'initialiser un signal avec une fonction
ayant comme argument ce même signal. Par exemple, Simili comprend :
signal a : std_ulogic_vector(7 downto 0) := init(a);
où init() est une fonction qui prend en entrée un std_ulogic_vector.
Ce paramètre est nécessaire pour déterminer la taille du vecteur
à renvoyer, afin de rendre init() indépendant de la taille du vecteur.
Par exemple, la fonction rand() fonctionne de cette manière afin
d'initialiser le coeur dans un état aléatoire pour vérifier sa stabilité.
La solution est d'utiliser une variable, un sous-type intermédiaire
ou même la capacité d'"overload" des opérateurs dans VHDL.
- La taille des vecteurs semble limitée pour certaines opérations pour une raison inconnue. F-CPU en 64 bits est possible mais il faut faire attention au code si on veut aller au-delà.
- Les "shared variable" ne sont pas autorisées à l'intérieur d'un package. Vanilla ne peut donc pas partager des variables globales entre des fonctions ou procédures, à l'exception des fichiers (FILE). Les variables doivent être déclarées à l'intérieur des procédures mais elles ne peuvent pas communiquer. Simili le permet.
GNU/Linux, plateforme des "hackers", est aussi adapté à la conception de circuits électroniques grâce à sa robustesse, sa capacité de scritpage et sa compatibilité avec les UNIX propriétaires plus chers. La majorité des vendeurs s'appuient sur la distribution RedHat 7.1, les distributions SuSE et Mandrake équivalentes doivent donc fonctionner correctement. Pour Debian, procurez-vous la version la plus récente possible. Un "Linux from scratch" nécessitera l'ajout de plusieurs librairies.
Après de nombreux efforts, la première étape de la conception de circuits numériques est enfin possible sous Linux pour les développeurs "Open Source", plus seulement pour "jouer". Avec une méthodologie adaptée, les quelques outils disponibles permettent de concevoir des sources en VHDL portables et de qualité tout en conservant les habitude du travail "ouvert". Les "freeware" permettent d'attendre que les Logiciels Libres soient reconnus au niveau industriel, ce qui est assez lent et pénible à cause du nombre réduit de contributeurs et du caratère particulier de l'industrie de la microélectronique.
L'étape présentée ici concerne la partie "purement logicielle"
de la conception : il manque le reste de la chaine de CAO
(synthèse, vérification et extraction) qui est encore plus dépendante
des "technologies propriétaires". La chaîne Alliance s'intègre
assez difficilement dans une chaine classique et les outils
alternatifs n'existent pas encore. La fabrication d'un circuit
intégré entièrement à partir d'outils libres, portables,
interchangeables, standard, n'est donc pas encore possible.
Les projets comme le F-CPU dépendent donc principalement
de la générosité des leaders industriels. Enfin, fondre un
circuit étant extrêmement cher, les seules opportunités
de fondre un tel circuit sont soit :
Les lecteurs désirant mieux connaitre VHDL sont invités à lire la FAQ située à http://www.vhdl.org/comp.lang.vhdl et de consulter régulièrement le groupe comp.lang.vhdl. De nombreux livres en français et en anglais sont disponibles en librairie, ainsi que de nombreuses ressources gratuites sur Internet (qu'une simple requête sur un moteur de recherche vous indiquera).
Enfin, cet article montre que malgré la faible activité apparente, le projet F-CPU est toujours vivant : la nécessaire dérive vers les questions très techniques peut être rebutante mais le travail continue malgré tout. Vous pouvez rejoindre l'équipe en vous abonnant aux mailing lists anglaise et française : même si vous ne participez pas, il y a toujours une discussion intéressante en cours.
http://www.f-cpu.org :
Site officiel du projet F-CPU. A consulter pour s'abonner aux mailing
lists, malgré le manque d'entretien du site (webmasters bienvenus).
http://www.opencollector.org :
base de ressources en ligne sur les projets "libres" en électronique numérique.
http://www.symphonyeda.com :
site web de Mohammed Haneef et de son logiciel : Simili.
http://linuxfr.org/bouffe/mensuelle/ :
Rendez-vous tous les mois à Paris au "First Jeudi" : des contributeurs du F-CPU
y discutent entre eux et avec d'autres organisations liées au Logiciel Libre.
http://tech-www.informatik.uni-hamburg.de/vhdl :
Ressources en lignes sur le langage VHDL (outils, sources, liens,
tutoriaux, manuels...)
http://freesoftware.fsf.org/download/vhdl-posix/ :
Prototype de couche POSIX pour certains outils commerciaux, avec en prime un
serveur HTTP en VHDL !
L'auteur : Yann Guidon est un artiste aprilien musicomane et chocolatomane, "accessoirement" contributeur du projet F-CPU depuis 1999.