FPGA CPLD : Guides : AXI4-Stream

De Wiki_du_Réseau_des_Electroniciens_du_CNRS
Aller à la navigationAller à la recherche

Liens utiles

Documentations :

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 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 à 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.

VHDL - AXI4 Exemple
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 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.

VHDL - AXI4 Exemple 1
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.

VHDL - AXI4 Exemple 2
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.

VHDL - AXI4 Exemple 3 Masqué
VHDL - AXI4 Exemple 3 Masqué

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

Solution

VHDL - AXI4 Exemple 3
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.