TP4 : Interruptions et architectures multi-processeurs

1 Objectif

Le but de ce quatrième TP est double :

D'un côté, on souhaite introduire de nouveaux périphériques supportant la communication par interruption, et analyser les mécanismes de communication entre un programme utilisateur et un périphérique.

D'un autre côté, on souhaite modéliser des architectures comportant plusieurs processeurs programmables.

Il existe deux types de périphériques:

• Un contrôleur TTY est un périphérique caractère car il supporte des requêtes de lecture ou d'écriture d'un seul caractère. Ce type de périphérique se comporte comme une cible sur le bus, puisqu'il ne peut que recevoir des commandes provenant d'un processeur, et qu'il n'a pas la possibilité de lire ou d'écrire lui-même en mémoire.

• Par opposition un périphérique bloc, tel qu'un contrôleur de disque, (ou un contrôleur réseau) doit tranférer de grosses quantités de données entre la mémoire et le disque (ou le réseau). Les transferts se font par blocs (un bloc contenant généralement 512 octets), et ces périphériques ont généralement une capacité DMA : Ils sont à la fois maître et cible sur le bus, cat ils peuvent directement lire ou écrire en mémoire.

2. Interruptions vectorisées

2.1 composants matériels

Lorsque le nombre de périphériques augmente, le nombre de lignes d'interruption augmente également, et il faut un mécanisme permettant de concentrer plusieurs dizaines de requêtes d'interruption vers un seul signal connecté au processeur.

Ceci nécessite d'introduire un nouveau composant matériel dans l'architecture : Le composant vci_icu est un contrôleur d'interruptions vectorisées. C'est une cible VCI dont vous trouverez la spécification fonctionnelle ​ici.

Le composant vci_multi_timer est également une cible VCI contenant un nombre queconque de timers programmables capables de générer des interruptions périodiques à destination du processeur. On trouvera la spécification fonctionnelle de ce composant ​ici.

Le composant vci_block_device est un contrôleur de disque simplifié. Ce composant FBF est à la fois un initiateur VCI, capable de lire et d'écrire dans la mémoire, et une cible qui peut recevoir des commandes de configuration. Le GIET ne gérant pas un véritable système de fichier, ce composant IOC ne gère qu'un unique fichier, stocké sur le disque de la station de travail qui exécute le simulateur. Le nom de ce fichier est un argument du constructeur. On trouvera la spécification fonctionnelle de ce composant ​ici.

Le composant vci_frame_buffer est un contrôleur d'écran graphique. C'est une cible VCI qui est vue comme un tampon mémoire directement adressable de M lignes de N pixels, dans lequel le logiciel peut lire ou écrire. Le contenu de ce buffer est parcouru périodiquement à la fréquence video, et son contenu est affiché sur l'écran graphique externe. On trouvera la spécification fonctionnelle de ce composant ​ici.

Le composant vci_dma est un composant matériel qui peut être programmé par le système d'exploitation pour éffectuer de gros transferts de données, tel que la copie d'une image d'un tampon mémoire situé dans l'espace utilisateur vers le tampon mémoire du composant FBF. On trouvera la spécification fonctionnelle de ce composant DMA ​ici.

Les deux composants IOC et DMA étant à la fois initiateur et cible, on obtient finalement une architecture possédant trois initiateurs VCI (indexés de 0 à 2), et 9 cibles VCI (indexées de 0 à 8), conformément au schéma ci-dessous.

Les lignes d'interruptions ne passent pas par le réseau VCI : chaque ligne d'interruption d'un périphérique est directement connectée aux ports p_irq_in[i] du composant ICU :

• La ligne d'interruption du TIMER est connectée au port p_irq_in[0]
• la ligne d'interruption du TTY est connectée au port p_irq_in[1]
• la ligne d'interruption du contrôleur de disque IOC est connectée au port p_irq_in[5]
• la ligne d'interruption du contrôleur DMA est connectée au port p_irq_in[6]

Le système d'exploitation (GIET) associe à chaque ligne d'interruption une routine de traitement spécifique, appelée ISR (Interrupt Service Routine), qui est exécutée par le processeur lorsque la ligne d'interruption est activée par le périphérique, et que les interruptions ne sont pas masquées. Il s'agit donc pour le périphérique de "voler" quelques cycles du processeur pour lui permettre d'exécuter un peu de code. L'ISR permet généralement au périphérique de signaler un événement en allant écrire dans un emplacement prédéfini en mémoire.

2.2 Communication entre le GIET et le contrôleur TTY

Dans le TP3, le programme utilisateur utilise l'appel système tty_getc() pour lire un caracère saisi au clavier. Cet appel système bloquant contient une boucle de scrutation dans laquelle, à chaque tour de boucle, on effectue une transaction sur le bus pour lire la valeur du registre STATUS du terminal TTY concerné. On ne sort de cette boucle que lorsqu'un caractère a effectivement été saisi. au clavier.

