TP4 : Architectures complexes : soclib-cc

1 Objectif

Le but de ce quatrième TP est double : D'une part on souhaite modéliser des architectures plus complexes utilisant deux niveaux d'interconnexion. D'autre part on va introduire l'outil soclib-cc.

2 Outil soclib-cc

L'architecture matérielle qui a été modélisée dans le TP3 était très simple (un seul processeur et 4 cibles), mais il a fallu compiler une cinquantaine de fichiers source (.cpp) et un nombre encore plus grans de fichiers d'en-tête (.h) pour générer le simulateur.

Tous ces fichiers proviennent du serveur WEB SoCLib, qui contient lui-même un serveur SVN permettant d'archiver les différents modèles de simulation. Ce serveur SVN fournit un service de gestion de versions et supporte le développement coopératif de la plate-forme.

Mais l'exploitation de cette bibliothèque de modèles de simulation pose (au moins) deux problèmes :

1. Il faut dentifier et localiser tous les fichiers nécessaires pour générer le simulateur d'une architecture particulière. L' archive qui vous a été fournie pour le TP3 rassemblait dans un seul répertoire la centaine de fichiers nécessaires, et le Makefile vous était fourni. Mais dans le cas général, l'identification des fichiers nécessaires à la compilation est un travail non négligeable, à cause des dépendances entre composants logiciels (le fichier A fait référence à des objets définis dans le fichier B, qui lui-même fait appel au fichier C, etc.). De ce fait, la construction du Makefile est généralement un exercice laborieux.

