Aller au contenu

Codage d'un contrôleur avec rafales.

TAG à placer sur le dépot à la fin de ce travail: avalon_burst_bram

Il s’agit d'adapter le contrôleur précédent pour le support des transmissions en rafales.

Contraintes de codage à respecter impérativement

  1. Ne pas créer un nouveau fichier mais modifier l'existant après l'avoir taggé dans le précédent exercice.
  2. Le contrôleur utilise le mode pipelined burst du bus Avalon (voir chapitre 3.5.5 de la documentation), c’est à dire que l' hôte précise en une seule requête le nombre de données à transférer via le signal burstcount
  3. Le code devra être synthétisable.
  4. Les transactions simples (burstcount=1) devront toujours être supportées.

Chronogramme attendu pour les transactions

Le chronogramme présente 2 transactions en rafale en lecture suivies de 2 transactions en rafale en écriture.

Chronogrammes pour des transactions en burst

  • On remarque que seule l'adresse de début de rafale est indiquée.
  • On remarque qu'en lecture, le contrôleur renvoie une donnée par cycle (l'hôte n'a pas le droit de l'interrompre).
  • On remarque qu'en écriture, l'hôte peut interrompre temporairement la transaction: l'agent attend tant qu'il n'a pas reçu toutes les données.

Conseils

  1. Il sera sûrement nécessaire de mettre en place un automate (si vous ne l'avez pas déjà fait), ainsi qu'un compteur pour les adresses de la rafale.
  2. Séparez toujours les blocs de code: par exemple, un code pour le compteur, un code pour l'automate.
  3. Attention en lecture et en écriture le comptage est différent:
    • En lecture, vous devez renvoyer burstcount données après la requête de lecture initiale.
    • En ecriture, après la requête initiale qui écrit la première donnée, vous devez recevoir burstcount-1 données.

Simulation

Les messages de simulation devraient être les suivants:

#            0.00000ns:  verbosity_pkg.set_verbosity: Setting Verbosity level=3 (VERBOSITY_WARNING)
# 
#            390.000ns: INFO:  Starting FIRST sequence of packets read/write/verify
#          23230.000ns: INFO:  Finished FIRST packet read/write/read sequences
#          23230.000ns: INFO:  Total time for simple Pipelined packet transfer sequences:  22840
# 
#          23430.000ns: INFO:  Starting SECOND second sequence of packets read/write/verify
#          36010.000ns: INFO:  Finished SECOND packet read/write/read sequences
#          36010.000ns: INFO:  Total time for Pipelined and Burst  packet transfer:  12580
#
#          36210.000ns: INFO:  Starting RAM config tests
#          36210.000ns: INFO:  2048 words written in the RAM with increasing adresses and values (sel = 1111)
#         119410.000ns: INFO:  Value 32'h12345678 written at first address above RAM last address and read back at address 0
#         119470.000ns: INFO:  Finished tests of RAM size without errors.
  • La première série de tests doit être toujours opérationnelle.
  • La deuxième série de tests doit confirmer que le mode rafale est opérationnel.
  • Enfin la troisième série de test vérifie que la taille de la mémoire paramétrable implantée dans le code est exactement celle désirée.

Cette fois encore, vérifiez le temps total des transferts en rafale (environ 12580). Si les valeurs obtenues sont trop éloignées, corrigez votre code:

  • Temps trop long: Votre code doit être capable d'envoyer ou recevoir une donnée par cycle.

En ce qui concerne les tests de taille de mémoire, vérifiez les déclarations des BRAM, ainsi que la gestion des adresses physiques à partir des adresses en provenance du bus AVALON.

Synthèse

Estimation de la complexité:

Si le code est synthétisable, vous devriez avoir un résultat de ce type:

## Synthesis stats
MISTRAL_MLAB             0
MISTRAL_M10K             8
MISTRAL_ALUT_ARITH      25
MISTRAL_ALUT            64
MISTRAL_FF              27
  • Le nombre de mémoires ne doit pas changer (par rapport à la version précédente).
  • MISTRAL_ALUT_ARITH: le compteur d'adresses nécessite des calculs arithmétiques.
  • MISTRAL_ALUT: de la logique en plus.
  • MISTRAL_FF: il faut stocker l'état des compteurs.

Si vos chiffres s'éloignent trop de ces valeurs (plus grands), il est probable que votre code soit mal écrit.

Estimation de la vitesse de fonctionnement

Compte tenu de la complexité accrue, cette version est nécessairement plus lente.

  • Un résultat autour de 150Mhz est correct.