The Nios II EDS includes the following two closely-related software development tool flows:

• The Nios II SBT
• The Nios II SBT for Eclipse

Both tools flows are based on the GNU C/C++ compiler. The Nios II SBT for Eclipse™ provides a familiar and established environment for software development. Using the Nios II SBT for Eclipse, you can immediately begin developing and simulating Nios II software applications.

The Nios II SBT also provides a command line interface.

Using the Nios II hardware reference designs included in an Altera development kit, you can prototype an application running on a board before building a custom hardware platform.

If the prototype system adequately meets design requirements using an Altera-provided reference design, you can copy the reference design and use it without modification in the final hardware platform. Otherwise, you can customize the Nios II processor system until it meets cost or performance requirements.

Because the pins and logic resources in Altera devices are programmable, many customizations are possible:

• You can rearrange the pins on the chip to simplify the board design. For example, you can move address and data pins for external SDRAM memory to any side of the chip to shorten board traces.
• You can use extra pins and logic resources on the chip for functions unrelated to the processor. Extra resources can provide a few extra gates and registers as glue logic for the board design; or extra resources can implement entire systems. For example, a Nios II processor system consumes only 5% of a large Altera FPGA, leaving the rest of the chip’s resources available to implement other functions.
• You can use extra pins and logic on the chip to implement additional peripherals for the Nios II processor system. Altera offers a library of peripherals that easily connect to Nios II processor systems.

You are not required to create a new Nios II processor configuration for every new design. Altera provides ready-made Nios II system designs that you can use as is. If these designs meet your system requirements, there is no need to configure the design further. In addition, you can use the Nios II instruction set simulator to begin writing and debugging Nios II applications before the final hardware configuration is determined.

Altera provides software constructs to access memory and peripherals generically, independently of address location. Therefore, the flexible peripheral set and address map does not affect application developers.

There are two broad classes of peripherals: standard peripherals and custom peripherals.

You can also create custom components and integrate them in Nios II processor systems. For performance-critical systems that spend most CPU cycles executing a specific section of code, it is a common technique to create a custom peripheral that implements the same function in hardware.

This approach offers a double performance benefit:

• Hardware implementation is faster than software.
• Processor is free to perform other functions in parallel while the custom peripheral operates on data.

The custom logic is integrated into the Nios II processor’s arithmetic logic unit (ALU). Similar to native Nios II instructions, custom instruction logic can take values from up to two source registers and optionally write back a result to a destination register.

Because the processor is implemented on reprogrammable Altera FPGAs, software and hardware engineers can work together to iteratively optimize the hardware and test the results of software running on hardware.

From the software perspective, custom instructions appear as machine-generated assembly macros or C functions, so programmers do not need to understand assembly language to use custom instructions.

After system generation, you can download the design onto a board, and debug software executing on the board. To the software developer, the processor architecture of the design is set. Software development proceeds in the same manner as for traditional, nonconfigurable processors.

• Simulate the behavior of a Nios II processor within your system.
• Verify the functionality of your design, as well as evaluate its size and speed quickly and easily.
• Generate time-limited device programming files for designs that include Nios II processors.
• Program a device and verify your design in hardware.

You only need to purchase a license for the Nios II processor when you are completely satisfied with its functionality and performance, and want to take your design to production.

The functional units of the Nios II architecture form the foundation for the Nios II instruction set. However, this does not indicate that any unit is implemented in hardware. The Nios II architecture describes an instruction set, not a particular hardware implementation. A functional unit can be implemented in hardware, emulated in software, or omitted entirely.

A Nios II implementation is a set of design choices embodied by a particular Nios II processor core. All implementations support the instruction set defined in the Instruction Set Reference chapter.

Each implementation achieves specific objectives, such as smaller core size or higher performance. This flexibility allows the Nios II architecture to adapt to different target applications.

Implementation variables generally fit one of three trade-off patterns: more or less of a feature; inclusion or exclusion of a feature; hardware implementation or software emulation of a feature. An example of each trade-off follows:

• More or less of a feature—For example, to fine-tune performance, you can increase or decrease the amount of instruction cache memory. A larger cache increases execution speed of large programs, while a smaller cache conserves on-chip memory resources.
• Inclusion or exclusion of a feature—For example, to reduce cost, you can choose to omit the JTAG debug module. This decision conserves on-chip logic and memory resources, but it eliminates the ability to use a software debugger to debug applications.
• Hardware implementation or software emulation—For example, in control applications that rarely perform complex arithmetic, you can choose for the division instruction to be emulated in software. Removing the divide hardware conserves on-chip resources but increases the execution time of division operations.

For information about which Nios II cores supports what features, refer to the Nios II Core Implementation Details chapter of the Nios II Processor Reference Handbook.

For complete details about user-selectable parameters for the Nios II processor, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

The Nios II processor can optionally have one or more shadow register sets. A shadow register set is a complete set of Nios II general-purpose registers. When shadow register sets are implemented, the CRS field of the status register indicates which register set is currently in use. An instruction access to a general-purpose register uses whichever register set is active.

A typical use of shadow register sets is to accelerate context switching. When shadow register sets are implemented, the Nios II processor has two special instructions, rdprs and wrprs, for moving data between register sets. Shadow register sets are typically manipulated by an operating system kernel, and are transparent to application code. A Nios II processor can have up to 63 shadow register sets.

The Nios II architecture allows for the future addition of floating-point registers.

For details about shadow register set implementation and usage, refer to “Registers” and “Exception Processing” in the Programming Model chapter of the Nios II Processor Reference Handbook.

For details about the rdprs and wrprs instructions, refer to the Instruction Set Reference chapter of the Nios II Processor Reference Handbook.

The processor generates an exception whenever it issues an unimplemented instruction so your exception handler can call a routine that emulates the operation in software. Unimplemented instructions do not affect the programmer’s view of the processor.

For a list of potential unimplemented instructions, refer to the Programming Model chapter of the Nios II Processor Reference Handbook.

• Floating Point Hardware 2—This component supports floating-point instructions as specified by the IEEE Std 754-2008 but with simplified, non-standard rounding modes. The basic set of floating-point custom instructions includes single precision floating-point addition, subtraction, multiplication, division, square root, integer to float conversion, float to integer conversion, minimum, maximum, negate, absolute, and comparisons.
• Floating Point Hardware—This component supports floating-point instructions as specified by the IEEE Std 754-1985. The basic set of floating-point custom instructions includes single precision floating-point addition, subtraction, and multiplication. Floating-point division is available as an extension to the basic instruction set.

These floating-point instructions are implemented as custom instructions. The Hardware Conformance table below lists a detailed description of the conformance to the IEEE standards.

• Add
• Subtract
• Multiply
• Divide
• Square root
• Comparison
• Integer conversion
• Minimum
• Maximum
• Negate
• Absolute

Other floating-point operations (including double-precision operations) are implemented with software emulation. The component requires the following device resources:

• ~2,500 4-input LEs
• 9 x 9 bit multipliers
• 3x M9K memories

In the following table, a and b are assumed to be single-precision floating-point values.

The cycles column specifies the number of cycles required to execute the instruction. A combinatorial custom instruction takes 1 cycle. A multi-cycle custom instruction requires at least 2 cycles. An N-cycle multi-cycle custom instruction has N - 2 register stages inside the custom instruction because the Nios II processor registers the result from the custom instruction and allows another cycle for g wire delays in the source operand bypass multiplexers. The number of cycles does not include the extra cycles (maximum of 2) that an instruction following the multi-cycle custom instruction is stalled by the Nios II/f if the instruction uses the result within 2 cycles. These extra cycles occur because multi-cycle instructions are late result instructions

In Qsys, the Floating Point Hardware 2 component is under Embedded Processors on the Component Library tab.

The Nios II Software Build Tools (SBT) include software support for the Floating Point Custom Instruction 2 component. When the Floating Point Custom Instruction 2 component is present in hardware, the Nios II compiler compiles the software codes to use the custom instructions for floating point operations.

