From abc842ae6d7f4907629dfd53f53d84c1122eb52a Mon Sep 17 00:00:00 2001
From: galmes
Date: Mon, 23 Feb 2004 13:46:15 +0000
Subject: Ajout de la doc que Pedro a pondu pendant les vacances

---
 2004/n/fpga/doc/dcd/interrupt/interrupt.tex | 188 ++++++++++++++++++++++++++++
 1 file changed, 188 insertions(+)
 create mode 100644 2004/n/fpga/doc/dcd/interrupt/interrupt.tex

(limited to '2004/n/fpga/doc/dcd/interrupt/interrupt.tex')

diff --git a/2004/n/fpga/doc/dcd/interrupt/interrupt.tex b/2004/n/fpga/doc/dcd/interrupt/interrupt.tex
new file mode 100644
index 0000000..2c162a3
--- /dev/null
+++ b/2004/n/fpga/doc/dcd/interrupt/interrupt.tex
@@ -0,0 +1,188 @@
+\subsection{Cahier des charges}
+
+Voici les contraintes du bloc de gestion des interruptions :
+
+\begin{itemize}
+\item{Gestion de 24 interruptions différentes}
+\item{3 niveaux de priorité}
+\item{Fréquence de fonctionnement à XXXX} % TODO : fq du bus ISA
+\item{Codage de l'addresse du bloc sur 10 bits}
+\item{Un signal de RAZ}
+\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}
+
+
+% TODO : Question
+% Est-ce que pour les lignes d'interruption on ne devrait pas juste
+% laisser une ligne IRQ et traiter en interne les priorités ? En effet, la
+% seule choses que voit l'ordinateur est qu'il y a une interruption. Pour la
+% priorité de celle-ci, il en a rien à foutre non ?
+%
+% Ou ça peut-être intéressant pour lui pour savoir si il y réagit de suite ou
+% si il peut continuer ce qu'il est en train de faire.
+%
+% TODO : Si garde 2 fils, changer entity.fig
+%	 Si garde 1 fils, changer schéma global (toute la carte fpga)
+%	 		  changer archi_phy.fig
+
+On rappel que chaque bloc ayant un fil d'interruption le relie au gestionnaire
+d'interruption. Suivant l'emplacement choisi, le module aura une priorité plus
+ou moins importante, sachant que la priorité de niveau 1 est la plus
+importante.
+
+Du point de vue comportemental, son fonctionnement est le suivant. 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 en transmettant
+l'addresse du gestionnaire sur le bus ISA.
+
+En retour, le gestionnairerecopie une sorte de "masque d'interruption"
+représentant quel a ou quels ont été les blocs ayant émis les interruptions de
+plus haut niveau. Dès que l'ordinateur a effectué une lecture des données, il
+le signal à l'aide du signal d'acquittement. Le gestionnaire repasse en mode
+d'attente des interruptions suivantes.
+interruptions suivante
+
+% Ici, on détail l'intérieur du bloc
+\subsection{Architecture physique}
+
+% Pipo
+Voici donc une explication du fonctionnement de ce bloc. 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}.
+
+\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}
+
+\begin{figure}[htbp]
+\caption{Graphcet du séquenceur du bloc de gestion des interruptions}
+\begin{center}
+\scalebox{0.7}{\includegraphics {./interrupt/images/graphcet.pdf}}
+%\includegraphics[width=\textwidth]{./interrupt/images/graphcet.pdf}}
+\end{center}
+\label{graphcet_interrupt}
+\end{figure}
+
+% 
+Lorsqu'un bloc génère une interruption, celle-ci arrive sur le
+\textbf{détecteur d'interruptions} ou ID associé à son niveau de priorité. Ces
+niveaux de priorité son au nombre de 3, le niveau 1 étant la priorité maximale
+et 3 la minimale.
+
+% Fonctionnement du bloc ID.
+Cet ID envoie alors le signal \textit{Interrupt detected} au module
+\textbf{Priority choice}. De plus, cet ID met un état haut en sortie sur le
+bit correspondant et le conserve tant qu'il n'a pas reçu de signal de reset.
+
+% Fonctionnement du bloc Priority choice.
+C'est au tour du module \textbf{Priority choice} d'agir. Celui-ci, à la
+réception du signal identifie à quel niveau de priorité il est associé et
+prévient le séquenceur de l'arrivée d'une interruption. Il attend alors la
+réponse du séquenceur. 
+
+Dès que ce signal (nommé \textit{enChoice}) arrive, l'addresse de l'ID ayant
+émis ce signal est codée en sortie sur deux bits. C'est le signal appelé IRQ0
+et IRQ1. Si plusieurs interruptions sont arrivées simultanément, le module
+choisira celle de priorité la plus haute.
+
+% TODO : Question 
+% pour le bloc priority choice, je peux soit le faire à base de graphcet
+% (machine de Moore), soit en concurentiel. Pour l'instant, je serai bien
+% partant pour le faire en concurentiel, mais ce choix est fait juste car cela
+% me semble plus simple pour l'instant.
+%
+% Le seul probl_me est que je ne sait pas si ce sera synthétisable...
+% D'ailleurs, comment sait-on qu'un bloc sera synthétisable ?
+% Une idée pour orienter ce choix ?
+
+% Le MUX
+Le \textbf{multiplexeur} choisi alors l'ID dont l'addresse lui a été transmise
+par l'IRQ. et la recopie sur sa sortie. Le \textbf{séquenceur} récupère alors
+la main et demande au registre de mémoriser la sortie du multiplexeur. Cette
+opération s'effectue grâce au signal \textit{enRegID}.
+
+Cette mémorisation permet de prendre un "instantané" de l'état de l'ID
+traité. Cela est une précaution dans les cas ou plusieurs interruptions
+arrivent sur le même bloc pendant que l'on traite la première interruption.
+
+Une fois la mémorisation effectuée, on peut alors remettre l'ID à zéro et le
+laisser intercepter les interruptions suivantes. Simultanément, on écrit sur
+le bus ISA que l'on a reçu au moins une interruption. Ceci est effectué à
+l'aide d'un registre et des lignes IRQ0 et IRQ1. Les deux dernières actions
+décrites sont effectuées grâce au signal \textit{enRegIRQ} que l'on pourra
+trouver aussi sou le nom \textit{RstID}.
+
+Le séquenceur attend alors que l'ordinateur demande une lecture. Pour
+effectuer cette lecture, l'ordinateur doit mettre sur le bus d'addresse
+l'addresse du bloc de gestion des interruptions. 
+
+% Fonctionnement du bloc d'interface ISA
+Lorsque ce signal arrive, le séquenceur prévient le \textbf{module
+d'interfaçage} avec le bus ISA. Ce module, qui jusqu'à présent avait ses
+sorties à l'état haut, recopie alors sur en sorties (sur le bus ISA) ses
+entrées. On attend alors plus que l'\textit{acquittement} de l'ordinateur pour
+recommencer le cycle.
+
+
+% TODO : mettre en forme. Pour l'instant, c'est brouillon
+% Ici, je vais finir de mettre des explications demain. Là je vais dormir :)
+
+% TODO : Ça, en fait, je vais inclure un module pour gérer les 3 cycles
+% d'horloge dans mon bloc !
+
+\textit{Remarque 1 :} On remarquera premièrement que pour que l'on ai pas de
+perte d'interruptions pendant le traitement 
+
+En effet, si une interruption arrive...
+
+Pour générer une interruption, on
+doit produire un front montant et garder un état haut pendant 3 cycles
+d'horloge.
+
+Rq : si 2 interruptions arrivent simultanément sur le même ID, on les transmet
+toutes les deux lorsque l'on recopie sur le bus ISA le registre contenant les
+interruptions détectées.
+
+Si un bloc a pas de réponses, il reposte son interruption. Est-ce possible ?
+
+Séquenceur teste les registres successivement, dès qu'il voit que l'un 
+de ceux-ci n'est plus égale à x"00", il modifie l'IRQ en conséquence.
+
+
+\subsection{Décomposition RTL}
+
+% Ici, détailler chaque petit bloc et mettre le code VHDL correspondant.
+
+\subsection{Simulation}
+
+% mettre aussi peut-être les tests unitaires de chaque bloc ?
-- 
cgit v1.2.3

