# Very High Speed Integrated Circuit Hardware Description Language/Records et challenges

Nous avons l'intention de mettre dans ce chapitre tous les records en taille, en vitesse et autres concernant les processeurs softcore. Cela nous permet de présenter rapidement un certain nombre de projets trouvés sur le net avec un classement de leurs diverses performances.
La plupart des projets présentés dans ce chapitre n'ont pas été testés.
Nous allons commencer par explorer les tailles des jeux d'instructions

## Record de taille du jeu d'instructions

Le plus petit jeu d'instructions imaginable en contient une seule. À notre grande surprise nous avons trouvé effectivement un processeur qui ne contient qu'une seule instruction.

### Processeur à une instruction

Il existe un processeur dont le jeu d'instructions comporte une seule instruction : il est appelé URISC (ultimate reduced instruction set computer) Il est décrit en anglais dans wikipédia comme un (en) One instruction set computer. Vous pouvez aussi trouver une vidéo Youtube en anglais sur le sujet.

### Processeur a quatre instructions

Il a déjà été présenté dans un précédent chapitre sous le nom : « Petit Système monopuce MCPU ». C'est un processeur 8 bits, mais il peut être étendu à 16 ou même 32 bits très facilement tellement son code est compact.

## Plus petit processeur en nombre de LUTs

On va s'intéresser dans cette section à la taille des processeurs en ressources F.P.G.A.. Il est certainement relativement difficile de comparer deux tailles pour deux fabricants de FPGA différents. C'est pour cela que nous allons séparer ce qui concerne Xilinx de ce qui concerne Altera.

### FPGA Xilinx
#### Processeur 8 bits

Le picoBlaze de Ken Chapman semble être le gagnant si l’on utilise des FPGA Xilinx, mais il est suivi de près par le PIC 16F84. Ils ont été respectivement décrits dans ce livre dans les chapitres :
* Micro contrôleur embarqué : le picoBlaze
* Embarquer un PIC 16F84

#### Processeur 16 bits

Nous présentons pour le moment deux processeurs 16 bits. Comme nous ne les avons pas encore utilisés, il nous est difficile de dire lequel est le gagnant. À notre avis c’est le mcx16, mais cela ne reste qu'un avis.

##### Processeur mcx16

Ce processeur est une réalisation 16 bits du picoBlaze par Gregory Bredthauer (Décembre 2011). Il possède son site mcx16 sur lequel vous pourrez trouver toute sa documentation.

##### Processeur SAYEH

Le processeur SAYEH (Simple Architecture,Yet Enough Hardware) semble être un très bon candidat mais il serait bon de vérifier. Il possède un compilateur C mais nous n'avons trouvé que son exécutable (pour windows) et pas son code source (du compilateur C). Vous pouvez le télecharger chez opencore en verilog.

##### Qu'en est-il du Spoc ?

Nous avons trouvé sur Internet un projet spoc0 de Jean Nicolle (téléchargeable ICI) qui comporte 8 instructions. En fait ce projet part directement d'un programme assembleur pour générer son cœur verilog. Ce projet est difficilement classable, nous ne savons pas le classer parmi les processeurs 8, 16 ou 32 bits. Il se trouve ainsi laissé parmi les processeurs 16 bits pour le moment.
Il nous faudra voir si ce processeur peut être considéré comme A4 (voir les challenges un peu plus bas dans la page) et voir aussi, si par hasard, l’idée derrière ce processeur ne peut pas nous conduire à un autre challenge.

#### Processeur 32 bits

« ZPU - the worlds smallest 32 bit CPU with GCC toolchain » de Harboe, Øyvind chez Opencores s'autoproclame gagnant dans cette catégorie, mais il serait intéressant de vérifier. Vous pouvez le télécharger ici : il existe en verilog et en VHDL.
ZPU est un processeur basé sur une pile et comporte donc peu d'instructions. L'ensemble de ses instructions est présenté ici. Il est maintenant la colonne vertébrale du projet Papilio qui est un projet susceptible d'intéresser tous les lecteurs de ce présent livre attirés par les applications des système mono-puce aux jeux vidéo.

### FPGA Altera

