summaryrefslogtreecommitdiff
path: root/2004
diff options
context:
space:
mode:
authorgalmes2004-04-08 20:21:57 +0000
committergalmes2004-04-08 20:21:57 +0000
commitdf93377dbedf2df555bc2467b9b281c70daf0c6f (patch)
treeb4c61631f1bbab2bf7ef2d7474c6a4dc37a9eee8 /2004
parent080a334584e1ecd3f3ad82c74bf2ee54a8ce11e4 (diff)
Gpio doc : ajout des entity des différents modules.
interrupt doc : Continue la doc...
Diffstat (limited to '2004')
-rw-r--r--2004/n/fpga/doc/dcd/gpio/gpio.tex65
-rw-r--r--2004/n/fpga/doc/dcd/interrupt/interrupt.tex41
2 files changed, 72 insertions, 34 deletions
diff --git a/2004/n/fpga/doc/dcd/gpio/gpio.tex b/2004/n/fpga/doc/dcd/gpio/gpio.tex
index 257d225..22f6856 100644
--- a/2004/n/fpga/doc/dcd/gpio/gpio.tex
+++ b/2004/n/fpga/doc/dcd/gpio/gpio.tex
@@ -220,7 +220,16 @@ Commençons par décrire le fonctionnement du registre synchrone nommé
Comme les registres standards, il possède une horloge, un signal de
remise-à-zéro, un signal enable, des entrées au nombre de 8 et des sorties au
nombre de 8 également. Par contre, celui-ci a un signal supplémentaire : le
-signal Read / Write ($R\bar{W}$).
+signal Read / Write ($R\bar{W}$). Son entity est donc la suivante :
+
+\begin{itemize}
+\item{1 signal d'horloge}
+\item{1 signal de remise-à-zéro}
+\item{8 signaux d'entrée}
+\item{8 signaux de sortie}
+\item{1 signal enable}
+\item{1 signal read / write}
+\end{itemize}
L'intérêt de ce registre par rapport à un registre "normal" est de pouvoir
relire son contenu. Cela est utile dans notre cas puisque durant le
@@ -249,8 +258,16 @@ Si dessous se trouve le code correspondant au registre décrit précédement.
\subsubsection{Le bloc trois-états : tristate}
Pour la lecture des valeurs sur les entrées / sorties, un composant nommé
-\textit{tristate} est utilisé. Ce composant est en fait un module asynchrone
-composé de huits composants trois états. Son comportement est donc le suivant :
+\textit{tristate} est utilisé. L'entity de ce module est la suivante :
+
+\begin{itemize}
+\item{8 signaux d'entrée}
+\item{8 signaux de sortie}
+\item{1 signal enable}
+\end{itemize}
+
+Ce composant est en fait un module asynchrone composé de huits composants
+trois états. Son comportement est donc le suivant :
\begin{itemize}
\item{Si enable (représenté par cs\_read\_output sur le schéma) est à un état
@@ -268,7 +285,13 @@ Le listing de ce composant est le suivant :
Lors de la conception du cahier des charges du bloc du module GPIO, nous
avions bien spécifié le fait que chaque pins devait être configurable soit en
-entrée, soit en sortie. C'est le rôle de ce bloc.
+entrée, soit en sortie. C'est le rôle de ce bloc. Son entity est la suivante :
+
+\begin{itemize}
+\item{8 signaux d'entrée}
+\item{8 signaux de constituant un masque}
+\item{8 signaux de sortie}
+\end{itemize}
Celui ci fonctionne donc de la manière suivante. Pour ce faire, celui-ci
possède deux "bus" de 8 entrées chacun. Le premier de ces bus est destiné au
@@ -285,14 +308,20 @@ correspondant au gestionnaire de direction.
\lstinputlisting{../../src/gpio/gpio_direction.vhd}
-% TODO : continuer icicicicicicicicici
-
-\subsubsection{Les gestionnaires d'interruptions : gpio\_it\_detect\_up et
-gpio\_it\_detect\_down}
+\subsubsection{La détection d'interruptions : gpio\_it\_detect\_up et down}
Le but de ces deux modules est de générer les interruptions. Le premier est
chargé de générer une interruptions si il y a un front motant. Le deuxième
-fait la même chose, mais pour les fronts descendants.
+fait la même chose, mais pour les fronts descendants. Les entity de ces deux
+blocs sont identiques et sont :
+
+\begin{itemize}
+\item{1 signal d'horloge}
+\item{1 signal de remise-à-zéro}
+\item{8 signaux d'entrée}
+\item{8 signaux de constituant un masque}
+\item{1 signal de sortie (interrupt detected)}
+\end{itemize}
Chacune des 8 pins devant être configurable pour déclencher une interruption
ou non, nous avons recours à des masques. Chaque gestionnaire à son propre
@@ -313,9 +342,21 @@ Voici le code associé au gestionnaire d'interruption sur front descendant.
Ce bloc est celui dont le comportement aura été décrit précédement dans les
sections en rapport avec l'architecture physique. On pourra d'ailleurs se
-rapporter aux différents schémas précédement vus. Ce bloc est donc
-l'assemblage des différents modules qui viennent d'être décrits. Ci-dessous,
-se trouve le listing correspondant à ce module.
+rapporter aux différents schémas précédement vus. Voici l'entity de ce bloc :
+
+\begin{itemize}
+\item{1 signal d'horloge}
+\item{1 signal d'horloge de bus}
+\item{1 signal de remise-à-zéro}
+\item{1 signal read / write}
+\item{1 signal d'interruption}
+\item{8 signaux associés au bus de données}
+\item{4 signaux pour accéder aux différents registres}
+\item{1 signal pour lire les valeurs sur les entrées / sorties}
+\end{itemize}
+
+Ce bloc est donc l'assemblage des différents modules qui viennent d'être
+décrits. Ci-dessous, se trouve le listing correspondant à ce module.
\lstinputlisting{../../src/gpio/gpio.vhd}
diff --git a/2004/n/fpga/doc/dcd/interrupt/interrupt.tex b/2004/n/fpga/doc/dcd/interrupt/interrupt.tex
index b7dc521..826aa60 100644
--- a/2004/n/fpga/doc/dcd/interrupt/interrupt.tex
+++ b/2004/n/fpga/doc/dcd/interrupt/interrupt.tex
@@ -17,8 +17,6 @@ modules de la carte de prévenir l'ordinateur qu'ils ont des informations à
lui transmettre. On pourra voir la figure \ref{entity_interrupt} page
\pageref{entity_interrupt}.
-% TODO : modifier suivant qu'on insère la caméra ou pas.
-% enlever les clk et le rst, ar bloc que combinatoire.
\begin{figure}[htbp]
\caption{Entity du bloc de gestion des interruptions}
\begin{center}
@@ -30,39 +28,40 @@ lui transmettre. On pourra voir la figure \ref{entity_interrupt} page
\label{entity_interrupt}
\end{figure}
+Du point de vue comportemental, son fonctionnement est le suivant. Dans le
+fonctionnement d'un robot, nombre d'évênements sont asynchrones. Pour signaler
+qu'un évênement s'est produit, le module génêre ce que l'on appel une
+interruption. Le gestionnaire d'interruption aura pour but de prévenir qu'une
+ou plusieurs interruptions se sont produitent et de permettre à l'ordinateur
+d'identifier les modules ayant généré cette ou ces interruptions.
-% TODO : Question
-%
-% TODO : Si garde 2 fils, changer entity.fig
-% Si garde 1 fils, changer schéma global (toute la carte fpga)
-% changer archi_phy.fig
-
+Chaque bloc ayant un fil d'interruption le relie au gestionnaire
+d'interruption. Lorsqu'un bloc génère une interruption, celle-ci arrive au
+gestionnaire d'interruption. Pour la générer, le bloc aura mis une ligne à
+l'état haut et conservera cet état haut, tant que l'ordinateur n'aura pas
+traité la dite interruption.
-Du point de vue comportemental, son fonctionnement est le suivant. Chaque bloc
-ayant un fil d'interruption le relie au gestionnaire d'interruption.
Lorsqu'une interruption est émise par un bloc, notre module la détecte et
transmet le signal IRQ sur le bus ISA. Dès que l'ordinateur est prêt à traiter
l'interruption, il demande à accéder au gestionnaire.
Pour cela, il va lire successivement trois registres. Chaque registre est
représenté par une addresse différente. Chacun de ces registres contient un
-masque. Les bits de ce masque signalent si un bloc a généré une interruption
+masque. Les bits de ces masques signalent si un bloc a généré une interruption
ou non. En retour à chaque demande du PC, le gestionnaire placera sur le bus de
données le masque correspondant.
-
+Une fois les trois masques obtenus, l'ordinateur pourra alors déterminer quels
+sont les différents modules a avoir émis des interruptions et choisir qui il
+voudra traiter de manière prioritaire.
% Ici, on détail l'intérieur du bloc
\subsection{Architecture physique}
% Pipo
-Voici donc une explication du fonctionnement de ce gestionnaire. On remarquera
-que ce bloc est crucial, car la perte d'une interruption peut résulter en une
-perte de temps, voir s'avérer désastreuse pour le robot. Il est donc
-nécessaire de prendre les plus grandes précautions lors de sa réalisation. On
-pourra consulter l'architecture physique sur la figure \ref{archi_interrupt}
-page \pageref{archi_interrupt}. Pour le séquenceur, son graphcet est illustré
-figure \ref{graphcet_interrupt} page \pageref{graphcet_interrupt}.
+Voici donc une explication du fonctionnement de ce gestionnaire. On pourra
+consulter l'architecture physique sur la figure \ref{archi_interrupt} page
+\pageref{archi_interrupt}.
\begin{figure}[htbp]
\caption{Architecture physique du bloc de gestion des interruptions}
@@ -73,9 +72,7 @@ figure \ref{graphcet_interrupt} page \pageref{graphcet_interrupt}.
\label{archi_interrupt}
\end{figure}
-%
-Lorsqu'un bloc génère une interruption, celle-ci arrive sur le gestionnaire
-d'interruption.
+%
% Fonctionnement du bloc d'interface ISA
Lorsque ce signal arrive, le séquenceur prévient le \textbf{module