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

Leçons de niveau 17
Une page de Wikiversité, la communauté pédagogique libre.
Début de la boite de navigation du chapitre
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 : Records et challenges
Very High Speed Integrated Circuit Hardware Description Language/Records et challenges
 », n'a pu être restituée correctement ci-dessus.

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

Processeur 8 bits[modifier | modifier le wikicode]

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 :

Processeur 16 bits[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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 ?[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

"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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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 fait à 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[modifier | modifier le wikicode]

  • 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[modifier | modifier le wikicode]

Le projet OpenMSP430 de 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 16x16
  • une interface de mise au point en série

Processeurs 32 bits[modifier | modifier le wikicode]

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 :

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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

Plus petit processeur pouvant exécuter du langage C[modifier | modifier le wikicode]

Processeur à une instruction[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

Le cœur Atmel AVR ATtiny261/461/861 de 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[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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).

Entrées et sorties du PicoBlaze

La taille des bus de cette figure n’est pas à respecter. Les seules entrée 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.

Début d’un principe
Fin du principe


Peut-on envisager de réaliser un compilateur C pour un processeur A4 ?

Transformer MCPU pour qu’il devienne A4[modifier | modifier le wikicode]

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 ?[modifier | modifier le wikicode]

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 ?


Un processeur A4 en lucid déclaré vainqueur pour le moment[modifier | modifier le wikicode]

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 ![modifier | modifier le wikicode]

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 nous oblige à 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) :

    #include "fc_io.h"
    #include "fc_system.h"
    int main(void)
    {
    //% hw_begin
        FC_IO_Clk clk(100);                 // 100 MHz
        FC_IO_Out led;  
        FC_IO_UART_TX uart_tx(115200,32);   // 32 Bytes FIFO
        FC_System_Timer timer;    
    //% hw_end
        int led_state = 0x01;    
        uart_tx << "Hello World!!";
        for(;;) {
            timer.Sleep(1000, TU_ms);
            led_state = ~led_state;
            led = led_state;
        }
    }

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.

Graphics Processing Unit[modifier | modifier le wikicode]

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 340x240 contre 400x300
  • 1 couleur contre 512 couleurs

mais nous avons l'intention de nous pencher sur son code.

D'autres challenges encore[modifier | modifier le wikicode]

Un challenge un peu philosophique pour commencer[modifier | modifier le wikicode]

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

Intelligence artificielle[modifier | modifier le wikicode]

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[modifier | modifier le wikicode]

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).

Voir aussi[modifier | modifier le wikicode]

Articles[modifier | modifier le wikicode]

Livres[modifier | modifier le wikicode]

  • J.C. Heudin et C. Panetto "Les architectures RISC" Dunod 1990
  • Peter M. Kogge "The Architecture of Symbolic Computers" McGraw-Hill (1991)

Sur Youtube en anglais[modifier | modifier le wikicode]