Very High Speed Integrated Circuit Hardware Description Language/Utiliser des systèmes mono-puce en verilog

Leçons de niveau 16
Une page de Wikiversité, la communauté pédagogique libre.
Début de la boite de navigation du chapitre
Utiliser des systèmes mono-puce en verilog
Icône de la faculté
Chapitre no 12
Leçon : Very High Speed Integrated Circuit Hardware Description Language
Chap. préc. :Améliorer l'ATMega8 avec l'ATMega16 et l'ATMega32
Chap. suiv. :Programmer in Situ et déboguer
fin de la boite de navigation du chapitre
En raison de limitations techniques, la typographie souhaitable du titre, « Very High Speed Integrated Circuit Hardware Description Language : Utiliser des systèmes mono-puce en verilog
Very High Speed Integrated Circuit Hardware Description Language/Utiliser des systèmes mono-puce en verilog
 », n'a pu être restituée correctement ci-dessus.

Ce chapitre sur verilog peut sembler inopportun dans un cours sur VHDL. Pourtant il faut avoir à l'esprit que ne pas s'autoriser à utiliser du verilog dans des projets autour de cœurs libres risque de nous couper d'un certain nombres de projets intéressants. Pour éviter cette situation, nous allons présenter les rudiments de verilog qui permettent de commencer à utiliser un cœur libre.

Utiliser un composant verilog dans un projet VHDL[modifier | modifier le wikicode]

La majorité des systèmes de développement modernes permettent de mélanger les deux langages VHDL et verilog. Il n'y a pas grand chose à savoir sur verilog pour en faire un composant.

Cependant, les composants que l’on utilise dans ce cours sont un peu spéciaux car il s'agit de processeurs. Ainsi, ce n’est pas toujours une bonne idée que d’utiliser le processeur comme composant. Ceux d'entre-vous qui ont lu le chapitre précédant sur l'ATMega8 ont pu remarquer que travailler sur ses PORTs se faisait à l'intérieur du processeur (dans le fichier io.vhd).

Essayons de faire un peu le bilan de ce qui a été réalisé jusqu'à maintenant, pour ajouter des PORTs connectés vers l'extérieur à travers les différents projets déjà présentés :

  • pour le picoBlaze cela peut se faire de l'extérieur et par conséquent disposer d'un picoBlaze en verilog n’est pas pénalisant en ce sens qu’il ne nécessite pas la lecture du code verilog.
  • pour le CQPIC en final cela ressemble au travail sur le picoBlaze mais parce que nous avons profondément changé le cœur ! Nous ne sommes pas sûr que ce travail aurait été fait si facilement s'il avait été écrit en verilog.
  • pour l'ATMega8 la gestion des PORTs se fait à l'intérieur du cœur, comme nous venons de le voir.

Il n'y a donc pas de règle générale pour ce travail !

Bien, avant de commencer, signalons que nous avons utilisé

Examinons maintenant quelques projets verilog.

Le projet risc16F84[modifier | modifier le wikicode]

Le projet CQPIC déjà évoqué dans ce livre dans un autre chapitre a donné naissance à ce projet risc16F84. Il peut être téléchargé chez Opencores. Mais risc16F84 est plus récent et par certains aspects bien plus avancé que le projet d'origine. Il propose en fait quatre versions que nous allons décrire tour à tour.

Les quatre versions[modifier | modifier le wikicode]

La première version est une traduction verilog du cœur CQPIC. Pour les autres versions laissons la parole à son auteur.

Clayton John (US), l'auteur de ce projet écrit : cependant j’ai réalisé au fil du temps qu'une personne utilisant un Microcontrôleur dans un FPGA n'a pas les mêmes contraintes (i.e. sur la taille des ports, le nombre de broches, les fonctions multiples de chacune des broches) que le concepteur du composant et j’ai ainsi pris quelques libertés sur les trois autres versions pour simplifier la logique en retirant des fonctionnalités qui ne sont pas voulues dans le FPGA ou l'ASIC. Par exemple il y a une version appelée "risc16f84_lite.v" qui n'a aucune interface avec l'EEPROM...

Une autre version, appelée "risc16f84_small.v" élimine les multiples sources d'interruptions présentes dans le composant CQPIC d'origine (puisque de toute façon il n'y a qu'un seul vecteur d'interruption, et qu'ainsi les routines doivent vérifier la source de l'interruption - pourquoi s'embêter à avoir des sources séparées? Faites votre propre structure de gestion des interruptions comme vous le voulez dans votre composant!)