In Qsys, the Floating Point Hardware component is under Embedded Processors on the Component Library tab.

The Nios II floating-point custom instructions are based on the Altera^® floating-point megafunctions: ALTFP_MULT, ALTFP_ADD_SUB, and ALTFP_DIV.

The Nios II software development tools recognize C code that takes advantage of the floating-point instructions present in the processor core. When the floating-point custom instructions are present in your target hardware, the Nios II compiler compiles your code to use the custom instructions for floating-point operations and the newlib math library.

For more information on adding reset signals to the Nios II processor, refer to “Advanced Features Tab” in the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

For more information on the break vector and adding debug signals to the Nios II processor, refer to “JTAG Debug Module Tab” in the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

Exception addresses are specified with the Qsys Nios II Processor parameter editor.

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 processor connects to an EIC through the EIC interface. When an EIC is present, the internal interrupt controller is not implemented; Qsys connects interrupts to the EIC.

The EIC selects among active interrupts and presents one interrupt to the Nios II processor, with interrupt handler address and register set selection information. The interrupt selection algorithm is specific to the EIC implementation, and is typically based on interrupt priorities. The Nios II processor does not depend on any specific interrupt prioritization scheme in the EIC.

For every external interrupt, the EIC presents an interrupt level. The Nios II processor uses the interrupt level in determining when to service the interrupt.

Any external interrupt can be configured as an NMI. NMIs are not masked by the status.PIE bit, and have no interrupt level.

An EIC can be software-configurable.

For a typical example of an EIC, refer to the Vectored Interrupt Controller chapter in the Embedded Peripherals IP User Guide.

For details about EIC usage, refer to “Exception Processing” in the Programming Model chapter of the Nios II Processor Reference Handbook.

Your 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 of the following conditions are true:

• The PIE bit of the status register is 1
• An interrupt-request input, irq<n>, is asserted
• The corresponding bit n of the ienable register is 1

The interrupt vector custom instruction is less efficient than using the EIC interface with the Altera vectored interrupt controller component, and thus is deprecated in Qsys. Altera recommends using the EIC interface.

The flexible nature of the Nios II memory and I/O organization are the most notable difference between Nios II processor systems and traditional microcontrollers. Because Nios II processor systems are configurable, the memories and peripherals vary from system to system. As a result, the memory and I/O organization varies from system to system.

A Nios II core uses one or more of the following to provide memory and I/O access:

• Instruction master port—An Avalon^® Memory-Mapped (Avalon-MM) master port that connects to instruction memory via system interconnect fabric
• Instruction cache—Fast cache memory internal to the Nios II core
• Data master port—An Avalon-MM master port that connects to data memory and peripherals via system interconnect fabric
• Data cache—Fast cache memory internal to the Nios II core
• Tightly-coupled instruction or data memory port—Interface to fast on-chip memory outside the Nios II core

The Nios II architecture handles the hardware details for the programmer, so programmers can develop Nios II applications without specific knowledge of the hardware implementation.

For details that affect programming issues, refer to the Programming Model chapter of the Nios II Processor Reference Handbook.

The Nios II architecture supports separate instruction and data buses, classifying it as a Harvard architecture. Both the instruction and data buses are implemented as Avalon-MM master ports that adhere to the Avalon-MM interface specification. The data master port connects to both memory and peripheral components, while the instruction master port connects only to memory components.

The Nios II architecture does not specify anything about the existence of memory and peripherals; the quantity, type, and connection of memory and peripherals are system-dependent. Typically, Nios II processor systems contain a mix of fast on-chip memory and slower off-chip memory. Peripherals typically reside on-chip, although interfaces to off-chip peripherals also exist.

The instruction master port is a pipelined Avalon-MM master port. Support for pipelined Avalon-MM transfers minimizes the impact of synchronous memory with pipeline latency and increases the overall f_MAX of the system. The instruction master port can issue successive read requests before data has returned from prior requests. The Nios II processor can prefetch sequential instructions and perform branch prediction to keep the instruction pipe as active as possible.

The instruction master port always retrieves 32 bits of data. The instruction master port relies on dynamic bus-sizing logic contained in the system interconnect fabric. By virtue of dynamic bus sizing, every instruction fetch returns a full instruction word, regardless of the width of the target memory. Consequently, programs do not need to be aware of the widths of memory in the Nios II processor system.

The Nios II architecture supports on-chip cache memory for improving average instruction fetch performance when accessing slower memory. Refer to the "Cache Memory" section of this chapter for details.

The Nios II architecture supports tightly-coupled memory, which provides guaranteed low-latency access to on-chip memory. Refer to the "Tightly-Coupled Memory" section of this chapter for details.

The data and instruction master ports never cause a gridlock condition in which one port starves the other. For highest performance, assign the data master port higher arbitration priority on any memory that is shared by both instruction and data master ports.

The instruction and data caches are enabled perpetually at run-time, but methods are provided for software to bypass the data cache so that peripheral accesses do not return cached data. Cache management and cache coherency are handled by software. The Nios II instruction set provides instructions for cache management.

A Nios II processor core might include one, both, or neither of the cache memories. Furthermore, for cores that provide data and/or instruction cache, the sizes of the cache memories are user-configurable. The inclusion of cache memory does not affect the functionality of programs, but it does affect the speed at which the processor fetches instructions and reads/writes data.

• Regular memory is located off-chip, and access time is long compared to on-chip memory
• The largest, performance-critical instruction loop is smaller than the instruction cache
• The largest block of performance-critical data is smaller than the data cache

Optimal cache configuration is application specific, although you can make decisions that are effective across a range of applications. For example, if a Nios II processor system includes only fast, on-chip memory (i.e., it never accesses slow, off-chip memory), an instruction or data cache is unlikely to offer any performance gain. As another example, if the critical loop of a program is 2 KB, but the size of the instruction cache is 1 KB, an instruction cache does not improve execution speed. In fact, an instruction cache may degrade performance in this situation.

If an application always requires certain data or sections of code to be located in cache memory for performance reasons, the tightly-coupled memory feature might provide a more appropriate solution. Refer to the "Tightly-Coupled Memory" section for details.

The load and store I/O instructions such as ldio and stio bypass the data cache and force an Avalon-MM data transfer to a specified address.

The bit-31 cache bypass method on the data master port uses bit 31 of the address as a tag that indicates whether the processor should transfer data to/from cache, or bypass it. This is a convenience for software, which might need to cache certain addresses and bypass others. Software can pass addresses as parameters between functions, without having to specify any further information about whether the addressed data is cached or not.

To determine which cores implement which cache bypass methods, refer to the Nios II Core Implementation Details chapter of the Nios II Processor Reference Handbook.

• Performance similar to cache memory
• Software can guarantee that performance-critical code or data is located in tightly-coupled memory
• No real-time caching overhead, such as loading, invalidating, or flushing memory

Physically, a tightly-coupled memory port is a separate master port on the Nios II processor core, similar to the instruction or data master port. A Nios II core can have zero, one, or multiple tightly-coupled memories. The Nios II architecture supports tightly-coupled memory for both instruction and data access. Each tightly-coupled memory port connects directly to exactly one memory with guaranteed low, fixed latency. The memory is external to the Nios II core and is located on chip.

Software accesses tightly-coupled memory using regular load and store instructions. From the software’s perspective, there is no difference accessing tightly-coupled memory compared to other memory.

A system can use tightly-coupled memory to achieve maximum performance for accessing a specific section of code or data. For example, interrupt-intensive applications can place exception handler code into a tightly-coupled memory to minimize interrupt latency. Similarly, compute-intensive digital signal processing (DSP) applications can place data buffers into tightly-coupled memory for the fastest possible data access.

If the application’s memory requirements are small enough to fit entirely on chip, it is possible to use tightly-coupled memory exclusively for code and data. Larger applications must selectively choose what to include in tightly-coupled memory to maximize the cost-performance trade-off.

There are three addresses that are part of the processor and deserve special mention:

• Reset address
• Exception address
• Break handler address

Programmers access memories and peripherals by using macros and drivers. Therefore, the flexible address map does not affect application developers.

