Énoncé - Moodle

Partie 2 :
Intégration d’un bus
et ajout de plusieurs module
sur l’architecture existante
A concevoir
A modifier
Donné
A reprendre
next
next
Routeur
(maître)
Dns
(esclave)
pkt
Simple Bus
Génerateur ready
De paquets pkt
Dispatch
(esclave)
read
y
pkt
Station1
pkt
Station2
Display
ack
pkt
Station3
Objectif :
L’objectif de cette partie est d’intégrer un bus entre le générateur de paquets et les station
d'affichage de manière à pouvoir rajouter un module sur ce bus: une table de
correspondance.
Définitions :
Le bus :
Le bus est un canal de communication permettant de relier ensemble différents modules.
Ces différents modules se divisent en deux catégories, les modules maîtres et les modules
esclaves. Les modules maîtres peuvent envoyer des requêtes de lecture et d’écriture
tandis que les modules esclaves ne font que répondre à ses requêtes. Des interfaces sont
disponibles en fonction du type de module. Le tableau suivant établit la liste des
différentes interfaces disponibles par le bus, en fonction du type de module :
Les modules maîtres (module) : simple_bus_blocking_if.h
Interface
Définition
Virtual simple_bus_status burst_read(
unsigned int unique_priority
, int *data
, unsigned int start_address
, unsigned int length = 1
, bool lock = false) = 0;
virtual simple_bus_status burst_write(
unsigned int unique_priority
, int *data
, unsigned int start_address
, unsigned int length = 1
, bool lock = false) = 0;
Cette méthode vous permet d'effectuer une lecture
bloquante de taille length*4 octets vers *data.
Les données sont lues depuis la mémoire d'un
esclave à l'adresse de départ start_adress.
unique_priority est la priorité de ce maître et la
variable lock permet d'empecher des requetes de
plus hautes priorités de prendre la main
Cette méthode permet l'ecriture bloquante de la
donnée *data de taille length*4 octets à l'adresse
start_adress d'un esclave.
Les modules esclaves : simple_bus_slave_if.h
Interface
Définition
Virtual simple_bus_status read(
int *data
, unsigned int address) = 0;
virtual simple_bus_status write(
int *data
, unsigned int address) = 0;
virtual unsigned int start_address()
virtual unsigned int start_address()
Cette méthode permet de spécifier la méthode de
lecture sur un périphérique connecté sur le bus. Cette
méthode est à implémenter. Elle est dépendante du
périphérique utilisé. Cette fonction sera à développer
lors de l’élaboration de votre module DNS (voir
description dans le paragraphe suivant)
Cette méthode permet de spécifier la méthode
d’écriture sur un périphérique connecté sur le bus.
Cette méthode est à implémenter. Elle est
dépendante du périphérique utilisé. Cette fonction
sera à développer lors de l’élaboration de votre
module dispatch (voir description dans le paragraphe
suivant)
Renvoie l'adresse de départ de la mémoire du
module (à implémenter)
Renvoie l'adresse de fin e la mémoire du module
(à implémenter)
Le paquet :
Le paquet est un objet constitué d’une adresse de destination et d’un message. Le tableau
suivant en décrit la structure :
ID (32
bits)
Adresse de
destination
(32 bits)
Payload (128 bits)
Le tableau suivant établit la liste des méthodes qui vous seront utiles :
Méthode de l’objet paquet
Packet(unsigned adr, unsigned int seed)
Packet(unsigned int* packet)
Unsigned getAddress()
void setAddress(unsigned addr)
Définition
Cette méthode permet de construire un
nouveau paquet constitué d’une adresse
de destination adr et du message généré à
l'aide de seed
Cette méthode permet de construire un
nouveau paquet à l'aide d'un tableau
packet de bonne taille
Cette méthode retourne l’adresse de
destination du paquet.
Cette méthode permet de modifier
l'adresse d'un paquet
Pour plus de renseignement, reportez-vous au code source du fichier packet.cpp et
packet.h.
Explorez le code source du bus de manière à comprendre son fonctionnement. Pour ce
faire, allez dans le répertoire « systemc-2.3.1\examples\sysc\simple_bus», analysez les
fichiers sources et le readme.
Travail à réaliser :
Le module table de correspondance (DNS) :
Ce module est un périphérique jouant le rôle d’une mémoire. Cette mémoire contiendra
les adresses (le numéro) des stations de destination . Concrêtement, le module DNS devra
comporter une mémoire de le taille de l'espace d'adressage (0 à 255). La correspondance
entre une adresse et la station concernée sera créée à la construction du module tel que :
• 0 à 85 : Station1
• 86 à 171: Station2
• 172 à 255 : Station3
Ce périphérique se verra attribuer l’adresse de départ 0x1234.
Pour envoyer un paquet, le générateur a besoin de savoir où se trouve le module de
destination. Pour ce faire, il va interroger la table de correspondance (DNS) afin de
connaître l’identification du module sur lequel est connecté la station de destination.
Cette interrogation s’effectue par une lecture à l'adresse de départ du DNS + l'adresse du
paquet.
Une fois le numéro de correspondance trouvé, le routeur va remplacer l'adresse du paquet
par le numéro de station correspondant.
Le Routeur :
Les fonctionnalités du routeur de la partie 1 vont être séparées en 2 modules différents :
le module maître routeur et le module esclave dispatch. Le module maître garde
l'interface avec le générateur de paquets afin de pouvoir récupérer les paquets générés.
Lorsqu'un paquet est prêt, le routeur s'en empare puis envoie une requête au DNS pour
savoir vers quelle station envoyer le paquet. Il remplace ensuite l'adresse du paquet par le
numéro de la station, puis envoie le paquet vers le module esclave de Dispatch.
Le Dispatch :
Les fonctionnalités du routeur de la partie 1 vont être séparées en 2 modules différents :
le module maître routeur et le module esclave dispatch. Le module Dispatch intègre les
interfaces avec les différentes stations.
Il devra posséder une mémoire permettant de contenir un paquet complet (soit un
unsigned int[6])
Il devra de plus intégrer une méthode sensible aux fronts montants de l'horloge qui
décrémentera un compteur simulant le temps de communication avec le dispatch.
La fonction write de l'interface slave_if devra être implémentée pour prendre en compte
ce temps d'attente (Pour voir un exemple d'implémentation, vous pouvez regarder le
simple_bus_slow_mem.h dans les exemples de systemC). Cette méthode remplira mot
par mot la mémoire du module avec les éléments du paquets. Une fois un paquet complet
envoyé, cette méthode reveillera le thread dispatch à l'aide de event.notify().
Un thread permettant le dispatch des paquets vers les stations devra être créé. Ce thread
sera réveillé par un event.notify() généré par la fonction write ci-dessus lorsqu'un paquet
est prêt dans la mémoire du dispatch. Tant que le thread dispatch est actif, la fonction
write devra renvoyer l'état SIMPLE_BUS_WAIT. Vous pouvez achever ce
comportement à l'aide d'une variable locale au module.
Remarques :

