Very High Speed Integrated Circuit Hardware Description Language/Introduction

Début de la boite de navigation du chapitre

fin de la boite de navigation du chapitre

Nous avons l'intention d'amener le lecteur à utiliser un processeur dans un F.P.G.A., et ceci de manière extrêmement pratique. Un des auteurs ne disposait que de peu d'informations pour travailler au départ (voir la littérature en fin de ce chapitre). Nous espérons que les lecteurs de ce livre ne rencontreront pas les mêmes problèmes et que suffisamment de détails pour se mettre à la tâche pourront être trouvés ici.

Ce livre représente un travail difficilement quantifiable comme n’importe quel bouquin papier, et pourtant aucun droit d'auteur n'est demandé au lecteur. Il faut une certaine conviction (politique ?) pour faire ce travail. Il s'agit d'une croyance au travail librement partagé. Nous rappelons que celui qui croit au libre n’est pas un guerrier se battant contre la propriété intellectuelle mais au contraire quelqu’un qui cherche par tous les moyens à respecter cette même propriété intellectuelle. Nous utiliserons par exemple beaucoup de projets libres dans les chapitres qui suivent et jamais nous n'oublierons d’en citer les auteurs (enfin nous l'espérons). De même, lorsque des collègues auront participé à ce travail, ils seront cités.

Mais revenons à une présentation moins politique de notre travail.

Introduction

Nous avons toujours adoré l’introduction du livre "The Wizzard of Quarks" de Robert Gilmore dans un tout autre domaine (physique des particules). Nous allons donc la paraphraser en espérant ne pas enfreindre les droits d'auteur.

Imaginez-vous posséder un centime d'Euro. Il n'y a pas à en faire toute une histoire. Mais comment devient votre vie si vous en possédez un milliard ? Les choses deviennent plus passionnantes et les possibilités qui vous sont offertes dans votre vie deviennent de plus en plus nombreuses, voir de plus en plus intéressantes.

Que se passe-t-il si l’on remplace le centime d'Euro par une porte logique ? Vous avez la même chose. Plus vous en avez plus les possibilités sont grandes. Une certaine beauté et un certain intérêt naissent du nombre. C'est ce qui rend les FPGA passionnants. Le nombre de portes disponibles augmente avec le temps et rend ainsi le nombre de domaines concernés toujours plus grand. Vous pouvez vous transformer en Architecte (Hardware) et donner libre cours à votre imagination, inventer des processeurs, inventer des périphériques et certainement plein d'autres choses encore...

Après cette invitation au rêve, revenons un peu sur terre.

Des changements profonds dans la conception en électronique numérique

La conception en électronique numérique a énormément évolué ces dernières années. On est d’abord passé de la conception en circuits traditionnels à la conception utilisant des circuits de plus en plus évolués. Les briques de bases sont ainsi passées des portes logiques aux microprocesseurs et microcontrôleurs. En même temps, les possibilités d’utilisation de la logique programmable ont elles aussi évolué vers des circuits de plus en plus performants : on est passé des Simples PLD (ou SPLD comme la 20V8) aux Complexes PLD (ou CPLD) puis au FPGA. Pour bien se faire une idée de cette évolution, un circuit FPGA de 2003 est capable de recevoir un processeur 8 bits qui occupe à peine 5% du circuit. C'est vrai que le processeur en question est taillé sur mesure pour le FPGA et que nos processeurs à nous, même sur 8 bits, occuperont plutôt 50% du circuit. Avec ces bouleversements, les méthodes de conception pour FPGA sont passées d'un niveau RTL (Register Transfer Level) bien maîtrisé, au niveau ESL (Electronic System Level) en plein développement. Les principaux langages de développement RTL sont VHDL, verilog et systemC. Les langages de développement ESL sont encore en développement. Pour pallier ce manque de langage, les divers fabricants comme Xilinx, Altera et ACTEL proposent des environnements graphiques (ou en tout cas avec Wizard=sorcier) pour assembler leurs processeurs avec de la logique externe. La grande difficulté de conception à ce niveau ESL se manifeste surtout par la difficulté de mise au point. Beaucoup de programmeurs sont formés dans les pays industrialisés (et en voie de développement) ; ils connaissent les difficultés de la mise au point d'un programme. Beaucoup moins d'architectes en matériels informatiques sortent de nos universités avec des connaissances solides en mise au point de matériel. (Cette dernière phrase n'est absolument pas une critique de notre système universitaire, le point important n’est pas le contenu des formations mais le nombre d'étudiants qui en sortent). Les défis du futur dans ce domaine sont donc de former beaucoup plus d'architectes en matériels informatiques. Nous espérons contribuer modestement à ce défi à travers ce cours.

