Debugger un composant VHDL sur FPGA

De Ensiwiki
Aller à : navigation, rechercher

Trouver les bugs dans une conception VHDL, ce n'est pas simple. Les bugs peuvent venir de divers endroits, y compris des outils que l'on utilise. Cette page devrait vous aider à identifier précisément les problèmes, et vous donne quelques pistes pour les corriger.

Premier réflexe : la simulation comportementale

  • Afficher au minimum l'état courant du processeur, PC et IR.
  • Remonter depuis le signal incorrect jusqu'à l'origine du problème.
  • Si il y a du rouge sur le chronogramme, c'est mauvais signe : ça peut être soit une valeur non-initialisée, soit un court-circuit.

Un problème ? Relisez la liste des erreurs fréquentes

La page Erreurs fréquentes avec ISE recense un certain nombre d'erreurs fréquentes avec leurs solutions, et de problèmes des logiciels avec leurs contournements. Si vous avez un comportement inexpliqué, retournez lire cette page ...

Lecture du rapport de synthèse

Le rapport de synthèse (fichier *.syr) est très verbeux, mais contient beaucoup d'informations, comme :

  • Des warnings, par exemple:
    • signaux non connectés,
    • signaux qui devraient être combinatoires mais qui ne le sont pas (« found N-bit latch for signal xyz », typiquement du à un oubli de valeur par défaut du signal xyz dans une machine d'états)
  • La fréquence maximum (en bas du fichier), et le chemin critique. Si cette fréquence est inférieure à 50MHz, ça ne marchera pas avec l'horloge interne du FPGA.

Passage sur FPGA

Le FPGA permet de vérifier que le design tourne correctement. Il est très peu pratique pour debugger, donc si ça ne marche pas, on utilisera en priorité la simulation post-routage et synthèse.

Ça marche en simulation, mais pas sur FPGA ? La simulation post-synthèse

La simulation comportementale fait un certain nombre d'approximations pour faire une simulation rapide. En particulier :

  • En simulation comportementale, la notion de temps est très simplifiée. La plupart des calculs ont l'air de se faire de manière instantanée, on ne voit pas les temps de propagation.
  • La simulation comportementale se base sur le code source. Si l'outil de synthèse a mal synthétisé quelque chose, on ne verra pas ce problème en synthèse comportementale.

ISE permet de simuler finement le code produit par le synthétiseur. La simulation est plus lente (très lente :p. Compter une dizaine de minutes pour une simu de 10 000 ns !), car le simulateur doit prendre en compte beaucoup plus de choses, la liste des signaux est moins bien organisée, mais le comportement est beaucoup plus proche de celui du FPGA, donc on arrive à reproduire la quasi-totalité des problèmes qui peuvent arriver sur carte.

Ci-dessous un exemple de simulation post-synthèse montrant un bug de XST, le synthétiseur d'ISE. On avait codé un registre IR avec enable (eirout), et on voit en simulation que IR change sans que eirout soit à '1' (il devrait changer en fin du cycle où eirout = '1').

Ise-post-synthesis.png

En simulation post-synthèse, la visualisation de signaux internes est très pénible (les noms des signaux ont été changés, la hierarchie applatie, ...). Pour visualiser simplement un signal, on peut modifier le code VHDL pour faire « sortir » ce signal du composant toplevel à synthétiser/simuler.

Comprendre le problème : décortiquer le résultat de la synthèse

Quand on a identifié précisément l'origine d'une incohérence entre simulation comportementale et simulation post-synthèse et routage, avec les outils de simulations, on peut regarder le résulat de l'outil de synthèse. Toujours dans la partie « Post-route simulation », l'arborescence des sources que l'outil montre est en fait l'arborescence des fichiers générés par l'outil de synthèse.

Sur la capture d'écran ci-dessous, il semble, sur le même bug que dans la section précédente, que le signal IR ait été directement branché en sortie de ROM (sans buffer intermédiaire). En fait, le code (qui ne rentre pas dans la fenêtre) généré ressemble à ceci :


inst_Mram_mem9 : X_RAMB16_S1
  generic map(
    INIT_00 => X"000000000000000000000000000000000000000000000000000000000000000E",
    -- ...
    SRVAL => X"0",
    INIT => X"0",
    WRITE_MODE => "READ_FIRST",
    LOC => "RAMB16_X0Y7"
  )
  port map (
    CLK => CLK_BUFGP,
    EN => GLOBAL_LOGIC1,
    SSR => GLOBAL_LOGIC0,
    WE => GLOBAL_LOGIC0, -- WE = 0, donc on n'écrit jamais, c'est bien une ROM.
    ADDR(13) => GLOBAL_LOGIC0,
    ADDR(12) => cProc_cDataPath_cPC_Q(12),
    -- ...
    ADDR(0) => cProc_cDataPath_cPC_Q(0),
    DI(0) => inst_Mram_mem9_DIA0,
    DO(0) => IRout_9_OBUF_22 -- Sortie de la ROM, branché sur IRout.
  );

Ise-vhdl-netlist.png

On peut aussi regarder le résultat de manière graphique. Vu que l'outil de synthèse a mis à plat la hierarchie, c'est difficile de s'y retrouver, mais toujours sur le même exemple, on peut vérifier que notre signal IRout_9_OBUF_22 connecte bien la sortie de la ROM vers un morceau de logique combinatoire (lut = look-up table) qui correspond vraissemblablement au calcul de l'état suivant en fonction de IR, et à un mux, qui correspond probablement au signal de selection de registre, qui utilise directement quelques bits de IR.

Ise-schematic-netlist.png


Debug sur FPGA

Si la simulation post-synthèse et routage marche, il va falloir utiliser directement le FPGA pour debugger.

Le FPGA est moins pratique que la simulation pour trouver les bugs pour au moins deux raisons :

  • L'horloge va vite (50 Mhz), on n'a pas le temps de voir ce qu'il se passe (par exemple, une diode allumée pendant un cycle, puis eteinte tout le temps paraitra éteinte à l'oeil)
  • On ne peut pas visualiser directement un signal interne, on est limité au ports de sortie.

Chaque problème a une solution ...

Brancher l'horloge du FPGA sur un GBF

On peut régler le GBF sur une fréquence qui permet de voir chaque cycle d'horloge (1Hz par exemple).

Sortir les signaux désirés sur les LEDs

On peut modifier le code VHDL pour sortir un signal arbitraire sur le port POUT, au lieu de sortir la sortie du registre.