TP2: Protocole de communication VCI/OCP

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 re-écrire les modèles de simulation des 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 trois composants matériels : 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. A la différence du protocole FIFO, le protocole VCI introduit une dissymétrie entre les initiateurs et les cibles : Le composant VciGcdMaster se comporte comme un initiateur, et contrôle non seulement le chargement des données vers le le composant VciGcdCoprocesseur cible, mais contrôle également la récupération du résultat. 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.

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 transaction (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 d'architecture, les différents composants matériels utilisent des transactions pour communiquer entre eux.

Terminologie :

• un flit est l'information qui peut être transférée en un seul cycle sur un interface VCI.
• un paquet est une séquence de flits qui sont transmis de façon atomique à travers le réseau d'interconnexion.
• 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 flits (à des adresses constantes ou consécutives). Le paquet réponse contient un seul flit pour acquitter la transaction.
• transaction CMD_READ : le paquet commande contient un seul flit (à l'adresse du premier octet) et le nombre d'octets à lire est défini par le champs PLEN. Le paquet réponse contient un ou plusieurs flits suivant la longueur de la rafale.

Question 1 : à 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 2 : 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 ?

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.

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 objet 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 en 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 longueur (en nombre d'octets). La longueur d'un segment peut être très variable : de quelques dizaines 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 logiciel toutes les informations concernant la segmentation de l'espace addressable, et la correspondance entre une cible VCI (identifiées par son index), et un segment. (voir fichiers mapping_table.h et segment.h).

Un segment est donc un objet 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 : ​http://www.soclib.fr/trac/dev/wiki/Component/MappingTable.

4.3 Décodage de l'adresse

Le champs ADDRESS de la commande VCI est décodé à deux endroits :

• les bits de poids faibles sont décodés par les cibles VCI pour déterminer sur quel octet porte la commande.
• les bits de poids fort sont décodés par le sous-système d'interconnexion pour déterminer l'index de la cible et router le paquet commande vers 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 générique 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 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 registres 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 est 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 longueur de 4*4 = 16 octets.

Pour tous les périphériques adressables, on simplifie le décodage des adresses par le matériel, en imposant la contrainte que l'adresse de base du segment associé au périphérique soit un multiple de sa longueur (on dit que le segment est aligné). La carte des registres est définie 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.

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

Question 3 : 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 4 : 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?

Le coprocesseur GCD doit signaler une erreur dans les trois cas suivants :

• le coprocesseur reçoit une commande VCI de longueur supérieure à un flit,
• l'adresse reçue n'appartient pas au segment qui a été défini pour le coprocesseur,
• le mode d'accès (Read ou Write) ne respecte pas les contraintes définies dans la carte des registres.

Question 5 : comment sont traitées les erreurs dans ce modèle de simulation? à quoi servent ces vérifications ?

5.2 Composant VciGcdMaster

Le composant VciGcdMaster est un initiateur VCI, qui joue le rôle d'un processeur, mais qui n'est pas programmable: Il exécute un unique programme qui est une une boucle infinie dans laquelle on effectue successivement les 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 GCD_OPA du coprocesseur GCD.
3. écriture de l'opérande OPB dans le registre GCD_OPB du coprocesseur GCD.
4. écriture dans le pseudo-registre GCD_START du coprocesseur GCD.
5. scrutation du registre GCD_STATUS du coprocesseur GCD, jusqu'à obtenir une valeur nulle (calcul terminé)..
6. lecture du résultat dans le registre GCD_OPA du coprocesseur GCD.
7. affichage des résultats... et on recommence.

Pour accéder au coprocesseur GCD, le composant VciGcdMaster 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.

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 qu'un seul initiateur et une seule cible. Comme il n'y a qu'un initiateur, il ne peut pas y avoir de conflit d'accès au bus, et comme il n'y a qu'une seule cible, il n'y a pas besoin de décoder les bits de poids fort de l'adresse pour router la commande. On n'a donc pas besoin d'utiliser le composant 'vci_vgsb'.

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<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >;

(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 les mêmes résultats que ceux obtenus dans le TP1, puisque les calculs effectués sont les mêmes (seul le protocole de communication a changé).

5.5 Architecture multi-maitres / multi-cibles

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 combinatoirement 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 (durée d'une transaction) et bande passante (nombre d'octets transférés par cycle), ce composant se comporte comme le PIbus.

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 l'adresse utilisée par le maitre (i) lui permette de communiquer avec le coprocesseur (i). N'oubliez donc 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<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >;

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

Vous devez rédiger un compte-rendu pour ce TP résumant vos expériences, et on vous demandera une démonstration de votre simulateur au début du TP de la semaine suivante...