• Virtual to physical address mapping
• Memory protection
• 32-bit virtual and physical addresses, mapping a 4-GB virtual address space into as much as 4 GB of physical memory
• 4-KB page and frame size
• Low 512 MB of physical address space available for direct access
• Hardware translation lookaside buffers (TLBs), accelerating address translation
  • Separate TLBs for instruction and data accesses
  • Read, write, and execute permissions controlled per page
  • Default caching behavior controlled per page
  • TLBs acting as n-way set-associative caches for software page tables
  • TLB sizes and associativities configurable in the Nios II Processor parameter editor
• Format of page tables (or equivalent data structures) determined by system software
• Replacement policy for TLB entries determined by system software
• Write policy for TLB entries determined by system software

For more information about the MMU implementation, refer to the Programming Model chapter of the Nios II Processor Reference Handbook.

You can optionally include the MMU when you instantiate the Nios II processor in your Nios II hardware system. When present, the MMU is always enabled, and the data and instruction caches are virtually-indexed, physically-tagged caches. Several parameters are available, allowing you to optimize the MMU for your system needs.

For complete details about user-selectable parameters for the Nios II MMU, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

• Memory protection
• Up to 32 instruction regions and 32 data regions
• Variable instruction and data region sizes
• Amount of region memory defined by size or upper address limit
• Read and write access permissions for data regions
• Execute access permissions for instruction regions
• Overlapping regions

For more information about the MPU implementation, refer to the Programming Model chapter of the Nios II Processor Reference Handbook.

You can optionally include the MPU when you instantiate the Nios II processor in your Nios II hardware system. When present, the MPU is always enabled. Several parameters are available, allowing you to optimize the MPU for your system needs.

For complete details about user-selectable parameters for the Nios II MPU, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

• Downloading programs to memory
• Starting and stopping execution
• Setting breakpoints and watchpoints
• Analyzing registers and memory
• Collecting real-time execution trace data

The debug module connects to the JTAG circuitry in an Altera FPGA. External debugging probes can then access the processor via the standard JTAG interface on the FPGA. On the processor side, the debug module connects to signals inside the processor core. The debug module has nonmaskable control over the processor, and does not require a software stub linked into the application under test. All system resources visible to the processor in supervisor mode are available to the debug module. For trace data collection, the debug module stores trace data in memory either on-chip or in the debug probe.

The debug module gains control of the processor either by asserting a hardware break signal, or by writing a break instruction into program memory to be executed. In both cases, the processor transfers execution to the routine located at the break address. The break address is specified with the Nios II Processor parameter editor in Qsys.

Soft processor cores such as the Nios II processor offer unique debug capabilities beyond the features of traditional, fixed processors. The soft nature of the Nios II processor allows you to debug a system in development using a full-featured debug core, and later remove the debug features to conserve logic resources. For the release version of a product, the JTAG debug module functionality can be reduced, or removed altogether.

The following sections describe the capabilities of the Nios II JTAG debug module hardware. The usage of all hardware features is dependent on host software, such as the Nios II Software Build Tools for Eclipse, which manages the connection to the target processor and controls the debug process.

Hardware breakpoints are implemented using the JTAG debug module’s hardware trigger feature.

Hardware trigger conditions are based on either the instruction or data bus. Trigger conditions on the same bus can be logically ANDed, enabling the JTAG debug module to trigger, for example, only on write cycles to a specific address.

When a trigger condition occurs during processor execution, the JTAG debug module triggers an action, such as halting execution, or starting trace capture. The table below lists the trigger actions supported by the Nios II JTAG debug module.

The JTAG debug module provides a two-level trigger capability, called armed triggers. Armed triggers enable the JTAG debug module to trigger on event B, only after event A. In this example, event A causes a trigger action that enables the trigger for event B.

The JTAG debug module can trigger on ranges of data or address values on the data bus. This mechanism uses two hardware triggers together to create a trigger condition that activates on a range of values within a specified range.

• Capture execution trace (instruction bus cycles).
• Capture data trace (data bus cycles).
• For each data bus cycle, capture address, data, or both.
• Start and stop capturing trace in real time, based on triggers.
• Manually start and stop trace under host control.
• Optionally stop capturing trace when trace buffer is full, leaving the processor executing.
• Store trace data in on-chip memory buffer in the JTAG debug module. (This memory is accessible only through the JTAG connection.)
• Store trace data to larger buffers in an off-chip debug probe.

Certain trace features require additional licensing or debug tools from third-party debug providers. For example, an on-chip trace buffer is a standard feature of the Nios II processor, but using an off-chip trace buffer requires additional debug software and hardware provided by Imagination Technologies™, LLC or Lauterbach GmbH.

The JTAG debug module can filter the data bus trace in real time to capture the following:

• Load addresses only
• Store addresses only
• Both load and store addresses
• Load data only
• Load address and data
• Store address and data
• Address and data for both loads and stores
• Single sample of the data bus upon trigger event

To keep pace with the processor executing in real time, execution trace is optimized to store only selected addresses, such as branches, calls, traps, and interrupts. From these addresses, host-side debug software can later reconstruct an exact instruction-by-instruction execution trace. Furthermore, execution trace data is stored in a compressed format, such that one frame represents more than one instruction. As a result of these optimizations, the actual start and stop points for trace collection during execution might vary slightly from the user-specified start and stop points.

Data trace stores 100% of requested loads and stores to the trace buffer in real time. When storing to the trace buffer, data trace frames have lower priority than execution trace frames. Therefore, while data frames are always stored in chronological order, execution and data trace are not guaranteed to be exactly synchronized with each other.

• Supervisor mode
• User mode

The following sections define the modes, their relationship to your system software and application code, and their relationship to the Nios II MMU and Nios II MPU.

Operating systems and other system software run in supervisor mode. In systems with an MMU, application code runs in user mode, and the operating system, running in supervisor mode, controls the application’s access to memory and peripherals. In systems with an MPU, your system software controls the mode in which your application code runs. In Nios II systems without an MMU or MPU, all application and system code runs in supervisor mode.

Code that needs direct access to and control of the processor runs in supervisor mode. For example, the processor enters supervisor mode whenever a processor exception (including processor reset or break) occurs. Software debugging tools also use supervisor mode to implement features such as breakpoints and watchpoints.

The operating system determines which memory addresses are accessible to user mode applications. Attempts by user mode applications to access memory locations without user access enabled are not permitted and cause an exception. Code running in user mode uses system calls to make requests to the operating system to perform I/O operations, manage memory, and access other system functionality in the supervisor memory.

The Nios II MMU statically divides the 32-bit virtual address space into user and supervisor partitions. Refer to Address Space and Memory Partitions section for more information about the MMU memory partitions. The MMU provides operating systems access permissions on a per-page basis. Refer to Virtual Addressing for more information about MMU pages.

The Nios II MPU supervisor and user memory divisions are determined by the operating system or runtime environment. The MPU provides user access permissions on a region basis. Refer to Memory Regions for more information about MPU regions.

Many Nios II systems have simpler requirements where minimal system software or a small-footprint operating system (such as the Altera^® hardware abstraction library (HAL) or a third party real-time operating system) is sufficient. Such software is unlikely to function correctly in a hardware system with an MMU-based Nios II processor. Do not include an MMU in your Nios II system unless your operating system requires it.

If your system needs memory protection, but not virtual memory management, refer to Memory Protection Unit section.

• Virtual addressing—Mapping a virtual memory space into a physical memory space
• Memory protection—Allowing access only to certain memory under certain conditions

The MMU contains a hardware translation lookaside buffer (TLB). The operating system is responsible for creating and maintaining a page table (or equivalent data structures) in memory. The hardware TLB acts as a software managed cache for the page table. The MMU does not perform any operations on the page table, such as hardware table walks. Therefore the operating system is free to implement its page table in any appropriate manner.

There is a 20 bit virtual page number (VPN) and a 12 bit page offset.

As input, the TLB takes a VPN plus a process identifier (to guarantee uniqueness). As output, the TLB provides the corresponding physical frame number (PFN).