Nous n'avons pas travaillé suffisamment avec les produits Altera pour le moment. Le seul travail réalisé est décrit ici.
Nous utilisons aussi la carte DE10-Lite maintenant dès la première année puis en projets pour la deuxième année. La seule expérience avec un processeur est un softcore compatible Tiny861 pour lequel à ce jour nous ne savons pas encore comment initialiser la mémoire programme sans recompiler complètement le projet. Ce problème est lié au FPGA de type MAX10, car nous savons le résoudre pour un cyclone iv. Nous savons cependant que ce problème a une solution, car la firme Alorium propose une carte avec un connecteur Arduino et un softcore directement programmable de l'environnement Arduino (sans recompilation du Hardware).

## Processeur possédant le plus grand nombre de périphériques

Les processeurs que l’on trouve dans cette section ne seront pas forcément les meilleurs. En ce qui nous concerne nous préférons de loin un processeur qui a peu de périphériques mais est suffisamment ouvert. Pourquoi ? Tout simplement parce que les périphériques seront faits à notre mesure et à notre idée si le processeur est bien fait. Cela dit, les timers par exemple, sont des périphériques bien utiles ainsi que la RS232 d'ailleurs. Disons que si pour commencer, vous ne désirez pas réaliser trop de périphériques mais plutôt explorer une architecture existante sans acheter le composant, alors les processeurs trouvés dans cette section sont de bons candidats à explorer.

### Processeurs 8 bits

* AVR AX8 de Daniel Wallner chez openCores semble proposer les périphériques suivants :
** Programmable UART
** deux 8/16 bits Timer/Counters avec prescalers séparés et le PWM
** Deux ports parallèles
** Les interruptions sont gérées, mais nous ne savons pas combien le sont.
Une page en anglais décrit l’utilisation de l'AX8 et en particulier son utilisation avec data2mem (utilitaire déjà présenté dans le chapitre Programmer in Situ et déboguer).
* AVR core de Ruslan Lepetenok chez Opencores propose les périphériques suivants :
** Programmable UART
** deux 8 bits Timer/Counters avec prescalers séparés et le PWM
** Huit sources d'interruptions externes
** Deux ports parallèles
Le projet Papilio a pour but d’offrir une carte FPGA libre pour apprendre l’utilisation des Processeurs softcore et utilise une version de ce cœur légèrement modifiée. Comme expliqué auparavant, ce processeur va être remplacé petit à petit par un processeur 32 bits.
À titre de comparaison, l'AVR que nous avons utilisé et présenté dans Embarquer un Atmel ATMega8 ne proposait aucun timer, une UART non programmable. Mais il est extrêmement ouvert et ajouter un PORT est très facile.

### Processeurs 16 bits

Le projet OpenMSP430 d’Olivier Girard, déjà évoqué nous semble à priori le meilleur candidat. Sa documentation particulièrement bien soignée, détaille le nombre de périphériques qui sont implantés :
* bloc de gestion d'horloge
* watchdog conforme à sa documentation
* jusqu'à 6 PORTs externes 16 bits (nombre configurable au moment de la compilation du cœur)
* le timer A avec son interruption ses captures
* un multiplieur 16 × 16
* une interface de mise au point en série

### Processeurs 32 bits

Une expérience que nous avons dans le domaine est le microBlaze qui possède un certain nombre de périphériques. Mais il n’est pas libre !
Il existe deux versions libres du microBlaze chez Opencores :
* AEMB de Tan, Shawn qui est un microBlaze en verilog avec un bus Wishbone et donc hérite de fait de tous les périphériques Wishbone publiés chez OpenCores
* MBLITE de Tamar Kranenburg qui est un microBlaze en VHDL qui semble être légèrement plus rapide que le microBlaze original
Nous n'avons pas bien compris le statut du projet MyBlaze de Jian Luo qui semble partir du projet MBLITE mais pour en faire quoi ?
Une autre expérience que nous avons est l'utilisation du NIOS ii qui est d'ailleurs présenté dans ce cours.

## Processeur gérant le mieux la RS232

Nous avons eu l’occasion d’utiliser la RS232 dans un autre chapitre mais nous avons l'intention de mettre ici un ou plusieurs processeurs capables de gérer la RS232 avec différentes vitesses de transfert.
* Nous avons utilisé la RS232 avec le picoBlaze et l'AVR mais à vitesse fixe.
* AVR core chez Opencores propose une UART programmable. Nous ne l'avons pas testé.

## Processeur gérant le mieux le JTAG

Le projet OpenMSP430 déjà évoqué nous semble à priori un bon candidat.

## Plus petit processeur pouvant exécuter du langage C
### Processeur à une instruction