Les fichiers qui vous sont fournis sont dans l’archive :
Inf3610_lab3_partie2.zip
 Lisez bien le README de l'exemple fourni dans
« systemc-2.3.1\examples\sysc\simple_bus»
 Le code source du bus écrit en SystemC vous est donné, il est disponible dans le
répertoire « bus » de l’archive. Le code du bus ne doit pas être modifié.
Questions partie 1 :
• Expliquez les différences entre sc_buffer, sc_signal et sc_fifo
• Pourquoi avoir utilisé des SC_Threads dans nos différents modules? Aurait-on pu
utiliser des SC_Methods?
Questions partie 2:
• Expliquez comment vous avez intégré le bus. Décrivez votre travail.
• Expliquez comment fonctionne votre module « DNS ».
• Commentez et expliquez votre code sources (le DNS, le routeur et le dispatch).
Evaluation :
Ce laboratoire est noté sur 20 points.
Barême :
Partie 1 : 7 points
• Exécution : 4 pts
• Questions : 3 pts
Partie 2 : 11 points
• Execution : 6 pts
• Commentaires dans le code, explication du fonctionnement : 5pts
Clarté du code et respect de la langue francaise : 2 pt
Directives pour le rapport :
Un rapport vous est demandé. Pas d’introduction, pas de conclusion, pas de blablabla.
Répondez aux questions pour chacune des parties
Directives pour les fichiers :
Faites un répertoire pour chaque partie (2 répertoires). Vous devez donc avoir
l’arborescence suivante :
inf3610_lab3_mat1_mat2
|-> partie1
|
|-> vos fichiers de la partie 1
|-> partie2
|
|-> vos fichiers de la partie 2

Download Report