 |
Interrupt Latency
|
Interrupt latency, sometimes called interrupt response time,
means different things to different people. Within the AMX
environment, KADAK uses the term interrupt latency to refer
to the time taken from the leading edge of an external interrupt
request signal to the processor to the fetch of the first
interrupt service instruction by the processor.
Interrupt latency consists of the sum of two components:
processor interrupt latency and software interrupt latency.
Many factors affect interrupt latency. The first is the delay
generated by the processor itself in its recognition of the
external interrupt request. This delay may be fixed for some
processors and variable for others. For RISC and superscalar
processors, the delay may range from 3 or 4 processor clock cycles
to tens or even hundreds of clock cycles.
The longest delays are usually associated with interrupt requests
which occur while the processor is executing complex instructions
which, for processor reasons, must be allowed to complete (or at
least reach some internal state at which the instruction can be
resumed) before the interrupt request can be acknowledged.
Multiply and divide are instructions of this type, as are looping
instructions such as block moves and string compares.
Additional delay may stem from instruction and or data caching
operations. Response will be faster if the interrupt service
instructions happen to already be in the cache as a consequence
of a previous interrupt.
Since the processor's interrupt response always requires the
saving of some processor state information, the processor architecture
can dramatically affect latency. Expect longer delays if the
processor automatically saves some or all registers or switches
to alternate register sets. The delays will be even longer
if the saving is done to memory.
Most processors permit some or all internal and/or external
device interrupts to be inhibited under software control.
The longest interval for which any software module disables
interrupts is called software latency.
Some, but not all, AMX kernels use this feature from
time to time to briefly inhibit all interrupt sources while
executing some critical section of code. The longest interval
for which AMX disables interrupts is called the
AMX interrupt latency. For the AMX kernels which do not
disable interrupts during critical sections of code, the AMX
interrupt latency will be 0.
KADAK has identified and measured the worst case (longest)
intervals during which AMX inhibits interrupts. AMX interrupt
latency measurements are provided on separate AMX timing data sheets.
Of equal importance to interrupt latency is what KADAK calls
handler latency, the time from the processor's first response
to an interrupt request signal through to the first useful
instruction in the interrupt service procedure.
The term useful is nebulous but can be characterized as follows.
Useful instructions are those which deal with the interrupting device
and its related application. Useful instructions can not usually be
executed until a few processor registers have been saved freeing
them for use. In some cases, a switch to an alternate stack
may be necessary. Once these housekeeping operations have been
completed, useful work can be accomplished.
Handler latency is therefore the sum of the processor latency and
the housekeeping execution time. Software latency must then be added
to the handler latency to give a worst case scenario.
| 