Distinct processes can use the same virtual address space. The process identifier, concatenated with the virtual address, distinguishes identical virtual addresses in separate processes. To determine the physical address, the Nios II MMU translates a VPN to a PFN and then concatenates the PFN with the page offset. The bits in the page offset are not translated.

Memory Protection

The Nios II MMU maintains read, write, and execute permissions for each page. The TLB provides the permission information when translating a VPN. The operating system can control whether or not each process is allowed to read data from, write data to, or execute instructions on each particular page. The MMU also controls whether accesses to each data page are cacheable or uncacheable by default.

Whenever an instruction attempts to access a page that either has no TLB mapping, or lacks the appropriate permissions, the MMU generates an exception. The Nios II processor’s precise exceptions enable the system software to update the TLB, and then re-execute the instruction if desired.

The Nios II MMU maintains read, write, and execute permissions for each page. The TLB provides the permission information when translating a VPN. The operating system can control whether or not each process is allowed to read data from, write data to, or execute instructions on each particular page. The MMU also controls whether accesses to each data page are cacheable or uncacheable by default.

Whenever an instruction attempts to access a page that either has no TLB mapping, or lacks the appropriate permissions, the MMU generates an exception. The Nios II processor’s precise exceptions enable the system software to update the TLB, and then re-execute the instruction if desired.

Each partition has a specific size, purpose, and relationship to the TLB:

• The 512-MB I/O partition provides access to peripherals.
• The 512-MB kernel partition provides space for the operating system kernel.
• The 1-GB kernel MMU partition is used by the TLB miss handler and kernel processes.
• The 2-GB user partition is used by application processes.

I/O and kernel partitions bypass the TLB. The kernel MMU and user partitions use the TLB. If all software runs in the kernel partition, the MMU is effectively disabled.

High physical memory can only be accessed through the TLB. Any physical address in low memory (29-bits or less) can be accessed through the TLB or by bypassing the TLB. When bypassing the TLB, a 29-bit physical address is computed by clearing the top three bits of the 32-bit virtual address.

Non-I/O load and store instructions use the default data cacheability property. I/O load and store instructions are always noncacheable, so they ignore the default data cacheability property.

The TLB is organized as an n-way set-associative cache. The software specifies the way (set) when loading a new entry.

The operating system software is responsible for guaranteeing that multiple TLB entries do not map the same virtual address. The hardware behavior is undefined when multiple entries map the same virtual address.

Each TLB entry consists of a tag and data portion. This is analogous to the tag and data portion of instruction and data caches.

Refer to the Nios II Core Implementation Details chapter of the Nios II Processor Reference Handbook for information about instruction and data caches.

The tag portion of a TLB entry contains information used when matching a virtual address to a TLB entry.

The TLB data portion determines how to translate a matching virtual address to a physical address.

Refer to “Instruction-Related Exceptions” for information about TLB exceptions.

When present and enabled, the MPU monitors all Nios II instruction fetches and data memory accesses to protect against errant software execution. The MPU is a hardware facility that system software uses to define memory regions and their associated access permissions. The MPU triggers an exception if software attempts to access a memory region in violation of its permissions, allowing you to intervene and handle the exception as appropriate. The precise exception effectively prevents the illegal access to memory.

The MPU extends the Nios II processor to support user mode and supervisor mode. Typically, system software runs in supervisor mode and end-user applications run in user mode, although all software can run in supervisor mode if desired. System software defines which MPU regions belong to supervisor mode and which belong to user mode.

• Base address
• Region type
• Region index
• Region size or upper address limit
• Access permissions
• Default cacheability (data regions only)

When regions are defined by size, the size is encoded as a binary mask to facilitate the following MPU region address range matching:

(address & region_mask) == region_base_address

When regions are defined by limit, the limit is encoded as an unsigned integer to facilitate the following MPU region address range matching:

(address >= region_base) && (address < region_limit)

The region limit uses a less-than instead of a less-than-or-equal-to comparison because less-than provides a more efficient implementation. The limit is one bit larger than the address so that full address range may be included in a range. Defining the region by limit results in slower and larger address range match logic than defining by size but allows finer granularity in region sizes.

If regions overlap so that a particular access matches more than one region, the region with the highest priority (lowest index) determines the access permissions and default cacheability.

The Nios II architecture provides thirty-two 32-bit general-purpose registers, r0 through r31. Some registers have names recognized by the assembler. For example, the zero register (r0) always returns the value zero, and writing to zero has no effect. The ra register (r31) holds the return address used by procedure calls and is implicitly accessed by the call, callr and ret instructions. C and C++ compilers use a common procedure-call convention, assigning specific meaning to registers r1 through r23 and r26 through r28.

For more information, refer to the Application Binary Interface chapter of the Nios II Processor Reference Handbook.

Control registers report the status and change the behavior of the processor. Control registers are accessed differently than the general-purpose registers. The special instructions rdctl and wrctl provide the only means to read and write to the control registers and are only available in supervisor mode.

The Nios II architecture supports up to 32 control registers. All nonreserved control registers have names recognized by the assembler.

The following sections describe the nonreserved control registers.

Control registers report the status and change the behavior of the processor. Control registers are accessed differently than the general-purpose registers. The special instructions rdctl and wrctl provide the only means to read and write to the control registers and are only available in supervisor mode.

The Nios II architecture supports up to 32 control registers. All nonreserved control registers have names recognized by the assembler.

The following sections describe the nonreserved control registers.

All fields in the estatus register have read/write access. All fields reset to 0.

When the Nios II processor takes an interrupt, if status.eh is zero (that is, the MMU is in nonexception mode), the processor copies the contents of the status register to estatus.

For details about the sstatus register, refer to The sstatus Register section.

The exception handler can examine estatus to determine the pre-exception status of the processor. When returning from an exception, the eret instruction restores the pre-exception value of status. The instruction restores the pre-exception value by copying either estatus or sstatus back to status, depending on the value of status.CRS.

Refer to the Exception Processing section for more information.

All fields in the bstatus register have read/write access. All fields reset to 0.

The Status Control Register Field Description table describes the details of the fields defined in the bstatus register.

When a break occurs, the value of the status register is copied into bstatus. Using bstatus, the debugger can restore the status register to the value prior to the break. The bret instruction causes the processor to copy bstatus back to status. Refer to the Processing a Break section for more information.

The value of the ipending register indicates the value of the enabled interrupt signals driven into the processor. A value of one in bit n means that the corresponding irq n input is asserted and enabled in the ienable register. Writing a value to the ipending register has no effect.

For information about controlling the extra exception information option, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

Software writes to the PTBASE field when switching processes. Hardware never writes to the PTBASE field.

Software writes to the VPN field when writing a TLB entry. Hardware writes to the VPN field on a fast TLB miss exception, a TLB permission violation exception, or on a TLB read operation. The VPN field is not written on any exceptions taken when an exception is already active, that is, when status.EH is already one.

Issuing a wrctl instruction to the tlbacc register writes the tlbacc register with the specified value. If tlbmisc.WE = 1, the wrctl instruction also initiates a TLB write operation, which writes a TLB entry. The TLB entry written is specified by the line portion of pteaddr.VPN and the tlbmisc.WAY field. The value written is specified by the value written into tlbacc along with the values of pteaddr.VPN and tlbmisc.PID. A TLB write operation also increments tlbmisc.WAY, allowing software to quickly modify TLB entries.

Issuing a rdctl instruction to the tlbacc register returns the value of the tlbacc register. The tlbacc register is written by hardware when software triggers a TLB read operation (that is, when wrctl sets tlbmisc.RD to one).

The tlbacc register format is the recommended format for entries in the operating system page table. The IG bits are ignored by the hardware on wrctl to tlbacc and read back as zero on rdctl from tlbacc. The operating system can use the IG bits to hold operating system specific information without having to clear these bits to zero on a TLB write operation.

For DBL, BAD, and PERM fields you can also use exception.CAUSE to determine these exceptions.

