Je ne parle pas ici de microcontroleur du genre PIC ou AVR mais plutôt de logique combinatoire. En fait il s'agit de partir d'un peu plus loin, au niveau portes logiques.
Pour tous ceux intéressés par la synthèse de circuits numériques, je vous recommande Digital Design and Computer Architecture. Il est également question de SystemVerilog et VHDL (à titre introductif).
PS : Je recommande à ceux qui souhaite apprendre un HDL de se tourner vers le SystemVerilog, qui est le seul véritable HDVL (Hardware Description and Verification Language), i.e. seul langage conçu nativement pour la synthèse et la vérification de circuits numériques complexes.
Je viens de voir le sujet, et je viens donc proposer mon point de vue sur la question. Avant le passage à la v4, nous (olyte, zeqL, megacier et moi-même) avions commencé à reprendre la rédaction d'un tutoriel portant sur la logique et l'électronique numérique. Après moult discussions, j'avais proposé de plutôt s'orienter sur la logique en elle-même, et le fonctionnement des composants numériques à partir de la logique. Le plan de ce cours pourrait ressembler à ceci :
Les bases de la logique et du numérique
Présentation de l'électronique
Le système binaire
Les bases arithmétiques
La logique combinatoire
Les portes logiques
Les équations : manipulation et simplification
Un additionneur
Un décodeur
Multiplexage et démultiplexage
TP : un afficheur 7 segments
Une unité arithmétique et logique (1ère partie)
Une unité arithmétique et logique (2nde partie)
La logique séquentielle
Les bascules
Les compteurs
Les registres
Les registres à décalage
TP : un UART
Les mémoires vives
Architecture d'une mémoire complète
Les bus de communication
Les microprocesseurs
Architecture générale
Les différents registres
Le registre d'instructions
Le jeu d'instructions
L'unité de contrôle ou séquenceur
Le langage assembleur
L'idée de ce tutoriel serait de permettre à tout le monde de comprendre les bases de la logique, et de progresser au fur et à mesure vers des architectures plus complexes de composants numériques. Cela pourrait donc tout autant s'adresser à des informaticiens qui veulent en savoir plus sur le fonctionnement des composants qu'ils programment, ou à des électroniciens qui souhaiteraient s'orienter vers du développement VHDL par exemple.
Pour en revenir aux FPGA et au VHDL, un cours serait effectivement le bienvenu. Toutefois, je pense qu'il serait plus intéressant de diviser les tutoriels par spécialités, et donc qu'il serait judicieux de séparer la partie apprentissage de la logique de la partie apprentissage du VHDL. Le tutoriel VHDL ne traiterait donc que du VDHL. Après libre à l'auteur de conseiller un niveau requis minimal en logique et le réorienter vers les premières parties du cours présenté précédemment sur la logique.
Enfin, je précise que tout ceci est uniquement mon point de vue. Mais je pense qu'il serait bien d'en discuter avec les potentiels auteurs du cours sur le VHDL, s'ils sont toujours là.
NB : Les processeurs n'ont plus de séquenceur depuis quelques temps, mis à part quelques microcontroleurs.
Ça, c'est totalement faux. Je ne sais pas où tu as lu ça, mais les processeurs actuels ont tous une unité de contrôle (un séquenceur comme tu dis). N'importe quel processeur actuel a bien une unité de décodage, parfois du micro-code pour les processeurs x86 actuels, et tout le tattouin.
La seule exception, ce sont certaines Transport trigerred architectures, et encore...
Pas à ma connaissance. Qu'ils soient in order ou out of order, ils ont tous une logique de décodage des instructions. Les signaux de contrôle se propagent au niveaux de bascules et des RS ; mais il n'existe plus de séquenceur à proprement parler.
Par définition, un séquenceur est un automate, donc une machine de Moore ou Mealy. Si ces circuits sont adaptés à de petits designs, ils le sont beaucoup moins pour des processeurs supportant plusieurs milliers d'instructions. (Imaginez la complexité d'un tel circuit, sachant que le nombre d'états dudit circuit est d'autant plus grand que le pipeline est profond.)
Néanmoins, il est vrai que les processeurs x86 disposent d'unité(s) de décodage des macro-opérations simples — instructions — et complexes — issues de la fusion d'opérations. Ces unités se rapprochent quelque peu d'automates, car ne sont pas séquentielles et font appel à une mémoire de micro-code. Mais elles ne contrôlent pas l'intégralité du processeur ; en ce point, elles diffèrent de la définition propre d'un séquenceur.
Si tu n'es pas convaincu, je t'invite à créer un processeur scalaire simple (à cinq étages, par exemple), in order et n'implémentant que quelques instructions. Tu peux également en trouver des exemples sur internet, et aucun ne dispose d'un séquenceur ! Les codes opérations et registres se propagent dans des buffer, et ne sont pas suivies par un automate — type machine de Moore ou Mealy.
Je suis parfaitement au courant de ce que tu raconte (lit "Fonctionnement d'un ordinateur de zéro", tu verras...), et je peux te certifier que tes exemples sont tout sauf convaincants, et sont même totalement faux.
Petite remarque : le séquenceur, c'est l'unité de contrôle, c'est à dire tout ce qui n'est pas ALU, registres, interface mémoire, ou autres unités fonctionnelles. Son rôle est de traduire une instruction en signaux de commandes à envoyer aux unités fonctionnelles (ALU, registres, et autres).
C'est là que tu as fait une erreur : rien n'oblige le séquenceur à être un automate, ce n'est pas dans la définition. Dans l'exemple du simple processeur in-order à 5 étages que tu m'as demandé de construire, l'ensemble Program Counter, unité de décodage, de Fetch, et les circuits autour, forme bien un séquenceur.
Alors c'est vrai que dans la majorité des livres et tutoriels, on aborde uniquement les unités basées sur des séquenceurs câblés et micro-codés, mais il existe d'autres formes d'unités de contrôle. Certaines sont purement combinatoires, d'autres se basent sur plusieurs automates.
C'est le cas sur les processeurs modernes, le séquenceur est composé d'un ensemble d'automates (et de circuits combinatoires affiliés), comprenant l'unité de décodage, d'Issue, l'unité de scheduling, celle de Completion/retirement, etc.
Par exemple, les processeurs actuels font obligatoirement vérifier les dépendances entre instructions par l'unité d'Issue. Pour vérifier ces dépendances, ton unité d'Issue est composée d'un circuit combinatoire, et d'une mémoire qui stocke les informations sur les registres et les circuits utilisés par les instructions déjà Issue dans ton pipeline. Cette mémoire est mise à jour à chaque Issue d'une instruction, ce qui fait que l'ensemble est toujours bouclé de manière à former un automate (de Mealy pour la majorité des cas).
Dans ton exemple du classical RISC pipeline à 5 étage, cette unité d'Issue est composée de la stalling unit (un paquet de comparateurs reliés par des portes OU), et des buffers de pipelines qui propagent les registres de destination (et de lecture, parfois). Regarde la façon dont c'est relié : tu verras des boucles qui forment un automate de Mealy.
Après, la logique d'Issue peut être plus compliquée. Les processeurs in-order ou OO peuvent utiliser un automate basé sur un scoreboard, certains processeurs OOO se basent sur un automate composé de l'unité d'Issue et d'un instruction buffer, et certains se basent sur des reservations stations et un common memory ordering bus. Techniquement, cette logique d'Issue est toujours un automate, même s'il est bien caché (notamment dans le cas des reservations stations...).
Ensuite, pour ta remarque concernant les unités de décodage µcodées des processeurs x86, elles disposent d'un µ-compteur ordinal qui leur donne un statut d'automate tout ce qu'il y a de plus normal. Sans cela, des instructions comme SCACB, constituées de longues boucles de micro-codes, ne fonctionneraient pas très bien...
Les seuls cas où il n'y a pas de séquenceur, c'est certaines transport trigerred architectures, pour lesquelles les signaux de commande sont encodés directement dans la représentation binaire de l'instruction.
En quoi mes exemples sont-ils faux ? Je code en Verilog, et n'ai jamais vus de séquenceur dans les processeurs actuels, n'y n'en ai intégré dans mes réalisations. De nature, un séquenceur est nécessairement combinatoire, puisque contrôlant l'état présent de la machine au regard du passé. C'est aussi une unité à portée « globale ».
Les étages de fetch, de décodage (quoique) et de gestion des dépendances sont certes des automates, mais n'en demeurent pas moins indépendants. Si vous considérez que disposer ces unités independantes en cascade constitue un séquenceur, alors oui, les processeurs en sont dotés. Mais ce n'est pas la définition que j'en ai.
Pour avoir réalisé un processeur micro-programmé, je vois une nette différence avec un MIPS ou un ARM. Les unités sont beaucoup moins indépendantes les unes des autres. Je vois le processeur avec séquenceur comme une « unité de production » dont la logique de contrôle suit les instructions de leur décodage à leur exécution ; le MIPS ou ARM ressemble plus à une chaîne de montage, dont chaque unité est indépendante.
Mais il est vrai que l'étage de décodage des x86 est semblable, notamment au passage des macro-ops aux micro-ops…
Si la définition que je vous en ai donné ne vous convient pas, donnez moi la votre (sa finalité).
Les étages de fetch, de décodage (quoique) et de gestion des dépendances sont certes des automates, mais n'en demeurent pas moins indépendants. Si vous considérez que disposer ces unités indépendantes en cascade constitue un séquenceur, alors oui, les processeurs en sont dotés. Mais ce n'est pas la définition que j'en ai.
Et ben voilà, on est d'accord. C'est ce que je te disais : ta définition n'est pas la bonne, et à vrai dire, je suis prêt à parier que tu es le seul à l'utiliser.
Ce n'est peut-être pas la définition que tu en as, mais la définition d'un séquenceur, c'est çà : ensemble de circuits électroniques qui se charge de piloter le chemin de données (ALU, registres, communication avec la mémoire) en leur envoyant des signaux de commandes. Pour faire simple, le séquenceur, c'est ce qu'il reste quand tu as enlevé le chemin de données, pas autre chose.
Le fait que tout cela soit un ensemble de circuits indépendants (et encore, il y a pas mal de boucles dans le pipeline), ou un bloc purement combinatoire (sans automates), ne change rien : c'est quand même un séquenceur.
Et au passage, petite correction : tu faisais une comparaison entre MIPS/ARM et processeur µ-codé. Le seul problème, c'est que le jeu d'instruction et la conception du séquenceur sont indépendants. La confusion est courante. Il est parfaitement possible de remplacer l'unité de décodage par un micro-code sans rien changer au pipeline, et en ne supprimant que quelques fonctions dans l'ALU, par exemple.
Désolé, je ne peux pas laisser le liens, ça mène vers un contenu protégé par les droits d'auteurs dont tu ne détiens pas, il me semble, les droit de reproduction et de mise à disposition.
Moi aussi je suis tres interesse, je pense que ce tuto aura un gros succes, car il en existe tres peu sur le net .
Est-t-il possible que tu publie malgre tout ce que tu as commence a rediger en guise de version beta ? Je pense que d'autres developpeurs VHDL t'aideront a corriger les coquilles et seront present pour repondre a nos questions.
Salut !! Je suis actuellement en train de programmer "Pong" grâce à un logiciel, carte et écran... Ca fait parti de mon TP, et je ne maîtrise pas encore ce langage. Les gens dans mon cas n'ont pas besoin des bases de numériques, puisque ça fait parti de mon enseignement. Et comme dit précédemment, on ne trouve que peu de tutos sur Internet à propos du VHDL, donc je vous serais très reconnaissant si vous publiiez à ce sujet. Merci beaucoup !!
- Edité par PierreThivel 18 décembre 2016 à 19:11:26
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.