Analyse des transferts sur le bus:

Travail initial:

Pour cette étape du travail il faut d'abord compléter la structure du système en y ajoutant les modules DMA vidéo. Pour ce fait il faut:

  • Les instancier,
  • connecter les interfaces wishbone maitre et esclave au bus (en ajoutant les signaux nécessaires),
  • les relier aux flux vidéo,
  • relier les interruptions au processeur.

SoC avec modules pour la vidéo

Les modules DMA ne démarrent pas tant qu'ils n'ont pas été activé par le processeur. Il faudra veiller à modifier le code s'exécutant sur le processeur pour activer les deux modules. Les deux modules devront utiliser la même zone mémoire pour respectivement y stocker et y lire l'image. Pour les tests que vous avez à effectuer, les interruptions n'ont pas besoin d'être activées.

Une fois l'ensemble fonctionnel, vous devriez obtenir un modèle de système dans lequel des accès concurrents de et vers la mémoire sont régulièrement fait.

Travail à faire:

  • Comment se fait l'arbitrage? Combien de temps prend-il?
  • Quel est le débit des transferts sur le bus?
  • Modifiez les paramètres des modules DMA vidéo (taille des buffers, taille des blocs)
    • Quelle est la taille minimale des buffers utilisables sans perte de pixels?
    • Quelle relation avec la taille des blocs?
    • ...
  • Ajouter un maître qui fait des lecture/écritures concurrentes de blocs de données
    • Comment évoluent les performances précédemment mesurées

Cette étape est importante car elle permet de bien estimer les débits effectifs obtenus sur le bus et permettra de dimentionner la suite des éléments qui seront ajoutés au SoC.

Précision du modèle de contrôleur SDRAM:

Jusqu'ici nous avons utilisé le modèle de mémoire VCI générique fourni par SoCLib. Ce modèle a un comportement très simple celui d'une mémoire synchrone en lecture en écriture. Chaque accès entraine une latence d'un cycle sur le bus wishbone.

Pratiquement, les SDRAM n'ont pas ce comportement. Les accès entrainent des latences plus ou moins importantes en fonction de la vitesse à laquelle on les fait fonctionner. De plus, les SDRAM ont des modes d'accès "piplinés" qui permettent de lire (ou d'écrire) des blocs de données dont les adresses sont consécutives. Dans ce cas la latence n'est subite que pour le premier accès. Ajoutons à cela le contrôleur mémoire, qui fait l'interface entre le SoC et la SDRAM, qui peut éventuellement contenir des mémoires tempos et changer les latences d'accès.

Pour cela, nous proposons d'utiliser un autre modèle pour le couple SDRAM/contrôleur qui, bien que ne représentant pas exactement la réalité, est moins simpliste et pour lequel les latences sont réglables.

Le module WbRam:

Le module WbRam est un modèle de SDRAM+contrôleur avec les caractéristiques suivantes:

  • Une interface wishbone (pas besoin du convertisseur de protocole VCI->WB)
  • Latence nulle pour les requêtes d'écriture
  • Latence initiale configurable pour les requêtes de lecture par bloc

Ce module modélise le comportement d'un contrôleur de SDRAM avec une fifo pour les requêtes d'écriture (absorbant ainsi la latence) et faisant systématiquement des requêtes pipilinées en lecture.

Il comportement suivants ne sont par contre pas modélisés:

  • les rafraichissements réguliers de la sdram;
  • les latences aux changements de pages;

De plus, les requêtes en écriture sont systématiquement acceptées, comme si la fifo d'écriture était de taille infinie.

L'intérêt de ce module est de modéliser est de voir les pénalités en cas d'écritures isolées (non faites par bloc).

Pour avoir une estimation plus précise nous pouvons utilise un vrai modèle RTL. Nous verrons dans la suite comment co-simuler des modules Verilog avec notre plateforme.

Le constructeur du module est:

               WbRam (
                      sc_core::sc_module_name insname,         // Nom du module SystemC
                      const soclib::common::IntTab &index,     // Indice de la cible
                      const soclib::common::MappingTable &mt,  // Table d'adressage
                      uint32_t read_latency                    // Latence initiale pour une lecture par bloc
                      );

Ce module reprend les paramètre de la RAM VCI qui sont la table d'adressage et l'indice du segment à allouer.

La latence initiale pour les lectures est paramétrable avec une valeur par défaut de 4.

Travail à faire:

  • Remplacez la RAM VCI par ce modèle.
  • Modifiez la latence initiale de lecture et observez les performances.

Estimation des débits pour un maître supplémentaire:

Comme dans la suite nous serons amené à ajouter un maitre supplémentaire au bus (qui correspondra au module réalisant l'application de traitement d'image) il serait intéressant d'évaluer le débit réellement disponible sur le bus et la RAM (maintenant qu'une partie est utilisée pour les flux vidéo).

Pour cela vous pouvez utiliser le module maître générique (par exemple le DummyWbMaster) pour générer des requêtes de lecture et d'écriture sur de et vers la RAM.