Ce processeur très particulier présenté dans une précédente section est capable d'exécuter du pseudo C. Le compilateur en question est disponible ici et une étude de ses performances ICI en PDF.

### Le picoBlaze

Le picoBlaze qui tient dans moins de 4% d'un circuit Spartan 3S200 (datant de 2003) a son compilateur C libre : pbcc. Il est dérivé de (en) sdcc (Small Device C Compiler). Nous n'avons jamais utilisé ce compilateur car nous estimons que l'architecture du picoBlaze n'est absolument pas adaptée :
* RAM de 64 octets seulement !
* un pile qui n'en est pas vraiment une : pas de possibilité d'y mettre des variables.

### Le PIC

Le chapitre Embarquer un PIC 16F84 décrit un PIC1684 qui prend seulement 5% d'un Spartan3S200 pour lequel un compilateur C existe. Celui fournit avec (en) MPLAB n’est pas optimisé s'il est obtenu gratuitement, mais (en) sdcc libre fonctionne maintenant correctement. Pour information le projet présenté dans Embarquer un PIC 16F84 utilisait le compilateur version étudiante pour MPLAB.

## Plus petit PIC16F

Le PIC 16F présenté dans Embarquer un PIC 16F84 tient dans 5% d'un spartan3 200k. Mais il existe un autre projet : PPX16 de Daniel Wallner chez Opencores. Ce deuxième projet n'a pas encore été testé pour voir lequel est le gagnant.

## Plus petit AVR

Le cœur Atmel AVR ATtiny261/461/861 d’Andreas Hilvarsson, chez Opencores, semble être un bon candidat pour la taille, mais il faudrait vérifier qu’il est bien plus petit que l'AX8 présenté plus haut.
Pour information, un TP sur le cœur Atmel AVR ATtiny261/461/861 est en cours de rédaction ICI dans ce live.

## Challenges

Dans cette section nous allons nous intéresser à quelques challenges : les architectes ou ceux qui espèrent le devenir sont invités à proposer des architectures de processeurs qui satisfont à un certain nombre de critères. Pour commencer nous proposons le challenge de la feuille A4.

### Processeurs A4

Le processeur A4 est un processeur qui nous trotte dans la tête depuis un certain temps mais aucun travail n'a encore été réalisé dessus. Il s'agit d'un processeur dont l'entité est voisine de celle d'un picoBlaze et dont la description doit tenir sur une seule page A4 (d'où son nom). Étant donné que l'entité est fixée on dira que c’est l'architecture qui doit tenir dans une feuille A4. Le langage de description peut être VHDL, Verilog, lucid, SystemC ou tout autre langage capable de générer d'une manière ou d'une autre une architecture dans une FPGA. Voici rappelée l'interface en image (nous metterons à jour cette image plus tard pour la RAM interne qui doit être sortie elle aussi).
La taille des bus de cette figure n’est pas à respecter. Les seules entrées et sortie que vous pouvez retirer sont celles des interruptions. Autrement dit la gestion des interruptions n’est pas obligatoire.
La gestion de la mémoire RAM est laissée à l'initiative de l'architecte : soit dans l'espace des PORTs, soit avec un bus spécifique qu’il faudra ajouter. Les mémoires et PORTs ne font donc pas partie de l'architecture.
Une écriture à l'aide d'un traitement de texte m'a donné 74 lignes avec une police de taille 10. Nous avons décidé donc d'arrondir à 75. Un processeur sera dit A4 si son architecture est décrite en strictement moins de 76 lignes.
Pour éviter que les challengers ne commentent pas leur code, les lignes de commentaires ne seront pas comptées.
Reste donc à définir le nombre de caractères par lignes. Il nous faut réfléchir pour ne pas trop pénaliser VHDL par rapport à verilog ! Finalement nous avons décidé de laisser le nombre de caractères par ligne non spécifié. Disons que sur ce point on doit rester raisonnable : interdiction de mettre deux instructions sur une même ligne si elle dépasse une largeur de feuille A4, mais sinon aucun problème.
Le principe du challenge est donc de réaliser un processeur contenant le plus d'instructions possible, le tout en strictement moins de 76 lignes. Les macro-instructions bâties sur les instructions compteront.
Le langage de description peut être VHDL, Verilog, lucid, SystemC ou tout autre langage capable de générer d'une manière ou d'une autre une architecture dans une FPGA.
Peut-on envisager de réaliser un compilateur C pour un processeur A4 ?