Finalement la quatrième version, appelée "risc16f84_clk2x.v" retire aussi les interfaces du port A et du port B, et qu'ainsi vous pouvez créer autant de ports que vous voulez dans ce composant. À cette fin, "risc16f84_clk2x.v" inclut aussi une interface bus auxiliaire, permettant au microcontrôleur d'accéder à 64k octets de registres de ports de périphériques, tous définis dans leur propre espace d'adressage -- pas dans l'espace limité du microcontrôleur PIC. Je l'ai utilisé pour adresser un écran de 12288 pixels, et chaque pixel avait sa propre adresse. Il est aisé de définir les adresses pour ce bus auxiliaire dans tous les outils de synthèse, ainsi ceci fonctionne très bien.

L'évolution la plus importante pour nous semble être la quatrième version. Son nom associé à "_clk2x" signifie d'ailleurs qu’il fonctionne deux fois plus vite que la version originale de CQPIC. C'est cette version que nous allons donc mettre en œuvre.

Le risc16f84_clk2x[modifier | modifier le wikicode]

Le projet openMSP430[modifier | modifier le wikicode]

MSP430 est le nom d´une famille de microcontrôleurs de la marque Texas Instruments.

Notez que dans le chapitre Utiliser un processeur externe, dans la section Processeur MSP 430 et SPI, nous utilisons un MSP 430 du commerce.

Mais nous allons pour l’heure nous intéresser au cœur MSP430, version Verilog de ce processeur. Ce projet est un des plus intéressants chez OpenCores. Il est en effet très avancé au niveau chargement de programme et débogage, sujets que nous aborderons dans le chapitre suivant.

Les instructions sont décrites dans la page anglaise consacrée au MSP430. Il y en a 27 (ce qui est relativement peu) auxquelles on ajoute des instructions émulées au nombre de 24.

Téléchargement du projet[modifier | modifier le wikicode]

Sous Linux il est possible de récupérer le projet avec :

svn export http://opencores.org/ocsvn/openmsp430/openmsp430/trunk/ openmsp430

commande qui nécessite d’être inscrit puisqu'on vous demandera votre mot de passe.

Pour commencer, le projet tout prêt[modifier | modifier le wikicode]

Pour éviter de trop chercher pour commencer, nous allons nous contenter de faire tourner le projet tout prêt pour notre carte.

Compilation d'un programme C[modifier | modifier le wikicode]

Si vous avez vraiment besoin d'un environnement intégré, vous pouvez télécharger la version gratuite du Code Composer Studio qui est limitée à une taille de code de 16 ko ce qui est largement suffisant pour nos besoins. Il en existe une version pour Windows et une version pour Linux.

Sinon, pour installer le compilateur C sous Linux, vous pouvez lire l’article (en anglais) de Linux Magazine. L'installation avec une Ubuntu peut se faire différemment :

sudo apt-get install gcc-msp430

.

Si vous ne possédez pas d'IDE, il vous faudra apprendre à utiliser la compilation en ligne de commande. En voici un exemple :

msp430-gcc -mmcu=msp430x149 -O2 -Wall -g   -c -o main.o main.c
msp430-gcc -mmcu=msp430x149 -o leds.elf main.o
msp430-objcopy -O ihex leds.elf leds.a43
msp430-objdump -dSt leds.elf >leds.lst

Un autre environnement de développement de plus en plus populaire est Energia. C'est un portage de l'environnement Arduino, c’est-à-dire que l’on peut programmer avec le style Arduino. Le problème est que cet environnement ne connaît pas le composant msp430x149. Nous regarderons un peu plus tard si cela peut se faire facilement en modifiant le fichier Boards.txt comme dans le monde Arduino.

Voir aussi[modifier | modifier le wikicode]

Il est important de signaler une version VHDL du MSP430. Les deux projets n'ont aucun point commun et ne sont pas réalisés par les mêmes auteurs.

Voir aussi[modifier | modifier le wikicode]

Dans le chapitre Utiliser un processeur externe de ce livre, nous utilisons dans la section Processeur ATMega avec Arduino et protocole i2c un esclave i2c en Verilog.