Périphérique Timer 64 bits

Un Timer c’est simple! mais en général, c’est limité à 32 bits. C’est pour cette raison que j’ai mis au point un timer ( en fait un compteur) 64 bits avec commande de capture par programme  et possibilité de lecture en 2 fois 32 bits.

Ce timer est conçu pour être immédiatement intégrable dans un système NIOS Altera ou Xilinx Microblaze ou PowerPC

Dans ces conditions, la capacité du compteur ainsi que sa résolution sont très élevée puisque 2**64 est un nombre considérable.

Vous trouverez tout le matériel (sources , résultat de simulation et petite documentation ici: Timer64

SOC et IP

Bientôt Noël ! C’est le bon moment pour faire un petit cadeau à mes fidèles lecteurs.  Ce qui me reste dans ma hotte, c’est une présentation du monde SOC et IP (dernière mise à jour , début 2009) et surtout une version en français d’un tutoriel NIOS II Altera.

En effet, ma vieille expérience en matière de NIOS ( 1 et 2)  m’a montré que pour chaque nouvelle version logicielle d’Altera, nous était proposé un nouveau tutoriel qui ne correspond jamais au design standard.  Ceci est normal car le fabriquant a besoin de faire la promotion de ses nouveaux produits et on doit d’ailleurs lui être reconnaissant de nous offrir une bonne documentation pour démarrer.

Mais à l’inverse l’utilisateur qui a opté pour une plateforme logicielle à évolution lente doit se donner une méthodologie rigoureuse. La souplesse de Quartus vient encore renforcer ce sentiment. En effet, on peut choisir pour la vue haute (TOP) du projet une description VHDL ou schématique.

C’est pourquoi, le choix que l’on retrouvera dans tous nos travaux pratiques s »appuie sur une description complète de la carte utilisée par un fichier TCL.  Ainsi sera fixé une bonne fois pour toutes le choix du type du composant, les noms et le type des entrées-sorties, les options de compilation éventuelles.  (Voir  Exemple de Fichier TCL)

Pour ceux qui n’ont pas de console TCL (Quartus web edition, je pense), On peut suivre la même démarche en peaufinant un fichier d’affectation des broches.

Histoire ancienne

Compiler du VHDL, c’est implanter de façon puissante ce que l’on appelait autrefois des fonctions logiques combinatoires et/ou  séquentielles.  Sauf que pour le compilateur VHDL la cible n’est pas à proprement parlé une porte mais un élément physique en général de type mémoire (les look-up table pour les FPGA) ou bascule.

Alors est-il encore utile d’enseigner la simplification des fonctions logiques ?  le débat est ouvert car en plus , en général, « à la main » on ne sait simplifier facilement (table de Karnaugh) que des problèmes combinatoires à 6 variables maximum. Le problème d’optimisation de fonctions multiples des mêmes variables est quasi insoluble, bref on est très limité. Mon avis est qu’il faut garder des bases pour introduire à la compréhension des logiciels que l’on va utiliser et c’est tout !

Je pratique les circuits numériques depuis leur début et ai pu suivre et accompagner leur évolution. A la fin des années 60, on faisait encore des circuits logiques  avec des transistors ( je pense aux technologies DTL, TTL, ECL). Le seul outil de conception était le papier et le crayon , et donc les méthodes de simplification de fonction (Karnaugh, Consensus) étaient de la plus haute importance.

Ensuite , sont venus les premiers circuits intégrés, les outils de CAO proposaient comme entrée la schématique et l’on devait déposer une porte , une bascule, un compteur qui allaient exister tel quel.  On ne se privait pas d’ailleurs d’introduire quelques bidouilles comme générer des impulsions calibrées en largeur au moyen d’une porte ET recevant une entrée et la même inversée n fois (équation logique de type A et /A = 0), opération  impossible à faire en synthèse VHDL car tout de suite optimisé comme 0).

C’est dans ce dernier contexte que m’était venu le besoin d’optimiser les circuits et donc de bénéficier d’un logiciel de simplification de fonctions . Ainsi est né FACILOG, une antiquité maintenant mais qui garde l’avantage d’expliciter de façon formelle les équations logique des fonctions combinatoires ou des machine d’états.

Les sources (C) de FACILOG sont disponibles et ce programme ne demande qu’à trouver une autre jeunesse. En particulier à l’époque pas ou peu de graphique, donc l’interface est uniquement texte,  de plus les noms des variables ont été automatisées pour simplifier, bref, on pourrait grandement l’améliorer tout en gardant l’idée de départ. Disposer en quelque sorte d’une calculette dédiée aux circuits logiques.

Tout en un seul fichier

