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

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

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é
* i2c slave qui est un esclave i2c chez Opencores écrit en Verilog dans un autre chapitre : Utiliser un processeur externe avec Arduino et protocole I2C.
Examinons maintenant quelques projets verilog.

## Le projet risc16F84

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

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
## Le projet openMSP430

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

Sous Linux il est possible de récupérer le projet avec :
commande qui nécessite d’être inscrit puisqu'on vous demandera votre mot de passe.

### Pour commencer, le projet tout prêt

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

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 :
Si vous ne possédez pas d'IDE, il vous faudra apprendre à utiliser la compilation en ligne de commande. En voici un exemple :
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.