{{{
#!html
TP2: Protocole de communication VCI/OCP
}}}
[[PageOutline]]
= 1. Objectif =
L'objectif de ce second TP est d'introduire la modélisation SystemC d'architectures utilisant le protocole de communication VCI/OCP.
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/OCP 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 cible =
L'architecture matérielle qu'on souhaite prototyper dans ce second TP instancie 7 composants matériels de
trois types différents :
Les deux composants ''!VciLcdCoprocessor'' et ''!VciLcdMaster'' sont instanciés trois fois chacun. Ils 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 composant ''!VciLcdMaster'' se comporte comme un initiateur, et le composant ''!VciLcdCoprocesseur'' se comporte come une cible. Le troisième composant ''!VciGbs'' est un composant matériel modélisant un bus système respectant le protocole VCI/OCP,
et permet aux composants initiateurs et cibles de communiquer entre eux.
[[Image(soclib_tp2_archi.png)]]
Le composant ''!VciGsb'' se comporte comme un bus, car il ne traite qu'une seule transaction à la fois.
Si plusieurs initiateurs cherchent à envoyer un paquet commande, lecontrôleur du bus sélectionne un initiateur
(en respectant une priorité tournante de type ''round-robin''), il aiguille la commande vers la bonne cible en
décodant les bits de poids fort de l'adresse, attend la réponse de la cible, et aiguille celle-ci vers le bon initiateur.
La transaction (n+1( n'est traitée que lorsque la ransaction (n) est entièrement terminée.
= 3. Protocole VCI/OCP =
Le protocol de communication VCI permet de construire des architectures matérielles 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 un composant ''initiateur'', qui envoie un paquet ''commande'', et est terminée par
un composant cible, qui répond à la commande en renvoyant un paquet ''réponse''.
== 3.1 Sous-Système d'interconnexion VCI ==
Dans la spécification VCI "advanced", il y a principalement deux types de commandes :
* transaction CMD_WRITE : le paquet commande contient un ou plusieurs mots VCI (à des adresses constantes ou consécutives) Le paquet réponse contient un seul mot VCI pour acquitter la transaction.
* transaction CMD_READ : le paquet commande contient un seul mot VCI (à l'adresse du premier mot VCIde la rafale) et le nombre de mots à lire est défini par le champs PLEN. Le paquet réponse contient un ou plusieurs mots VCI suivant la
longueur de la rafale.
Question : à quoi sert le paquet réponse dans le cas d'une transaction d'écriture ?
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. Le champs VCI ADDRESS doit donc être décodé
par le (ou les) composant(s) matériel(s) qui réalise(nt) le sous-sytème d'interconnexion, pour aiguiller
le paquet commande vers sa destination. De façon symètrique, le sous-système d'interconnexion doit
décoder le champs VCI RSRCID pour aiguiller le paquet réponse vers l'initiateur concerné.
Question : Pourquoi les différents types de sous-sytèmes d'interconnexion (bus, cross-bar, micro-réseaux, etc.)
sont-ils conçus de telle sorte qu'ils utilisent des ressources matérielles séparées pour aiguiller les commandes et les réponses ?
[[Image(soclib_tp2_vci_protocol.png)]]
Un canal de communication VCI utilise donc deux sous-canaux : un sous-canal ''direct'' pour
la commande et un sous-canal ''retour'' pour la réponse. Il est intéressant de noter que chacun de ces deux sous-canaux respecte le protocole FIFO. Les signaux CMDVAL et CMDACK (resp. RSPVAL et RSPACK) correspondent aux signaux WOK et ROK du protocole FIFO pour le sous-canal commande (resp. réponse). C'est un exemple typique d'encapsulation de protocoles.
== 3.2 Les signaux VCI ==
La figure ci-dessous détaille les signaux utilisés par le protocole VCI.
[[Image(soclib_tp2_vci_signals.png)]]
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, et doivent être définis dans la ''top-cell'' décrivant l'architecture générale du système.
== 3.3 Modélisation des interfaces VCI ==
La 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 =
La plate-forme de
= 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 :
*
*
*
*
*
== 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 = 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 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''.
[[Image(soclib_tp2_coprocessor.png)]]
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.
== 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)
1. écriture de l'opérande OPA dans le registre ''r_opa'' du coprocesseur LCD.
1. écriture de l'opérande OPB dans le registre ''r_opb'' du coprocesseur LCD.
1. écriture dans le pseudo-registre ''r_start'' du coprocesseur LCD.
1. lecture du résultat dans le registre ''r_res'' du coprocesseur LCD.
1. 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''.
[[Image(soclib_tp2_master.png)]]
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 :
[[Image(soclib_tp2_simple_archi.png)]]
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...