# Very High Speed Integrated Circuit Hardware Description Language/Utiliser un processeur externe

Nous allons présenter dans ce chapitre un certain nombre de solutions consistant à déporter le processeur vers l'extérieur. Quand nous avons commencé l'écriture de ce livre nous ne pensions pas en arriver là... mais quelques prises de consciences nous ont fait changer d'avis :
* la baisse continue des prix des microcontrôleurs du commerce. On trouve maintenant des platines de développement 16/32 bits à moins de 20 € (chez Texas Instrument notamment en 2015) et moins de 10 € en 2022 pour un ESP32 malgré la crise des semi-conducteurs du Covid en 2020.
* la réalisation de projets autour de la robotique mobile nous amène à augmenter la taille de notre processeur. Ainsi un processeur 32 bits permet de faire assez facilement des calculs en nombre flottant.
* une étude de 2008 (EETimes 30 juillet 2008) montrait que seulement 1/3 des utilisations de FPGA utilisant un processeur utilisait ce processeur dans le FPGA. Les choses ont probablement changées depuis : il semble que l’on soit passé à 50% en 2014.
L'étude de EETimes ci-dessus tentait d'examiner des pistes pour interfacer les deux mondes du micro-contrôleur et celui du FPGA en soulignant qu’à priori aucun des deux n'est prévu pour cela.
Nous allons examiner dans ce chapitre les communications entre un processeur du commerce et le FPGA qui ne sera considéré donc que comme un périphérique. Dire périphérique ne veut pas dire sans aucune intelligence. Ainsi un petit processeur pourra se glisser dans ce FPGA et être responsable de la communication avec le processeur externe !
Les communications que nous envisageons d'étudier pour le moment sont le protocôle SPI et le protocole i2c. Le domaine des 32 bits sera peut être approfondi un jour prochain avec le bus External Bus Interface (EIB) que l’on peut rencontrer sur ce type de micro-contrôleur de type ARM.
Pour rendre ce chapitre intéressant à un public le plus diversifié possible, nous sommes obligés d’utiliser plusieurs architectures différentes allant du 8 au 32 bits. Nous espérons que, même si vous ne disposez que d'une architecture différente, vous trouviez ici suffisamment d'informations pour un portage utile pour vous. Nous rappelons que vous pouvez aussi rédiger un chapitre ou une simple section concernant votre architecture... ce qui pourrait être utile à d'autres lecteurs.

## Les connecteurs PMod

Les FPGA que nous utilisons sont sur des cartes d'évaluation réalisées par Digilent. Elles sont caractérisées par des extensions appelées PMod que nous allons présenter maintenant.

### Utilisation simple des PMod

Parmi les périphériques que l’on peut acheter pour les FPGA, il en existe un certain nombre avec des connecteurs PMod. Ils sont alors très faciles à mettre en œuvre avec ou sans câble. Le seul point qu’il faut surveiller est de ne pas le brancher à l’envers. Pour s'y repérer il suffit de savoir que d'un côté du connecteur vous avez tout au bout Vcc et à côté la masse gnd. Si vous repérez cela des deux côtés, c’est gagné. La photo ci-dessous, par exemple, montre la connexion de deux périphériques de puissance (non visibles) à la carte FPGA. Allez voir dans le chapitre Commande de robot mobile et périphériques associés d'autres photos disponibles.

### Utilisation avec périphérique non adapté

Nous avons déjà publié dans le chapitre Commande de robot mobile et périphériques associés une série de photos montrant l’utilisation d'un PMod pour connecter une manette Nunchuk. Nous en reprenons une ci-dessous.
Vu le positionnement de notre connecteur blanc sur le PMod, l'alimentation Vcc = 3,3 V se trouve à gauche du connecteur lorsqu'on le regarde de face. De toute façon, il est bon de se rappeler que Vcc est en bout. C'est le fil orange de la photo.
Puisque nous commençons à aborder les notions de droite et gauche des connecteurs PMods, vous devez garder à l'esprit que cette notion est définie quand on regarde le PMod de l'extérieur vers la carte FPGA, comme par exemple sur la photo ci-dessus.
Lorsque le connecteur PMod est double (c'est souvent le cas sur les cartes plus récentes comme Nexys 3, la nouvelle Basys 3 et d'autres encore) les deux Vcc sont superposés (en face à gauche).

### Utilisation avec plaque à essai

