TP3 : Processeurs programmables

1 Objectif

L'objectif de ce troisième TP est d'introduire des processeurs programmables dans les architectures modélisées. Les initiateurs cablés utilisés dans les deux premiers TPs sont remplacés par des processeurs programmables (avec leurs caches L1 : cache de données et cache d'instructions). On utilisera des processeurs RISC 32 bits, car ce type de processeur possède un excellent rendement énergétique. On introduira également dans l'architecture les mémoires embarquées contenant le code binaire de l'application logicielle, ainsi que les données manipulées par le programme.

2 Architecture matérielle cible

La première architecture modélisée comporte un seul initiateur VCI et 4 cibles VCI :

• mips est un processeur MIPS32 avec ses caches L1. On utilise le composant VciXcache
• rom est une mémoire non inscriptible contenant le code binaire. On utilise le composant VciSimpleRam
• ram est une mémoire inscriptible contenant les données. On utilise également un composant VciSimpleRam
• tty est un périphérique adressable de type écran/clavier. On utilise le composant VciMultiTty?
• lcd est le coprocesseur cible réalisant le calcul du PGCD. On utilise évidemment le composant VciLcdCoprocessor?.
• bus est le bus système déjà utilsé dans le TP2. On utilise le composant VciVgsb.

3 Génération et chargement du logiciel embarqué

Il existe plusieurs façons de définir et de générer le code binaire qui sera exécuté par le (ou les) processeur(s) du MPSoC. Si on part d'unr application logicielle écrite en langage C, il faut utiliser un cross-compilateur spécifique pour le processeur choisi. Le résultat est un fichier binaire au format ELF. Le code binaire correspondant doit être chargé dans les mémoires embarquées du MPSoC.

Il y a donc deux étapes bien distinctes

• génération du code (i.e. génération du fichier ELF).
• chargement de ce code dans les mémoires.

3.1 Génération du code

3.2 Chargement du code

4 Travail à réaliser

L'archive soclib_tp3.tgz​ contient différents fichiers dont vous aurez besoin pour ce TP. Créez un répertoire de travail spécifique TP3, recopiez l'archive dans ce répertoire TP3, et décompressez-la:

$ tar xzvf soclib_tp2.tgz

Cette archive contient les fichiers généraux suivants, extraits de la plate-forme SoCLib :

• vci_param.h : definition des paramètres VCI.
• vci_signals.h : definition d'un canal VCI.
• vci_initiator.h : définition d'un port VCI initiateur.
• vci_target.h : définition d'un port VCI cible.
• int_tab.h : définition des index composites.
• segment.h : définition d'un segment de l'espace adressable.
• segment.cpp : implémentation des méthodes du segment.
• mapping_table.h : définition de la mapping table.
• mapping_table.cpp : implémentation des méthodes de la mapping table.
• address_decoding_table.h : table indexée par une partie de l'adresse.
• address_decoding_table.cpp : implémentation des méthodes de la table indexée.
• alloc_elems.h : allocation de tableaux d'objets complexes

L'archive contient également les fichiers suivants :

• vci_lcd_master.h : définition du composant VciLcdMaster (fichier complet)
• vci_lcd_master.cpp : méthodes associées (fichier incomplet)
• vci_lcd_coprocessor.h : définition du composant VciLcdCoprocessor. (fichier complet)
• vci_lcd_coprocessor.cpp : méthodes associées (fichier incomplet)
• vci_vgsb.h : définition du composant VciVgsb. (fichier complet)
• vci_vgsb.cpp : méthodes associées (fichier complet)
• tp2_simple_top.cpp : top-cell d'une architecture simple à deux composants (fichier incomplet)

5.1 Composant VciLcdCoprocessor

Le composant VciLcdCoprocessor se comporte comme un périphérique adressable, et doit donc être modélisé comme une cible VCI. Il possède un seul port de type VciTarget, et 4 registres (ou pseudo-registres) implantés dans l'espace addressable, qui peuvent donc - en principe - être lus ou écrits par n'importe quel initiateur du sytème. Chacun de ces registres a une largeur de 4 octets. Par conséquent, le segment occupé par ce périphérique dans l'espace adressable a une taille de 4*4 = 16 octets.

Pour simplifier le décodage des adresses, on impose la contrainte que l'adresse de base de ce segment est un multiple de sa longueur (on dit que le segment est aligné). La carte d'implantation des registres est définit comme suit :

Nom du registre	Offset	Mode
r_opa	0x0	Write Only
r_opb	0x4	Write Only
r_start	0x8	Write Only
r_res	0xc	Read Only

Attention : Il n'existe pas réellement de registre r_start dans le composant matériel. Lorsque le composant VciLcdCoprocessor reçoit une commande d'écriture à l'adresse correspondant à l'adresse de r_start, la donnée WDATA correspondante n'est écrite nulle part, mais la commande est interprêtée par le coprocesseur comme un ordre de démarrage du calcul.

Une erreur est signalée si le coprocesseur reçoit une commande de longueur supérieure à un mot, ou si l'adresse reçue n'appartient pas au segment qui a été défini pour le coprocesseur, ou si le mode d'accès (Read ou Write) ne respecte pas les contraintes ci-dessus.

Question : comment sont traitées les erreurs dans ce modèle de simulation? à quoi servent ces vérifications ?

La figure ci-dessous décrit la structure de l'automate de contrôle du composant VciLcdCoprocessor.

Le fichier vci_lcd_coprocessor.h contient une définition complête du composant VciLcdCoprocessor. Il n'a pas besoin d'être modifié, mais vous aurez besoin de le lire attentivement pour modifier le fichier vci_lcd_coprocessor.cpp, qui contient une description incomplête des méthodes associées à ce composant. Complétez le code des méthodes transition() et genMoore().

5.2 Composant VciLcdMaster

Le composant VciLcdMaster est un initiateur VCI, qui exécute une boucle infinie dans laquelle il exécute successivement les 6 actions suivantes:

1. calcul de deux valeurs aléatoires (entiers positifs codés sur 32 bits)
2. écriture de l'opérande OPA dans le registre r_opa du coprocesseur LCD.
3. écriture de l'opérande OPB dans le registre r_opb du coprocesseur LCD.
4. écriture dans le pseudo-registre r_start du coprocesseur LCD.
5. lecture du résultat dans le registre r_res du coprocesseur LCD.
6. affichage des résultats.

Pour accéder au coprocesseur LCD, le composant a besoin de l'adresse de base du segment de l'espace adressable aui a été assigné au coprocesseur LCD. Le composant VciLcdMaster étant un automate cablé (non programmable), on considère que cette adresse est également "câblée". Elle est donc définie comme un paramètre du constructeur. La figure ci-dessous décrit la structure de l'automate de contrôle du composant VciLcdMaster.

Chaque transaction VCI nécessite deux états dans l'automate: un premier état pour envoyer la commande (on reste dans cet état tant qu'on a pas reçu confirmation que la commande a été acceptée), et un second état dans lequel on attend la réponse (on reste dans cet état tant qu'on a pas reçu une réponse valide).

Le fichier vci_lcd_coprocessor.h contient une description complète du composant !VciLcdMaster. Il n'a pas besoin d'être modifié, mais vous devez le lire attentivement pour modifier le fichier vci_lcd_coprocessor.cpp, qui contient une description incomplète des méthodes associées à ce composant. Complétez le code des méthodes transition() et genMoore().

5.3 Architecture minimale

Pour valider les modèles de simulation des composants VciLcdMaster et VciLcdCoprocessor, on construit une architecture minimale ne contenant que deux composants matériels, conformément au schéma ci-dessous :

En vous inspirant de ce que vous avez fait dans le TP1, complétez le fichier tp2_simple_top.cpp qui vous est fourni, en précisant :

• les caractéristiques du segment mémoire associé au coprocesseur LCD.
• les valeurs des paramètres VCI (largeurs des champs) dans l'objet vci_param.
• les valeurs des arguments des constructeurs des deux composants.

On prendra pour valeurs des paramètres VCI les valeurs définies en commentaire dans le fichier tp2_simple_top.cpp.

5.4 Compilation et génération du simulateur

Il faut ensuite compiler les différents fichiers pour générer le simulateur. On va utiliser la même méthode que dans le TP1, mais il y a une difficulté supplémentaire, à cause du paramètre template vci_param des composants VciLcdMaster, VciLcdCoprocessor. Dans un contexte de compilation séparée, il est nécessaire de définir explicitement la valeur de ce paramètre dans chacun des fichiers source avant de lancer la génération du fichier objet associé. Pour cela, il faut rajouter la ligne suivante à la fin des fichiers vci_lcd_master.cpp et vci_lcd_coprocessor.cpp :

template class VciLcdMaster<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >;

(pensez à changer le nom de la classe pour vci_lcd_coprocessor.cpp.

Ceci étant fait, écrivez le Makefile permettant la génération du fichier exécutable simple_simulator.x. N'oubliez pas d'inclure dans la liste des fichiers objets les fichiers mapping_table.o, segment.o, address_decoding_table.o, address_masking_table.o (en plus des fichiers objet correspondant aux deux composants matériels

Le lancement du simulateur doit vous fournir la même trace d'exécution que celle que obtenue dans le TP1, puisque les calculs effectués sont les mêmes (seul le protocole de communication a changé.

5.5 Architecture multi-maitres

L' architecture interne du composant VciVgsb est décrite dans la figure ci-dessous. Le bus des commandes VCI, et le bus des réponses VCI sont modélisés par des multiplexeurs. Ces multiplexeurs sont commandés par un automate à trois états qui réalise une priorité tournante entre les initiateurs. Comme vous pouvez le constater sur le schéma, ce composant se comporte comme un automate de Mealy, puisque - une fois le bus alloué à un initiateur - les signaux de sortie dépendent combinatorement des signaux d'entrée. La latence minimale d'une transaction rafale de N mots VCI est de (N+1) cycles, dans le cas où la cible répond immédiatement. Du point de vue latence et bande passante, ce composant se comporte comme le PIbus.

En vous inspirant du fichier tp2_simple_top.cpp de la question précédente, écrivez le fichier tp2_multi_top.cpp, qui décrit l'architecture à 7 composants décrite au début de ce TP. Vous ferez en sorte que le maitre (i) communique avec le coprocesseur (i). N'oubliez pas de définir 3 segments différents pour les trois coprocesseurs.

Il faut également ajouter à la fin du fichier vci_vgsb.cpp la ligne permettant de définir la valeur du paramètre template vci_param :

template class VciVgsb<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >;

Modifiez le Makefile pour générer le fichier exécutable multi_simulator.x, en n'oubliant pas d'inclure le fichier vci_vgsb.o dans l'ensemble des fichiers objet. Le lancement du simulateur doit vous fournir une trace d'exécution qui entrelace les compte-rendus des trois initiateurs qui s'exécutent en parallèle. Chaque initiateur commande un seul coprocesseur, et la seule ressource partagée est le bus de communication.

6 Compte-rendu

Il ne vous est pas demandé de compte-rendu pour ce TP, mais on vous demandera une démonstration de votre simulateur au début du TP de la semaine suivante...