{{{
#!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é dans le cadre du cours MPSoC. 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 bus système.
= 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 ''!VciGcdCoprocessor'' et ''!VciGcdMaster'' 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 ''!VciGcdMaster'' se comporte comme un initiateur, et le composant ''!VciGcdCoprocesseur'' se comporte come une cible. Le troisième composant ''!VciVgsb'' (Virtual Generic System Bus) est un composant matériel modélisant un bus multi-maîtres, multi-cibles respectant le protocole VCI/OCP.
[[Image(soclib_tp2_archi.png)]]
Le composant ''!VciVgsb'' se comporte comme un bus, car il ne traite qu'une seule transaction à la fois.
Si plusieurs initiateurs cherchent à envoyer un paquet commande, le contrô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ériels utilisent des transactions pour communiquer entre eux. Une transaction est un couple (paquet commande / paquet 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 Interconnection 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 VCI de la rafale) et le nombre d'octets à 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 ?
Dans une architecture à espace d'adressage partagé, 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 dans le sens (initiateur => cible) pour
la commande et un sous-canal dans le sens (cible=>initiateur) 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).
== 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 '''N''' 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). Nous n'utiliserons que des valeurs de PLEN multiples 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. `RERROR = 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, puisqu'elle permet d'adapter le protocole
aux besoins particuliers de chaque application embarquée (on n'a pas toujours besoin de 4 Goctets d'espace adressable).
Mais elle crée une difficulté pour la modélisation des composants matériels, puisqu'il faut écrire des modèles de
simulation génériques, capable de s'adapter à différentes largeurs des champs adresse ou 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.
(voir fichier ''vci_param.h'').
Comme on l'a fait pour le canal de communication FIFO, on définit trois 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. (voir fichier ''vci_signals.h'')
* l'objet `VciInitiator` regroupe tous les ports utilisés par un initiateur VCI pour émettre une commande, et recevoir la réponse. (voir fichier ''vci_initiator.h'')
* l'objet `VciTarget` regroupe tous les ports utilisés par une cible VCI pour émettre une réponse, et recevoir une commande. (voir fichier ''vci_target.h'')
Ces trois objets possèdent évidemment un paramètre template de type `VciParams`.
= 4 Outillage logiciel =
Dans cette section, on présente différentes classes C++ définies par la plate-forme de prototypage virtuel SoCLib pour
faciliter et simplifier l'écriture des modèles de simulation.
== 4.1 Indexation des composants VCI ==
On assigne à tout composant matériel possédant un port VCI (composant ''cible'' ou composant ''initiateur'') un index permettant de l'identifier de façon unique. Cet index peut être éventuellement structuré (on parle d'index composite) si l'architecture est structurée ''clusters''. Un index composite est la concaténation d'un index global (le numéro de cluster) et d'un index local (à l'intérieur d'un cluster).
La plate-forme SoCLib définit la classe C++ ''!IntTab'' pour représenter ces index composites. (voir fichier ''int_tab.h'').
Dans ce TP, on utilisera un seul niveau d'indexation, mais il faut utiliser l'objet ''!IntTab'' pour indexer les composants VCI.
== 4.2 Segmentation de l'espace addressable ==
Dans une architecture à mémoire partagée, on assigne à tout composant ''cible'' un (ou plusieurs) segment(s) dans l'espace adressable.
Un segment est une ''tranche'' de l'espace adressable. Il possède donc une adresse de base, et une taille (en nombre d'octets). La taille d'un
segment peut être très variable : de quelques d'octets pour un périphériques adressable, à quelques Moctets pour un contrôleur mémoire.
C'est en analysant les bits de poids fort de l'adresse que le sous-système d'interconnexion détermine à quel segment appartient l'adresse,
et donc vers quelle cible un paquet commande doit être aiguillé. Le découpage de l'espace adressable en segments et l'assignation de ces
segments aux différentes cibles est donc un caractéristique globale de l'architecture, et doit donc être définie dans la ''top-cell'' décrivant l'architecture générale du système.
La plate-forme SoCLib définit la classe C++ ''!MappingTable'' permettant de centraliser dans un même objet toutes
les informations concernant la segmentation de l'espace addressable, et la correspondance entre les cible VCI (identifiées par leur index),
et les segments. (voir fichiers ''mapping_table.h'' et ''segment.h'').
Un segment est caractérisé par 5 informations :
* un nom
* une adresse de base
* une taille (en octets)
* l'index de la cible VCI à laquelle il est assigné
* un attribut de cachabilité
Pour plus de détails, vous pouvez consulter le site WEB du projet SoCLib : [https://www.soclib.fr/trac/dev/wiki/Component/MappingTable].
== 4.3 Décodage des champs ADDRESS et SRCID ==
Dans une architecture à mémoire partagée, l'adresse VCI est décodée à différents endroits :
les bits de poids faibles sont décodés par les périphériques adressables pour déterminer l'action à réaliser, et les bits de poids fort sont décodés par le sous-système d'interconnexion pour déterminer l'index de la cible concernée. Pour faciliter ce décodage, la plate-forme SoCLib définit les classe C++ ''!AddressDecodingTable'' (voir fichier ''address_decoding_table.h'') et
''!AddressMaskingTable'' (voir fichier ''address_masking_table.h'')
== 4.4 Allocation de tableaux ==
On a parfois besoin d'utiliser des tableaux d'objets complexes. Par exemple, le composant ''!VciVgsb'' possède un nombre variable
de ports VCI initiateur, et un nombre variable de ports VCI cibles. Ces ports sont donc définis comme des tableaux de ports. Pour
pouvoir nommer chacun des éléments d'un tableau, la plate-forme SoCLib définit un mécanisme générique d'allocation et de désallocation
de tableaux (voir fichier ''alloc_elems.h'').
= 5 Travail à réaliser =
L'archive [attachment:soclib_tp2.tgz soclib_tp2.tgz] contient différents fichiers dont vous aurez besoin pour ce TP.
Créez un répertoire de travail spécifique TP2, recopiez l'archive dans ce répertoire TP2, 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
* `exception.h` : traitement et report d'erreurs
L'archive contient également les fichiers suivants :
* `gcd.h` : ce fichier décrit les fichiers adressables du coprocesseur GCD (fichier complet)
* `vci_gcd_master.h` : définition du composant `VciGcdMaster` (fichier complet)
* `vci_gcd_master.cpp` : méthodes associées (fichier incomplet)
* `vci_gcd_coprocessor.h` : définition du composant `VciGcdCoprocessor`. (fichier complet)
* `vci_gcd_coprocessor.cpp` : méthodes associées (fichier incomplet)
* `vci_vgsb.h` : définition du composant `VciVgsb`. (fichier complet)
* `vci_vgsb.cpp` : méthodes associées (fichier complet)
* `tp2_simple_top.cpp` : top-cell d'une architecture simple à deux composants (fichier incomplet)
== 5.1 Composant ''!VciGcdCoprocessor'' ==
Le composant ''!VciGcdCoprocessor'' 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*` = 16 octets.
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''' ||
|| GCD_OPA || 0x0 || Read/Write ||
|| GCD_OPB || 0x4 || Write Only ||
|| GCD_START || 0x8 || Write Only ||
|| GCD_STATUS || 0xc || Read Only ||
Comme pour tout composant contenant des registres addressables, on définit dans un fichier
séparé ''gcd.h'' les mnémoniques correspondant aux numéros des registres, car cette information
est utilisée non seulement par le composant ''!VciGcdCoprocesseur'' (pour décoder les adresses),
mais également par le composant ''!VciGcdMaster'' (pour générer les adresses).
* Une commande d'écriture vers le registres GCD_OPA (resp. GCD_OPB) permet d'écrire l'opérande A (resp. opérande B).
* Une commande de lecture du registre GCD_OPA retourne la valeur du résultat si le coprocesseur a fini son calcul. Elle retourne une valeur non significative si le coprocesseur n'a pas fini son calcul.
* Une commande de lecture du registre GCD_STATUS retourne la valeur 0 lorsque le coprocesseur est dans l'état ''IDLE''. Elle retourne une valeur différente de 0 si le coprocesseur n'a pas fini son calcul.
* Une commande d'écriture vers le pseudo-registre GCD_START déclenche le calcul du PGCD portant sur les valeurs présentes dans les registres GCD_OPA et GCD_OPB. La donnée correspondant à cette écriture (champs VCI WDATA) n'est écrite nulle part.
Comme vous pouvez le constater dans la figure ci-dessous, le coprocesseur GCD contient deux automates
fonctionnant en parallèle :
* l'automate ''vci_fsm'' contrôle l'interface VCI : il répond aux commandes qu'il reçoit, en écrivant dans le registre concerné s'il sagit d'une écriture, ou en renvoyant la valeur demandée s'il s'agit d'une lecture.
* l'automate ''exe_fsm'' contrôle l'exécution de la boucle de calcul du PGCD.
[[Image(soclib_tp2_coprocessor.png)]]
'''Question''' : Pourquoi faut-t-il deux automates séparés pour contrôler l'interface VCI et pour contrôler le calcul
du PGCD proprement dit ?
'''Question''' Dans la fonction de transition, on a écrit le code définissant les transitions de l'automate ''vci_fsm'' après
le code définissant les transitions de l'automate ''exe_fsm'', bien que les transitions de l'automate ''exe_fsm'' dépendent
de l'état de l'automate ''vci_fsm''. On aurait aussi bien pu décrire ces deux automates dans l'ordre inverse.
Quelle mécanisme du langage SystemC utilise-t-on pour rendre l'ordre de description des automates indifférent?
Une erreur est signalée si le coprocesseur GCD 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 définies dans la carte des registres.
'''Question''' : comment sont traitées les erreurs dans ce modèle de simulation? à quoi servent ces vérifications ?
Le fichier `vci_gcd_coprocessor.h` contient une définition complête du composant `VciGcdCoprocessor`.
Il n'a pas besoin d'être modifié, mais vous aurez besoin de le lire attentivement pour modifier
le fichier `vci_gcd_coprocessor.cpp`, qui contient une description incomplête des méthodes associées à ce composant. Complétez le code des méthodes `transition()` et `genMoore()`.
== 5.2 Composant ''!VciGcdMaster'' ==
Le composant `VciGcdMaster` est un initiateur VCI, qui exécute une boucle infinie dans laquelle il exécute
successivement les 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 GCD_OPA du coprocesseur GCD.
1. écriture de l'opérande OPB dans le registre GCD_OPB du coprocesseur GCD.
1. écriture dans le pseudo-registre GCD_START du coprocesseur GCD.
1. lecture du registre GCD_STATUS du coprocesseur GCD, jusqu'à obtenir une valeur nulle (calcul terminé)..
1. lecture du résultat dans le registre GCD_OPA du coprocesseur GCD.
1. affichage des résultats.
Pour accéder au coprocesseur GCD, le composant a besoin de l'adresse de base du
segment de l'espace adressable qui a été assigné au coprocesseur GCD.
Le composant ''!VciGcdMaster'' étant un automate cablé (non programmable), on considère
que cette adresse est également "câblée". 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 ''!VciGcdMaster''.
[[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_gcd_coprocessor.h` contient une description complète du composant `VciGcdMaster`.
Il n'a pas besoin d'être modifié, mais vous devez le lire attentivement pour modifier
le fichier `vci_gcd_coprocessor.cpp`, qui contient une description incomplète des méthodes associées à ce composant.
Complétez le code des méthodes `transition()` et `genMoore()`.
== 5.3 Architecture minimale ==
Pour valider les modèles de simulation des composants `VciGcdMaster` et `VciGcdCoprocessor`,
on construit 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 caractéristiques du segment mémoire associé au coprocesseur GCD.
* les valeurs des paramètres VCI (largeurs des champs) dans l'objet `vci_param`.
* les valeurs des arguments des constructeurs des deux composants.
On prendra pour valeurs des paramètres VCI les valeurs définies en commentaire dans le fichier ''tp2_simple_top.cpp''.
== 5.4 Compilation et génération du simulateur ==
Il faut maintenant 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 `VciGcdMaster`, `VciGcdCoprocessor`.
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_gcd_master.cpp` et `vci_gcd_coprocessor.cpp` :
{{{
template class VciGcdMaster >;
}}}
(pensez à changer le nom de la classe pour `vci_gcd_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é.
En cas de difficulté, vous pouvez obtenir une trace détaillée (cycle par cycle) des valeurs contenues dans les registres.
Il faut relancer la compilation en ajoutant le flag ''-DSOCLIB_MODULE_DEBUG'' dans les options de compilation.
== 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.
[[Image(soclib_tp2_bus.png)]]
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 >;
}}}
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...