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 dans ce TP comporte un seul initiateur VCI et 4 cibles VCI :

• mips32 est un processeur MIPS32 avec ses caches L1. On utilise le composant VciXcacheWrapper
• rom est une mémoire non inscriptible contenant le code de boot. On utilise le composant VciSimpleRam
• ram est une mémoire inscriptible contenant le code et 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.

Les modèles de simulation des composants matériels instanciés dans cette architecture sont disponibles dans la bibliothèque SoCLib. Ils vous sont fournis, et vous n'aurez pas à les re-écrire vous-même.

Le composant VciXcacheWrapper est un contrôleur de cache générique à interface VCI, qui peut être utilisé pour interfacer différents coeurs de processeur avec le reste du système. Le coeur du processeur est modélisé par un ISS (Instruction Set Simulateur). Le type du proceseur instancié (MIP32, ARM, SPARCV8, PPC405, NIOS, MicroBlaze?, etc.) est défini par un paramètre template du composant VciXcacheWrapper.

Le composant VciSimpleRam est utilisé pour modéliser des mémoires inscriptibles embarquées (SRAM), ou pour modéliser des mémoires non inscriptibles (ROM) dont le contenu est cablé. Ce composants peut contenir un ou plusieurs segments (correspondant à des tranches disjointes de l'espace addressable). Cela signifie que ce composant décode les bits de poids fort de l'adresse VCI pour adresser le segment désigné. Les dimensions des tableaux qui implémentent les bancs mémoire physique sont définis par les longueurs des segments définis dans la MappingTable?.

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'une 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_xcache_wrapper.h : définition du composant VciXcacheWrapper
• vci_xcache_wrapper.cpp : méthodes associées
• vci_lcd_coprocessor.h : définition du composant VciLcdCoprocessor
• vci_lcd_coprocessor.cpp : méthodes associées
• vci_simple_ram.h : définition du composant VciSimpleRam
• vci_simple_ram.cpp : méthodes associées
• vci_multi_tty.h : définition du composant VciMultiTty
• vci_multi_tty.cpp : méthodes associées
• vci_vgsb.h : définition du composant VciVgsb
• vci_vgsb.cpp : méthodes associées
• tp3_mono_top.cpp : top-cell d'une architecture simple à deux composants (fichier incomplet)

5.1 Génération du logiciel embarqué

5.2 Instanciation des codèles des composants

5.3 Définition de la Top-cell

Il faut compléter le fichier tp3_mono_top.cpp, pour définir la segmentation de l'espace adressable, définir les arguments des constructeurs et les valeurs des paramètres template des différents composants matériels instanciés.

Cette architecture nécessite la définition de 6 segments:

• seg_lcd est le segment associé au coprocesseur LCD. On prendra pour adresse de base la valeur 0xD0000000. La longueur de 16 octets correspond aux quatre registres adressables de ce composant.
• seg_tty est le segment associé au contrôleur de terinaux TTY. On prendra pour adresse de base la valeur 0xC0000000, et pour longueur 64 octets, ce qui permet d'adresser jusqu'à 4 terminaux indépendants (consulter la spécification fonctionnelle du composant VciMultiTty?).
• seg_reset est le segment contenant contient le code de boot exécuté à la mise sous tension. Il est évidemment assigné à la ROM. L'adresse de base 0xBFC00000 est imposée par la spécification du processeur MIPS32. On choisira une capacité de stockage de 4Koctets.
• seg_giet est le segment contenant le code du Gestionnaire d'Interruptions, Exceptions, et Trappes (GIET). Il est assigné à la RAM. L'adresse de base 0x80000000 est imposée par la spécification du processeur MIPS32. On choisira une capacité de stockage de 4 Koctets.
• seg_code est le segment contenant le code de l'application logicielle embarquée. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x00400000,

et une capacité de stockage de 16 Koctets.

• seg_data est le segment contenant les données globales et la pile d'exécution de l'application logicielle embarquée. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x10000000, et une capacité de stockage de 64 Koctets.

5.3 Génération du logiciel embarqué

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...