Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Compte Rendu TP-1 DSP: Elrhomari Yousra ALAMI Zouhir

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 10

Compte

Rendu TP-1
DSP

Réalisé par:

ELRHOMARI Yousra
ALAMI Zouhir

Encadré par:
Mr. ELBDOURI
Mr. MANSOURI
LAB 1 :

Initiation au Code Composer Studio (CCS)

Profilage du code.

L’objectif de ce TP est de se familiariser avec l’environnement de développement


CCS (Code Composer Studio) de Texas Instrument et le starter DSP (DSK) en plus
d’être capable d’estimer les performances du DSP C67 de TI.
3. Mise en marche et diagnostique de la carte
 On alimente le kit et on attend que les LEDs clignotent puis restent allumées.
 Dans le but de diagnostiquer le kit. On branche le câble USB et on lance DSK
Diagnostics.
 Utility, puis on clique sur Start, et on attend jusqu’à la fin de l’opération. Si tout
s’est bien passé, on a vérifié le bon fonctionnement des principales composantes
du kit.

 Time Profiling
 On crée un répertoire pour chaque projet. On lance le setup de Code Composer
Studio.
 Ensuite on supprime la configuration existante. Dans le cas de notre première
manip, on va travailler avec le simulateur, on va sélectionner et ajouter la
configuration du simulateur, on enregistre puis on quitte le setup, on a ensuite le
choix de lancer ou pas le Code Composer Studio.

 Création du répertoire
 On crée un répertoire de travail : D:\TP_1\Lab1.
 Comme prévu, on a lancé le setup de Code Composer Studio (CCS) et on fait les
tâches suivantes :
o Supprimer la configuration existante.
o On sélectionne le simulateur « C6713 device Cycle Accurate Simulator
Little », enregistrer et puis quitter en lançant le Code Composer Studio.
o Vérifier que la carte est bien alimentée.

 Créer un nouveau projet dans notre répertoire


On crée un nouveau projet, on vérifie qu’on est situé dans notre répertoire, et on vérifie
que la cible est TMS320c67xx.

 Créer un fichier de configuration CDB (Configuration Data Base)


 Il est nécessaire de créer un fichier de configuration d’extension .cdb, ce fichier
doit correspondre à notre carte, pour cela on fait File  New  DSP/BIOS
Configuration, et puis on sélectionne le fichier c6713.cdb. On l’enregistre ensuite
dans notre répertoire en mettant le nom adéquat.
 Maintenant il faut l’ajouter dans notre projet, on utilise le Menu Project/Add files
to Project, et on ajoute notre fichier .cdb
 Dans le menu Option / customize, on coche la case Load Program After Built pour
charger le programme directement après l’avoir Build.
 On crée notre premier fichier .c, et on tape le code suivant :
On sauvegarde le fichier dans notre répertoire
avec l’extension .c, et on ajoute le fichier à
notre projet avec le menu Project / Add files
to Project, et on sélectionne le mode Debug.

On compile notre programme de façon à créer


un fichier exécutable dont l’extension est
.out. Par défaut, le fichier généré sera appelé
lab_1.out.

On compile et Link le programme, on garde la


fenêtre en arrière-plan.

On exécute le programme en pas à pas : Debug : Go


Main
On utilise la fenêtre Watch pour regarder les
variables. Afin d’ajouter une variable et regarder sa
valeur on la sélectionne puis après un clic droit on
choisit le sous-Menu Add to Watch Window
Après l’exécution dans la fenêtre Watch on obtient le
résultat du calcul.

On ouvre une session de Profiling : Profile  Setup.


En cliquant sur : Collect Application et Profile All functions.
On clique ensuite sur l’horloge pour valider le profiling.
Puis on utilise la Menu Profile  Viewer
Dès lors, on doit faire apparaitre la fenêtre de
visualisation.
On ne s’intéresse qu’aux fonctions <dotp> et
<main>, on supprime les autres fonctions
On fait apparaitre les mesures <Incl min>, <Incl
max>, <Incl average> en utilisant l’onglet
Columns and Rows Setting

On place un point d’arrêt dans le code avant d’exécuter le code :

On exécute le programme, et on examine les résultats affichés sur le Profile :

Réponses
1. La différence de temps est dû aux nombres d’accès mémoire, parce que les données
doivent être récupérés pour effectuer le calcul, et déjà on avait des données qui se
répètent c’est pour cela qu’il y’a une différence entre le min et le max.

2. Le nombre minimal est important parce que l’appel à la fonction se fait 2 fois, ainsi on
aura un double du nombre d’accès à la mémoire

4. Optimisation
 L’opération d’optimisation permettra de réduire le nombre des cycles d’horloge