2. Par ailleurs, la plupart des modèles ont des paramètres templates (puisque la plupart des composants ont des interfaces VCI, et que les largeurs des champs VCI sont paramétrables). Pour chaque composant possédant un (ou plusieurs) paramètre(s) template, il faut donc modifier le fichier .cpp pour préciser la valeur des paramètres template avant de lancer la compilation de ce composant (on dit qu'on instancie les template). Vous avez fait ce travail dans le TP2, et c'est un travail très fastidieux dès que les architectures modélisées deviennent complexes.

La chaîne de compilation soclib-cc a pour but de résoudre ces deux problèmes dans le cas général, en automatisant la recherche des dépendances, l'instanciation des templates, et l'appel du compilateur. Pour permettre cette automatisation, tout composant logiciel de SoCLib doit être accompagné d'un fichier de metadata (fichier possédant le suffixe .sd) qui contient les informations suivantes:

• le nom de la classe C++
• les paramètres templates associés, avec leurs types et les valeurs par défaut (si applicable)
• les chemins d'accès aux fichiers d'en-tête (.h) et d'implémentation (.cpp)
• la liste des ports d'interface du composant
• la liste des dépendances vers d'autres composants
• les paramètres du constructeur, avec leurs types

Ce fichier est écrit en un langage ad-hoc (mais que Python peut parser nativement), et on trouvera ci-dessous, à titre d'exemple, le fichier vci_simple_ram.sd:

	
Module('caba:vci_simple_ram',
        classname = 'soclib::caba::VciSimpleRam',
	tmpl_parameters = [parameter.Module('vci_param',  default = 'caba:vci_param')],
        header_files = ['../source/include/vci_simple_ram.h',],
        implementation_files = ['../source/src/vci_simple_ram.cpp'],
        ports = [
	          Port('caba:vci_target', 'p_vci'),
                  Port('caba:bit_in', 'p_resetn', auto = 'resetn')      
                  Port('caba:clock_in', 'p_clk', auto = 'clock')],
        uses = [
                  Uses('caba:base_module'),
	          Uses('common:linked_access_buffer',
                             addr_t = parameter.StringExt('sc_dt::sc_uint<%d>', parameter.Reference('addr_size')),
                             id_t = parameter.StringExt('sc_dt::sc_uint<%d>', parameter.Reference('srcid_size'))),
                  Uses('common:loader'),
                  Uses('common:mapping_table',],
        instance_parameters = [
                  parameter.IntTab('ident'),
                  parameter.Module('mt', 'common:mapping_table', auto='env:mapping_table'),
                  parameter.Module('loader', 'common:loader', auto='env:loader'),
                  parameter.Int('latency')],
        extensions = [
                  'dsx:addressable=ident',
                  'dsx:get_ident=ident:p_vci',
                  'dsx:mapping_type=memory'],
)

Il faut par ailleurs définir les caractéristiques de la top-cell dans un fichier de directives pour soclib-cc. Ce fichier est habituellement nommé platform.desc, mais le nom n'est pas imposé. Ce fichier est également en langage parsable par Python, et contient le nom de fichier de la top-cell SystemC, la liste des composants instanciés et les valeurs des paramètres VCI. Vous trouverez ci-dessous, à titre d'exemple, le fichier tp3.desc décrivant l'architecture du TP3:

todo = Platform('caba', 'tp3_top.cpp',
            uses = [
                    Uses('caba:vci_xcache_wrapper', iss_t = 'common:mips32el'),
                    Uses('caba:vci_simple_ram'),
                    Uses('caba:vci_multi_tty'),
                    Uses('caba:vci_vgsb'),
                    Uses('caba:vci_gcd_coprocessor'),
                    Uses('common:mapping_table'),
                    Uses('common:elf_file_loader')],
            cell_size = 4,
            plen_size = 8,
            addr_size = 32,
            rerror_size = 1,
            clen_size = 1,
            rflag_size = 1,
            srcid_size = 12,
            pktid_size = 1,
            trdid_size = 1,
            wrplen_size = 1
)

3 Architectures Clusterisées

Nous appellerons architecture clusterisée une architecture dans laquelle on utilise un double système d'index pour repérer les initiateurs et les cibles VCI. Un cluster est un sous-système regroupant généralement plusieurs initiateurs et plusieurs cibles VCI, communiquant entre eux par un interconnect local (bus ou crossbar). Chaque composant est donc repèré par un couple (cluster_index, local_index).

L'espace d'adressage reste partagé par tous les composants du système (quel que soit leur cluster), et n'importe quel initiateur peut directement adresser n'importe quelle cible. Si l'initiateur et la cible n'appartiennent pas au même cluster, les paquets VCI (commande et réponse) sont acheminés grace à un interconnect global (généralement un micro-réseau intégré ou NoC).

Ce regroupement en clusters répond généralement à deux objectifs:

• D'un point de vue architecture, regrouper dans un même cluster les composants qui communiquent beaucoup entre eux permet de réduire la latence des communications, et de minimiser la consommation. Ce découpage permet également de distribuer la mémoire embarquée, et d'éviter le goulot d'étranglement que constituerait un unique banc mémoire sur la puce (même si l'accès à la mémoire externe reste un goulot d'étranglement).
• D'un point de vue électrique, le découpage en clusters permet de résoudre en partie les problèmes d'horlogerie, puisque chaque cluster peut être implanté dans un domaine d'horloge séparé (approche GALS : Globally Asynchronous / Locally Synchronous). Le franchissement des frontières d'horlogre est alors la responsabilité du micro-réseau assurant les communications inter-clusters.

Pour faciliter le décodage des adresses, on décompose les bits de poids fort de l'adresse VCI en deux champs GADR et LADR, de telle sorte que le décodage du champs GADR définisse complêtement le numéro du cluster cible. Le décodage du champs LADR permet lui de déterminer l'index local de la cible dans un cluster. Le nombre de bits des champs GADR et LADR dépend évidemment du système.

GADR

LADR

OFFSET

Cette organisation hiérarchique à deux niveaux impose évidemment que les valeurs des champs GADR des segments associés aux cibles d'un même cluster soient égales entre elles (ou appartiennent à un même ensemble de valeurs caractéristiques de ce cluster)

4 Travail à réaliser

L'archive soclib_tp4.tgz​ contient différents fichiers dont vous aurez besoin pour ce TP. Elle contient également un sous-répertoire soft qui est utilisé pour la génération du logiciel embarqué. Attention: ce répertoire soft de l'archive contient des fichiers différents de ceux qui étaient fournis pour le TP3.

Créez un répertoire de travail spécifique TP4, recopiez l'archive dans ce répertoire TP4, et décompressez-la:

$ tar xzvf soclib_tp4.tgz

4.1 Utilisation de soclib-cc

On va pour commencer regénérer le simulateur utilisé dans le TP3, en utilisant soclib-cc.

Comme vous pouvez le constater, le répertoire principal de l'archive ne contient plus que deux fichiers : le fichier tp3_top.cpp décrivant l'architecture, et le fichier tp3.desc, puisqu'on utilise directement les modèles de composants enregistrés dans l'arbre SVN SoCLib.

Il faut vérifier que le chemin d'accès à à soclib-cc est bien dans votre PATH en exécutant:

$ source /users/outil/soc/env_soclib.sh

Puis lancer la compilation avec la commande :

$ soclib-cc -p tp3.desc -o tp3.simulator.x

Vérifiez que le simulateur tp3_simulator.x qui vient d'être généré exécute toujours correctement l'application logicielle du TP3. Vous pouvez pour cela donner explicitement le cheminom (pathname) du fichier contenant le code binaire comme second argument sur la ligne de commande :

$ ./tp3_simulator.x 1000000  ../TP3/soft/bin.soft

4.2 Contrôleur d'interruption et timer

La plate-forme matérielle du TP3 utilisait une technique de scrutation (polling) pour lire des caractères en provenance du terminal TTY. Cette technique d'attente active n'est pas très efficace dans les applications logicielles où un seul processeur doit exécuter plusieurs tâches en pseudo parallélisme, grâce à des techniques de multiplexage temporel.

On souhaite donc remplacer ce mécanisme de scrutation par un mécanisme d'interruption, en utilisant la capacité du contrôleur TTY à générer une interruption lorsque qu'un caractère est frappé sur le clavier. Ceci nécessite d'introduire un nouveau composant matériel dans l'architecture : Le composant vci_icu est contrôleur d'interruption vectorisé. C'est une cible VCI dont vous trouverez la spécification fonctionnelle à l'URL ci-dessous : ​https://www.soclib.fr/trac/dev/wiki/Component/VciIcu.

On en profite pour introduire un autre périphérique : 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. Vous trouverez la spécification fonctionnelle de ce composant à l'URL ci-dessous : ​https://www.soclib.fr/trac/dev/wiki/Component/VciMultiTimer.

Modifiez le fichier tp3_top.cpp pour instancier et connecter ces deux nouveaux composants, et renommez tp4_top.cpp le fichier ainsi modifié. Modifiez également le fichier tp3_desc et renommez le tp4_desc

4.3 Routines de traitement des interruptions

4.4 Architecture multi-processeurs

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