Processeur multicycle 8 bits

Étude de cas

Processeur multicycle 8 bits – vérification RTL et préparation du portage DE1. Un processeur multicycle VHDL à programme interne fixe, étendu à partir d’une conception RTL universitaire existante, vérifié avec GHDL (dont des suites ALU exhaustives) et préparé pour un portage Terasic DE1.

Contexte et défi

Le point de départ était une conception RTL de processeur multicycle 8 bits existante, issue d’un projet universitaire : une FSM de contrôle (FETCH, DECODE, LOAD_IMM, WAIT_UAL, CAPTURE, WRITEBACK, HALT) pilotant une ROM d’instructions fixe 16x8, une ALU à 12 opérations avec un handshake start/done, et des registres de résultat et de fanions. L’enjeu était de rendre cette conception défendable et prête pour une carte FPGA : construire un véritable environnement de vérification autour d’elle, trouver et corriger d’éventuels bugs de frontière, et la préparer pour l’intégration FPGA, sans réécrire l’architecture du processeur lui-même.

Périmètre et responsabilités

Ce dépôt étend et adapte une conception RTL existante issue d’un projet universitaire ; le processeur complet n’a pas été construit entièrement à partir de zéro. Ce qui est spécifiquement attribuable au travail de ce dépôt : l’environnement de vérification (les huit testbenches GHDL et le modèle de référence indépendant dans tb/tb_pkg.vhd), une correction de frontière sur le compteur programme, la préparation du portage Terasic DE1 (wrapper, projet Quartus, contraintes et affectations de broches), le workflow d’intégration continue, et la documentation. La FSM de contrôle, l’ALU et l’architecture du datapath sont la conception d’origine du projet universitaire.

La correction du compteur programme cible un bug de frontière précis : PC est déclaré avec une plage 0..15, mais dans le RTL importé, les deux incréments utilisaient un simple PC + 1, si bien que la lecture de ROM[15] faisait sortir PC de sa plage et arrêtait la simulation avant le décodage de HALT. Les deux incréments utilisent désormais une arithmétique modulo 16 explicite, et la régression exerce précisément cette frontière.

Architecture / Conception du système

Le datapath sépare une ROM d’instructions fixe, un registre d’instruction, deux registres d’opérandes (A, B) chargés uniquement depuis des octets immédiats de la ROM, une ALU registrée (ual_8) atteinte via un handshake start/done, et un registre de résultat avec les fanions Z/N/C/V. ual_8 compose cinq sous-unités combinatoires ou séquentielles : un additionneur/soustracteur 8 bits, une unité logique, un décaleur, un multiplicateur shift-add 8x8 non signé, et un cœur de racine carrée entière 16 bits. R n’est écrit que par les opérations ALU et n’est jamais rebouclé dans le datapath : il n’y a ni mémoire de données, ni banc de registres, ni branchement, ni pile, et les instructions se limitent à LOAD_A, LOAD_B, HALT et des opérations ALU simples sélectionnées par le quartet bas de l’octet d’instruction.

Mise en œuvre

Le programme fixe de la ROM charge A = 0x19 et B = 0x07, puis exerce toutes les opérations ALU sauf NOT et les codes inutilisés, et se termine par HALT. Le timing des instructions est une propriété architecturale de la FSM de contrôle et du datapath : une séquence LOAD s’étend sur 3 fronts d’horloge, une opération ALU simple sur 8 fronts, MUL sur 16 fronts et SQRT sur 17 fronts, directement dérivés du graphe d’états de la FSM et des latences des sous-unités plutôt que de mesures de performances réelles. Le wrapper DE1 instancie le RTL du processeur sans le modifier et n’ajoute que la glue de carte : un diviseur d’horloge de démonstration (donnant une horloge cœur à 8 Hz pour que la trace de résultat sur ~110 fronts d’horloge soit observable), un synchroniseur de reset à deux registres, et un décodage sept segments pour l’affichage du résultat.

Vérification et preuves

Chaque testbench est un testbench GHDL auto-vérifiant, comparé à un modèle de référence indépendant qui utilise une arithmétique entière classique plutôt que la structure bit-à-bit du RTL lui-même. Six des huit testbenches sont exhaustifs : 1573888 vecteurs vecteurs sont appliqués sur l’additionneur/soustracteur, l’unité logique, le décaleur, le multiplicateur, le cœur de racine carrée et l’ALU complète, et ce périmètre ne concerne que l’ALU et ses sous-unités, pas la vérification du processeur complet. Les deux testbenches restants vérifient le processeur lui-même cycle par cycle face à un modèle au niveau instruction, incluant la frontière ROM[15]/HALT et un reset asynchrone en cours d’opération. Sur l’ensemble des huit testbenches, le résultat de la régression complète du dépôt est 8 réussi(s) / 0 échoué(s).

L’intégration DE1 est préparée et revue statiquement : vrai.

L’exécution historique sur DE1 est une question distincte de l’état de la révision actuelle. L’auteur atteste qu’une version antérieure de cette conception a fonctionné sur une carte Terasic DE1 physique lors du projet universitaire ; il s’agit d’une simple attestation de l’auteur, car aucune sortie Quartus, aucun fichier de programmation, aucun journal du programmateur, aucun rapport ni aucune photo n’est conservé comme preuve indépendante. Cette version antérieure précède la correction du compteur programme modulo 16 : elle ne dit rien de la révision corrigée actuelle ni du wrapper actuel, qui ne sont ni l’un ni l’autre démontrés de façon indépendante sur matériel.

Résultats

Sur l’ensemble des suites de test, les six testbenches exhaustifs ALU/sous-unités (6 réussi(s) / 0 échoué(s)) et la régression processeur complète sur huit testbenches (8 réussi(s) / 0 échoué(s)) passent face au modèle de référence, avec un périmètre distinct maintenu pour chaque chiffre : le nombre de vecteurs ALU/sous-unités est un chiffre séparé et plus étroit que le résultat de régression complète sur huit testbenches. Aucun Fmax, résultat de placement-routage, taux d’utilisation ou autre métrique d’implémentation n’est revendiqué, et aucune exécution sur carte FPGA de la révision actuelle n’est revendiquée ; l’exécution historique du projet universitaire n’est attestée que par l’auteur, comme décrit ci-dessus.

Limites

Pour la révision et le wrapper actuels, aucune compilation Quartus, aucun placement-routage, aucun assemblage, aucune programmation de la DE1 ni aucun résultat TimeQuest n’est établi de façon indépendante, et aucune fermeture de timing n’est revendiquée : la préparation DE1 actuelle n’est établie qu’au niveau de la vérification de synthèse GHDL et de la revue statique, et l’exécution historique sur DE1 n’est attestée que par l’auteur. Le jeu d’instructions ne comporte ni branchement, ni mémoire de données, ni banc de registres, ni arbitrage de bus, et le programme de la ROM est fixe à la synthèse. Le multiplicateur tronque silencieusement son octet haut sans positionner C ni V.

Points clés à retenir

Reprendre une conception RTL existante et non triviale pour la rendre fiable a nécessité de construire un environnement de vérification depuis rien : un modèle de référence indépendant, une couverture exhaustive là où l’espace d’états le permet, et des vérifications cycle par cycle du processeur là où ce n’est pas le cas. Cela a aussi demandé d’être précis sur ce que signifie réellement « étendre » une conception – corriger un véritable bug de frontière sans toucher à l’architecture dans laquelle il s’inscrit, et être explicite, dans la régression elle-même, sur ce qui est établi, ou non, pour la cible FPGA.

Livrables / Références

Dépôt public : github.com/mahdidou711/vhdl-8bit-multicycle-processor.