que le code nécessite pour pouvoir s’exécuter.
 On accède au menu Project  Configuration et puis on sélectionne le mode
Release et on clique sur le bouton <Set Active>.
 On recompile et recharge le programme, et on l’exécute par la touche F5.
 Dans ce mode, on ne peut plus observer les temps d’exécution. Il faut donc créer
un mode intermédiaire par le Menu : <Project  Configuration  Add>
 On nomme notre nouvelle configuration Optimize et on la rend active.
 On recompile le programme, et on ferme le profile courant et on ouvre une
nouvelle session pour voir les modifications, on exécute alors le programme.

Réponses
1. Les nouveaux temps d’exécution du programme :

2. Le temps minimum diminue parce qu’on a changé le mode normal en mode Optimisé,
c’est-à-dire on a optimisé le nombre d’accès mémoire, ainsi on a réduit le nombre de
cycles d’horloge nécessaire pour faire l’exécution du code
3. On consulte le code assembleur de notre code, et plus précisément la fonction dotp, on
obtient ceci :
En analysant le code assembleur, on regarde exactement les instructions que fait notre fonction
en C (Récupération de valeur, addition et multiplication) tout en manipulant les différents cœurs
de notre DSP.
Maintenant on va modifier le code pour mesurer les performances en flottant. Pour cela, on
change le type de retour de la fonction dotp par float. En reconstruisant le code on refait les
mesures, Les nouvelles valeurs max et min sont :

Afin d’améliorer la vitesse de ce code, on peut aligner les données en ajoutant les deux lignes
suivantes au début du code :
#pragma DATA_ALIGN(a,8)
#pragma DATA_ALIGN(x,8)
En regardant les valeurs Max et Min on constate que ça a diminué :

5. On peut conclure que l’utilisation du pragma DATA_ALIGN() a permis d’optimiser le code,


et de réduire ainsi le nombre de cycles d’horloge. La ligne #pragma DATA_ALIGN(a,8) permet
d’aligner a de façon à être divisible par 8, comme ça l’accès et la manipulation de données sera
plus simple, la chose qui a entrainé la diminution des cycles d’horloge nécessaire pour la fonction
dotp et pour le code C complet en général.
6. Le mot clé volatile pour une variable signifie qu’y accéder est un effet de bord. Cela veut
dire que même une lecture peut changer son état ou d’une autre partie du programme. Ou
autrement dit, une variable volatile peut changer de valeur ou provoquer le changement de valeur
d’autres variables par des moyens inconnus par le compilateur, cela permet d’éviter certaines
optimisations du compilateur

5. Optimisation

Manipulation 2 : Mixage entre le code C et l’assembleur sur DSP


Le but de cette partie c’est de mixer le Code C avec l’assembleur, en écrivant une fonction en
assembleur, et en faisant appel à cette dernière depuis le code C.
Le résultat sera sans doute une optimisation du nombre de cycles d’horloge.
Le premier exemple sera de calculer la somme des n + (n-1) + (n-2) + …. + 1, on commence par
écrire le code C dans un fichier source .c qu’on ajoutera au projet, ensuite on ajoute un code
.asm de la même façon.

Fichier .c comme code Fichier .asm décrivant la


principal contenant l’appel fonction sumfunc(short),
de la fonction à développer en utilisant l’addition avec
en assembleur le cœur L1, on a utilisé le
reg A4 pour le passage des
variables du code C en
ASM, et du reg B3 pour le
passage de l’ASM vers C

On compile et exécute le code, on peut voir le résultat en utilisant le Watch :

Le temps d’exécution du code et de la fonction assembleur :

On réalise le code complètement en C et on mesure les performances, on obtient :

On peut conclure que dans le cas d’un appel d’une fonction et de l’intégration du codage
assembleur dans le code C, on a réduit le temps d’exécution du code, cela est dû au fait que le
codage en assembleur permet de bien gérer les opérations à effectuer et d’optimiser la
consommation de la mémoire.

Manipulation 4 : Calcul de la factorielle d’un nombre


Fichier .asm décrivant la
fonction factoriel(short),
en utilisant la
multiplication avec le
Fichier .c comme code cœur M1, avec
principal contenant l’appel l’instruction MPY au lieu
de la fonction à développer de ADD. On a utilisé le reg
en assembleur. A4 pour le passage des
variables du code C en
ASM, et du reg B3 pour le
passage de l’ASM vers C

On compile et exécute le code, on peut voir le résultat en utilisant le Watch :

Le temps d’exécution du code et de la fonction assembleur :

On réalise le code complètement en C et on mesure les performances, on obtient :


De même on trouve que le temps d’exécution dans le cas du mixage est moins que celui du codage
en C seulement

Vous aimerez peut-être aussi