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

\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 est présenté 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'anomalies 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.