The following sections provide more information about the tlbmisc fields.

• The tag portion of pteaddr.VPN
• tlbmisc.PID
• The tlbacc register

The TLB entry to be read is specified by the following values:

• the line portion of pteaddr.VPN
• tlbmisc.WAY

When system software changes the fields that specify the TLB entry, there is no immediate effect on pteaddr.VPN, tlbmisc.PID, or the tlbacc register. The registers retain their previous values until the next TLB read operation is initiated. For example, when the operating system sets pteaddr.VPN to a new value, the contents of tlbacc continues to reflect the previous TLB entry. tlbacc does not contain the new TLB entry until after an explicit TLB read.

Hardware sets the WE flag to one on a TLB permission violation exception, and on a TLB miss exception when status.EH = 0. When a TLB write operation writes the tlbacc register, the write operation also writes to a TLB entry when WE = 1.

tlbmisc.PID contains the PID field from a TLB tag. The operating system must set the PID field when switching processes, and before each TLB write operation.

The MMU sets tlbmisc.PID on a TLB read operation. When the software triggers a TLB read, by setting tlbmisc.RD to one with the wrctl instruction, the PID value read from the TLB has priority over the value written by the wrctl instruction.

The size of the PID field is configured in Qsys at system generation, and can be from 8 to 14 bits. If system software defines a process identifier smaller than the PID field, unused upper bits must be written as zero.

The DBL flag indicates whether the most recent exception is a double TLB miss condition. When a general exception occurs, the MMU sets DBL to one if a double TLB miss is detected, and clears DBL to zero otherwise.

• Supervisor-only instruction address
• Supervisor-only data address
• Misaligned data address
• Misaligned destination address

Refer to Nios II Exceptions (In Decreasing Priority Order) table in the "Exception Overview" section for more information on these exceptions.

The following exceptions set the D flag to one:

• Fast TLB miss (data)
• Double TLB miss (data)
• TLB permission violation (read or write)
• Misaligned data address
• Supervisor-only data address

For information about controlling the extra exception information option, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

When the option for extra exception information is enabled and a processor exception occurs, the badaddr register contains the byte instruction or data address associated with certain exceptions at the time the exception occurred. The Nios II Exceptions Table lists which exceptions write the badaddr register along with the value written.

The BADDR field allows up to a 32-bit instruction address or data address. If an MMU or MPU is present, the BADDR field is 32 bits because MMU and MPU instruction and data addresses are always full 32-bit values. When an MMU is present, the BADDR field contains the virtual address.

If there is no MMU or MPU and the Nios II address space is less than 32 bits, unused high-order bits are written and read as zero. If there is no MMU, bit 31 of a data address (used to bypass the data cache) is always zero in the BADDR field.

The config register configures Nios II runtime behaviors that do not need to be preserved during exception processing (in contrast to the information in the status register).

The mpubase register works in conjunction with the mpuacc register to set and retrieve MPU region information and is only available in systems with an MPU.

The BASE field specifies the base address of an MPU region. The 25-bit BASE field corresponds to bits 6 through 30 of the base address, making the base address always a multiple of 64 bytes. If the minimum region size set in Qsys at generation time is larger than 64 bytes, unused low-order bits of the BASE field must be written as zero and are read as zero. For example, if the minimum region size is 1024 bytes, the four least-significant bits of the BASE field (bits 6 though 9 of the mpubase register) must be zero. Similarly, if the Nios II address space is less than 31 bits, unused high-order bits must also be written as zero and are read as zero.

The INDEX and D fields specify the region information to access when an MPU region read or write operation is performed. The D field specifies whether the region is a data region or an instruction region. The INDEX field specifies which of the 32 data or instruction regions to access. If there are fewer than 32 instruction or 32 data regions, unused high-order bits must be written as zero and are read as zero.

Refer to the MPU Region Read and Write Operations section for more information on MPU region read and write operations.

The mpuacc register works in conjunction with the mpubase register to set and retrieve MPU region information and is only available in systems with an MPU. The mpuacc register consists of attributes that will be set or have been retrieved which define the MPU region. The mpuacc register only holds a portion of the attributes that define an MPU region. The remaining portion of the MPU region definition is held by the BASE field of the mpubase register.

A Qsys generation-time option controls whether the mpuacc register contains a MASK or LIMIT field.

The MASK and LIMIT fields are mutually exclusive. Refer to mpucc Control Register Field for MASK Variation Table and mpuacc Control Register Field for LIMIT Variation Table.

The following sections provide more information about the mpuacc fields.

When the amount of memory reserved for a region is defined by size, the MASK field specifies the size of the memory region. The MASK field is the same number of bits as the BASE field of the mpubase register.

MASK Region Size Encodings Table lists the MASK field encodings for all possible region sizes in a full 31-bit byte address space.

The MASK field contains the following value, where region_size is in bytes:

MASK = 0x1FFFFFF << log2(region_size >> 6)

When the amount of memory reserved for a region is defined by an upper address limit, the LIMIT field specifies the upper address of the memory region plus one. For example, to achieve a memory range for byte addresses 0x4000 to 0x4fff with a 256 byte minimum region size, the BASE field of the mpubase register is set to 0x40 (0x4000 >> 6) and the LIMIT field is set to 0x50 (0x5000 >> 6). Because the LIMIT field is one more bit than the number of bits of the BASE field of the mpubase register, bit 31 of the mpuacc register is available to the LIMIT field.

The C flag determines the default data cacheability of an MPU region. The C flag only applies to data regions. For instruction regions, the C bit must be written with 0 and is always read as 0.

When data cacheability is enabled on a data region, a data access to that region can be cached, if a data cache is present in the system. You can override the default cacheability and force an address to noncacheable with an ldio or stio instruction.

The MT flag determines the default memory type of an MPU data region. . The MT flag only applies to data regions. For instruction regions, the MT bit must be written with 0 for instruction regions and is always read as 0.

When data cacheability is enabled on a data region, a data access to that region can be cached, if a data cache is present in the system. You can override the default cacheability and force an address to noncacheable with an ldio or stio instruction. The encoding of the MT field is setup to be backwards-compatible with the Nios II Classic core MPU where bit 5 of MPUACC contains the cacheable bit (0 = non-cacheable, 1 = cacheable) and bit 6 is zero.

The eccinj register injects 1 and 2 bit errors to the Nios II processor’s internal RAM blocks that support ECC. Injecting errors allows the software to test the ECC error exception handling code. The error(s) are injected in the data bits, not the parity bits. The eccinj register is only available when ECC is present.

When shadow register sets are implemented, status.CRS indicates the register set currently in use. A Nios II core can have up to 63 shadow register sets. If n is the configured number of shadow register sets, the shadow register sets are numbered from 1 to n. Register set 0 is the normal register set.

A shadow register set behaves precisely the same as the normal register set. The register set currently in use can only be determined by examining status.CRS.

Shadow register sets are typically used in conjunction with the EIC interface. This combination can substantially reduce interrupt latency.

For details of EIC interface usage, refer to the Exception Processing section.

System software can read from and write to any shadow register set by setting status.PRS and using the rdprs and wrprs instructions.

For details of the rdprs and wrprs instructions, refer to the Instruction Set Reference chapter of the Nios II Processor Reference Handbook.

The sstatus register is physically stored in general-purpose register r30 in each shadow register set. The normal register set does not have an sstatus register, but each shadow register set has a separate sstatus register.

The sstatus register is present in the Nios II core if both the EIC interface and shadow register sets are implemented. There is one copy of sstatus for each shadow register set.

When the Nios II processor takes an interrupt, if a shadow register set is requested (RRS = 0) and the MMU is not in exception handler mode (status.EH = 0), the processor copies status to sstatus.

For details about RRS, refer to "Requested Register Set”.

For details about status.EH, refer to the Nios II Processor Status After Taking Exceptions Table.

• If the processor is currently running in the normal register set, insert the new register set number in estatus.CRS, and execute eret.
• If the processor is currently running in a shadow register set, insert the new register set number in sstatus.CRS, and execute eret.

