Changes between Version 16 and Version 17 of SoclibCourseTp1

Timestamp:

Sep 1, 2009, 6:46:55 PM (15 years ago)

Author:

alain

Comment:

--

SoclibCourseTp1

@@ -133 +133 @@
 
 Comme pour tout modèle CABA SoCLib, les variables membres de la classe `FifoLcdCoprocessor` sont de trois types :
- * '''ports''' : les variables membres représentant les ports d'entrée sortie sont de type ''sc_core::sc_in'' ou ''sc_core::sc_out'',
-ou des objets plus complexe (possédant éventuellement un paramètre template) représentant des regroupements de plusieurs ports élémentaires : c'est la cas des types `soclib::caba::FifoOutput<typename>` et `soclib::caba::FifoInput<typename>` utilisés pour accéder à un cana FIFO. Pour des raisons de lisibilité, il est recommandé que les noms de registre soient préfixé par '''p_'''. On définira 2 ports simples (''p_ck'', ''p_resetn''), et deux ports FIFO (''p_in'' et ''p_out''). Ce sont évidemment des variables publiques.
+ * '''ports''' : les variables membres représentant les ports d'entrée sortie sont de type ''sc_core::sc_in'' ou ''sc_core::sc_out'', ou des objets plus complexe (possédant éventuellement un paramètre template) représentant des regroupements de plusieurs ports élémentaires : c'est la cas des types `soclib::caba::FifoOutput<typename>` et `soclib::caba::FifoInput<typename>` utilisés pour accéder à un cana FIFO. Pour des raisons de lisibilité, il est recommandé que les noms de registre soient préfixé par '''p_'''. On définira 2 ports simples (''p_ck'', ''p_resetn''), et deux ports FIFO (''p_in'' et ''p_out''). Ce sont évidemment des variables publiques.
 * '''registres''' : les variables membres représentant les registres sont de type ''sc_core::sc_signal''. Pour des raisons de lisibilité, il est recommandé que les noms de registre soient préfixé par '''r_'''. On définira trois registres ''r_fsm'', ''r_opa'' et ''r_opb''. Ce sont des variables privées.
  * '''constantes''' : ces variables membres sont en fait des constantes permettant de stocker les valeurs des paramètres définis comme arguments du constructeur pour les composants matériels génériques. Ces variables membres sont initialisées dans le constructeur, et leur valeur reste constante au cours de la simulation.  Pour des raisons de lisibilité, il est recommandé que les noms de constantes soient préfixé par '''m_'''. Ces variables sont toujours privées.  Le coprocesseur n'étant pas paramètrable, on ne définira aucune variable de ce type.
@@ -155 +154 @@
 Il faut lancer la commande suivante dans votre répertoire de travail TP1 :
 {{{
-$ g++ -Wno-deprecated -I. -I/.../systemc/systemc-2.2/include -c -o fifo_lcd_master.o fifo_lcd_master.cpp
+$ g++ -Wno-deprecated -I. -I/users/outils/dsx/cctools/include -c -o fifo_lcd_master.o fifo_lcd_master.cpp
 }}}
 Cette commande doit créer fichier objet ''fifo_lcd_master.o dans le répertoire TP1. 
@@ -182 +181 @@
 Vous pouvez compiler ce fichier ''tp1_top.cpp'' pour générer le fichier objet correspondant en utilisant la commande:
 {{{
-$ g++ -Wno-deprecated -I. -I/users/outils/dsx/cctools/include -c -o tp1_top.o tp1_top.cpp
+$ g++ -Wno-deprecated -I. -I/users/outils/dsx/cctools/include -c -o  tp1_top.o  tp1_top.cpp
 }}}
 Cette commande doit créer fichier objet ''tp1_top.o'' dans le répertoire TP1. 
@@ -200 +199 @@
 Quelle est la duréee moyenne d'une itération?
 
+Regroupez toutes les commandes de compilation dans un fichier ''Makefile'', en explicitant les dépendances entre les fichiers.
+
 == 2.4 Simulation avec le moteur de simulation SystemCASS ==
 
-Comme cela a été expliqué en cours, le style d'écriture des modèles de simulation CABA utilisé dans SoCLib permet une simulation efficace,
-puisque dans le cas où tous les composants matériels se comportent comme des automates de Moore, les deux fonctions ''transition'' et ''genMoore'' de chaque composant sont exécutées une seule fois par cycle. Dans ces conditions, il est inutile d'utiliser un mécanisme d'ordonnancement dynamique (avec gestion d'un échéancier) comme cela est fait par le moteur de simulation disponible dans la distribution standard systemc2.2 fournie par le consortium OSCI.
-
-Le moteur de simulation SystemCASS, développé par le laboratoire LIP6, utilise une technique d'ordonnancement statique (sans échéancier) qui permet de réduire le temps de simulation d'un ordre de grandeur. Il n'est pas nécessaire de modifier le code SystemC des composants instanciés, ni le code systemC décrivant la top_cell, mais il faut recompiler l'ensemble des fichiers sources:
-
-/users/outils/dsx/systemcass/include
-/users/outils/dsx/systemcass/lib
-
+Comme cela a été expliqué en cours, le style d'écriture des modèles de simulation CABA utilisé dans SoCLib permet une simulation rapide - même en utilisant le moteur de simulation SystemC2.0 fourni par le consortium OSCI -
+puisque dans le cas où tous les composants matériels se comportent comme des automates de Moore, les deux fonctions ''transition'' et ''genMoore'' de chaque composant ne sont exécutées qu'une seule fois par cycle. 
+
+Mais il est possible de gagner un facteur 10 sur la vitesse de simulation en  utilisant le moteur de simulation SystemCASS, développé par le laboratoire LIP6, qui utilise une technique d'ordonnancement statique (sans échéancier) pour exploiter
+les caractéristiques particulières des modèles SoCLib. 
+
+Pour utiliser SystemCASS, il n'est pas nécessaire de modifier le code SystemC des composants instanciés, ni le code systemC décrivant la top_cell, mais il faut recompiler l'ensemble des fichiers sources, en modifiant les chemins d'accès aux fichiers
+d'include et aux bibliothèques de SystemC.
+
+La génération des fichiers objets utilise la commande suivante :
+{{{
+$ g++ -Wno-deprecated -I. -I/users/outils/dsx/systemcass/include -c -o filename.o filename.cpp
+}}}
+La génération de l'exécutable utilise la commande suivante :
+{{{
+$ g++ -Wno-deprecated -L. -L/users/outils/dsx/systemcass/lib -o simulator.x fifo_lcd_master.o fifo_lcd_coprocessor.o tp1_top.o -lsystemc 2>&1 | c++filt
+}}}
+Modifiez le fichier Makefile de la question précédente pour générer un exécutable fast_simulator.x et comparez les vitesses des deux simulateurs. 
+
+
+== 4. Compte-rendu ==
+
+Il ne vous est pas demandé de compte-rendu pour ce TP, mais on vous demandera une démonstration de votre simulateur
+au début du TP de la semaine suivante.
+suivant
+
+