Version 5 (modified by 16 years ago) (diff) | ,
---|
TP1: Modélisation CABA (Cycle Accurate Bit Accurate)
0. Objectif
L'objectif de ce premier TP est de vous amener à écrire vous-même, en utilisant le langage SystemC quelques modèles de composants matériels très simples, en respectant le niveau d'abstraction CABA (Cycle Accurate, Bit Accurate) utilisé pour modéliser les composants de la bibliothèque SoCLib. Ce type de modélisation s'appuie sur la théorie des automates d'états synchrones communicants (CFSM), et permet d'utiliser des technique d'ordonnancement statique permettant d'accélérer la simulation.
1. Architecture à modéliser
L'architecture matérielle à modéliser réalise Elle ne comporte que deux composants matériels: Le premier composant est un coprocesseur cablé (c'est à dire non programmable) qui calcule le PGCD (plus grand commun diviseur) de deux nombres entiers positifs A et B, codés sur 32 bits. Le second composant est chargé de transmettre les valeurs des opérandes A et B au coprocesseur, et de récupérer le résultat. Ces deux composants matériels fonctionnent en parallèle, et communiquent entre eux par des canaux de communication de type FIFO.
Ces deux composants sont donc modélisés par deux automates cadencés par la même horloge CK, avec écriture dans les tous les registres du système sur le front montant de CK. Ils sont initialisés par le même signal NRESET, actif à l'état bas.
1.1 Canal de communication FIFO
1.2 Composant fifo_lcd_coprocessor
L'algorithme de calcul du PGCD implanté par cet automate cablé peut être décrit par le code C suivant :
uint32_t lcd( uint32_t opa, uint32_t opb) { while (opa != opb ) { if ( opa > opb ) opa = opa - opb; if ( opa < opb ) opb = opb - opa } return( opa ); }
Le chemin de donnée permettant de réaliser ce calcul doit donc comporter deux registres r_opa et r_opb pour stocker les valeurs opa et opb qui évoluent au cours du calcul, ainsi qu'un comparateur et un soustracteur sur 32 bits.
Par ailleurs l'automate cablé reçoit les deux valeurs des opérandes OPA et OPB sur son port FIFO d'entrée, et renvoie le résultat sur son port FIFO d'entrée.
Finalement, l'automate qui contrôle le composant "fifo_lcd_coprocesseur exécute un boucle infinie, dans laquelle il effectue successivement les 4 opérations suivantes:
- lecture de l'opérande A sur son port FIFO d'entrée
- lecture de l'opérande B sur son port FIFO d'entrée
- calcul effectif du PGCD
- écriture du résultat sur son port FIFO de sortie
Ces quatres opérations ont des durées d'exécution variables, puisque le nombre de cycles pour effectuer le calcul (étape 3) dépend de la valeur des opérandes, et que les opérations de communications (étapes 1, 2 ou 4) ont des durées qui dépendent de la disponibilité du composant fifo_lcd_master.
Outre le registre d'état de l'automate r_fsm, cet automate contrôle donc deux autres registres r_opa" et r_opb utilisés pour le calcul :
- Dans l'état READ_OPA (resp. READ_OPB), on écrit dans le registre r_opa (resp r_opb) la valeur de l'opérande OPA (resp. OPB) lue sur le port FIFO d'entrée (champs p_in.data). On ne sort de cet état que si la donnée est valide (condition p_in.rok = true).
- Dans l'état WRITE_RES, on écrit le contenu du registre r_opa sur le port FIFO de sortie p_out.data. On ne sort de cet état que si la donnée est acceptée (condition p_out.wok = true).
- Dans l'état COMPARE, on effectue la comparaison entre les contenus des registres r_opa et r_opb. On n'écrit pas dans les registres r_opa et r_opb, mais les conditions de sortie dépendent du résultat de la comparaison.
- Dans l'état DECR_A (resp. DECR_B), on écrit le dans le registre r_opa (resp. r_opb). On ne reste qu'un cycle dans ces états, puisque la décrémentation ne dépend d'aucune condition extérieure.
1.3 Composant fifo_lcd_master
Ce composant matériel effectue le travail normalement effectué par un processeur programmable, consistant à générer les valeurs des deux opérandes, à transmettre ces valeurs d'entrée au coprocesseur, à récupérer le résultat calculé par le coprocesseur, et à afficher ce résultat sur un terminal. L'utilisation de processeurs programmables suppose qu'on est capable de déployer le code binaire exécutable par le processeur programmable sur l'architecture matérielle simulée. Ce problème sera traité dans la suite de ce cours, mais dans ce premier TP, on se contente d'utiliser un processeur cablé, qui exécute en boucle le programme suivant:
- génération (pseudo-aléatoire) de deux valeurs OPA et OPB.
- écriture de l'opérande OPA sur son port FIFO de sortie.
- écriture de l'opérande OPB sur son port FIFO de sortie
- lecture du du résultat sur son port FIFO d'entrée.
- affichage des valers sur le terminal.
Pour modéliser la génération aléatoire, on utilise la fonction rand() fournie par la LibC de la station de travail qui exécute la simulation. On génère évidemment des valeurs aléatoires différentes à chaque itération de la boucle, mais pour faciliter le deboguage, on garantit un fonctionnement reproductible, en contrôlant la valeur initiale du générateur aléatoire grace à la fonction srand() utilisée dans le constructeur du modèle.
Le composant fifo_lcd_masterest donc un composant matériel paramètrable (un paramètre permettant de contrôler la séquence de valeurs aléatoires), modélisé comme un automate à 5 états :
Outre le registre d'état de l'automate r_fsm, cet automate contrôle quatre autres registres : les registres r_opa, r_opb, et r_res permettent de stocker respectivement les deux opérandes et le résultat du calcul. Le registre r_cyclecount est incrémenté à chaque cycle, e permet de gérer une date (en nombre de cycles) depuis l'initialisation du système.
- dans l'état RANDOM on écrit les valeurs pseudo-aléatoires OPA et OPB dans les registres r_opa et r_opb. On ne reste q'un cycle dans cet état.
- dans l'état WRITE_OPA (resp. WRITE_OPB) on écrit le contenu du registre r_opa (resp r_opb) sur le port FIFO de sortie (champs p_out.data). On ne sort de ces états que si la donnée est acceptée (condition p_out.wok = true).
- dans l'état READ_RES, on écrit dans le registre r_res la valeur lue sur le port FIFO d'entrée (champs p_in.data). On ne sort de cet état que si la donnée lue est valide (condition p_in.rok = true).
- Dans l'état DISPLAY, on ne modifie pas le contenu des registres r_opa, r_opb, et r_res, mais on affiche la date
courante ainsi que les valeurs des opérandes et du résultat sur le terminal standard de la station de travail qui exécute la simulation. On ne reste qu'un cycle dans cet état.
2. Travail à réaliser
2.1 Ecriture du modèle CABA du coprocesseur
Le modèle de simulation d'un composant matériel (appelé module en SystemC) nécessite la définition d'une classe C++ dont le nom correspond au nom du module matériel modélisé. Il faut donc écrire deux fichiers.
- Le fichier ""module.h contient la définition de la classe
- de
2.2
2.3
Attachments (5)
- soclib_tp1_archi.png (30.4 KB) - added by 16 years ago.
- soclib_tp1_coprocessor.png (27.5 KB) - added by 16 years ago.
- soclib_tp1_fifo.png (35.0 KB) - added by 16 years ago.
- soclib_tp1_master.png (23.0 KB) - added by 16 years ago.
- soclib_tp1.tgz (3.6 KB) - added by 16 years ago.
Download all attachments as: .zip