Before executing eret to change the register set, system software must set individual external interrupt masks correctly to ensure that registers in the shadow register set cannot be corrupted. If an interrupt is assigned to the register set, system software must ensure that one of the following conditions is true:

• The ISR is written to preserve register contents.
• The individual interrupt is disabled. The method for disabling an individual external interrupt is specific to the EIC implementation.

Depending on system requirements, the system software can create a dedicated stack for each register set, or share a stack among several register sets. If a stack is shared, the system software must copy the stack pointer each time the register set changes. Use the rdprs instruction to copy the stack register between the current register set and another register set.

• After the gp register is initialized in the normal register set, copy it to all shadow register sets, to ensure that all code can correctly address the small data sections.
• Copy the zero register from the normal register set to all shadow register sets, using the wrprs instruction.

MPU region read operations retrieve the current values for the attributes of a region. Each MPU region read operation consists of the following actions:

• Execute a wrctl instruction to the mpubase register with the mpubase.INDEX and mpubase.D fields set to identify the MPU region.
• Execute a wrctl instruction to the mpuacc register with the mpuacc.RD field set to one and the mpuacc.WR field cleared to zero. This action loads the mpubase and mpuacc register values.
• Execute a rdctl instruction to the mpubase register to read the loaded the mpubase register value.
• Execute a rdctl instruction to the mpuacc register to read the loaded the mpuacc register value.

The MPU region read operation retrieves mpubase.BASE, mpuacc.MASK or mpuacc.LIMIT, mpuacc.C, and mpuacc.PERM values for the MPU region.

MPU region write operations set new values for the attributes of a region. Each MPU region write operation consists of the following actions:

• Execute a wrctl instruction to the mpubase register with the mpubase.INDEX and mpubase.D fields set to identify the MPU region.
• Execute a wrctl instruction to the mpuacc register with the mpuacc.WR field set to one and the mpuacc.RD field cleared to zero.

The MPU region write operation sets the values for mpubase.BASE, mpuacc.MASK or mpuacc.LIMIT, mpuacc.C, and mpuacc.PERM as the new attributes for the MPU region.

Normally, a wrctl instruction flushes the pipeline to guarantee that any side effects of writing control registers take effect immediately after the wrctl instruction completes execution. However, wrctl instructions to the mpubase and mpuacc control registers do not automatically flush the pipeline. Instead, system software is responsible for flushing the pipeline as needed (either by using a flushp instruction or a wrctl instruction to a register that does flush the pipeline). Because a context switch typically requires reprogramming the MPU regions for the new thread, flushing the pipeline on each wrctl instruction would create unnecessary overhead.

The MPU is disabled on system reset. Before enabling the MPU, Altera recommends initializing all MPU regions. Enable desired instruction and data regions by writing each region’s attributes to the mpubase and mpuacc registers as described in the "MPU Region Read and Write Operations" section of this chapter. You must also disable unused regions. When using region size, clear mpuacc.MASK to zero. When using limit, set the mpubase.BASE to a nonzero value and clear mpuacc.LIMIT to zero.

To perform a context switch, use a wrctl to write a zero to the PE field of the config register to disable the MPU, define all MPU regions from the new thread’s data structure, and then use another wrctl to write a one to config.PE to enable the MPU.

Define each region using the pair of wrctl instructions described in the "MPU Region Read and Write Operations" section of this chapter. Repeat this dual wrctl instruction sequence until all desired regions are defined.

The Nios II processor executes the INITI instruction on each cache line, which initializes the instruction cache RAM. The RAM does not require special initialization because any detected ECC errors are ignored if the line is invalid; the line is invalid after INITI instructions initialize the tag RAM.

Nios II processor instructions that write to every register (except register 0) initialize the register file RAM blocks. If shadow register sets are present, this step is performed for all registers in the shadow register set using the WRPRS instruction.

Nios II processor instructions that write every TLB RAM location initialize the MMU TLB RAM. This RAM does not require special initialization.

Disable ECC in software by writing 0 to CONFIG.ECCEN. Software can re-enable ECC without reinitializing the ECC-protected RAMs because the ECC parity bits are written to the RAM blocks even if ECC is disabled.

Typically, software can recover from an unrecoverable MMU TLB ECC error (2 bit error) because the TLB is a software-managed cache of the operating system page tables stored in the main memory (e.g., SDRAM). Software can invalid the TLB entry, return to the instruction that took the ECC error exception, and execute the TLB’s mishandled code to load a TLB entry from the page tables.

In general, software cannot recover from a register file ECC error (2 bit error) because the correct value of a register is not known. If the exception handler reads a register that has a 2 bit ECC error associated with it, another ECC error occurs and an exception handler loop can occur.

Exception handler loops occur when an ECC error exception occurs in the exception handler before it is ready to handle nested exceptions. To minimize the occurrence or exception handler loops, locate the ECC error exception handler code in normal cacheable memory, ensure that all data accesses are to non-cacheable memory, and minimize register reading.

The ECC error signals (ecc_event_bus) provide the EEH signal for external logic to detect a possible exception handler loop and reset the Nios II processor.

This section describes the code sequence for injecting ECC errors for each ECC-protected RAM, assuming the ECC is enabled and interrupts are disabled for the duration of the code sequence.

1. Ensure all code up to the JMP instruction is in the same instruction cache line or is located in an ITCM.
2. Use a FLUSHI instruction to flush an instruction cache line other than the line containing the executing code.
3. Use a FLUSHP instruction to flush the pipeline.
4. Use a WRCTL instruction to set ECCINJ.ICTAG to INJS or INJD. This setting causes an ECC error to occur on the start of the next line fill.
5. Use a JMP instruction to jump to an instruction address in the flushed line.
6. The ECC error is injected when writing the tag RAM at the start of the line fill.
7. Use a RDCTL instruction to ensure that the value of ECCINJ.ICTAG is NOINJ.
8. The ECC error triggers after the target of the JMP instruction.

1. Ensure all code up to the JMP instruction is in the same instruction cache line or is located in an ITCM.
2. Use a FLUSHI instruction to flush an instruction cache line other than the line containing the executing code.
3. Use a FLUSHP instruction to flush the pipeline.
4. Use a WRCTL instruction to set ECCINJ.ICDAT to INJS or INJD. This setting causes an ECC error to occur on the start of the next line fill.
5. Use a JMP instruction to jump to an instruction address in the flushed line.
6. The ECC error is injected when writing the tag RAM at the start of the line fill.
7. Use a RDCTL instruction to ensure that the value of ECCINJ.ICDAT is NOINJ.
8. Execute the target of the JMP instruction twice (first to inject the ECC error and second to be triggered by it).

1. Use a WRCTL instruction to set ECCINJ.RF to INJS or INJD (as desired).
2. Execute any instruction that writes any register except R0.
3. Use a RDCTL instruction to ensure that the value of ECCINJ.RF is NOINJ.
4. Use an instruction to read the desired register from rA such as OR rd, r0, rx where rx is the register written in the previous step. This action triggers the ECC error.
5. Use an instruction to read the desired register from rB such as OR rd, rx, r0 where rx is the register written in the previous step.

1. Use a WRCTL instruction to set ECCINJ.TLB to INJS or INJD.
2. Use a WRCTL instruction to write a TLB entry. The ECC error will be injected at this time and any associated uTLB entry will be flushed.
3. Use a RDCTL instruction to ensure the value of ECCINJ.TLB is NOINJ.
4. Perform an instruction/data access to cause the hardware to read the TLB entry (copied into uTLB) and the ECC decoder should detect the ECC error at this time. Alternatively, initiate a software read of the TLB (by writing TLBMISC.RD to 1).
5. If a software read was initiated, the TLBMISC.EE field should be set to 1 on any instruction after the WRCTL that triggered the software read.
6. If a hardware read was initiated, the ECC error should be triggered on the first instruction after the hardware read.

All Nios II exceptions are precise. Precise exceptions enable the system software to re-execute the instruction, if desired, after handling the exception.

