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