#### Transformer MCPU pour qu’il devienne A4

Petit Système monopuce MCPU déjà présenté satisfait partiellement à ces critères. Sa description VHDL tient effectivement dans une page A4 car son architecture est décrite en 36 lignes si l’on retire les lignes vides et les commentaires. Mais il ne possède aucun mécanisme pour réaliser des PORTs sauf probablement à mordre sur la mémoire programme. C'est ce que l’on va s'attacher à réaliser maintenant.
Le nombre d'instructions est donc de 11 (à partir de 4) pour le meilleur processeur A4 du moment.

#### Et le PIC 16F57 ?

Le PIC 16F57 possède un jeu d'instruction sur 12 bits. Peut-il être décrit pour qu’il devienne A4 ? Comme il possède 32 instructions cela laisse deux lignes par instruction si l’on veut qu’il soit A4 ! C'est bien peu !
On peut exprimer le problème d'une autre façon : peut-on réaliser une architecture d'environ une dizaine d'instructions, instructions très bien pensées, qui permettent à l'aide de macros d'exécuter l’ensemble des instructions du 16F57 ?
La réalisation de macro-instructions est abordée dans un projet RISC de S. de Pablo, J.A. Cebrián, L.C. Herrero et A.B. Rey qui est décrit ici : A very simple 8-bit RISC processor for FPGA. Détailler ce document doit permettre de commencer le projet de cette section PIC16F57. On peut aussi essayer de rendre le projet de cette publication A4, peut-être, d'autant plus qu’il est en verilog. Pour information il est décrit en environ 170 lignes… il y a donc du travail pour compacter.

#### Un processeur A4 en lucid déclaré vainqueur pour le moment

Justin Rajewski a réalisé en Janvier 2018 un processeur que l'on peut examiner pour entrer dans le challenge A4.
Voici le processeur 8 bits correspondant de 16 instructions qui est décrit en environ 98 lignes de code lucid. Si on enlève les commentaires et les sauts de ligne on tombe à 88 lignes. Si l'on enlève en plus les 9 lignes de déclaration du module on tombe à 79 lignes. Il n'est pas difficile de supprimer 4 lignes avec les accolades et/ou parenthèses.
Ce processeur est donc déclaré vainqueur pour le moment.
Le seul moyen de faire mieux est donc de proposer plus d'instructions ou comme on va le voir dans la section suivante, proposer plus d'abstraction.

### Instant SOC ou la fin du challenge A4 ?