Cette façon de faire est à conseiller lorsque vous chercher à réaliser une connexion entre un de vos propre périphérique et une carte FPGA.
* La tension d'alimentation des FPGA est 3,3 V. Ne présentez jamais une tension de 5V sur une entrée FPGA.
Cette utilisation ne nécessite pas d'explication supplémentaire sinon que le mieux est d’utiliser des fils de connexions Digilent, ceux que l’on voit sur la photo entre la Basys2 et les commandes des moteurs. L'achat de périphériques PMod vous fournit automatiquement ce genre de connectique. Si vous n'avez pas l'intention d'investir dans des périphériques PMod, utilisez de simples câbles males-males pour plaques à essais.

### Trouver les contraintes à mettre dans le fichier ucf

Les fichiers ucf que l’on télécharge dans la page des platines FPGA sont suffisamment commentés pour être facilement utilisables. La convention pour les PMods doubles est que l’on commence par le haut (et du côté opposé à Vcc). Par exemple, si vous avez :
alors JA<0> est en haut côté droit du connecteur PMod (lorsqu'on est en face), JA<1> est un cran vers la gauche ... JA<4> est en bas à droite ... et JA<7> est en bas à gauche avant la masse.
* Les numéro de gauche du fichier de contraintes (le 0 de JA<0> par exemple) ne correspondent pas aux numéros de broches de la figure : JA<0> correspond à JA1 (à droite). Ce sera toujours une source de confusion, mais il faut vous y habituer.
* Tous les numéros dans les tableaux ci-dessous correspondent aux numéros du dessin.
Si on vous dit que le câblage du PMod a été choisi comme (voir plus loin par exemple) :
| SPI | -- | -- | MOSI | MISO | SCK | SS |
| PMOD | 12 (Vcc) | 11 (GND) | 10 | 9 | 8 | 7 |
cela veut dire que SS est en broche 7 du connecteur Pmod, c'est-à-dire en bas à droite.

## Processeur ATMega avec Arduino et SPI

Nous commençons par utiliser l'Arduino parce que c’est probablement une des architectures les plus utilisées actuellement parmi les architectures modestes de 8 bits. Elle est caractérisée par une facilité exemplaire de programmation et des prix attractifs (autour de 20 €). Ce prix ne fera que descendre dans les années suivantes.

### Présentation de l'Arduino utilisé

L'Arduino en général est décrit aussi dans un chapitre du livre sur les AVR de la Wikiversité. Mais il est décliné en plusieurs versions.
Nous avons choisi la Platine "Pro Micro - 3,3 V/8MHz" de chez Sparkfun. Ce choix est essentiellement lié au fait que la platine est en 3,3 V et donc directement compatible avec le FPGA, ce qui n’est pas le cas de la majorité des platines Arduino. L'inconvénient associé à cette baisse de tension d'alimentation est le passage de sa fréquence d'horloge de 16 à 8 MHz, ce qui reste largement suffisant pour ce que nous prévoyons de faire dans cette section.

#### Vous ne possédez pas cette platine

Si vous avez déjà une platine Arduino, elle est probablement en 5V, donc pas compatible au niveau des tensions avec le FPGA. Ne vous découragez pas pour autant, les tensions peuvent être adaptées.
Les sorties du micro-contrôleur peuvent être adaptées avec un simple diviseur de tension avec deux résistances (10k et 20k) pour ne pas détériorer le FPGA. La sortie du FPGA peut être branchée directement en entrée du micro-contrôleur mais cela nécessite un test pour être sûr que ce dernier considère le 3,3 V comme un 1 logique.
On peut aussi réaliser une adaptation bidirectionnelle. Ce genre d'adaptation est décrit par exemple dans ce lien. Considérez particulièrement celle qui utilise un FET (2N7000) et deux résistance de 10k, adaptation que nous avons eu l’occasion de tester.

#### La conversion analogique/numérique

Une des applications pratiques à l'interface FPGA micro-contrôleur est l’utilisation des convertisseurs analogiques numériques présents dans la majorité de ces derniers. C'est ce que nous avions l'intention de réaliser dans le projet PMod Processeur pour une liaison série sur la Basys 2. Notez que cette technique existe aussi dans certaines cartes FPGA comme la MOJO 3.0. En effet cette carte est architecturée autour d'un ATMega32U4 et d'un FPGA Spartan6. Il est possible de récupérer les valeurs des convertisseurs Analogiques Numériques dans le FPGA.
Utiliser le langage Arduino pour lire une valeur analogique est très simple. Il existe une primitive appelée "analogRead". Rappelons pour être complet que les convertisseurs des ATMega sont sur 10 bits.

### Complément sur l'installation Linux

Le site de Sparkfun, le hookup Guide n’est pas complet pour la programmation de la Platine "Pro Micro - 3,3 V/8MHz". Ajouter les cartes sparkfun à l'aide du fichier fourni ne suffit pas. Des lignes sont à mettre dans le fichier "46-arduino.rules" dans /etc/udev/rules.d :
Suivies par un
elles permettent une programmation et une utilisation de la liaison série.
Depuis la rédaction de cette section, nous avons rencontré une installation Linux Ubuntu qui n'a pas nécessité ces changements... contrairement à notre version un peu plus ancienne. À vous de faire les tests correspondants...

### Présentation du protocole SPI

La programmation SPI dans le monde Arduino est facile. Mais sa mise en œuvre avec un FPGA nécessite une bonne compréhension de ce protocole.
L'article Serial Peripheral Interface de Wikipédia présente le protocole correspondant.
Des étudiants de l'IUT de Troyes ont travaillé sur ce type de projet et ont écrit quelques lignes ici.

#### La programmation SPI

La programmation SPI du côté Arduino ne présente donc pas de difficulté particulière.
Voici donc un programme Maître (langage C) d'exemple :
Il peut être utilisé pour un début d'exploration.
Si vous voulez tester la communication bidirectionnelle du SPI, remplacez la boucle ci-dessus par celle-ci :
Cette version bidirectionnelle avec une division seulement par deux de l'horloge a été testée en échange SPI avec une Nexys 3 avec succès (recopie des interrupteurs sur les LEDs avec une seconde de retard à cause du delay qui peut être naturellement supprimé).
Nous n'avons pas réussi à faire fonctionner le transfert bidirectionnel avec
mais seulement en recopiant la variable de réception recievedData dans la variable à envoyer dataToSend (comme dans le programme juste au-dessus de cette remarque).
Examinons donc maintenant ce que nous devons faire côté FPGA pour y réaliser un esclave SPI.

#### Esclave SPI sur FPGA

Nous avons décidé de ne pas construire notre propre esclave mais d’en chercher un sur opencore : SPI Master Slave de Jonny Doin. Téléchargez-le. Nous avons ensuite écrit un composant général contenant cet esclave que voici :
Ce qui est donné ci-dessus permet un échange bidirectionnel entre l'Arduino Maître et le FPGA esclave.
Le fichier de contrainte correspondant est (pour une Nexys3) présenté dans la boite déroulante ci-dessous :
Il vous montre que l’on a utilisé le connecteur PMod nommé JC (partie basse).
Le câblage du PMod a été choisi comme :
| SPI | -- | -- | MOSI | MISO | SCK | SS |
| PMOD | 12 (Vcc) | 11 (GND) | 10 | 9 | 8 | 7 |
et nous avons utilisé la partie inférieure du connecteur en reliant la masse mais pas la source de tension : le FPGA et l'Arduino ont tous les deux leur propre alimentation par l'USB.
Le site de Sparkfun, le hookup Guide, vous permet de déduire une connexion que l’on représente dans un tableau qui met en correspondance les broches du Sparkfun Pro Micro avec le PMOD de Digilent pour un bon fonctionnement.
| Sparkfun Pro micro | -- | GND | 16 | 14 | 15 | 10 |
| PMOD (Digilent) | 12 (Vcc) | 11 (GND) | 10 | 9 | 8 | 7 |
En clair les deux tableaux peuvent être fusionnés comme ceci :
| SPI | -- | -- | MOSI | MISO | SCK | SS |
| PMOD | 12 (Vcc) | 11 (GND) | 10 | 9 | 8 | 7 |
| Sparkfun Pro micro | -- | GND | 16 | 14 | 15 | 10 |
Ce tableau signifie que la broche Arduino (Sparkfun) qui porte le numéro 10 est reliée à la broche numéro 7 du PMod. Cette broche est à l'opposé de Vcc sur le connecteur PMod inférieur.
Vous serez obligé d'adapter la partie PMOD à votre carte FPGA et à votre choix de PMOD dans votre fichier ucf. Il est donné plus haut mais nous rappelons la partie concernée :
Le connecteur PMod sur la carte Nexys 3 qui nous a servi à faire les essais est double : une partie haute et une partie basse. C'est pour cela qu’apparaît "Connecteur bas" dans les commentaires de ce fichier ucf.
Le "CLOCK_DEDICATED_ROUTE" apparaissant dans le fichier ucf signifie que l'horloge fabriquée par l'Arduino maître va être directement utilisée dans le FPGA comme horloge (c'est-à-dire avec des "if rising_edge(sck)"). Or cette horloge ne sera pas unique : s'il y a un processeur dans le fpga il aura aussi la sienne. Ces deux horloges n'ayant aucun rapport entre elles doivent être alors maniées avec précautions. Le terme générique pour désigner ces problème est clock domain crossing en anglais et nous ne savons pas traduire exactement cette expression (traversée des domaines d'horloge peut-être).
Pour éviter ce genre de problème on échantillonne l'horloge en principe. Tel n'a pas été le choix de l'auteur du module SPI utilisé. Il peut ainsi fonctionner à plus grande vitesse. Mais pour le cœur i2c utilisé plus loin, l'échantillonnage a été réalisé. Normal la fréquence d'horloge de l'i2c est souvent 100 kHz.

### Projets associés

* PMod Processeur pour une liaison série sur la Basys 2 décrit un projet qui associe l'Arduino Pro Micro de Sparkfun et une Basys2 en vue d'une installation sur une base robotique mobile

## Processeur ATMega avec Arduino et protocole I2C

Nous utiliserons encore la Platine "Pro Micro - 3,3 V/8MHz" de chez Sparkfun et restons donc dans le monde Arduino.
Nous allons nous intéresser maintenant au protocole I2C. L'intérêt de ce protocole par rapport au SPI est la notion d'adresse : chaque périphérique a une adresse particulière. Cela permet de réaliser plusieurs périphériques dans notre FPGA et de les adresser individuellement. En principe le SPI nécessite une ligne SS (Slave Select) par esclave et cela prend vite des broches. L'étude de la manette Nunchuk dans ce livre utilisait le FPGA comme i2c maître alors que nous allons plutôt l’utiliser en esclave dans cette section.
* i2c master slave de Eli Smertenko chez Opencores en VHDL, mais contrairement à ce que suggère son nom l'esclave n’est pas implanté en tant que module séparé
* i2c slave est un esclave i2c chez Opencores écrit en Verilog
* et un autre esclave i2c lui aussi en Verilog
Le dernier esclave est trop rudimentaire pour être utilisé, le premier nécessite un travail important. Nous choisissons donc le deuxième même s'il est en Verilog. Rappelons à ce propos que nous avons commencé à écrire un chapitre sur le sujet (mariage VHDL et Verilog) qui n’est pas encore très avancé. Le deuxième a été choisi aussi parce qu’il dispose de 4 octets en entrée et de 4 octets en sortie. Cela nous semble suffisant même si l'exemple donné plus loin n'en utilise qu'un seul en entrée et sortie.
Pour information la librairie Arduino pour l'i2c fixe la fréquence du maître à 100 kHz. Si vous voulez une fréquence plus grande il faudra :
* changer la fréquence dans la librairie Arduino
* ou utiliser votre propre librairie C
Le câblage a été choisi comme :
| I2C | -- | -- | -- | -- | SCL | SDA |
| Sparkfun Pro micro | -- | GND | -- | -- | 3 | 2 |
| PMOD (Digilent) | 12 (Vcc) | 11 (GND) | 10 | 9 | 8 | 7 |

### Programmes Arduino de lecture/écriture pour l'esclave FPGA

Nous allons distinguer dans un premier temps la lecture et l'écriture.

#### Écrire une valeur sur les LEDs

La situation est donc la suivante : on dispose d'un cœur FPGA réalisant un esclave i2c d'adresse 0x3C. Il est câblé de telle manière qu'un de ses registres de sortie (il peut en avoir jusque 4) est relié à des leds.
Le programme suivant :
fonctionne parfaitement avec le cœur FPGA décrit plus loin.
Nous avons passé beaucoup de temps pour ajouter le Wire.write(0) qui est absolument obligatoire à cause du fait que le premier registre dans lequel on écrit est en adresse 0.

#### Écrire une valeur sur les LEDs en C pur

Nous avons testé le programme ci-dessous avec succès. Il utilise une librairie simple écrite par Peter Fleury :
Il est naturellement possible de mélanger le langage Arduino avec cette librairie, par exemple comme ceci :
Pour ceux qui veulent la librairie complète, la voici :

#### Lecture de données en provenance de l'esclave

L'esclave est un FPGA pour lequel 4 registres sont disponibles en lecture. Le programme suivant :
permet de récupérer les valeurs des interrupteurs et les valeurs câblées en dur dans notre périphérique i2c.
Une question vient peut-être à l'esprit du lecteur : comment réaliser Wire.requestFrom(0x3C, 4); avec la librairie C ?
Voici donc un exemple qui mélange le langage Arduino et le C (surtout pour avoir à disposition la liaison série) :
Hormis un petit problème sur notre carte FPGA avec un bouton switch, tout semble fonctionner normalement.

#### Voir aussi

* Autre librairie C pour AVR
* librarie i2c spécialisée pour AVR
Depuis le temps que nous en parlons, il est temps maintenant de présenter notre cœur FPGA comme esclave i2c.

### Un Cœur FPGA pour réaliser un esclave I2C (en Verilog)

Le cœur FPGA est celui de chez Opencores (i2c slave) avec comme seul changement la fréquence d'horloge de notre Nexys 3 à 100 MHz dans i2c_slave_define.v et un module global dans i2cSlaveTop.v :
On a donc modifié l'original comme suit :
* remplacer reg0 par leds8 qui pour nous sera directement relié aux 8 leds de notre carte FPGA
* ajouté sw comme premier registre d'entrée qui sera directement relié à nos interrupteurs de la carte Nexys 3
Pour information, l'adresse du périphérique est fixée en dur dans un fichier et non pas au moment de l'instanciation. Cela ne permet donc pas d’utiliser deux périphériques i2c dans un même FPGA sans changement... C'est un peu dommage, mais nous changerons peut-être cela dans le futur...
Le fichier ucf correspondant montre que l’on utilise les switchs comme entrée et les 8 leds comme sortie.
Bien sûr, chaque type de carte aura son fichier ucf. Mais cet exemple permettra une adaptation plus facile. Pour faciliter encore sa compréhension rappelons à l'aide de tableaux le câblage choisi.
Le câblage du PMod a été choisi avec la partie inférieure du connecteur en reliant la masse, ce que montre le tableau suivant :
| i2c | -- | -- | -- | -- | SCL | SDA |
| Sparkfun Pro micro | -- | GND | -- | -- | 3 | 2 |
| PMOD (Digilent) | 12 (Vcc) | 11 (GND) | 10 | 9 | 8 | 7 |

#### Évaluation grossière de la vitesse de transmission

Nous avons parlé d'une fréquence d'horloge du maître de 100 kHz mais qu'en est-il de la fréquence d'émission de de réception des 4 octets de notre cœur ?
La documentation officielle que l’on trouve avec le cœur fait état de :
* 8 octets à émettre au minimum pour écrire les 4 octets
* 7 octets bidirectionnels pour la réception
En admettant que l'envoi d'un octet est équivalent à l'envoi de 10 bits (à cause du start et stop), la fréquence maximale d'échange est donc : ${\frac {100000}{10*(8+7)}}=666Hz$
Utiliser ce mode de dialogue en robotique mobile où l’on a besoin souvent d'informations sur les capteurs de 20 à 50 fois par seconde est donc envisageable.
À ce point nous avons à disposition deux modes de dialogues entre un processeur et un FPGA : le SPI et I2C. Ces deux modes sont très intéressants car pratiquement tous les microcontrôleurs ont à disposition des périphériques qui gèrent ces deux protocôles.
Nous allons maintenant complètement changer de processeur pour donner d'autres exemples.

## Processeur MSP 430 et SPI

Le microcontrôleur MSP430 fait partie des architectures 16 bits. Il entre en concurrence avec les PIC24F. Sa particularité est sa gamme faible consommation.

### Présentation du MSP430

Nous allons utiliser un MSP430 pour ce projet qui va consister à récupérer les valeurs données par le processeur dans le FPGA.
Le MSP430 est un processeur 16 bits présenté rapidement dans un chapitre de ce livre, qui est caractérisé par sa faible consommation. Il existe un kit appelé "Launchpad" à faible prix (environ 10 €). Son gros intérêt, à part son prix, est une tension de 3,3 V directement compatible avec le FPGA et un environnement de développement identique à l'Arduino.

### Installer Energia sous Linux

Si vous téléchargez les binaires chez energia.nu, décompressez-les et votre environnement est en état de marche pour compiler.
Pour téléverser dans les processeurs, il faut ajouter dans un fichier 99-ti-launchpad.rules (dans /etc/udev/rules.d ) mettre :
À ce stade, seule la ligne correspondant à notre launchPad MSP-EXP430G2 est nécessaire. Mais nous utiliserons un peu plus loin, dans ce chapitre, le 32 bits ARM Cortex M4 TM4C123GXL. Autant faire d'une pierre deux coups.
Un redémarrage du service udev est alors nécessaire. La commande
fera alors l'affaire.

### La conversion analogique/numérique

Nous parlons de la conversion analogique/numérique ici car c’est une application naturelle à l'interfaçage d'un FPGA avec un microcontrôleur. Les convertisseurs Analogiques Numériques du MSP430 sont des convertisseurs sur 10 bits (comme pour les Arduinos) et fonctionnent jusqu'à 200 000 fois par seconde (Greater than 200-ksps maximum conversion rate). Ils peuvent passer à 12 bits pour certaines familles du MSP430.
Pour éviter à nos étudiants connaissant l'Arduino de se perdre dans un nouvel environnement, nous allons utiliser un environnement équivalent qui s’appelle Energia. Le langage correspondant est identique.
Comme pour l'Arduino, lire une valeur analogique est très simple. Il existe aussi une primitive appelée "analogRead".

### Le protocole SPI

La programmation SPI, comme présentée dans le projet précédent, est facile. Nous ne reviendrons pas sur la présentation de ce protocole (voir projet correspondant avec l'Arduino de ce chapitre).
Pour faire fonctionner le protocole SPI il faut un maître et un esclave. Commençons par un maître réalisé avec le MSP430.

#### Le maître avec un MSP430

Voici un squelette de programme pour commencer à réfléchir :
Nous avons passé beaucoup de temps avec ce programme trouvé sur Internet qui ne fonctionnait pas ! Il suffisait d'inverser les pinMode avec la librairie SPI comme ci-dessus.
Les commentaires en début de programme sont corrects. Nous l'affirmons ici car il y a plusieurs versions de LaunchPad. La notre est la LaunchPad avec un MSP430G2553 (version 1.5) dont le brochage peut être trouvé ICI.
Notre esclave va être présenté maintenant. Il s'agit d'une carte FPGA Nexys3 doté d'un spartan6.

#### Esclave SPI sur FPGA

La notion d'esclave SPI enfouie dans un FPGA a été abordée dans une précédente section.
Le câblage du PMod a été choisi encore comme :
| SPI | -- | -- | MOSI | MISO | SCK | SS |
| PMOD | 12 (Vcc) | 11 (GND) | 10 | 9 | 8 | 7 |
| MSP430 | -- | GND | P1.7 | P1.6 | P1.5 | P2.0 |

### Projets associés

* PMod Processeur MSP430 et SPI pour la robotique mobile décrit un projet qui associe le Launchpad MSP430 et une Basys2 en vue d'une installation sur une base robotique mobile. Ce projet a été abandonné, en fait, mais son énoncé reste lisible.

## CORDIC et MSP430

CORDIC est déjà évoqué dans :
* Chapitre 16 de ce livre
* CORDIC sur Arduino dans un autre projet
Nous ne reprendrons donc pas la théorie ici. Rappelons quand même que nous allons utiliser un format virgule fixe sur 16 bits de type Q3.13, ce qui veut dire que la partie décimale comporte 13 bits après la virgule. Si l’on se rapporte au décimal, cela fait 3 digits corrects après la virgule.

### Version logicielle de CORDIC

Nous avons repris le programme Arduino et modifié un peu les types, particulièrement le type int. En effet, la taille du type int nécessite de se plonger dans la documentation du compilateur. Ne pas le faire nous expose à des erreurs comme cela nous est arrivé avec le type "long int" qui est sur 32 bits sur les AVRs mais 16 bits sur les PIC. Heureusement le compilateur du GNU nous permet de définir la taille des types de manière univoque et c’est ce que nous avons fait dans le programme ci-dessous.
Remplacer
qui se trouve dans loop par
Gardez à l'esprit que ce qui est publié ci-dessus est fonctionnel pour le MSP430. Vous ne devrez tenir compte de la remarque ci-dessous que si vous voulez l’utiliser dans l'environnement Arduino (ou avr-gcc en général).
Le sous-programme "HexQ3_13ToString" que nous utilisions depuis deux ans avec les AVR, nous a montré quelques faiblesses avec le compilateur C du MSP430 ! Il a donc été remanié et nous avons l'intention de tester cette nouvelle version dans les AVRs, mais cela n'a pas encore été fait !
La raison du dysfonctionnement est le décalage vers la droite. On rappelle qu'en C un tel décalage ne fait pas toujours la même chose pour les nombres signés ou pas signés. Si on utilise des nombres non signés, il rentrera systématiquement '0'. Si l’on utilise les nombres signés il rentrera un '0' si les nombres sont positifs et un '1' si les nombres sont négatifs.

### Cœur FPGA CORDIC interfacé au MSP430 par une liaison SPI

Nous allons maintenant nous intéresser à l'interfaçage d'un cœur matériel CORDIC dans un FPGA avec un processeur externe de type MSP430. Nous avons choisi pour cela le SPI plutôt qu'un autre protocole car il nous semble être le plus rapide (horloge à 8MHz =fréquence quartz/2).
La partie matérielle est aussi donnée (sans le cœur SPI) que l’on peut trouver sur Internet.
La version présentée est fonctionnelle mais peut être largement améliorée puisque seul le sinus est retourné au MSP 430 par la liaison SPI. Nous laissons le soin aux lecteurs de perfectionner cet ensemble puisque, le but ici, est simplement de vous montrer comment cette liaison est possible.
Certain se demandent pourquoi nous avons utilisé le FPGA pour gérer la liaison série ? La raison est que nous avons beaucoup de mal à faire transiter par la même liaison, la programmation d'une part, et une liaison série d’autre part, et ceci sous Linux comme sous Windows XP. Il semble tout simplement que la liaison USB ne puisse pas servir aux deux, ce qui n’est pas le cas pour les platines 32 bits de chez Texas. En lisant plus attentivement la documentation, nous avons compris que la msp430 launchpad utilisée, n'était pas conçue pour de la liaison série à travers l'USB.
Il y a d'autres moyens de communications à explorer avec le MSP430. Par exemple, le MSP430 contient une gestion DMA certes limitée, mais nous n'avons pas suffisamment détaillé sa documentation pour voir s'il était possible de l’utiliser pour notre problème. Ce problème ne sera probablement jamais exploré ici car le msp430 launchpad est remplacé progressivement par le msp432 launchpad étudié un peu plus loin.
Nous allons maintenant entrer dans le domaine des 32 bits. Ce qui a été vu précédemment sur le SPI et l'i2c reste d'actualité, mais nous allons explorer d'autres modes de transferts.

## Utilisation du TM4C123GH6PM (Tiva C LaunchPad)

Nous entrons maintenant dans le domaine des processeurs 32 bits avec un TM4C123GH6PM qui est un ARM Cortex 4. Sa documentation officielle se trouve facilement sur Internet. Son choix est lié à l’existence d'une platine d'évaluation ((en)Tiva-C LaunchPad) avec :
* un prix de moins de 17 € (13,23 € HT chez Farnel)
* un environnement de développement du type Arduino appelé Energia
* une fixation plus aisée que pour le LaunchPad MSP430 (point de vue qui reste discutable)
À l’heure où nous écrivons ces lignes (octobre 2014) l'environnement Arduino ne supporte le DUE (32 bits) qu'en version beta et tout ceci pour un prix approchant les 40 €. Le seul concurrent que nous voyons au Tiva-C LaunchPad est la Teensy 3.1. Elle se programme directement dans l'environnement Arduino (avec un Plugin ajouté) et coûte moins de 20 €.
Quatre années plus tard (2018) l'environnement Arduino supporte en plus le Blue Pill STM32 qui est une carte 32 bits que l'on trouvait aux alentours de 1,1 € à l'époque. Aujourd'hui (2020) le prix est plutôt autour de 1,5 €. Il existe une version un peu plus chère mais avec 128/256 ko de Flash (contre 64ko pour le Blue Pill).
En 2019 (et peut être probablement avant) on pouvait trouver une autre famille de 32 bits, l'ESP32. Il s'agit d'un double cœur d'un processeur 32 bits qui n'est pas un ARM 32 bits. Il est aussi programmable à partir de l'environnement Arduino pour un prix aux alentours de 3 €.
En 2020 un nouveau processeur fait son apparition. Il s'agit du risc v 32 bits avec des cartes autour de 4 €. Une autre version double cœur 64 bits autour de 20 €, est disponible, le tout encore programmable avec l'environnement Arduino.
Même si nous abordons le domaine des 32 bits, nous ne pourrons en aucun cas concurrencer les FPGA de type (en) Zynq de chez Xilinx en mettant un processeur externe. Si la vitesse est votre problème, prenez un Zynq. Si la simplicité est votre problème, envisagez un processeur externe.
La documentation de la platine que nous allons utiliser se trouve ICI sur le site Energia. Cela laisserait penser que Texas Instrument apporte un peu d'aide au développement d'Energia. Robert Wessels qui développe Energia depuis 2012 semble faire partie du personnel de Texas Instrument. Côté concurrence, vu la vitesse de développement de l'IDE Arduino ce ne serait pas le cas d'Atmel ? Nous parlons bien au conditionnel car nous n'avons aucune information officielle sur le sujet. Nous croyons savoir qu'Atmel serait actif pour le développement du compilateur avr-gcc. Chacun sa stratégie. Laissons donc ces stratégies commerciales aux professionnels pour entrer dans ce que nous connaissons le mieux, la technique.
L'exécution du compilateur C avec Energia avec un environnement Linux 64 bits nécessite quand même des librairies 32 bits. Nous avons fini par trouver un problème équivalent dans le Forum Arduino. Ainsi, l'exécution des trois lignes présentées, sous Ubuntu a résolu nos problème :
Nous allons commencer par étudier notre vieil ami, le protocole SPI.

### Le protocole SPI

La programmation SPI est la même que pour le MSP430 puisque l'environnement de développement est identique. Nous donnons quand même le programme puisque le brochage change. Faites un effort avec la documentation de la platine pour constater la bonne utilisation du SPI.
Ce programme a été testé avec notre esclave SPI sur FPGA décrit précédemment.

#### Câblage utilisé

On a utilisé le connecteur PMod nommé JC (partie basse) comme ceci :
Le câblage du PMod a été choisi comme :
| SPI | -- | -- | MOSI | MISO | SCK | SS |
| PMOD | 6 (Vcc) | 5 (GND) | 4 | 3 | 2 | 1 |
et donc le fichier ucf correspondant pour la partie haute du connecteur JC :
Côté TM4C123G on câble :
| Tiva C LaunchPad | -- | GND | PB_7 | PB_6 | PB_4 | PB_5 |
| PMOD (Digilent) | 6 (Vcc) | 5 (GND) | 4 | 3 | 2 | 1 |

### Communication i2c

Comme ce problème a été traité avec l'Arduino, nous allons faire une variation pour cette section. Nous allons utiliser un cœur i2c esclave écrit en VHDL. Nous avons fini par trouver un esclave i2c en VHDL... et très récemment un contrôleur i2c intelligent. Ce contrôleur développé par Mike Field mérite d’être étudié de près. Lui l'utilise dans quelques projets mais surtout en maître. Il nous faut donc comprendre son fonctionnement pour voir s'il n’est pas possible de l’utiliser en esclave.
Pour utiliser l'i2c sous Energia avec le TM4C123G on câble :
| Périphérique i2c (numéro) | -- | GND | SCL(3) | SDA(3) |
| Tiva C LaunchPad | -- | GND | PD0 | PD1 |
| PMOD (Digilent) | 6 (Vcc) | 5 (GND) | 4 | 3 |
Il faut savoir que l’on utilise le périphérique i2c portant le numéro 3 en câblant ainsi. C'est celui qui est utilisé par la bibliothèque Energia par défaut.

### Peut-on utiliser ĺa DMA pour les transferts bidirectionnels avec les FPGA ?

La DMA permet des transferts directs entre périphériques et la mémoire RAM. Le module qui s'occupe de cela dans le processeur qui nous intéresse s’appelle μDMA. Il permet aussi des transferts directs de mémoire à mémoire mais nous ne nous y intéresserons pas.

#### Données du convertisseur Analogique Numérique vers le FPGA

Dans cette section, on cherche à réaliser un transfert monodirectionnel : du processeur TM4C123GH6PM vers le FPGA.
La conversion Analogique numérique sur ce type de processeur se fait à une fréquence d'environ 260 kHz (temps de conversion 3,9 μs). La question que l’on va chercher à résoudre est de réaliser des transferts SPI de ces valeurs au fur et à mesure qu’elles arrivent par DMA, donc sans utiliser de temps processeur (ou presque).
La fréquence de 260 kHz donnée ne correspond pas à la fréquence d'horloge du SPI. En effet à chaque conversion il faut transmettre 12 bits (soit deux octets car l'unité de base du SPI est l'octet). Cela fait donc une fréquence minimum de l'horloge du SPI de 4,160 000 MHz.