Changes between Version 5 and Version 6 of SoclibCourseTp2


Ignore:
Timestamp:
Sep 6, 2009, 1:50:37 PM (16 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SoclibCourseTp2

    v5 v6  
    11{{{
    22#!html
    3 <h1>TP2: Protocole de communication VCI</h1>
     3<h1>TP2: Protocole de communication VCI/OCP</h1>
    44}}}
    55[[PageOutline]]
     
    77= 1. Objectif =
    88
    9 L'objectif de ce second TP est d'introduire la modélisation du protocole de communication VCI.
     9L'objectif de ce second TP est d'introduire la modélisation du protocole de communication VCI/OCP.
    1010Pour des raisons d'inter-opérabilité, tous les composants matériels de la plate-forme de prototypage SoCLib
    11 respectent le protocole de communication VCI, qui a été présenté en cours. On va donc modifier les deux
     11respectent le protocole de communication VCI présenté en cours. On va donc modifier les deux
    1212composants matériels du TP1, pour qu'ils utilisent des ports de communication VCI plutôt que des ports FIFO.
    1313Ceci va permettre d'interconnecter plusieurs composants ''initiateurs'' et plusieurs composants ''cibles''
     
    1818L'architecture matérielle qu'on souhaite prototyper dans ce second TP instancie 7 composants matériels de
    1919trois types différents :
    20 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 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.
     20Les 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,
     21et permet aux composants initiateurs et cibles de communiquer entre eux.
    2122
    2223[[Image(soclib_tp2_archi.png)]]
    2324
    2425Le composant ''!VciGsb'' se comporte comme un bus, car il ne traite qu'une seule transaction à la fois.
    25 Si plusieurs initiateurs ...
     26Si plusieurs initiateurs cherchent à envoyer un paquet commande, lecontrôleur du bus sélectionne un initiateur
     27(en respectant une priorité tournante de type ''round-robin''), il aiguille la commande vers la bonne cible en
     28décodant les bits de poids fort de l'adresse, attend la réponse de la cible, et aiguille celle-ci vers le bon initiateur.
     29La transaction (n+1( n'est traitée que lorsque la ransaction (n) est entièrement terminée. 
    2630
    2731= 3. Protocole VCI/OCP =
    2832
    29 Le protocol de communication VCI permet de construire des architectures matérielle multi-processeurs à memoire
     33Le protocol de communication VCI permet de construire des architectures matérielles multi-processeurs à memoire
    3034partagé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).
    31 Une transaction est initiée par composant ''initiateur'' est chargé de
    32 démarrer la transaction, et un composant cible est chargé de répondre à la commande qu'il a reçue.
    33  * paquet commande un paquet commande contient principalement une adresse
     35Une transaction est initiée par un composant ''initiateur'', qui envoie un paquet ''commande'', et est terminée par
     36un composant cible, qui répond à la commande en renvoyant un paquet ''réponse''.
     37
     38== 3.1 Sous-Système d'interconnexion VCI ==
     39
     40Dans la spécification VCI "advanced", il y a principalement deux types de commandes :
     41 * 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.
     42 * 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
     43longueur de la rafale.
     44
     45Question : à quoi sert le paquet réponse dans le cas d'une transaction d'écriture ?
     46
    3447En principe, n'importe quel initiateur est capable de communiquer avec n'importe quelle cible. 
    35 La cible est désignée par les bits de poids fort de l'adresse.
    36 
    37 L'adreentre un intitiateur et
    38 utilsentUn système de ce type possède trois types de composants :
    39  * des composants ''initiateurs", capable de
    40 d'adressage partagé implante un protocole de communication très simple supportant le contrôle de flux.
    41 
    42 [[Image(soclib_tp2_fig1_archi.png)]]
    43 
    44 == 2.1 Canal de communication VCI ==
     48La cible est désignée par les bits de poids fort de l'adresse. Le champs VCI ADDRESS doit donc être décodé
     49par le (ou les) composant(s) matériel(s) qui réalise(nt) le sous-sytème d'interconnexion, pour aiguiller
     50le paquet commande vers sa destination. De façon symètrique, le sous-système d'interconnexion doit
     51décoder le champs VCI RSRCID pour aiguiller le paquet réponse vers l'initiateur concerné.
     52
     53Question : Pourquoi les différents types de sous-sytèmes d'interconnexion (bus, cross-bar, micro-réseaux, etc.)
     54sont-ils conçus de telle sorte qu'ils utilisent des ressources matérielles séparées pour aiguiller les commandes et les réponses ?
     55
     56[[Image(soclib_tp2_fig1_vci_protocol.png)]]
     57
     58Un canal de communication VCI utilise donc deux sous-canaux : un sous-canal ''direct'' pour
     59la 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.
     60
     61== 3.2 Les signaux VCI ==
    4562
    4663La figure ci-dessous détaille les signaux utilisés par le protocole VCI.
    4764
    48 [[Image(soclib_tp2_fig2_fifo.png)]]
     65[[Image(soclib_tp2_fig2_vci_signals.png)]]
    4966
    5067La plupart des champs VCI on des largeurs paramètrables (en nombre de bits) :
     
    5875 * 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''.
    5976
    60 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.
    61 
    62 Cette généricité des interfaces de communication VCI est évidemment une souplesse très utile,
     77Bien 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.
     78
     79== 3.3 Modélisation des interfaces VCI ==
     80
     81La généricité des interfaces de communication VCI est évidemment une souplesse très utile,
    6382mais elle crée une difficulté pour la modélisation des composants matériels, puisqu'ilfaut écrire des modèles de
    6483simulation génériques, capable de s'adapter à différentes largeurs d'adresse ou de donnée.