Dans certaines circonstances,  pour une raison de documentation plus lisible, on peut être tenté de placer les informations de placement / routage directement dans le fichier source VHDL au lieu de les fixer dans les outils dédiés.

On perd de ce fait, l’aspect portable du VHDL qui devient dépendant de la cible utilisée. Cela peut cependant être admis , au moins de façon temporaire pour des petits projets non évolutifs.

Le fichier copie.vhd  indique la syntaxe employée pour une entrée et une sortie dans le cas d’un projet  Xilinx ise (pour plus de détails , voir doc Xilinx cgd.pdf page 35).

Avec une syntaxe très proche, on peut faire la meme chose pour un projet Altera / quartus. Voir le fichier copie_altera.vhd

On peut aller plus loin et fixer la place d’un élément ou des contraintes pour le routage.

Bref, avoir tout le projet documenté dans le fichier source VHDL

Picoblaze

Décrire du matériel ou du logiciel est une tache longue qui demande beaucoup de test de validation. Si l’on veut un tant soit peu progresser, il est tout à fait nécessaire d’engranger l’expérience acquise sous forme de modules réutilisables à volonté (c’est le design reuse). On ne fait que redire sous une autre forme la nécessité de structurer les projets.

Parmi les tâches répétitives dans les projets de conception de cartes électroniques, l’interfaçage avec des éléments classiques tels que  écran, clavier, port série etc… sont les plus fréquentes.  Or le niveau de complexité de ces interfaces (un écran LCD est un bon exemple)  demande de mettre en œuvre des temporisations, un séquencement intelligent et un contrôle de l’ensemble qui n’est pas simple. Concevoir le tout, cela revient en quelque sorte à concevoir un microcontroleur spécifique.

Une solution efficace consiste dans ce contexte à utiliser un composant programmable  type microcontroleur 8 bits comparable au pic ( voir article Tp Pic).

Dans cet ordre d’idée, la société Xilinx propose un tel microcontroleur optimisé pour ses séries Spartan et Virtex, c’est le picoblaze. On en trouvera une présentation résumée ici.

Nous avons développé une application d’affichage  de messages sur un écran LCD.   Ce petit projet permet de s’initier au picoblaze en tant que composant programmable. On pourra en particulier juger de la documentation et des sources picoblaze, apprécier l’outil d’assemblage du code, enfin  comparer le résultat à la solution « tout VHDL » en termes de surface occupée mais aussi temps passé au développement et évolution possible.

Signaux virtuels (modelsim)

Nous, pauvres électroniciens, sommes souvent rebelles à ce qui nous semble trop d’informatique. Et pourtant, ce vieux TCL utilisé comme langage de commande dans Modelsim, Quartus , partout où on le souhaite, comme il peut nous simplifier les projets! Parmi ses nombreuses possibilités,  Modelsim offre celle de créer des signaux « virtuels » utiles chaque fois que l’on veut afficher quelque chose de non standard.

C’est le cas lorsqu’on travaille sur un projet comportant un processeur. Si l’on veut visualiser en simulation le bon déroulement d’un programme, il est fastidieux sinon quasiment impossible de se contenter de l’opcode binaire ou hexadécimal. L’outil simulation se présente alors comme passablement inadapté.  Si le code machine est suffisamment structuré en champs de bits, il est par contre possible de se fabriquer un désassembleur qui, appliqué à ce même code, pourra, via un signal virtuel, afficher en clair les mnémoniques. Muni du fichier listing assembleur, on pourra aisément alors se repérer.

Nous en avons un bon exemple dans le fichier virtual.do du projet PIC. On commence (virtual type) par définir un type énuméré dont les 64 éléments sont tous les mnémoniques possibles classés selon leurs 6 bits de codage. Ensuite, on définit un signal virtuel correspondant au champ de ces  6 bits (virtual signal). Enfin on crée un nouveau signal qui va extraire l’élément énuméré (comme un élément de tableau) et donc le mnémonique de l’intruction à afficher (virtual function).

TP PIC

Il y a quelques années,  je voulais monter un TP de sensibilisation aux systèmes sur puce. Où trouver un modèle VHDL de processeur ? Quelle méthodologie employer pour le porter sur un FPGA ? Quel est le bilan comparativement à une solution totalement faite sur mesure ? Quel serait le gain d’une solution intégrée de processeur embarqué ?

Les étudiants auxquels je m’adressais ayant une connaissance  du composant PIC de Microchip et comme par ailleurs deux modèles VHDL (totalement « soft »)  étaient disponibles sur le site en open source opencores.org, mon choix se fit naturellement sur ce composant.

