Voir la source de FPGA CPLD : Guides : AXI4-Stream

== Liens utiles ==
{| class="wikitable centre" width="100%"
|-
| '''Documentations :'''
* <div id="AMBA"> [http://www.arm.com/products/system-ip/amba-specifications.php Specification AMBA4 AXI4-Stream Protocol.pdf] : Document de référence pour la protocole AXI4-Stream </div>
*[[Media:Xilinx AXI Reference Guide.pdf|Xilinx AXI Reference Guide.pdf]] : Guide d'utilisation de l'AXI4 avec les IP Xilinx
|}

== Description ==

L'AXI4-Stream n'est qu'une déclinaison du protocole AXI (Advanced eXtensible Interface), qui lui-même prend en compte la spécification AMBA (Advanced Microcontroller Bus Architecture) . Dans la plupart des cas, dans un design VHDL, le AXI4-Stream est suffisant.

Beaucoup de modules IP Xilinx, surtout lorsqu'ils sont compatibles avec le [http://www.xilinx.com/tools/microblaze.htm MicroBlaze] utilisent le protocole AXI4-Stream.

La plupart du temps, on utilise le même genre de protocole sans savoir qu'il est normalisé par l'AXI4-Stream. En l'utilisant, on s'assure néanmoins de pouvoir interchanger facilement et rapidement des modules respectant ce protocole.

== Fonctionnement ==

Le protocole AXI4-Stream est un protocole avec handshake qui utilise entre 2 et 9 signaux pour communiquer. Dans la communication, on définit un maître et un esclave. Le maître est l'émetteur de la donnée et l'esclave la reçoit. Les deux signaux qui sont obligatoires sont les signaux :
* '''TDATA''' : vecteur de la donnée
* '''TVALID''' : indique qu'une donnée est présente et valide pour l'esclave
Dans la plupart des cas, on va utiliser un signal supplémentaire :
* '''TREADY''' : flag présenté par l'esclave pour indiquer qu'il est prêt à recevoir la donnée.

Il est possible de se passer du signal '''TREADY''' et dans ce cas, on considère que la transmission se fait sans confirmation de la part de l'esclave.

Les autres signaux que l'on peut utiliser dans le transfert sont les suivants :
* '''TID''' : Permet d'identifier la trame en cours de transmission (dans le cas où des trames différentes seraient transmises de façon entrelacées)
* '''TDEST''' : Fonctionne comme un adresse de destination dans le cas de plusieurs esclaves ou de plusieurs destinations dans l'esclave.
* '''TLAST''' : Indique la fin d'une trame, utile lorsque les trames sont de tailles variables
* '''TKEEP''' : Permet d'indiquer si la donnée transmise doit être prise en compte dans la trame
* '''TSTRB''' : Indique si la donnée est une donnée utile ou un octet de positionnement. L'octet de positionnement peut permettre de ne mettre à jour qu'une partie des informations détenus par l'esclave, par exemple si on écrit de façon contigüe dans des registres, on peut sauter l'un d'eux. c'est ce qui fait la différence avec le signal '''TKEEP'''.
* '''TUSER''' : Vecteur de données parallèle à la donnée principale qui peut comporter d'autres informations à destination de l'esclave ou passer à travers avec une latence prédéterminée pour correspondre à la latence de la donnée principale.

Nous allons considérer le cas le plus simple, qui comprend les trois signaux de base. Pour plus de détails sur le fonctionnement complet du protocole, veuillez vous reporter à la spécification.

'''/!\ Pour ce qui va suivre, ouvrez la spécification [[#AMBA|AMBA]] à la page 19.'''

Dans le cas où on utilise le signal '''TREADY''', on considère trois cas de figures :
* '''TVALID''' est présent avant '''TREADY''' : '''TVALID''' est actif jusqu'à ce que '''TREADY''' le soit aussi. Sauf si une nouvelle donnée est présentée, il est désactivé aussitôt.
* '''TREADY''' est présent avant '''TVALID''' : La donnée est prise en compte dès son arrivée et '''TVALID''' est désactivé aussitôt. '''TREADY''' peut rester actif si l'esclave peut accueillir plusieurs données à la suite.
* '''TVALID''' et '''TREADY''' sont présents en même temps : Ils sont alors désactivés en même temps au front d'horloge suivant sauf si comme les cas précédents une nouvelle donnée est présente ou que l'esclave est toujours prêt à recevoir une donnée.

== Exemples ==

On choisit de représenter l'architecture suivante pour représenter différents cas de figure.

[[Image:VHDL - AXI4 Exemple.jpg|frameless|center|600px|VHDL - AXI4 Exemple]]

Le module 1 est le maître par rapport à la FIFO et la FIFO est le maître par rapport au module 2. Il n'est pas nécessaire de connaître le fonctionnement des modules 1 et 2. Pour l'exemple, on considère que ces modules ont des comportements anarchiques et que des données peuvent sortir à n'importe quel moment du module 1 et que le module 2 peut les accepter à intervalle irrégulier. 

Ces comportement ne sont pas si exceptionnels que l'on pourrait le penser. Ils peuvent être typiquement ceux de modules de communication dans des interface de types conversion de I²C vers UART ou Ethernet vers SPI (pour prendre deux exemples au hasard). Pour vous en convaincre, vous pouvez regarder le schéma bloc (page 3) du [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232BL_BQ.pdf FT232B].

On nomme les signaux ainsi :
* Entre le module 1 et la FIFO : '''TDATA_1F''', '''TVALID_1F''', '''TREADY_1F'''
* Entre la FIFO et le module 2 : '''TDATA_F2''', '''TVALID_F2''', '''TREADY_F2'''

Dans le fonctionnement de la FIFO, le signal '''TREADY_1F''' est valide lorsque la FIFO n'est pas pleine. Dès que trois données sont stockées dans la FIFO, le signal '''TREADY_1F''' passe à l'état bas, ce qui doit empêcher le maître d'ajouter de nouvelles données. Le signal '''TVALID_F2''' est actif si au moins une donnée est stockée dans la FIFO. La donnée est effectivement transmise si '''TREADY_F2''' est actif.

La FIFO a la particularité de pouvoir anticiper si une place va se libérer en observant si le module 2 va lire la donnée au coup d'horloge suivant.

Pour mieux suivre les problèmes d'embouchure, on présentera dans les chronogrammes le compteur de donnée présentes dans la FIFO.

*'''Exemple n°1 :'''

Dans ce premier exemple, on ne considère que le module 1 et la FIFO. Le module 1 va remplir la FIFO et attend qu'il y ait de la place pour y stocker sa donnée courante.

[[Image:VHDL - AXI4 Exemple 1.jpg|frameless|center|350px|VHDL - AXI4 Exemple 1]]

Lors des fronts d'horloge 3, 4 et 5, les données D0, D1 et D2 sont stockées dans la FIFO. A partir de là, la FIFO indique qu'il n'y a plus de place en positionnement '''TREADY_1F''' à l'état bas. '''TREADY_1F''' repasse à '1' quelques instants plus tard ce qui permet au module 1 de stocker sa donnée suivante D3.

Notez que le compteur est toujours à 3 lorsque '''TREADY_1F''' repasse à l'état haut. La FIFO sait que le module 2 va lire la donnée D0 au front n°8 ce qui va libérer une place. Le compteur reste donc à 3 (une donnée sortante et une donnée entrante en même temps).

De ce chronogramme, on pourrait supposer que le module 1 est plus rapide que le module 2 et que l'on risque de perdre des données si la FIFO n'est pas assez grande pour stocker toute les données envoyées par le module 1.

*'''Exemple n°2 :'''

Dans cet exemple très simple, on suppose que le module 2 est plus rapide que le module 1 et donc que la donnée stockée est immédiatement lue.

[[Image:VHDL - AXI4 Exemple 2.jpg|frameless|center|350px|VHDL - AXI4 Exemple 2]]

Dans un cas dans celui-là, la FIFO ne serait pas nécessaire car elle n'est jamais remplie qu'avec une donnée. Les modules 1 et 2 pourrait être reliè directement en AXI4.

*'''Exemple n°3 :'''

Pour cet exemple, vous allez devoir compléter le chronogramme suivant en fonction des signaux présentés. '''Très important :''' on considère que le module 1 ne se soucie pas de l'état de '''TREADY_1F''', il envoie les données sans vérification.

[[Image:VHDL - AXI4 Exemple 3 Masqué.jpg|frameless|center|600px|VHDL - AXI4 Exemple 3 Masqué]]

Vérifiez votre réponse ci-dessous et lisez les explications.

<div class="toccolours mw-collapsible mw-collapsed">
'''Solution'''
<div class="mw-collapsible-content">
[[Image:VHDL - AXI4 Exemple 3.jpg|frameless|center|600px|VHDL - AXI4 Exemple 3]]

* Lors des fronts d'horloge 2 et 3, des données sont stockées, ce qui positionne '''TVALID_F2''' à '1' et incrémente le compteur. 
* Au front 6, une donnée est lue et une donnée est stockée, le compteur reste à 2.
* Au front 7, une donnée est stockée, ce qui porte le compteur à 3.
* Aux front 8 et 9, des données sont lues, le compteur redescend à 1.
* Aux front 10 et 12, deux données sont à nouveau stockées, ce qui porte le compteur à 3.
* Aux front 14 et 15, les données ne peuvent pas être stockées car la FIFO est pleine et elles seront complétement perdues.
* Aux front 16 et 17, les données sont en même temps lues et stockées, le compteur reste à 3.
* Au front 19, une donnée est stockée et une donnée est lue, là aussi le compteur reste à 3. Comme les données D6 et D7 n'ont pas pu être stockées, c'est la donnée D8 qui vient après la donnée D5 en sortie sur '''TDATA_F2'''.

</div></div>