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.

FPGA Xilinx

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

Cette section est vide, pas assez détaillée ou incomplète. Votre aide est la bienvenue !

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

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

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

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.

Principe

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.

Cette section est vide, pas assez détaillée ou incomplète. Votre aide est la bienvenue !

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 ?

Remarque

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.

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

Remarque

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.

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

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

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

Propriété

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

Articles

• R16: a New Transputer Design for FPGAs
• Design of a Transputer Core and its Implementation in an FPGA
• (en) Transputer article en anglais qui présente le transputer, y compris ses instructions.

Livres

• 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

• (en) Lecture #5 -- lab 2 audio filtering
• (en) Lecture #6 -- Stack machine and compiler