head	1.1;
access;
symbols
	bg2_23:1.1
	bg2_22:1.1
	bg2_21:1.1
	bg2_20:1.1
	bg2_16:1.1
	bg2_15:1.1
	bg2_12:1.1
	bg2_07:1.1
	isorc2008_submission:1.1
	handbook_alpha_edition:1.1;
locks; strict;
comment	@% @;


1.1
date	2007.08.25.18.00.53;	author martin;	state Exp;
branches;
next	;
commitid	e5e46d06e544567;


desc
@@


1.1
log
@Handbook update
@
text
@\section{Interrupts}
\label{sec:interrupt}

This is a working document for changes in the interrupt system. That
means extending the simple timer interrupt and exception interrupt
system to a full interrupt controller including inter-processor
interrupts.

see page 8-41 of Intel document for interrupt handling with priority
and EOI signalling.

Questions:
\begin{itemize}
    \item Do we need interrupts within interrupts for our RT based
    interrupt system? I don't think so -- than interrupt priority
    classes and enabling is not an issue
    \item Shall we try to avoid a new interrupt shortly after EOI
    signalling (stack issue)?
    \item Do we need an ack signal to the peripheral device? I don't
    think so
\end{itemize}

BTW: restricting interarrival time in HW is not that new --
Wikipedia talks about it ;-)

Also IA-32e mode can specify task priorities that disable classes of
interrupts.

Check also:
\begin{itemize}
    \item LEON/SPARC docu
    \item NIOS docu
    \item MicroBlaze? ARM?
\end{itemize}

\subsection{Current State}

describe what is function of the current interrupt system (including
VHDL and Java source)
@