Contrairement à d’autres expériences tout à fait heureuses de modèles opencores.org, le modèle de PIC choisi s’est avéré comporter quelques défauts.  Ceci m’a fourni la trame d’un TP  PIC: Synthétiser une application avec le modèle d’origine; Constater le défaut; Effectuer une simulation pour en trouver l’origine; Corriger le défaut et réimplanter.

On peut ainsi se faire une idée des cotés positifs mais aussi des risques du « design reuse », l’avantage essentiel étant que le projet final est totalement maitrisé et portable puisqu’on possède toutes les sources VHDL.

On trouvera les détails de cet ancien TP remanié ici

Premier projet

Afin de servir de base d’apprentissage du langage, des outils et du savoir faire VHDL de synthèse, je vais définir un projet simple pour tous qui puisse être testé sur n’importe quelle carte de développement.

Un projet trop simple présente cependant l’inconvénient de ne pas avoir de contraintes sévères et donc de s’éloigner du monde « réel » . En compensation, on veillera à estimer les performances (fréquence maximale de fonctionnement et surface occupée) comme si elles étaient primordiales. On essaiera de noter chaque fois qu’il aura lieu les solutions alternatives. En particulier, une solution à base de processeur pourra être introduite.

Pour moi, le projet minimal doit comporter une machine d’état, un compteur, des entrées-sorties.

Après avoir posé le cahier des charges du projet, on effectuera uns structuration de l’ensemble ( découpage en blocs), puis l’écriture de chaque bloc, les différentes simulations, le placement-routage et la simulation post-routage, puis le test sur une carte.

Cette méthodologie peut paraitre lourde pour un petit projet ( vis à vis de la puissance du langage VHDL) mais entre un projet réel et un projet de débutant, la seule différence est l’éffort à apporter à la structuration de l’ensemble ( et cela, ce n’est pas le VHDL qui va le résoudre). Donc, ce qui est important c’est d’avoir une méthode rigoureuse.

Personnaliser Quartus Altera

En matière de saisie VHDL, nous avons avant tout deux revendications:

  • Pouvoir utiliser Emacs comme éditeur VHDL
  • Travailler prioritairement avec les bibliothèques std_logic_1164 et numeric_std, cette dernière étant la plus rigoureuse en matière de types numériques.

Quartus nous propose dans Tools>Options un certain nombre de possibilités.

  • En ce qui concerne Emacs, on sélectionne text editor et on indique le chemin complet de l’exécutable.Options quartus

Un bon point pour quartus, car à partir de ce moment, emacs sera appellé pour toute opération VHDL comme File > New> VHDL File

Par contre, il ne semble pas possible de fixer par défaut les bibliothèques VHDL que l’on préfère. On le fera très simplement dans emacs.

En conclusion:

  • Emacs est fixé comme éditeur préféré
  • Pour créer un nouveau source, on crée le fichier nouveau.vhd dans emacs par la commande File > New> VHDL File
  • On rajoute les bibliothèques ( VHDL>Template>package)
  • On décrit l’entité et l’architecture
  • On sauve

Personnaliser Xilinx ISE

En matière de saisie VHDL, nous avons avant tout deux revendications:

  • Pouvoir utiliser Emacs comme éditeur VHDL
  • Travailler prioritairement avec les bibliothèques std_logic_1164 et numeric_std, cette dernière étant la plus rigoureuse en matière de types numériques.

Xilinx ISE nous propose dans Edit>preferences un certain nombre de possibilités.

  • En ce qui concerne Emacs, on sélectionne text editor et on indique une ligne de commande pour Editor: custom runemacs.exe $1 $2

Ceci implique que l’on ait bien précisé dans son « Path » le chemin d’accès au logicile emacs. Exemple windows: Paramètres> panneau de configuration> Systeme>Avancè>Variables d’environnement puis Path> modifier on rajoutera sur la decription path ;c\logiciel\emacs-21_bin (si emacs a été installé de cette manière).

Fermer le navigateur ISE, relancer et tout fichier VHD sera ouvert dans emacs.

Preferences emacs

  • Si l’on sélectionne la ligne ISE Text Editor on voit par contre une option de bibliothèques( celles que préfère xilinx) non modifiables qui sont inclues chaque fois qu’on passe par le menu Project>new source) . Ayant changé d’éditeur et préférant une autre bibliothèque, on va préconiser d’ignorer ce menu.

En conclusion:

  • Emacs est fixé comme éditeur préféré
  • Pour créer un nouveau source, on crée le fichier nouveau.vhd dans emacs, on rajoute les bibliothèques ( VHDL>Template>package)
  • On décrit l’entité et l’architecture
  • Puis dans le navigateur on lie le fichier au projet par project>Add source

Morale: Contrairement aux synthétiseurs universels, les outils intégrés brident les possibilités du langageVHDL.