show menu


Les utilisateurs connectés peuvent télécharger ce tutoriel en pdf

Analyser un design HW avec un Integrated Logic Analyser (ILA)

Posté par Florent - 06 Juillet 2017

Introduction

Dans ce tutoriel, nous allons insérer un Integrated Logic Analyser (ILA) dans un block design afin de comprendre la communication sur le bus AXI entre la PS et la PL.

Créer le Projet

Suivez le tutoriel 9 pour créer un projet utilisant l’IP AXI GPIO.

Marquer les signaux à Debugger

Dans ce tutoriel, nous allons analyser les communications entre la PS et la PL en analysant l’interface AXI entre l’IP AXI Interconnect et l’IP AXI GPIO.

Ouvrez le Block Design. Faites un clic droit sur le bus entre la sortie M00_AXI de l’IP AXI Interconnect et l’entrée S_AXI de l’IP AXI GPIO et cliquez sur “Mark Debug”.

Figure 1 - Mark Debug

Validez le Block Design. Il ne devrait pas y avoir d’erreur. Régénérez les “output products” et synthétiser le design.

Ajouter l’Integrated Logic Analyser (ILA)

Ouvrez le design synthétisé. La fenêtre “Debug” doit s’ouvrir lorsque vous ouvrez le design synthétisé. Sinon, vous pouvez l’ouvrir manuellement en cliquant sur “Window > Debug”. Ensuite cliquez sur l’icône “Set Up Debug sur la gauche de la fenêtre “Debug”.

Figure 2 - Set Up Debug

Dans la fenêtre “Set Up Debug”, dans la page “Net to Debug”, cliquez sur l’icone “Filter pour afficher tous les signaux qui n’ont pas de domaine d’horloge (“clock domain”). Selectionnez tous les signaux restants, faite un clique droit sur la selection et cliquez sur “Select Clock Domain…”.

Figure 3 - ILA - Select Clock Domain

Dans la fenêtre “Select Clock Domain”, assurez-vous que “FCLK_CLK0” est sélectionné et cliquer sur OK.

Figure 4 - Select Clock Domain

Tous les signaux capturés par le même ILA doivent avoir le même domaine d’horloge.

Cliquez sur next > Next > Finish. Enregistrez le design synthétisé (ctrl + S), lancez l’implémentation du design et ouvrez le design implémenté.

Figure 5 - ILA dans la Netlist du design implémenté

 

Si l’ILA a été correctement implémentée, vous devriez le voir dans la Netlist du design implémenté.

Fermez le design implémenté et générez le bitstream.

Exportez le design hardware pour SDK en incluant le bitstream et démarrez SDK.

Démarrer le debug dans Xilinx SDK

Dans SDK vous devriez avoir le projet application crée suivant le tutoriel 9. Programmez le FPGA. Lancez une nouvelle session de debug GDB.

Figure 6 – Afficher le numero de ligne ou ajouter un point d’arret dans Xilinx SDK

Ajoutez un point d’arrêt (breakpoint) sur la ligne 40 (“if(direction == DIR_LEDS_RIGHT){“). Si vous voulez afficher les numéros de lignes dans SDK, faites un clic droit sur la colonne bleue sur la gauche et cliquer sur “Show Line Numbers”. Pour ajouter un point d’arrêt (breakpoint), vous pouvez double-cliquer sur la colonne bleue ou faire un clic droit dessus, cliquer sur “Add Breakpoint” et entrer le numéro de ligne désiré.

Retournez dans Vivado. Cliquez sur “Open Hardware Manager” dans le “Flow Navigator”. Cliquez sur “Open the target”. Vous devriez voir la fenêtre de l’ILA.

Figure 7 – Fenêtre ILA dans Vivado

Dans la fenêtre “Trigger Setup”, cliquez sur l’icône “+” et chercher “AWVALID”. Sélectionnez ensuite le signal.

Figure 8 - Set the signal AWVALID as probe

Changez la valeur de comparaison de “X” à “1”.

Figure 9 - Changer la valeur de comparaison du signal

Changez la valeur de “Trigger position in window” à “512”.

Figure 10 - Trigger position in window

Lancez l’ILA en pressant l’icône.

Le statut de l’ILA devrait changer pour “Waiting for Trigger”.

Figure 11 - ILA “Waiting for Trigger”

Continuez l’exécution de l’application dans SDK (appuyer sur F8). Le programme va s’arrêter sur la ligne du point d’arrêt. Dans Vivado, l’ILA devrait toujours être dans l’état “Waiting for Trigger” puisque l’application n’a pas encore changé la valeur des LEDs. Continuez de nouveau l’exécution de l’application dans SDK. Dans Vivado, l’état de l’ILA devrait maintenant être “Idle” et les données devraient avoir été capturées.

Figure 12 – Capure des signaux par l’ILA

Analyser les données sur l’interface AXI

La Figure 13 montre le flux de communication sur une interface AXI pour exécuter une écriture de données.

Figure 13 – Flux d’écriture sur l’interface AXI (Source Xilinx UG1037)

Si on analyse l’interface AXI de l’IP AXI GPIO sur la Figure 14, on peut voir 5 groupes de signaux (identifiés par leurs noms) :

·        s_axi_aw*: signaux correspondant au canal d’adresse d’écriture

·        s_axi_ar*: signaux correspondant au canal d’adresse de lecture

·        s_axi_r*: signaux correspondant au canal de données en lecture

·        s_axi_w*: signaux correspondant au canal de données en écriture

·        s_axi_b*: signaux correspondant au canal réponse d’une écriture

Figure 14 - AXI GPIO IP

 

Dans notre cas, nous exécutons une écriture via l’interface AXI. Comme montre sur la Figure 13, la première étape d’une écriture AXI correspond au maitre envoyant l’adresse et le signal de contrôle via le canal d’adresse d’écriture. Dans notre sortie d’ILA, cela corresponds à :

·        L’adresse  0x41200000 est écrite par le maitre sur le bus *_AXI_AWADDR

·        Le signal *AXI_AWVALID est mis a 1 par le maitre pour indiquer une requête valide d’écriture

Dans la seconde étape, le maitre envoie la donnée à écrire:

·        La donnée est écrite sur le bus *_AXI_WDATA

·        le signal *_AXI_WVALID est mis à 1 par le maitre pour indiquer que la donnée est valide

·        le signal *_AXI_WREADY est mis à 1 par l’esclave pour indiquer qu’il est prêt pour la donnée suivant (si disponible)

Dans la dernière étape, l’esclave indique que l’opération d’écriture est un succès:

·        le signal *_AXI_BRESP est mis à 1 par l’esclave

 



Poster un commentaire

Seuls les utilisateurs connectés peuvent poster des commentaires