summaryrefslogtreecommitdiff
path: root/2004/n/fpga/doc/dcd/interrupt/interrupt.tex
blob: a4adce708017012fbe09a1d7bf9e4b0fc0c22b09 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
\subsection{Cahier des charges}

Voici les contraintes du bloc de gestion des interruptions :

\begin{itemize}
\item{Gestion de 24 interruptions diff�rentes}
\item{Transmission des interruptions par bloc de 8 bits}
\end{itemize}


% en gros c'est comment est vu le module c�t� userland.
\subsection{Vue comportementale}

Le bloc de gestion des interruptions a pour but de permettre aux diff�rents
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}.

\begin{figure}[htbp]
\caption{Entity du bloc de gestion des interruptions}
\begin{center}
\scalebox{0.7}{
\includegraphics {./interrupt/images/entity.pdf}
%\includegraphics[width=\textwidth]{./interrupt/images/entity.pdf}
}
\end{center}
\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
l'ordinateur 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.

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'interruptions. 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.

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 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}

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}
\begin{center}
%\scalebox{0.7}{\includegraphics {./interrupt/images/archi_phy.pdf}}
\includegraphics[width=\textwidth]{./interrupt/images/archi_phy.pdf}
\end{center}
\label{archi_interrupt}
\end{figure}


Comme on peut le constater, ce module est tr�s simple. En effet, celui-ci est
compos� uniquement de 3 bloc OR � huit entr�es, d'un bloc OR � trois entr�es
et de 3 bloc three-state � huits entr�es chacun.

Son fonctionnement interne est donc le suivant. Lorsqu'une interruption arrive
sur un des blocs, un signal IRQ est g�n�r� par les blocs OR. Lorsque le PC
d�sire consulter qui a g�n�r� une interruption, il active successivement les
blocs three-state qui passent alors d'un �tat haute-imp�dance � un �tat dans
lequel sont recopi�es en sortie les entr�es.


\subsection{D�composition RTL}

% Ici, d�tailler chaque petit bloc et mettre le code VHDL correspondant.
\subsubsection{Les blocs OU logiques : OR3 et OR8}

Ces deux blocs sont relativement simples puisque leur seule fonction est
d'effectuer des OU logiques. La premi�re version effectue un OU entre trois
entr�es, la deuxi�me version entre 8 entr�es.

Le code correspondant au bloc OR3 se trouve en annexe~\ref{sec:or3}
page~\pageref{sec:or3}.

Le code correspondant au bloc OR8 se trouve en annexe~\ref{sec:or8}
page~\pageref{sec:or8}.

\subsubsection{Le bloc trois-�tats : tristate}

Dans ce module, nous avons besoin de pouvoir �crire des donn�es sur un bus.
Pour cela, il faut que l'on puisse mettre les pattes � l'�tat haute-imp�dance
lorsqu'un autre composant d�sire �crire sur le bus. Un composant nomm�
\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 est � un �tat bas, les sorties sont dans un �tat
haute-imp�dance (not� 'Z')}
\item{Si enable est � l'�tat haut, on recopie les entr�es / sorties sur le bus
de donn�es}
\end{itemize}

Le code correspondant au bloc d�crit pr�c�dement se trouve en
annexe~\ref{sec:tristate} page~\pageref{sec:tristate}.

% TODO : relecture � partir de ici !
\subsubsection{Le gestionnaire d'interruptions : interrupt}

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. Voici l'entity de ce bloc :

\begin{itemize}
\item{24 signaux d'interruptions entrantes}
\item{8 signaux associ�s au bus de donn�es}
\item{3 signaux pour acc�der aux diff�rents registres}
\item{1 signal IRQ}
\end{itemize}

Ce bloc est donc l'assemblage des diff�rents modules qui viennent d'�tre
d�crits. Le listing correspondant � ce module est donn�
annexe~\ref{sec:interrupt} page~\pageref{sec:interrupt}.


\subsection{R�sultats de synth�se logique}

Ci dessous sont pr�sent�es un r�sum� des informations fournies suite � la
synth�se logique du module.

\lstinputlisting{./interrupt/res_interrupt.syr}

On peut donc constater que les ressources qui seront utilis�es par le module
de gestion des interruptions sont faibles compar�es aux capacit�s du FPGA
choisi, � savoir, un Spartan2 xc2s200 avec un boitier pq208. 

Ces caract�ristiques nous conviennent parfaitement au vu des ressources
utilis�es par les autres modules. 

\subsection{Simulation}

Les r�sultats de la simulation RTL de notre bloc de gestion des interruptions
sont sur la figure \ref{interrupt_route} page \pageref{interrupt_route}. On
pourra v�rifier que celle-ci est bien conforme aux r�sultats escompt�s. 

\begin{figure}[htbp]
\begin{center}
\includegraphics[height=\textheight]{./interrupt/sim/interrupt_route.pdf}
\end{center}
\label{interrupt_route}
\end{figure}

Apr�s cette synth�se, nous avons programm� une carte de test pour v�rifier
qu'il n'y ai pas d'anomalie et nous avons pu constater que tout se d�roulait
comme pr�vu ! Pour cela, nous avons utilis� les leds et switchs inclus sur la
carte de test.