Nous allons donner quelques exemples qui seront développés dans ce cours.

Quelques exemples illustratifs

Pour être un peu plus concret sur les besoins en connaissances d'architectures matérielles, nous allons essayer de donner quelques exemples concrets en se référant à des processeurs existants.

1. Nous allons réaliser des pseudo cartes vidéo dans ce livre et les piloter par des processeurs 8-bits. Est-ce concevable sans FPGA ? La réponse est évidemment non (sauf pour des bricoleurs très patients qui se manifestent parfois dans des vidéo Youtube). Une des raisons essentielles est le manque de ports dans les architectures commercialisées. Il nous faudra facilement 8 PORTs en sortie pour commander ces cartes vidéo. Connaissez-vous un tel processeur 8 bits commercialisé ? On peut toujours étendre le nombre de PORTs par de la logique, mais cette logique devient vite complexe et devra donc être réalisée avec au moins un CPLD si ce n'est avec un FPGA.
2. Nous avons eu l’occasion de développer un jeu commandé par un vieux joystick numérique : 4 contacts électriques ouverts ou fermés, un par direction. Puis nous avons décidé de le remplacer par une manette Nunchuk. Naturellement faire cela avec un processeur du commerce est réalisable mais cela aurait nécessité de changer complètement le programme qui tourne dans le processeur (Nunchuk est en i2c). Pour nous cela n'a pas été le cas car il est possible dans un FPGA de réaliser une interface qui fasse la même chose qu'une autre. Ceci a une conséquence très importante : ne jugez pas un processeur embarqué dans un FPGA par le nombre de ses périphériques. Les périphériques c’est vous qui les faites et du coup vous êtes complètement maître de leur interface. Dans le cas présent, nous avons réalisé une machine d'états qui commandait un cœur i2c qui nous renvoyait les valeurs analogiques du joystick. Puis nous avons utilisé des comparateurs pour décider qu’à partir d'une certaine valeur, c’est comme si on avait fermé un interrupteur. Notre interface i2c s'est ainsi transformée en 4 fils logiques de directions et pouvait prendre la place de l'ancien joystick à interrupteurs. À ce stade de lecture de ce livre, il est peu probable que vous compreniez tout ce que nous venons d'exprimer, mais essayez d’en saisir la philosophie : une très grande souplesse dans la fabrication des périphériques.
3. Le picoBlaze est un processeur développé par Xilinx qui n'existe pas dans le commerce mais qui est très représentatif pour la gestion de périphériques. Aucun périphérique ne lui est associé par défaut, mais ils sont faciles à réaliser et interfacer. Même si vous voulez voir tourner un picoBlaze en lui faisant réaliser un chenillard, il vous faudra lui associer un port de sortie et c’est à vous de le faire.
4. Un des avantages de créer vos propres périphériques est l’utilisation éventuelle de registres FIFOs. Cela permet de bufferiser des données qui viennent d'une liaison RS232, d'un clavier PS2 ou de l’i2c par exemple. Cette façon de faire est, à priori, peu utilisée dans les processeurs commercialisés (nous n'en sommes pas très sûr, c’est donc à vérifier).
5. Il est inutile de vouloir copier les périphériques existants. Vous devez les imaginer par vous-même. Selon nous, les seuls périphériques qui peuvent faire exception sont le timer et la rs232. Nous avons dit "qui peuvent" et non "qui doivent" même si nous pensons qu’il faut mieux mettre en œuvre votre imagination plutôt que de vouloir copier l'existant. Pourquoi avons-nous rangé les timers à part ? Pour le temps réel par exemple. Il est relativement peu commun d’avoir des compétences dans l'écriture d'un noyau temps réel et dans le matériel correspondant. Si vous avez des timers présents cela peut vous éviter de changer le noyau temps réel. Notre chapitre sur le temps réel étant en cours de construction pour le moment, nous devons encore imaginer la façon dont nous allons nous y prendre.

Choisir un processeur softcore

Un des auteurs de ce cours a commencé à réaliser des projets "systèmes sur puces" en 2009, et n'avait qu'une obsession : faire tourner un programme en C dans un FPGA. Ce cours va vous montrer de manière très pratique comment faire. Une limite naturelle aux processeurs 8 bits semble un bon début pour comprendre les principaux axes d'attaque du problème. Ces processeurs correspondent mieux, à notre avis, au niveau 15 (L1/L2). Cela permet de n'envisager que des applications sans système d'exploitation domaine plutôt réservé aux architectures 16/32/64 bits.

Il existe un nombre impressionnant de processeurs softcore libres ou payants et le problème du choix parmi toutes ces propositions est un problème entier. En ce qui nous concerne, nous avons choisi d’utiliser plutôt des architectures existantes. Nous voulons dire par là des processeurs commercialisés et refait complètement (ou plutôt partiellement) en VHDL. Pourquoi ? Tout simplement parce que nous sommes en charge des enseignements sur microcontrôleurs et qu'ainsi nous connaissons les environnements de développement MPLAB, AvrStudio et maintenant Arduino. Il nous faut admettre que ce n'est absolument pas un bon critère de choix si l’on sort du domaine universitaire. C'est assez intéressant de faire tourner un PIC ou un Atmel AVR dans un FPGA pour un universitaire, mais si un industriel n'a aucune compétence avec l'un ou l'autre, ne serait-il pas mieux, pour lui, de choisir le processeur qu'a construit son fabricant de FPGA ? J'espère que le lecteur nous pardonnera ce choix, d'autant plus que s'attacher à définir de bons critères pour un tel choix nous semble vraiment trop dépendant du contexte industriel (et donc hors de portée de notre réflexion d'universitaire).

Pour information, les divers fabricants proposent leurs processeurs softcore. Ils sont en général taillés sur mesure pour les FPGA correspondants.

• Xilinx propose le PicoBlaze (8 bits) et le Microblaze (32 bits) qui sont abordés dans ce cours
• Altera / Intel propose le NIOS 2 (32 bits) et en 2022 le NIOS 5 (architecturé autour d'un RISC V 32 bits)
• Lattice propose le Mico8 (8 bits) et le Mico32 (32 bits)
• Actel propose, entre autres, une architecture ARM7 (32 bits) mais implanté en dur dans son FPGA.

Structure de ce livre

Nous n'envisageons pas de montrer comment construire un processeur softcore dans ce cours, mais plutôt d’utiliser des systèmes monopuces existants. Pour les architectes de matériels informatiques en herbe voici un lien en anglais qui leur permettra de comprendre l'architecture des processeurs. Le chapitre 3, et, plus encore, le chapitre 4 de ce présent cours, restent de très bons points d'entrées pour l'étude des architectures.

Il est certainement difficile d’éviter l'ordinateur de type PC et ses interfaces dans un tel cours. C'est pour cette raison que nous avons l'intention d’aborder quatre types d'interfaces différentes :

• la liaison PS/2. Elle est déjà présentée dans ce cours sous forme de TPs corrigés.
• la connexion VGA sera le fil du début de ce cours, c'est-à-dire présente dans beaucoup d'exemples.
• la liaison RS232 sera utilisée elle aussi puisqu'elle est vraiment universelle.
• la liaison USB est une liaison complexe à mettre en œuvre mais certainement importante à connaître. Nous n'avons pas encore réussi à la mettre en œuvre dans un FPGA mais ne désespérons pas de le faire un jour.

D'autres liaisons seront explorées :

• i2c d'abord à travers un exemple très particulier, la manette Nunchuk puis par la réalisation d'un périphérique i2c
• protocole Bluetooth pour relier notre FPGA à un téléphone portable ou une tablette
• protocole Wifi (pas encore présent dans ce cours mais qui devra être exploré). (Ajout de 2022 : nous avons un chapitre sur la relation entre FPGA et processeur et il est facile de trouver des platines de ESP32 gérant le Wifi.)

Avant de rentrer dans le vif du sujet avec un PIC 16C57, il nous faut aborder quelques problèmes généraux d'architecture. Ainsi, le calcul d'un PGCD sera notre guide pour les chapitres 2, 3, 5 et 6 qui suivent.

Puis viendra enfin quelques exemples de processeurs softcore dans les chapitres 7, 8, 9, 10, 11 et 15. Il n’est pas important pour un étudiant de connaître tous ces exemples, les processeurs étant trop variés : PicoBlaze, PIC16C57, PIC 16F84, ATMega8 et microBlaze. Nous les publions ici pour qu'un étudiant ou un enseignant puisse faire son choix et décide ensuite de l'approfondir. En effet les exemples présentés sont intéressant d'un point de vue matériel mais relativement simples d'un point de vue logiciel. Vous aurez cependant tout loisir de remarquer qu'au fur et à mesure de l’augmentation de la complexité des jeux (passage du Pong au casse-briques et enfin au pacman) la partie logicielle deviendra elle aussi de plus en plus sophistiquée.

Remarque

Les chapitres traitants des PIC16C57, PIC 16F84, ATMega8 et MicroBlaze sont des projets donnés à des étudiants de deuxième année d'IUT Génie Électrique et Informatique Industrielle. Le fait qu’il s'agisse de travailler autour d'un jeu vidéo (de Pong, en l’occurrence, puis du casse-briques) les motive énormément : chaque phase de test logicielle consiste à essayer le jeu.

Par contre ces chapitres sont plutôt rédigés comme un rapport de projet écrit au fur et à mesure de son avancement. Cela complique certainement parfois un peu la lecture, mais consolez-vous avec le fait que vous avez tout cela gratuitement.

Le chapitre 12 aborde l’utilisation de cœurs écrits dans un autre langage que VHDL, à savoir verilog.

Le chapitre 13 a été ajouté récemment. Il cherche à répondre à la question de la programmation in situ et des problèmes dérivés. L'idéal serait d'implémenter des protocoles existants. Le protocole série asynchrone est certainement le plus facile à mettre en œuvre pour charger un programme dans un softprocesseur car il existe des logiciels pour cela. À notre avis ce chapitre n’est pas prêt d’être terminé car il nécessite la lecture de codes sources en C.

Le chapitre 14 tout juste commencé a comme objectif d'explorer le multitâche et/ou le temps réel. Comme il n'est peu avancé, il est difficile de dire ce qu’il contiendra mais nous pensons explorer le temps réel pour ATMega8 (le plus petit possible quitte à ajouter des commutations de taches en matériel) et pour les PIC 16F84. Pour ces derniers, comme il n'existe pas vraiment de système multitâche libres nous étudierons la possibilité de réaliser plusieurs PICs (un par tâche) dans un même FPGA.

Le chapitre 15 aborde le microBlaze, le processeur 32 bits de Xilinx. C'est un chapitre qui n'a pas beaucoup d'intérêt pour un lecteur qui travaille avec d'autres FPGA puisque son fondeur lui proposera certainement un processeur concurrent.

Le chapitre 20 se propose de classer le plus possible de cœurs suivant un certain nombre de critères. Il se termine par un challenge, le processeur A4.

Futur de ce livre

Nous nous proposons dans un futur proche (d'ici la fin 2015) de travailler dans deux domaines :

• le temps réel ou au moins le multitâche
• le bus USB

Remarque

La programmation temps réel nécessite de modifier les cœurs pour ajouter un timer qui manque et parfois le système d'interruption correspondant. Cela ne peut pas se faire en un seul jour. (Toujours pas fait en 2023 !!!)

Tout cela terminera complètement ce livre sauf si des lecteurs nous demandent d'explorer d'autres 8 bits. Pour information, il existe des cœurs de PIC18F, de Z80, de 6802, de 68HC11 et bien d'autres encore. L'idéal pour nous, reste qu'un lecteur qui a de l'expérience avec un autre 8 bits que ceux présentés, ajoute un chapitre à ce livre, et partage ainsi son retour d'expérience.

Nous nous dirigerons ensuite vers les systèmes 16 bits. Il nous faudra certainement bâtir un nouveau livre pour cela, plus orienté système. Le temps de l'exploration des processeurs de signal numérique sera aussi venu... Bien du travail en perspective... qui demande de l'aide d'autres collègues...

Nous n'avons pas prévu de travailler sur les bus comme Wishbone mais peut être que justement les processeurs 16 bits nous y conduiront...

Futur bis de ce livre

Nous ferons le grand ménage dans la section "Futur de ce livre" un peu plus tard. En effet depuis sa rédaction, un certain nombre de choses ont changé :

• apparition de deux chapitres dédiés aux processeurs 32 bits, le microBlaze et le N.I.O.S. d'Altera,
• apparition d'une section sur le MSP430 qui est une architecture 16 bits
• probable apparition d'un chapitre sur les DSP

Dans notre tête tout était clair au début : ce livre serait consacré uniquement aux 8 bits. Un autre le compléterait pour les autres architectures. Aujourd'hui, force est de constater que nous n'avons pas respecté ces objectifs. Tout simplement parce qu'en fait nous n'avons pas l'intention de refaire un nouveau livre.

Ce livre est-il à côté de la plaque ?

Une polémique sur les architectures 8 bits a fait rage (c'est un peu exagéré) sur la mort de ces dernières (Is 8-bits dying) dans EETimes du 9 juillet 2012. Si c’est le cas tout est à refaire, nous nous sommes trompés d'objectif !

Dans les années 1980, si l’on nous avait dit qu'en fin de carrière nous enseignerions encore les architectures 8 bits à des étudiants, nous n'y aurions tout simplement pas cru… Et pourtant, elles sont toujours là et c’est ce que nous faisons encore aujourd'hui. Nous pensons qu’il y a encore beaucoup de place pour les architectures 8 bits. Quand on est jeune on voit surtout l'aspect performance, vitesse, et l'aspect complexité ne nous rebute pas. Mais en vieillissant… Aujourd’hui nous sommes pour une utilisation raisonnée des architectures : mettre des 8-bits là où il en faut, et des 32 bits à leurs places respectives (En 2014 les architectures 8 bits étaient toujours les plus vendues). On a besoin de 32-bits dès qu’il y a du graphisme interactif à gérer : téléphones portables, GPS, tablettes… Pour la petite histoire ce beau principe n'a pas été complètement respecté dans ce livre (comme quoi !). En effet, le microBlaze (32-bits) a été utilisé dans un projet qui a été réalisé aussi avec un simple ATMega8 (8-bits) ! Les deux programmes nécessitaient une boucle d'attente passive! Et bien oui, le 8-bits dans ce projet était encore trop puissant, je ne vous parlerai donc pas du 32 bits!

Pour terminer, il y a eu un commentaire un peu sarcastique sur cette polémique avec lequel nous sommes complètement d'accord : d'ici que l’on trouve des circuits 32-bits avec 8 broches (comme un ATTiny)… on a encore le temps voir venir.

À part ce combat sur les architectures 8 bits, d'autres critiques sur VHDL et sur les FPGA sont lisibles sur Internet :

• VHDL, the new Latin qui rapporte un propos de 2003 de Aart De Geus (Synopsys CEO) qui prétend que seul System-Verilog a de l'avenir mais pas VHDL. VHDL-AMS a été normalisé en 1999 et ses librairies seulement en 2004. Ceci explique peut être partiellement que ce déclin annoncé depuis plus de 10 ans n'a pas encore eu lieu ;
• Are FPGA Dead? (03 décembre 2013) qui est en fait plus un point de vue de terminologie. L'auteur ne comprend pas que l’on appelle un composant comme le Zynq (Xilinx) encore un FPGA. La grande différence avec ce qui est traité dans ce livre est que dans le Zynq il y a un processeur en dur (de type ARM).

Ce que nous pouvons dire c’est que tout investissement personnel dans les domaines abordés dans ce livre seront certainement réutilisables avec d'autres technologies. D'ailleurs, pour paraphraser le premier titre, le latin est-il si inutile que cela ? Si oui, pourquoi l'enseigne-t-on encore ?

États d’âme : interfacer des processeurs externes

Nous avons rencontré beaucoup de difficultés (non résolues pour certaines d'entre elles) lors de la réalisation de choses à priori simples comme mettre un bootloader dans l'AVR que nous utilisons... pour le rendre compatible avec l'environnement Arduino. Les échecs répétés sur la question nous ont obligé à nous poser sérieusement des questions qu’il n’est pas inutile de développer. Même s'il semble qu'un peu de pessimisme se glisse dans ces réflexions, nous n'avons pas prévu d'abandonner les challenges posés par la rédaction de ce livre à court terme.

Est-il possible de concurrencer une équipe d'ingénieur ?

Il est facile de résumer le problème de la manière suivante. Le cœur AVR principalement utilisé dans ce livre a été développé par une seule personne Juergen Sauermann. Nous y avons apporté quelques modifications mineures. Il y a donc seulement deux personnes qui ont participé à son élaboration. Comment deux personnes qui communiquent très peu (un e-mail par an) peuvent-elles faire ce qui est réalisé par une équipe d'ingénieur chez Atmel ? Nous y avons cru à un certain moment mais voila, il faut se rendre à l'évidence.

Mais c’est libre !

Le problème est que nous sommes obsédés par le libre ! et qu'en final nous redécouvrons que le libre a ses limites. Comment expliquer ces limites alors que nous utilisons Linux depuis plus de 16 ans et que nous n'avons pas rencontré de problèmes particuliers ?

Nous pensons qu’il est facile de trouver des équipes qui développent du logiciel libre. Le nombre de logiciels libres que l’on peut trouver en est une preuve. Mais réunir une telle équipe pour un processeur libre est beaucoup plus difficile ! Les rares processeurs libres qui réunissent une équipe, à notre connaissance, sont OpenRisc1000, Leon, probablement riscv.org ainsi que le projet FPGArduino. Mais nous espérons qu’il y en a d'autres qui nous ont échappés. Par contre il en existe qui sont utilisables librement pendant un temps limité. Par exemple MIPS microAptiv que nous venons de découvrir.

Nous espérons bien sûr que ce livre contribuera à instruire et aidera donc indirectement des équipes à se monter. Mais quand ?

Et la vitesse ?

En fait ce livre est élaboré pour des enseignements réalisés dans un IUT GEII (deuxième année) et à l’UTT en troisième année. Pour faire simple on est dans le domaine que les anglo-saxons appellent undergraduate. Quelle en est la conséquence ?

Tous nos projets et exercices ne sont pas déterminés par une vitesse excessive. Les applications vont du jeu vidéo (simple) à maintenant la robotique mobile... et nous n'avons jamais rencontré de goulot d'étranglement (en vitesse). Nos programmes ont toujours comportés une boucle d'attente passive. Ceci est très important. Du coup, nous nous demandons si nous avons bien utilisé les FPGA dans les domaines pour lesquels ils sont prévus. Les FPGA sont des composants chers (voir très chers) et ne sont utilisés que pour :

• un grand parallélisme pour augmenter la puissance de calcul (nous ne l'avons pas encore fait)
• éviter de câbler beaucoup de circuits et de logique (ce que nous avons fait)

Nous pensions que seul le premier point était le domaine réservé des FPGA mais nous avons ajouté le deuxième car nous avons rencontré récemment trois appareils comportant un FPGA :

• un automate programmable avait un Xilinx Spartan 2 (technologie des années 2000)
• le composant ICD3 pour télécharger les programmes dans les PIC comporte un Xilinx Spartan3E
• un GBF avait un Altera

La solution : utiliser ce que les équipes d'ingénieurs ont fait

Il y a trois manières d'interpréter le titre de cette section :

• utiliser un cœur en dur comme dans les FPGA Zynq que certains puristes refusent d'appeler encore FPGA
• utiliser un processeur acheté et l'interfacer au FPGA
• utiliser un soft processeur du fabricant de FPGA

Dans les trois cas, c’est une équipe d'ingénieur qui a bâti le processeur. On est donc sûr à 99,9% qu’il n'y a pas de bug.

Mais pour notre processeur softcore ATMega8 nous avons du mal à estimer l'absence de bug. D'un côté nous y avons fait fonctionner un programme C de 700 lignes sans avoir rencontré de problème particulier... et de l'autre nous avons fini par découvrir (2018) des problèmes sérieux lors de l'utilisation de la virgule flottante (problème finalement résolu en 2020). Et de plus, nous avons rencontrés des problèmes étranges lors d'un portage de bootloader !

Ainsi, à partir de 2014 nous avons décidé d'étudier sérieusement les interfaces entre un processeur du commerce et un FPGA. Une autre raison à cela est le prix. Pour moins de 20 € nous avons acheté une carte Texas Instrument qui dispose d'un processeur 32 bits (Tiva C LaunchPad). Nous avons mis à peine une semaine à l'interfacer à notre FPGA, par du SPI alors que, si notre mémoire est bonne, nous avons mis un mois (heureusement pas à plein temps) à faire fonctionner notre ATMega8 au tout début. Plus récemment, nous avons passé une cinquantaine d'heures à porter l'ATTiny861 sur Altera.

Une autre solution pour utiliser ce que les équipes d'ingénieurs ont fait, est donc d’utiliser des FPGA de nouvelle génération comme le Zynq. Le processeur n’est pas extérieur mais intérieur et en dur. Il ne fait donc pas partie de ce que l’on appelle les "soft processeurs". Quelques exemples récents :

• le "Red Pitaya" qui est un oscilloscope USB/Ethernet ouvert décrit dans sa propre page WIKI.
• parallella est aussi une architecture autour du zynq comme le montre la photo du site

L'achat d'Altera par Intel (en juin 2015) apportera probablement des nouvelles architectures de FPGA avec des cœurs en dur de la famille 8086, mais cela changera-t-il la donne ? Finalement le seul événement en 2022 est la migration du NIOS en NIOS V qui reste donc un soft processeur mais avec une architecture RISC V (donc libre).

Que les lecteurs se rassurent, nous n'avons malgré tout pas l'intention d'abandonner complètement les soft processeurs.

Points de vue

Nous ouvrons cette section comme domaine de discussion pour que les lecteurs laissent leurs états d’âme et leurs impressions sur les architectures matérielles et leur enseignement. Il serait bon de ne pas amener cette discussion sur le terrain politique. Nous ne pensons pas que les hommes politiques aient une grande responsabilité dans l'histoire et ce, quels que soient leur bords.

Point de vue - 1

Je vais parler à la première personne du singulier dans cette section car ce qui est écrit n'engage que moi. Qui est moi ? La politique d'écriture dans la Wikiversité est de rester anonyme... mais l’historique permet de retrouver l'Auteur...

Je ne connais bien les programmes officiels d'enseignement que du département Génie Électrique des IUT. Mais ce que je peux constater sur ces programmes, c’est la diminution progressive des enseignements sur les architectures matérielles numériques. J'ignore si c’est une volonté délibérée ou si ce glissement est dans l'air du temps !

Avant la dernière réforme des programmes, l’application officieuse de la règle des 80% nous a fait tomber dans ce que j'appelle le minimum du minimum de l'enseignement du domaine. (La règle des 80% consiste à donner un programme officiel et à dire aux IUT qui n'ont pas les moyens de tout faire de n'en faire que 80%). Cette règle n'a rien d'officielle et donc tous les IUT ne sont pas concernés.

Après la réforme des programmes (2013/2015 : il nous faut 2 ans pour la mettre en place), nous sommes tombés encore en-dessous de ce que je considérais comme minimum... autrement dit plus grand chose ! Je peux difficilement aller plus loin dans la critique puisque beaucoup de lecteurs ne sont pas concernés par ces programmes. Mais, l'avantage de la situation est que je ressens plus que jamais l'impérative nécessité de continuer ce livre... Ce que je ne délivre plus à mes étudiants pourra être écrit ici et servir à d'autres...

Regardons donc le problème d'un autre point de vue (encore plus discutable). Est-ce que la France a innové dans le domaine des architectures ces dernières années ? Du point de vue industriel et militaire, je ne peux me prononcer car je ne connais pas bien ces deux domaines. Mais du point de vue grand public, que dire ?

Pour ne citer que ce qui est Européen :

• L'Architecture ARM est anglaise (chaque ARM vendu paye une licence anglaise, y compris Xilinx et Altera avec leur processeurs en dur)
• Raspberry Pi est anglais et sous licence ARM
• Arduino est Italien et sous licence ARM pour le DUE et pour toutes les nouvelles architectures qui apparaissent à partir de 2019 (Arduino MKR Vidor 4000 avec son FPGA intégré)
• Imagination Community prétend être à l'origine du PIC32 de MicroChip, développe aussi MIPSfpga et est anglais
• Cartes FPGA allemandes
• Les circuits FTDI sont anglais (écossais pour être précis)
• RedPitaya est un scope USB architecturé autour d'un Zynq et c’est Slovène.

Encore une fois je peux difficilement aller plus loin sans rester raisonnable. Les exemples présentés ne sont pas que du domaine purement architecture numérique sur FPGA. Mais quand même ! Il s'agit d'architectures au sens large qui n'ont pas révolutionné le monde... mais qui ont engendré une masse de publications impressionnante pour certaines d'entre elles.

La plus exemplaire de ces innovations est incontestablement l'Arduino au moins pour l'enseignement. Rendre une carte programmable par un simple branchement USB est en soi révolutionnaire. C'est connu depuis longtemps et pourtant il a fallu attendre l'Arduino pour une diffusion de masse ! L'environnement Arduino est plutôt sobre et pourtant sa librairie est tellement bien pensée qu'elle sert aujourd'hui à programmer :

• les AVRs bien sûr, et les 32 bits Atmel
• le STM32, en tout cas la version BluePill (qui peut être trouvé autour de 1 € en 2019)
• l'ESP32 et sa facilité d'utilisation du WIFI
• les ARMs Texas Instrument avec une autre version Energia de l'environnement
• depuis 2017 les produits Alorium Technology qui sont de vrais FPGA qui remplacent un AVR (ce que l'on fait dans ce livre en moins bien peut-être)
• depuis 2018 FPGArduino pour un SOC MIPS/riscv programmable dans l'environnement Arduino
• et depuis 2019  Arduino MKR Vidor 4000 avec son FPGA intégré

Il y a probablement d'autres point de vue pour aborder le problème, ce que je laisse au lecteur.

Pour sortir des problèmes franco-français, je ne peux que constater le peu d'évolution sur les nouvelles architectures des processeurs... et me demander si le Pentium n'a pas tué la concurrence et l'innovation. Une exception quand même l'ARM qui est passé de 32 à 64 bits dans les années 2010 et qui se porte très bien. Un autre processeur est en train de progresser énormément, c'est le risc v (2020).

J’ai acheté un livre sur les architectures symboliques en 1991 et me demande si la recherche dans ce domaine continue. Si je tape "symbolic computers" dans google je trouve beaucoup de références sur le livre en question et des articles de cette époque. Qui a donc tué l'innovation internationale dans le domaine des architectures matérielles ? Le Pentium ou l'évolution de cette recherche vers des domaines plus stratégiques ou commerciaux donc un peu plus cachés ? Après l'écriture de ces lignes, j'ai fini par lire une explication : l'intelligence artificielle est rentrée dans une phase "hivernale" entre les années 1980 et 2000. La raison : le marché, comme d'habitude. Il était très difficile de gagner sa vie en 1980 avec l'intelligence artificielle. Mais c'est devenu possible aujourd'hui avec le développement de la robotique et surtout l'exploration des données (data mining)... Le marché est donc là, il faut en profiter pour trouver de nouvelles architectures.

Personnellement je pense que rien n'est figé. L'innovation est encore possible n’importe où sur la planète (et pourquoi pas en France). L'espace pour innover est absolument gigantesque. Voici quelques chiffres aussi présentés dans le chapitre 19 qui montrent ce gigantisme : 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) Ces chiffres montrent une chose très importante : Il nous reste certainement à innover dans le domaine du logiciel, mais, de mon point de vue, encore bien plus dans le domaine matériel !

Étant physicien d'origine, je me rappelle la réaction de la communauté des physiciens français à l'attribution du prix Nobel 1987 sur la supraconductivité haute température. Cette communauté s'est justement demandée si l'enseignement en France pouvait laisser présager cette possibilité de supraconduction à haute température. Ne serait-il donc pas temps de nous interroger sur notre enseignement du hardware ? Faut-il vraiment le laisser filer ? Attendre un prix Nobel pour se poser ces questions est illusoire pour nous, puisque ce domaine des architectures n'est couvert par aucun grand prix international !

Le chapitre 21 présente des challenges (deux seulement pour le moment). Il est assez mal rédigé et part un peu dans tous les sens. Apportez y donc votre contribution.

La pandémie du Covid 19 a montré la fragilité des pays industriels face à l'approvisionnement en processeurs. En effet dès avril 2021 on pouvait constater une pénurie de processeurs qui selon les spécialistes pourrait durer plus d'une année. Cette pénurie pénalise à peu près toutes les industries. L'Europe, pour une autre raison, a déjà annoncé dès juin 2019 qu'elle espérait obtenir une certaine indépendance mais surtout sur les processeurs rapides : L’Europe veut produire son propre processeur. A priori l'architecture de base sera un RISCV déjà évoqué ici.

Voila, c’est tout pour le moment.

Voir aussi

Liens internes

Une connaissance préalable du langage VHDL est absolument nécessaire.

• Conception en VHDL
• Système embarqué

Il est nécessaire de bien connaître le langage C pour beaucoup de chapitres de ce livre.

• Le langage C chez Wikipédia
• La programmation C et ses exercices chez WikiBook
• Introduction au langage C chez Wikiversité

En langue anglaise (pour la partie matérielle) :

• System on a chip
• VHDL for FPGA Design
• Microprocessor Design
• Embedded System

Sur Youtube en anglais

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

Liens externes

• Série de 12 étapes pour construire un processeur 16 bits : Le processeur S3 sur carte Nexys2/ Nexys3
• Free range factory en anglais : site à explorer qui propose un livre libre et une carte FPGA libre (mais évidemment pas gratuite) et super compacte nommée XuLa
• John's VHDL FPGA Projects en anglais
• miniSoc d'OpenCores.org
• Exemple d’utilisation du Zynq dans le projet ouvert appelé Red Pitaya qui est un oscilloscope USB/Ethernet.
• (en) Hardware Software co-design reappears. Étude sur l'évolution de la coopération logiciel/matériel (Juillet 2019).

Livres

• A. NKESTA "Circuits logiques programmables : Mémoires, PLD, CPLD et FPGA", Ellipses (1998)
• F. Anceau et Y. Bonnassieux "Conception des circuits VLSI : du composant au système", DUNOD (2007).
• A. ATTOUI "Architecture des systèmes sur puce : Processeurs synthétisables, CAO VLSI, Norme VCI, environnements ISE et Quartus", Ellipses (2005) se consacre, entre autres, à Altera et NIOS et (en) AMBA
• P. P. Chu "FPGA prototyping by VHDL Examples", WILEY (2008) dédié au Spartan 3 et aborde le PicoBlaze
• Z. Navabi "Embedded Core design with FPGA", McGraw-Hill (2007), assez général mais les applications sont Altera et NIOSII et en Verilog.
• P. P. Chu "Embedded SoPC Design with NIOS II Processor and VHDL Examples", WILEY (2011)
• Patrick R. Schaumont "A Practical Introduction to Hardware Software Codesign" Springer (2010)
• Enoch O. Hwang "Digital Logic and Microprocessor Design with VHDL" Har/Cdr (2005)