| Register | Name | Register Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | status| status
controls the state of the Nios II processor
| 1 | estatus | holds a copy of the status register during
non-break exception processing.
| 2 | bstatus | holds a copy of the status register during
break exception processing.
| 3 | ienable | Interrupt-enable bits (see ienable)
| 4 | ipending | Pending-interrupt bits (see ipending
| |
| Bits | Field | Description | ||||||
|---|---|---|---|---|---|---|---|---|
| 31:3 | Reserved | |||||||
| 2 | EH| EH is the exception handler bit. The processor sets EH to one when
an exception occurs (including breaks). Software clears EH to zero
when ready to handle exceptions again. EH is used by the MMU to
determine whether a TLB miss exception is a fast TLB miss or a
double TLB miss. In systems without an MMU, EH is always zero.
| 1 | U | U is the user mode bit. When U = 1, the processor operates in user
mode. When U = 0, the processor operates in supervisor mode. In
systems without an MMU, U is always zero.
| 0 | PIE | PIE is the processor interrupt-enable bit. When PIE = 0, interrupts
are ignored. When PIE = 1, interrupts can be taken, depending on
the value of the ienable register.
| |
The ienable register controls the handling of external hardware interrupts. Each bit of the ienable register corresponds to one of the interrupt inputs, irq0 through irq31. A value of one in bit n means that the corresponding irqn interrupt is enabled; a bit value of zero means that the corresponding interrupt is disabled. See “Exception Processing” on page 3–34 for more information.
The value of the ipending register indicates the value of the interrupt signals driven into the processor. A value of one in bit n means that the corresponding irqn input is asserted. Writing a value to the ipending register has no effect.
| Instruction | Description | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| trap eret The trap and eret instructions generate and return from exceptions. These instructions are
similar to the call/ret pair, but are used for exceptions.
trap saves the status register in
the estatus register, saves the return address in the
ea register, and then transfers execution
to the general exception handler. eret returns from
exception processing by restoring status
from estatus, and executing the instruction specified by the
address in ea.
| break | bret The break and bret instructions generate and
return from breaks. break and bret are used
exclusively by software debugging tools. Programmers never use these instructions in
application code.
| rdctl | wrctl These instructions read and write control registers, such as the
status register. The value is
read from or stored to a general-purpose register.
| flushd | flushda flushi initd initda initi These instructions are used to manage the data and instruction cache memories.
| flushp | This instruction flushes all pre-fetched instructions from the pipeline. This is necessary before
jumping to recently-modified instruction memory.
| sync
| This instruction ensures that all previously-issued operations have completed before allowing
execution of subsequent load and store operations.
| |
The Nios II architecture provides a simple, non-vectored exception controller to handle all exception types. Each exception, including hardware interrupts, causes the processor to transfer execution to an exception address. An exception handler at this address determines the cause of the exception and dispatches an appropriate exception routine.
Exception addresses are specified in SOPC Builder at system generation time.
All exceptions are precise. Precise means that the processor has completed execution of all instructions preceding the faulting instruction and not started execution of instructions following the faulting instruction. Precise exceptions allow the processor to resume program execution once the exception handler clears the exception.
The Nios II architecture supports 32 external hardware interrupts. The processor core has 32 level-sensitive interrupt request (IRQ) inputs, irq0 through irq31, providing a unique input for each interrupt source. IRQ priority is determined by software. The architecture supports nested interrupts.
The software can enable and disable any interrupt source individually through the ienable control register, which contains an interrupt-enable bit for each of the IRQ inputs. Software can enable and disable interrupts globally using the PIE bit of the status control register. A hardware interrupt is generated if and only if all three of these conditions are true:
The Nios II processor core offers an interrupt vector custom instruction which accelerates interrupt vector dispatch. Include this custom instruction to reduce your program's interrupt latency.
The interrupt vector custom instruction is based on a priority encoder with one input for each interrupt connected to the Nios II processor. The cost of the interrupt vector custom instruction depends on the number of interrupts connected to the Nios II processor. The worst case is a system with 32 interrupts. In this case, the interrupt vector custom instruction consumes about 50 logic elements (LEs).
If you have a large number of interrupts connected, adding the interrupt vector custom instruction to your system might lower fMAX.
Except for the break instruction (see “Processing a Break” on page 3-38), this section describes the actions the processor takes in response to interrupt and instruction-related exceptions. Table 3-32 lists all possible non-break exception processing actions performed by hardware. Check marks indicate which actions apply to each of the processor scenarios, namely, systems without an MMU, systems with an MMU, and systems with an MMU that is currently processing an exception. For systems with an MMU, status.EH indicates whether or not exception processing is already in progress. When status.EH = 1, exception processing is already in progress and the states of the exception registers are preserved to retain the original exception states.
Maintained by John Loomis, last updated 10 November 2008