TP2: Protocole de communication VCI

1. Objectif

L'objectif de ce second TP est d'introduire la modélisation du protocole de communication VCI. Pour des raisons d'inter-opérabilité, tous les composants matériels de la plate-forme de prototypage SoCLib respectent le protocole de communication VCI, qui a été présenté en cours. On va donc modifier les deux composants matériels du TP1, pour qu'ils utilisent des ports de communication VCI plutôt que des ports FIFO. Ceci va permettre d'interconnecter plusieurs composants initiateurs et plusieurs composants cibles à travers un micro-réseau à commutation de paquets intégré sur puce.

2. Architecture matérielle

L'architecture matérielle pour de ce second TP instancie trois types de composants matériels. Les deux composants VciLcdCoprocessor et VciLcdMaster ont des fonctionnalités identiques à celles des composants utilisés dans le premier TP, mais ces composants possèdent maintenant des ports de communication qui respectent le protocole VCI/OCP. Le troisième composant VciGbs est un composant matériel modélisant un bus système respectant le protocole VCI/OCP, et permettant aux différents composants matériels de communiquer entre eux.

Le composant VciGsb se comporte comme un bus, car il ne traite qu'une seule transaction à la fois. Si plusieurs initiateurs ...

3. Protocole VCI/OCP

Le protocol de communication VCI permet de construire des architectures matérielle multi-processeurs à memoire partagée. Dans ce type de d'architecture, les différents composants matérielles utilisent des transactions pour communiquer entre eux. Une transaction est un couple (commande / réponse). Une transaction est initiée par composant initiateur est chargé de démarrer la transaction, et un composant cible est chargé de répondre à la commande qu'il a reçue.

• paquet commande un paquet commande contient principalement une adresse

En principe, n'importe quel initiateur est capable de communiquer avec n'importe quelle cible. La cible est désignée par les bits de poids fort de l'adresse.

L'adreentre un intitiateur et utilsentUn système de ce type possède trois types de composants :

• des composants initiateurs", capable de

d'adressage partagé implante un protocole de communication très simple supportant le contrôle de flux.

2.1 Canal de communication VCI

La figure ci-dessous détaille les signaux utilisés par le protocole VCI.

La plupart des champs VCI on des largeurs paramètrables (en nombre de bits) :

• le paramètre X définit le nombre de bits du champs ADDRESS. Les adresses VCI sont des adresses octets, mais elles doivent être alignées sur des frontières de mot.
• le paramètre B définit le nombre d'octets d'un mot de donnée VCI. Ce paramètre définit le largeur des trois

champs WDATA, RDATA et BE.

• le paramètre K définit le nombres de bits termettant de coder la longueur PLEN d'un paquet (en nombre d'octets). La valeur PLEN doit également être un multiple du paramètre B.
• le paramètre S définit le nombre de bits du champs SRCID, qui permet de coder le numéro de l'initiateur VCI qui a démarré la transaction. Ce paramètre définit donc le nombre maximum d'initiateurs dans le système.
• Le paramètre E définit le nombre de bits permettant de coder le type d'erreur dans le champs RERROR

du paquet commande. La valeur 0 signifie "pas d'erreur".

• Les deux paramètres T et P définissent le nombre de bits des deux champs TRDID et PKTID. Ces deux champs permettent d'étiqueter une commande VCI par une numéro de thread et/ou par un numéro de transaction. Ils peuvent ëtre utilisés par un initiateur pour envoyer une commande n+1 sans attendre d'avoir reçu la réponse à la commande n.

Bien sûr les valeurs de ces paramètres VCI doivent être les mêmes pour tous les composants matériels d'une même architecture.

Cette généricité des interfaces de communication VCI est évidemment une souplesse très utile, mais elle crée une difficulté pour la modélisation des composants matériels, puisqu'ilfaut écrire des modèles de simulation génériques, capable de s'adapter à différentes largeurs d'adresse ou de donnée. On utilise pour cela la techique des templates du langage C++ : on regroupe toutes les valeurs de ces paramêtres dans un oblet C++ de type VciParams?, qui est utilisé comme paramètre template par tous les composants matériels qui possèdent des ports de communication VCI.

On définit également trois autres objets, qui facilitent l'écriture des modèles de simulation CABA :

• l'objet VciSignals? regroupe tous les signaux (commande et réponse) d'un canal VCI.
• l'objet VciInitiator? regroupe tous les ports utilisés par un initiateur VCI pour émettre une commande,

et recevoir la réponse.

• l'objet VciTarget? regroupe tous les ports utilisés par une cible VCI pour émettre une réponsee,

et recevoir une commande. Ces trois objets utilisent évidemment un paramètre template de type VciParams?.

4. Segmentation de l'espace adressable

5. Travail à réaliser

L'archive attachement:soclib_tp1.tgz contient différents fichiers dont vous aurez besoin pour ce premier TP. Créez un répertoire de travail spécifique TP1 pour ce TP, recopier l'archive dans ce répertoire TP1, et décompressez-la:

$ tar xzvf soclib_tp2.tgz

Cette archive contient les fichiers suivants :

* * * * *

4.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 = 16octets.

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

Question : à 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é. Le fichier vci_lcd_coprocessor.cpp contient une description incomplête des méthodes associées à ce composant. Complêtez le code des méthodes transition() et genMoore(), pour traiter les états de l'automate qui ne le sont pas.

4.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 "cablée", et 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é. Le fichier vci_lcd_coprocessor.cpp contient une description incompête des méthodes associées à ce composant. Complêtez le code des méthodes transition() et genMoore(), pour traiter les états de l'automate qui ne le sont pas.

5.3 Architecture minimale

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

co top-ce 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 valeurs des paramètres VCI.
• les caractéristiques du segment mémoire associé au coprocesseur LCD.
• les valeurs des arguments des constructeurs des deux composants.

5.4 Compilation et génération du simulateur

Il faut ensuite compiler pour générer les fichiers

5.5 Architecture multi-maitres

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