• Exception—a transfer of control away from a program’s normal flow of execution, caused by an event, either internal or external to the processor, which requires immediate attention.
• Interrupt—an exception caused by an explicit request signal from an external device; also: hardware interrupt.
• Interrupt controller—hardware that interfaces the processor to interrupt request signals from external devices.
• Internal interrupt controller—the nonvectored interrupt controller that is integral to the Nios II processor. The internal interrupt controller is available in all revisions of the Nios II processor.
• Vectored interrupt controller (VIC)—an Altera-provided external interrupt controller.
• Exception (interrupt) latency—The time elapsed between the event that causes the exception (assertion of an interrupt request) and the execution of the first instruction at the handler address.
• Exception (interrupt) response time—The time elapsed between the event that causes the exception (assertion of an interrupt request) and the execution of nonoverhead exception code, that is, specific to the exception type (device).
• Global interrupts—All maskable exceptions on the Nios II processor, including internal interrupts and maskable external interrupts, but not including nonmaskable interrupts.
• Worst-case latency—The value of the exception (interrupt) latency, assuming the maximum disabled time or maximum masked time, and assuming that the exception (interrupt) occurs at the beginning of the masked/disabled time.
• Maximum disabled time—The maximum amount of continuous time that the system spends with maskable interrupts disabled.
• Maximum masked time—The maximum amount of continuous time that the system spends with a single interrupt masked.
• Shadow register set—a complete alternate set of Nios II general-purpose registers, which can be used to maintain a separate runtime context for an ISR.

Each of the Nios II exceptions falls into one of the following categories:

• Reset exception—Occurs when the Nios II processor is reset. Control is transferred to the reset address you specify in the Nios II processor IP core setup parameters.
• Break exception—Occurs when the JTAG debug module requests control. Control is transferred to the break address you specify in the Nios II processor IP core setup parameters.
• Interrupt exception—Occurs when a peripheral device signals a condition requiring service
• Instruction-related exception—Occurs when any of several internal conditions occurs, as detailed in the Nios II Exceptions Table. Control is transferred to the exception address you specify in the Nios II processor IP core setup parameters.

The following table columns specify information for the exceptions:

• Exception—Gives the name of the exception.
• Type—Specifies the exception type.
• Available—Specifies when support for that exception is present.
• Cause—Specifies the value of the CAUSE field of the exception register, for exceptions that write the exception.CAUSE field.
• Address—Specifies the instruction or data address associated with the exception.
• Vector—Specifies which exception vector address the processor passes control to when the exception occurs.

Exception latency specifies how quickly the system can respond to an exception. Exception latency depends on the type of exception, the software and hardware configuration, and the processor state.

The interrupt controller can mask individual interrupts. Each interrupt can have a different maximum masked time. The worst-case interrupt latency for interrupt i is determined by that interrupt’s maximum masked time, or by the maximum disabled time, whichever is greater.

1. Sets status.RSIE to 1, and clears all other fields of the status register.
2. Invalidates the instruction cache line associated with the reset vector.
3. Begins executing the reset handler, located at the reset vector.

Clearing the status.PIE field disables maskable interrupts. If the MMU or MPU is present, clearing the status.U field forces the processor into supervisor mode.

Invalidating the reset cache line guarantees that instruction fetches for reset code comes from uncached memory.

Aside from the instruction cache line associated with the reset vector, the contents of the cache memories are indeterminate after reset. To ensure cache coherency after reset, the reset handler located at the reset vector must immediately initialize the instruction cache. Next, either the reset handler or a subsequent routine should proceed to initialize the data cache.

The reset state is undefined for all other system components, including but not limited to:

• General-purpose registers, except for zero (r0) in the normal register set, which is permanently zero.
• Control registers, except for status. status.RSIE is reset to 1, and the remaining fields are reset to 0.
• Instruction and data memory.
• Cache memory, except for the instruction cache line associated with the reset vector.
• Peripherals. Refer to the appropriate peripheral data sheet or specification for reset conditions.
• Custom instruction logic
• Nios II C-to-hardware (C2H) acceleration compiler logic.

For more information refer to the Nios II Custom Instruction User Guide for reset conditions.

Break processing is the means by which software debugging tools implement debug and diagnostic features, such as breakpoints and watchpoints. Break processing is a type of exception processing, but the break mechanism is independent from general exception processing. A break can occur during exception processing, enabling debug tools to debug exception handlers.

The processor enters the break processing state under either of the following conditions:

• The processor executes the break instruction. This is often referred to as a software break.
• The JTAG debug module asserts a hardware break.

1. Stores the contents of the status register to bstatus.
2. Clears status.PIE to zero, disabling maskable interrupts.

The bstatus control register and general-purpose registers bt (r25) and ba (r30) in the normal register set are reserved for debugging. Code is not prevented from writing to these registers, but debug code might overwrite the values. The break handler can use bt (r25) to help save additional registers.

After processing a break, the break handler releases control of the processor by executing a bret instruction. The bret instruction restores status by copying the contents of bstatus and returns program execution to the address in the ba register (r30) in the normal register set. Aside from bt and ba, all registers are guaranteed to be returned to their pre-break state after returning from the break handler.

• The external interrupt controller interface
• The internal interrupt controller

The Nios II processor does not depend on any particular implementation of an EIC. The degree of EIC configurability, and EIC configuration methods, are implementation-specific. This section discusses the EIC interface, and general features of EICs. For usage details, refer to the documentation for the specific EIC in your system.

When an IRQ is asserted, the EIC presents the following information to the Nios II processor:

• The requested handler address (RHA)—Refer to the Requested Handler Address section of this chapter
• The requested interrupt level (RIL)—Refer to the Requested Interrupt Level section of this chapter
• The requested register set (RRS)—Refer to Requested Register Set section of this chapter
• Requested nonmaskable interrupt (RNMI) mode—Refer to the Requested NMI Mode section of this chapter

The Nios II processor EIC interface connects to a single EIC, but an EIC can support a daisy-chained configuration. In a daisy-chained configuration, multiple EICs can monitor and prioritize interrupts. The EIC directly connected to the processor presents the processor with the highest-priority interrupt from all EICs in the daisy chain.

An EIC component can support an arbitrary level of daisy-chaining, potentially allowing the Nios II processor to handle an arbitrary number of prioritized interrupts.

For a typical EIC implementation, refer to the Vectored Interrupt Controller chapter in the Embedded Peripherals IP User Guide.

The RHA for each interrupt is typically software-configurable. The method for specifying the RHA is dependent on the specific EIC implementation.

If the Nios II processor is implemented with an MMU, the processor treats handler addresses as virtual addresses.

The RIL is ignored for nonmaskable interrupts.

The method of assigning register sets to interrupts depends on the specific EIC implementation. Register set assignments can be software-configurable.

Multiple interrupts can be configured to share a register set. In this case, the interrupt handlers must be written so as to avoid register corruption. For example, one of the following conditions must be true:

• The interrupts cannot pre-empt one another. For example, all interrupts are at the same level.
• Registers are saved in software. For example, each interrupt handler saves its own registers on entry, and restores them on exit.

Typically, the Nios II processor is configured so that when it takes an interrupt, other interrupts in the same register set are disabled. If interrupt preemption within a register set is desired, the interrupt handler can re-enable interrupts in its register set.

By default, the Nios II processor disables maskable interrupts when it takes an interrupt request. To enable nested interrupts, system software or the ISR itself must re-enable interrupts after the interrupt is taken.

status.IL and RIL are ignored for nonmaskable interrupts.

For the best interrupt performance, assign a dedicated register set to each of the most time-critical interrupts. Less-critical interrupts can share register sets, provided the ISRs are protected from register corruption as noted in the Requested Register Set section of this chapter.

The method for mapping interrupts to register sets is specific to the particular EIC implementation.

• The PIE bit of the status control register is one.
• An interrupt-request input, irqn, is asserted.
• The corresponding bit n of the ienable control register is one.

Upon hardware interrupt, the processor clears the PIE bit to zero, disabling further interrupts, and performs the other steps outlined in the "Exception Processing Flow" section of this chapter.

