Voir la source de P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

= Rapport de Présoutenance =

http://projets-imasc.plil.net/mediawiki/images/0/05/Rapport_VAESSEN_presoutenance.pdf

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.


== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.


Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1:  ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

=== Semaine 8: ===

Au lieu d'essayer de comprendre comment fonctionne de manière précise l'abritrage du bus amba et comment fontionne le processus de selection d'un composant en fonction de l'adresse sur le bus, je me suis concentré sur les signaux reliées directement au mémoire (ram, rom et sdram) physique afin d'écrire mon composant.

L'idée serait d'utiliser ces signaux et faire une sortie sur un GPIO pour connaitre son état en le visualisant sur un oscilloscope.

=== Semaine 9: ===

Discussion et abandon de l'idée de la semaine 8, car une nouvelle contrainte a été fixée:

-le résultat de chacun des compteurs devra pouvoir être accessible à des adresses mémoire sur le bus amba donc accessible par le processeur.

=== Semaine 10: ===

Mise au propre du cahier des charges, et étude de la norme AMBA.

Test grmon RCP au travers Eclipse, infructueux, car la carte n'est pas reconnue.

== Semaine 11: ==

Écriture d'une ébauche de composant et étude des possibilités en fonction des signaux disponible dans le contrôleur mémoire.

== Semaine 12: ==

Étude bibliographique (documents de Gaisler, norme AMBA).

== Semaine 13: ==

Rédaction du rapport et préparation à la présoutenance.

== Semaine 14: ==

Prise en main de ModelSim PE 10.4, pour simuler le SOC (des erreurs sont encore à régler).

== Semaine 15: ==

Début de l'écriture du composant:
- correction des incohérences du design (au niveau du déclenchement du composant)
- amélioration du design (réduction de largeur des bus)

== Semaine 16: ==

Écriture et test du composant.

== Semaine 17: ==

Écriture de la fonction de la reconnaissance d'écriture dans un composant surveillé.

Écriture de la fonction permettant la reprogrammation du composant en valeur maximale. 

Documentation sur l'utilitaire Chipscope Pro et son utilisation avec la carte.

== Semaine 18: ==

Tentative d'utilisation de Chipscope Pro, des erreurs sont constatées (ce qui est d'ailleurs évoqué lors de la configuration dans Chipscope : "connection to PAD or IBUFG net can cause error in PAR") (Qui provoque des erreurs lors de l'implémentation du design).

On rajoute des bascules D afin d'éviter ces erreurs, cependant nous ne verrons que l'état des bus au moment des fronts montants ou descendants (ce que est logique, car l'on ne peut pas échantillonné avec durée inférieur à celle de l'horloge).

L'implémentation avec est impossible à cause d'un signal "non existent", alors que celui existe belle et bien, donc on peut confirmer le fonctionnement du composant grâce à la simulation.

Test des commandes utiles au travers de grmon pour la version non modifiée et modifié du leon3.

On a commencé la réflexion sur un cache l2c primitif, ce composant permettrais de fournir directement le résultat si celui-ci à déjà était réalisé auparavant (Analogie: une personne que pose deux fois de suite la même question dans un intervalle borné relativement court).

== Semaine 19: ==

Début du rapport final.

Raccourcissement du code du composant.

Écriture des signaux de sortie: hrdata, hresp et hready, des fonctions de multiplexage en sortie seront nécessaires.

Ceci reste à confirmer grâce à un test sur la carte et/ou une simulation.

Nous avons réussi à faire fonctionner la simulation sur Modelsim PE.

Nous avons fait en sorte que le composant soit visible et reconnu lors de la simulation*

*à confirmer sans les attributes keep

== Semaine 20: ==

Réalisé:

Le composant est présent dans le log de la simulation modelsim pe. Nous n'avons pas confirmé par la simulation du design, en effet on cherche une "solution simple" pour montrer son bon fonctionnement.

Reconnaissance du composant par le contrôleur de bus AMBA, on trouve une trace cohérente dans la mémoire à l'adresse 0xFFFFF800 (via grmon) est faite sur le design réelle (la carte).

Lecture de la valeur du compteur dans grmon (sur la carte), cela-ci s'incrémente en permanence (le compteur est régler pour s'incrémenter à chaque accés au contrôleur mémoire), il faut montrez qu'il est possible de surveiller une portion de la mémoire.



à faire:


Début de la présentation de PFE à faire.

Et rédaction du rapport à terminer.

Vidéo à faire.

-confirmer la présence du composant avec son compteur dans ModelSim PE
:Utile ?

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.



=== Bibliographie: ===


[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design 
http://www.gaisler.com/products/grlib/grip.pdf