Est-on arrivé à l'abstraction ultime avec le projet que nous allons présenter maintenant ?
En 2020 (pendant le confinement Coronavirus), nous sommes tombés sur le projet Instant SOC qui pourrait nous obliger à déclarer ce projet comme le grand gagnant du challenge A4 . Il est aussi cité dans le site riscv.org (site officiel du probable futur processeur, le RISCV) et est donc bâti sur un processeur riscv 32 bits.
Ce projet utilise le C++ pour décrire matériellement et logiciellement un SOC riscv. Ce qui fait la différence entre ce que l'on a vu précédemment est (encore une fois) le niveau d'abstraction. Pour nous faire une simple idée du code, voici un exemple trouvé sur la page d'accueil du site du projet (déjà cité Instant SOC) :
Dans cet exemple, la partie matérielle fait 4 lignes (si l'on enlève les commentaires [qui sont probablement obligatoires] "//% hw begin" et "//% hw_end") tout cela pour générer un riscv 32 bits complet, probablement avec pipeline et tout ce qu'il faut. Bon si l'on est très sérieux, il faut ajouter les deux lignes d'inclusions en début du programme... Et si l'on est encore plus sérieux on remarquera quand même que dans ce projet toute l'architecture matérielle est sous-entendue. Quand on a rédigé les règles dans un tel livre dédié au matériel, on pensait de manière implicite qu'il faudrait un minimum de description matériel.
Nous avions déjà pensé à un niveau d'abstraction de type C++ mais pas à un niveau SOC. Il s'agissait plutôt de travailler au niveau instructions, c'est-à-dire une ligne de C++ par instruction, suivie d'une génération automatique de VHDL. Mais nous n'avons jamais réalisé ce projet.
Alors grand gagnant ou pas ? Donnez votre avis.
Voir aussi : (en) System on a chip

### Graphics Processing Unit

Un autre challenge possible est la réalisation d'un adaptateur vidéo libre concurrent de gameduino. Nous n'avons pas encore réfléchi sur les règles que l’on pourrait donner pour ce challenge mais les caractéristiques techniques de gameduino semblent un bon début. Il est possible de trouver une partie de son code verilog sur Internet.
Si l’on veut commencer un peu moins fort, le GPU de Frank Buss semble lui aussi un bon début d'autant plus que son code est disponible ICI. Ses performances sont bien sûr bien en deçà de la gameduino :
* résolution 340 × 240 contre 400 × 300
* 1 couleur contre 512 couleurs
mais nous avons l'intention de nous pencher sur son code.

## D'autres challenges encore
### Un challenge un peu philosophique pour commencer

Les scientifiques et ingénieurs éprouvent quelques difficultés pour s’inspirer de ce qu'a trouvé la vie au cours de son évolution. Alors qu'on trouve couramment des caméras à forte résolution et sensibles à beaucoup de couleurs, on ne sait pas encore imiter la stéréo vision des yeux d'une mouche (qui ne comporte aucune optique de focalisation globale et peu de capteurs). Des recherches dans ce sens ont été initiées par le CNRS… et sur d'autres sujets par les grandes universités américaines.
Dans le domaine abordé par ce livre on est en droit de se poser aussi des questions. Comme beaucoup de recherches sont réalisées sur les réseaux neuronaux, nous les laissons de côté… pour nous consacrer à des briques à assembler de type processeur. D'où la question formulée de deux façons :
Est-il possible de réaliser des briques (à concevoir) qui assemblées réalisent de plus en plus de calcul ? Autrement dit, est-il possible de réaliser un processeur un ou deux bits qui s'assemble pour en donner un de plus en plus gros …
L'auteur de cette question a l'intuition d'une réponse négative, mais cela ne veut pas dire pour autant qu’il faille la balayer. De toute façon, si une réponse positive existe :
* elle n'a pas encore été trouvée… c’est tout ce que l’on peut dire, et cela ne prouve pas qu'elle n'existe pas
* le transistor peut naturellement être considéré comme une telle brique de base, ainsi que la porte NAND : ils permettent tous les deux un assemblage pour donner tout ce que l’on connaît en électronique aujourd’hui
* les mémoires sont conçues à partir de cellules et vérifient donc partiellement cet assemblage (partiellement, car les cellules mémoires doivent être assemblées avec un décodeur d'adresse en plus)
* les slices des FPGA forment aussi des briques de bases, même si d'autres parties de FPGA ont des fonctionnalités particulières… mais elles ne sont pas assez évoluées pour répondre à la question
* le FPGA sera le meilleur moyen d'expérimenter et de chercher une réponse à cette question
Puisque nous avons commencé cette section par la comparaison avec la vie, rappelons quelques chiffres. Un cerveau humain fait 10 millions de milliard d'opérations par seconde et ne consomme que de 10 à 25 W. Pour le même travail, un ordinateur aurait besoin de 100 Millions de Watts. Voir « Mémordinateurs » dans Pour la Science n°452 juin 2015.

### Intelligence artificielle

Les ordinateurs de cinquième génération annoncés en fin des années 1980 doivent encore être explorés. Il y a certainement du travail à réaliser dans ce domaine, et encore une fois, les FPGA sont tout désignés pour ces expérimentations. Tous les processeurs correspondants ont disparu.
Un exemple ?
Les Français J.C. Heudin et C. Panetto ont présenté leur RISC dédié à l'intelligence artificielle dans leur livre "Les architectures RISC". Il s’appelle le KIM20 a même été fabriqué mais ne peut probablement plus être trouvé. Quoi de mieux qu'un FPGA pour le faire renaître de ses cendres.
Voir par exemple une machine SECD en python dans github basée sur la (en) machine SECD décrite par KOGGE dans son livre, et cet article "The mechanical evaluation of expressions" de 1964.
Rien ne dit que les architectures envisagées dans cette section ne répondent pas à la question philosophique de la section précédente.

### Renaissance du Transputer

En fin des années 1980 et au début des années 1990 la recherche sur les architectures semblait être plus innovatrice qu'aujourd'hui. Ce point de vue est celui d'un non spécialiste de la question. L'exemple caractéristique est le Transputer. Il est probablement possible de les faire renaître dans un FPGA (voir la bibliographie plus loin).