The value of the ipending control register shows which interrupt requests (IRQ) are pending. By peripheral design, an IRQ bit is guaranteed to remain asserted until the processor explicitly responds to the peripheral.

The Nios II processor generates the following instruction-related exceptions:

• Trap instruction
• Break instruction
• Unimplemented instruction
• Illegal instruction
• Supervisor-only instruction
• Supervisor-only instruction address
• Supervisor-only data address
• Misaligned data address
• Misaligned destination address
• Division error
• Fast TLB miss
• Double TLB miss
• TLB permission violation
• MPU region violation

For more information, refer to the "Potential Unimplemented Instructions" section of this chapter.

For information about controlling this option, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

When the processor issues an instruction with an undefined opcode or opcode-extension field, and illegal instruction exception checking is turned on, an illegal instruction exception is generated.

Refer to the OP Encodings and OPX Encodings for R-Type Instructions tables in the Instruction Set Reference chapter of the Nios II Processor Reference Handbook to see the unused opcodes and opcode extensions.

Refer to the Nios II Core Implementation Details chapter of the Nios II Processor Reference Handbook for information about each specific Nios II core.

This exception is implemented only in Nios II processors configured to use supervisor mode and user mode. Refer to the "Operating Modes" section of this chapter for more information.

This exception is implemented only in Nios II processors that include the MMU.

This exception is implemented only in Nios II processors that include the MMU.

For information about controlling this option, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

A data address is considered misaligned if the byte address is not a multiple of the width of the load or store instruction data width (four bytes for word, two bytes for half-word). Byte load and store instructions are always aligned so never take a misaligned address exception.

For information about controlling this option, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

A destination address is considered misaligned if the target byte address of the instruction is not a multiple of four.

For information about controlling this option, refer to the Instantiating the Nios II Processor chapter of the Nios II Processor Reference Handbook.

The division error exception detects divide instructions that produce a quotient that can't be represented. The two cases are divide by zero and a signed division that divides the largest negative number -2147483648 (0x80000000) by -1 (0xffffffff). Division error detection is only available if divide instructions are supported by hardware.

There are two kinds of fast TLB miss exceptions:

• Fast TLB miss (instruction)—Any instruction fetch can cause this exception.
• Fast TLB miss (data)—Load, store, initda, and flushda instructions can cause this exception.

The fast TLB miss exception handler can inspect the tlbmisc.D field to determine which kind of fast TLB miss exception occurred.

There are two kinds of double TLB miss exceptions:

• Double TLB miss (instruction)—Any instruction fetch can cause this exception.
• Double TLB miss (data)—Load, store, initda, and flushda instructions can cause this exception.

The general exception handler can inspect either the exception.CAUSE or tlbmisc.D field to determine which kind of double TLB miss exception occurred.

There are three kinds of TLB permission violation exceptions:

• TLB permission violation (execute)—Any instruction fetch can cause this exception.
• TLB permission violation (read)—Any load instruction can cause this exception.
• TLB permission violation (write)—Any store instruction can cause this exception.

The general exception handler can inspect the exception.CAUSE field to determine which permissions were violated.

• An instruction fetch or data address matched a region but the permissions for that region did not allow the action to complete.
• An instruction fetch or data address did not match any region.

The general exception handler reads the MPU region attributes to determine if the address did not match any region or which permissions were violated.

There are two kinds of MPU region violation exceptions:

• MPU region violation (instruction)—Any instruction fetch can cause this exception.
• MPU region violation (data)—Load, store, initda, and flushda instructions can cause this exception.

The general exception handler can inspect the exception.CAUSE field to determine which kind of MPU region violation exception occurred.

The fast TLB miss exception handler only handles the fast TLB miss exception. It is built for speed to process TLB misses quickly. The fast TLB miss exception handler address, specified with the Nios II Processor parameter editor in Qsys, is called the fast TLB miss exception vector in the Nios II Processor parameter editor.

• RHA—The requested handler address for the interrupt handler assigned to the requested interrupt.
• RRS—The requested register set to be used when the interrupt handler executes. If shadow register sets are not implemented, RRS must always be 0.
• RIL—The requested interrupt level specifies the priority of the interrupt.
• RNMI—The requested NMI flag specifies whether to treat the interrupt as nonmaskable.

  For further information about the RHA, RRS, RIL and RNMI, refer to “The Nios II/f Core” in the Nios II Core Implementation Details chapter of the Nios II Processor Reference Handbook.

When the EIC interface presents an interrupt to the Nios II processor, the processor uses several criteria, as follows, to determine whether to take the interrupt:

• Nonmaskable interrupts—The processor takes any NMI as long as it is not processing a previous NMI.
• Maskable interrupts—The processor takes a maskable interrupt if maskable interrupts are enabled, and if the requested interrupt level is higher than that of the interrupt currently being processed (if any). However, if shadow register sets are implemented, the processor takes the interrupt only if the interrupt requests a register set different from the current register set, or if the register set interrupt enable flag (status.RSIE) is set.

  Table 45.  Conditions Required to Take External Interrupt

  RNMI == 1		RNMI == 0
  status.NMI == 0	status.NMI == 1	status.PIE == 0	status.PIE == 1
  			RIL <= status.IL	RIL > status.IL
  				Processor Has Shadow Register Sets			No Shadow Register Sets
  				RRS == status.CRS		RRS != status.CRS
  				status.RSIE == 0	status.RSIE == 1
  Yes	No	No	No	No 17	Yes	Yes	Yes

The Nios II processor supports fast nested interrupts with shadow register sets, as described in  the "Shadow Register Set" section of this chapter.

Keeping status.PIE set allows higher level interrupts to be taken immediate, without requiring the interrupt handler to set status.PIE to 1.

The processor disables maskable interrupts when taking an exception, just as it does without shadow register sets. An individual interrupt handler can re-enable interrupts by setting status.PIE to 1, if desired.

Interrupts can be re-enabled by writing one to the PIE bit, thereby allowing the current ISR to be interrupted. Typically, the exception routine adjusts ienable so that IRQs of equal or lower priority are disabled before re-enabling interrupts.

Refer to "Handling Nested Exceptions” for more information.

Refer to the Nios II Exceptions table for more information in the Exception Overview section.

To determine the cause of an exception, simply read the cause of the exception from exception.CAUSE and then transfer control to the appropriate exception routine.

When the extra exception information is not available, use the sequence in the example below to determine the cause of an exception.

• An exception handler enables maskable interrupts
• An EIC is present, and an NMI occurs
• An EIC is present, and the processor is configured to keep maskable interrupts enabled when taking an interrupt
• An exception handler triggers an instruction-related exception

  For details about when the Nios II processor takes exceptions, refer to “Exception Processing Flow” on page 3–44.

For details about unimplemented instructions, refer to the Processor Architecture chapter of the Nios II Processor Reference Handbook.

For details about MMU and MPU exceptions, refer to the Instruction-Related Exceptions section of this chapter.

A system can be designed to eliminate the possibility of nested exceptions. However, if nested exceptions are possible, the exception handlers must be carefully written to prevent each handler from corrupting the context in which a pre-empted handler runs.

If an exception handler issues a trap instruction, an optional instruction, or an instruction which could generate an MMU or MPU exception, it must save and restore the contents of the estatus and ea registers.

When individual external interrupts have dedicated shadow register sets, the Nios II processor supports fast interrupt handling with no overhead for saving register contents. To take full advantage of fast interrupt handling, system software must set up certain conditions. With the following conditions satisfied, ISRs need not save and restore register contents on entry and exit:

• Automatic nested interrupts are enabled.
• Each interrupt is assigned to a dedicated shadow register set.
• All interrupts with the same RIL are assigned to dedicated shadow register sets.
• Multiple interrupts with different RILs can be assigned to a single shadow register set. However, with multiple register sets, you must not allow the RILs assigned to one shadow register set to overlap the RILs assigned to another register set.

  The following tables demonstrate the validity of register set assignments when preemption within a register set is enabled.