Étude du miniprocesseur embarqué "MCPU"

Tim Boescke, cpldcpu@opencores.org a publié en 2001-2004 un miniprocesseur (appelé MCPU par la suite) de quatre instructions (MCPU chez opencores) destiné à tenir dans un CPLD. Ses quatre instructions (on parle de jeu d'instructions) sont les suivantes :

Évidemment on a utilisé dans ce tableau

• RAZ pour Remise à zéro
• MAJ pour mise à jour
• Accu pour Accumulateur
• PC pour compteur ordinal

Seul l’adressage direct est implanté dans cette architecture et c’est bien suffisant pour un début.

Ce qui fait le grand intérêt de cette architecture c’est qu’il est possible de définir par dessus ces instructions des macros instructions de manière assez subtile :

Vous disposez à ce point de 11 instructions (4 instructions d'origine + 7 macros), ce qui est suffisant pour un calcul de PGCD (voir aussi le chapitre précédent pour le PGCD).

Remarque

La documentation originale de Tim Boescke mentionne pour l'instruction "SUB mem" la réalisation de Accu=Accu-mem[AA AAAA]. Nous pensons au contraire qu'elle réalise Accu=mem[AA AAAA] - Accu ce qui n'est absolument pas habituel. La sémantique de cette instruction risque de perturber l'utilisateur de cette architecture.

Si vous voulez respecter la sémantique habituelle vous devriez faire plutôt :

SUB mem = NOR zero, ADD one, ADD mem, NOR zero, ADD one

Transformer notre programme en ...

Quand on a l'habitude de faire fonctionner des micro contrôleurs on sait qu’il suffit de compiler un programme en fichier hex qu'un programmateur permettra d'envoyer à une EPROM. Mais ici, comment et où va finir notre programme ? En général on dispose d'un programme convertisseur qui permet de transformer notre fichier hex en VHDL. Ce VHDL finira dans des blocs logiques ou dans de la RAM (il y en a dans tout FPGA moderne).

Ainsi mettre notre MCPU dans un FPGA ou dans un CPLD (comme initialement prévu par son concepteur) est un peu différent : dans le CPLD il est très probable que le programme soit externe (EPROM externe par exemple), alors que dans un FPGA on s'arrangera pour laisser le programme en interne dans une RAM/ROM prévue à cet effet.

Remarque

Puisqu’il n'y a pas de standard pour la description de RAM/ROM en VHDL, les différents fabricants de FPGA laissent au style de programmation VHDL le soin de définir ce qui sera finalement utilisé dans le FPGA en lieu et place des RAM/ROM. C'est pratique, mais cela a un inconvénient : celui d’être dépendant du fabricant.

Exercice 1

Le programme VHDL de description original de Tim Boescke pour décrire son architecture est tellement simple que nous le donnons maintenant complètement :

-- Minimal 8 Bit CPU
-- rev 15102001
-- 01−02/2001 Tim Boescke
-- 10 /2001 slight changes for proper simulation.
-- t.boescke@tuhh.de
library ieee; 
use ieee.std_logic_1164.all; 
use ieee.std_logic_unsigned.all; 

entity CPU8BIT2 is 
	port (	data:	inout	std_logic_vector(7 downto 0); 
		adress:	out	std_logic_vector(5 downto 0); 
		oe:	out	std_logic; 
		we:	out	std_logic;	-- Asynchronous memory interface 
		rst:	in	std_logic; 
		clk:	in	std_logic); 
end; 

architecture CPU_ARCH of CPU8BIT2 is 
	signal	akku:	std_logic_vector(8 downto 0);	-- akku(8) is carry ! 
	signal	adreg:	std_logic_vector(5 downto 0); 
	signal 	pc:	std_logic_vector(5 downto 0); 
	signal	states:	std_logic_vector(2 downto 0); 
begin 
	process(clk,rst) 
	begin 
	 if (rst = '0') then 
		adreg	<= (others => '0');-- start execution at memory location 0 
		states	<= "000"; 
		akku <= (others => '0'); 
		pc <= (others => '0'); 
	 elsif rising_edge(clk) then 
		-- PC / Adress path 
		if (states = "000") then 
			pc	<= adreg + 1; 
			adreg	<= data(5 downto 0); 
		else	 
			adreg	<= pc; 
		end if; 
		-- ALU / Data Path 
		case states is 
		 when "010" => akku <= ("0" & akku(7 downto 0)) + ("0" & data); 	-- add 
		 when "011" => akku(7 downto 0) <= akku(7 downto 0) nor data;	-- nor 
		 when "101" => akku(8) <= '0';-- branch not taken, clear carry 
		 when others => null;	-- instr. fetch, jcc taken (000), sta (001) 
		end case;						 
		-- State machine 
		if (states /= "000") then states <= "000"; 	-- fetch next opcode 
		elsif (data(7 downto 6) = "11" and akku(8)='1') then states <= "101";	-- branch not taken 
		else states <= "0" & not data(7 downto 6);-- execute instruction	 
		end if;	 
	 end if; 
	end process; 
	-- output 
	adress	<= adreg; 
	data 	<= "ZZZZZZZZ" when states /= "001" else akku(7 downto 0); 
	oe <= '1' when (clk='1' or states = "001" or rst='0' or states = "101") else '0'; 	-- no memory access during reset and 
	we <= '1' when (clk='1' or states /= "001" or rst='0') else '0'; 			-- state "101" (branch not taken) 	 
end CPU_ARCH;

Cette architecture utilise une seule mémoire pour les données et le programme : ils peuvent donc être mélangés dans une même mémoire. Répondre aux questions suivantes :

1. Le compteur programme destiné à chercher les instructions en mémoire programme est sur 6 bits. Quelle est la taille de la mémoire programme sachant que, comme le montre le tableau des instructions, les opcodes sont sur 8 bits ?
2. Dans le tableau ci-dessus, AAAAAA désigne une adresse mémoire en binaire sur 6 bits tandis que DDDDDD désigne une destination sur aussi 6 bits. Quelle est la taille de la mémoire donnée adressable ?
3. L'astuce de cette architecture est qu’il est possible de définir par dessus ces instructions des macros instructions (ensemble d'une ou plusieurs instructions) de manière assez subtile. Pouvez-vous donner l'opcode de "JMP dst" ?
4. Le signal "Akku" représente le registre accumulateur, là où se trouve le résultat de toute exécution d'instruction. Pourquoi est-il sur 9 bits au lieu de 8 ?
5. La machine d'états qui séquence le processeur est décrite après le commentaire "State machine" sur 3 lignes. Son état est décrit par le signal "state". Combien d'états (au maximum) peut comporter cette machine ?
6. Quel est l'état futur de l'état "001" ?
7. Chercher les équations de récurrences de cette machine d'états.
8. Assembler manuellement le programme du PGCD, puis transformer manuellement le binaire en mémoire ROM VHDL. Insérer cette ROM avec le processeur et tester à l'aide d'une simulation.

 État present Opcode(7) Opcode(6) Akku(8) État futur
    000        1          1        1       101       pas de saut car retenue à 1
    000        1          1        0       000       saut car retenue à 0
    000        0          1        X       010
    000        1          0        X       001
    000        0          0        X       011
    001        X          X        X       000
    010        X          X        X       000
    011        X          X        X       000
    100        X          X        X       000
    101        X          X        X       000
    110        X          X        X       000
    111        X          X        X       000

Nous allons nous intéresser maintenant à la réalisation de ce processeur en architecture Harvard, c'est-à-dire en séparant la mémoire donnée de la mémoire programme. L'intérêt est de réaliser un processeur pouvant exécuter une instruction par période d'horloge, mais sa compréhension nécessite un certain recul sur l'architecture des chemins de données dans les processeurs.

Autre code source de MCPU

Un membre du forum stackoverflow a écrit une version un peu plus lisible de MCPU en VHDL :

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity mcpu is
    port (
        data_bus: inout std_logic_vector(7 downto 0);
        address: out std_logic_vector(5 downto 0);
        n_oe: out std_logic;
        -- Asynchronous memory interface
        n_we: out std_logic;    
        n_reset: in std_logic;
        clock: in std_logic
    );
end;

architecture refactored of mcpu is
  signal accumulator: std_logic_vector(8 downto 0);
  alias carry is accumulator(8);  
  alias result is accumulator(7 downto 0);
  alias opcode is data_bus(7 downto 6);

  signal address_register: std_logic_vector(5 downto 0);
  signal pc: std_logic_vector(5 downto 0);
  signal states: std_logic_vector(2 downto 0);

  type cpu_state_type is (FETCH, WRITE, ALU_ADD, ALU_NOR, BRANCH_NOT_TAKEN);
  signal cpu_state: cpu_state_type;

  type state_encoding_type is array (cpu_state_type) of std_logic_vector(2 downto 0);
  constant STATE_ENCODING: state_encoding_type := (
      FETCH => "000", 
      WRITE => "001", 
      ALU_ADD => "010", 
      ALU_NOR => "011", 
      BRANCH_NOT_TAKEN => "101"
  );

begin
    process (clock, n_reset)
    begin
        if not n_reset then
            -- start execution at memory location 0
            address_register <= (others => '0');  
            states <= "000";
            cpu_state <= FETCH;
            accumulator <= (others => '0');
            pc <= (others => '0');
        elsif rising_edge(clock) then

            -- PC / Adress path
            if cpu_state = FETCH then
              pc <= address_register + 1;
              address_register <= data_bus(5 downto 0);
            else
              address_register <= pc;
            end if;

            -- ALU / Data Path
            case cpu_state is
                when ALU_ADD => 
                    accumulator <= ('0' & result) + ('0' & data_bus);
                when ALU_NOR => 
                    result <= result nor data_bus;
                when BRANCH_NOT_TAKEN => 
                    carry <= '0';
                when others => null;
            end case;

            -- State machine
            if cpu_state /= FETCH then 
                cpu_state <= FETCH;
            elsif opcode ?= "11" and carry then 
                cpu_state <= BRANCH_NOT_TAKEN;
            else
                states <= "0" & not opcode;       -- execute instruction
                case opcode is
                    when "00" => cpu_state <= ALU_NOR;  -- 011
                    when "01" => cpu_state <= ALU_ADD;  -- 010                    
                    when "10" => cpu_state <= WRITE;    -- 001
                    when "11" => cpu_state <= FETCH;    -- 000
                    when others => null;                     
                end case;
            end if;
        end if;
    end process;

    -- output
    address <= address_register;    
    data_bus <= result when (cpu_state = WRITE) else (others => 'Z');

    -- output enable is active low, asserted only when
    -- rst=1, clk=0, and state!=001(wr_acc) and state!=101(read_pc)
    n_oe <= '1' when (clock='1' or cpu_state = WRITE or n_reset = '0' or cpu_state = BRANCH_NOT_TAKEN) else '0';

    -- write enable is active low, asserted only when
    -- rst=1, clk=0, and state=001(wr_acc)
    n_we <= '1' when (clock = '1' or cpu_state /= WRITE or n_reset = '0') else '0';

end;

Séquencement du programme

Le déroulement d'un programme se fait par recherche de l'instruction "Instruction Fetch" et incrémentation du PC (compteur programme ou compteur ordinal) pour pouvoir aller chercher l'instruction suivante. Voici le schéma correspondant :

Le compteur ordinal

Instructions NOR et ADD

Ces deux instructions sont dans le même groupe car elles vont chercher toutes les deux une donnée en mémoire. Voici le schéma correspondant :

Nos deux premières instructions

Vous voyez apparaître dans cette figure une Unité Arithmétique et Logique ou ALU qui est responsable de la réalisation de deux instructions. Cela signifie qu'elle possède à ce stade un seul fil de sélection non présenté dans le schéma. Un registre supplémentaire, l’accumulateur noté "AC", apparaît maintenant dans notre nouvelle architecture.

Remarque

Regrouper les instructions par groupes nécessite une certaine expérience. Lisez l’article Instruction Machine qui vous détaille un classement des instructions.

Séquencement de NOR et ADD

Cela consiste tout simplement à associer les deux schémas précédents :

Séquencement de nos deux premières instructions

Instruction STA ou écriture dans la mémoire données

L'instruction STA

Évidemment l'adresse provient de l'instruction.

Séquencement des 3 instructions

On assemble les deux derniers schémas :

Séquencement de nos trois premières instructions

Un soin tout particulier devra être pris pour l’ensemble AC + ALU + DMUX si l’on veut garder la valeur dans AC (front d'horloge inévitable).

Instruction de contrôle et son chemin de donnée

L'instruction de contrôle unique est JCC qui a la particularité de mettre la retenue à 0 après son exécution.

Notre seule et unique instruction de contrôle : JCC

Jusqu'à présent, le bit de retenue n'a pas été ajouté au schéma pour raisons de simplifications.

Ensemble des instructions

L'ensemble des instructions peut être réalisé par le chemin de données suivant:

Architecture complète

La fonction combinatoire "Fct" détecte l'instruction JCC et la retenue à 0.

Remarque

Le fait de séparer la mémoire données de la mémoire programme présente un grave inconvénient pour une si petite architecture : on ne peut plus mettre les données dans la mémoire programme puisqu’il n'y a plus d'instruction pour venir les chercher ! Il existe heureusement plusieurs solutions pour contourner cela :

1. Décomposer la mémoire données en deux parties comme dans la très grande majorité des micro contrôleurs modernes, soit un banc de registres suivi de la RAM proprement dite. Le banc de registres relié à l'extérieur permettrait d'entrer les données par l'extérieur.
2. Prévoir dans l'assembleur une possibilité de séparer des valeurs qui iront dans la mémoire données. La programmation du composant se fera par l'envoi du programme pour la mémoire programme et par l'envoi des données pour la mémoire données.

Réalisation de l'unité de contrôle

L'unité de contrôle permet de générer "wr_mem", rd_mem", "ac_src" et "pc_src" à partir des bits d'instructions et de la retenue. C'est donc tout simplement une super-fonction combinatoire remplaçant "Fct".

Exercice 2

Implanter complètement l'architecture MCPU monocycle et la tester avec le programme PGCD.