Dans ce TP4, le programme utilisateur utilise l'appel système tty_get_irq() pour lire un caractère. Cet appel système utilise un tampon mémoire partagé _tty_get_buf, protégé par une variable de synchronisation -tty_get_full. Ces deux variables appartiennent au système d'exploitation et sont stockées dans le segment seg_kunc, qui est à la fois protégé (non accessible par les programmes utilisateur) et non cachable. Plutôt que d'effectuer une scrutation sur le registre STATUS du contrôleur TTY, l'appel système tty_get_irq() teste la variable _tty_get_full, ce qui permet (en principe) au système d'exploitation d'attribuer le processeur à un autre programme utilisateur si te tampon est vide. C'est la routine d'interruption (ISR) associée au terminal TTY qui se charge d'écrire le code ASCII du caractère dans le tampon _tty_get_buf, et de forcer à 1 la variable de synchronsation _tty_get_full pour signaler que le tampon est plein. Cette variable de synchronisation est remise à 0 par l'appel système tty_getc_irq() lorsque le caractère est transféré du tampon système tty_get_buf vers le tampon mémoire défini par l'utilisateur.

Dans une architecture monoprocesseur, le processeur peut exécuter plusieurs tâches (plusieurs programmes utilisateurs) en pseudo-paralléliseme, par multiplexage temporel. Chaque tâche possède alors son propre terminal écran/clavier, qui sont tous contrôlés par le même contrôleur TTY. Dans une architecture multi-processeurs, chaque processeur peut exécuter plusieurs tâches, et on a un contrôleur TTY séparé pour chaque processeur . Le GIET supporte au plus 8 processeurs, et au plus 4 tâches par processeur. Le GIET supporte donc au plus

32 terminaux ecran/clavier, et définit donc deux tableaux _tty_get_buf[32] et _tty_get_full[32], indexés

par le numéro du terminal concerné.

Question : Comment les deux entités communicantes (l'ISR et l'appel système) calculent-elles l'index du terminal concerné ? La réponse se trouve dans les fichier drivers.c et isr.s.

Question: Que fait la routine d'interruption ISR déclenchée par le périphérique TTY lorsqu'un caractère est frappé alors que la variable _tty_get_full[i] vaut 1 ? La réponse se trouve dans le fichier isr.s.

Question: Quel est l'avantage de ce type de communication par interruption, comparé au mécanisme de scrutation utilisé dans le TP3 ?

2.2 Communication entre le GIET et le contrôleur IOC

3 Modélisation de l'architecture matérielle

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

$ tar xzvf soclib_tp4.tgz

Outre les fichiers qui permettent de générer le simulateur de l'architecture matérielle, cette archive contient également le sous-répertoire soft qui est utilisé pour la génération du logiciel embarqué.

Question : Complêtez le fichier tp4_top.cpp pour définir les adresses de base et les tailles des cinq segments associés aux composants ICU, TIMER, IOC, FBF et DMA.

Question : Complétez le fichier tp4_top.cpp pour définir les paramètres des constructeurs des cinq nouveaux composants ICU, TIMER, IOC, FBF et DMA. Utilisez le Makefile pour pour générer le simulateur.

Question : Complétez la net-list pour connecter les 4 lignes d'interruption utilisées dans cette architecture mono-processeur.

4. Logiciel embarqué

4.1 Code de boot

Le code de boot défini dans le fichier reset.s doit maintenant initialiser le vecteur d'interruption (c'est à dire le tableau indexé par le numéro d'interruption, et contenant les adresses des différentes routines d'interruption).

Question : En ouvrant le fichier isr.s, déterminez les nom des quatre ISRs associées aux composants Timer, TTY, IOC et DMA. Modifiez le fichier reset.s pour initialiser les entrées correspondantes du vecteur d'interruption.

4.2 Programme utilisateur utilisant le TTY

Question : Ecrire ou modifier un programme main() réalisant un interprêteur de commandes utilisant les appels système tty_getc_irq(), tty_getw_irq(), tty_printf.

4.3 Activation du TIMER

On veut maintenant activer la génération d'interruptions périodiques par le TIMER. Consultez le fichier stdio.c pour déterminer quels sont les deux appels système qui permettent de définir la période du TIMER et d'autoriser les interruptions périodiques.

Question : Modifiez le programme main()pour que le TIMER génère une interruption périodique tous les 100 000 cyles. Exécutez ce nouveau programme et vérifiez le comportement de la machine.

Question : Pour le fun, un interprêteur de commande permettant d'activer ou de désactiver le TIMER

4.4 Contrôleur de disque

Le contrôleur de disque disponible dans SoCLib...

5. Architecture multi-processeurs générique

On va dans cette section modéliser une architecture matérielle comportant un nombre variable de processeurs de sorte que le nombre de processeurs soit un paramètre ; défini sur la ligne de commande au lancement du simulateur. On souhaite exécuter sur cette architecture matérielle une application logicielle multi-tâches coopérative.

5.1 architecture matérielle

5.2 Code de boot

5.4 Programme coopératif multi-tâches

6 Compte-rendu

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