Changes between Version 49 and Version 50 of SoclibCourseTp1

Timestamp:

Nov 23, 2012, 11:37:06 AM (12 years ago)

Author:

alain

Comment:

--

SoclibCourseTp1

@@ -59 +59 @@
 }
 }}} 
-Le chemin de donnée permettant de réaliser ce calcul doit donc comporter deux registres r_opa et r_opb pour stocker 
+Le chemin de donnée (matériel) 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 de sortie.
 
-Finalement, l'automate qui contrôle le composant `fifo_gcd_coprocesseur` exécute un boucle infinie, dans laquelle il effectue successivement les 4 opérations suivantes:
+Finalement, l'automate (matériel) qui contrôle le composant `fifo_gcd_coprocesseur` exécute un boucle infinie, dans laquelle il effectue successivement les 4 opérations suivantes:
 
  1. lecture de l'opérande A sur son port FIFO d'entrée
@@ -77 +77 @@
 [[Image(soclib_tp1_coprocessor.png)]]
 
-Outre le registre d'état de l'automate ''r_fsm'', cet automate contrôle donc deux autres registres ''r_opa'' et ''r_opb''
+Outre le registre d'état de l'automate ''r_fsm'', cet automate contrôle donc les écritures dans 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). 
@@ -86 +86 @@
  == 2.3 Composant ''fifo_gcd_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 composant matériel effectue le travail normalement effectué par le logiciel s'exécutant sur un processeur programmable, consistant à définir les valeurs des deux opérandes, à transmettre ces valeurs 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 les TPs suivants, mais dans ce premier TP, on se contente d'utiliser un ''automate cablé'', qui exécute en boucle le programme suivant:
  1. génération  (pseudo-aléatoire) de deux valeurs OPA et OPB. 
@@ -136 +136 @@
 
 Comme pour tout modèle CABA SoCLib, les variables membres de la classe `FifoGcdCoprocessor` 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 des ports soient préfixés 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 canal FIFO. Pour des raisons de lisibilité, il est recommandé que les noms des ports soient préfixés 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 des registres 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 des 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.
+ * '''constantes''' : ces variables membres sont en fait des constantes permettant de stocker les valeurs des paramètres structurels 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 des 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.
 
 Le constructeur du coprocesseur GCD ne possède qu'un seul argument, qui est le nom d'instance (on a besoin d'un nom d'instance, car il est possible d'avoir plusieurs instances du même coprocesseur dans une architecture).  Ce nom d'instance est de type ''sc_core::sc_module_name'', et il est stoké dans une variable membre de la classe ''sc_module'', qui est une classe générique dont héritent tous les modèles de composant SoCLib.