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 hardware reference designs included in an 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 -provided reference design, you can copy the reference design and use it without modification in the final hardware platform. Otherwise, you can customize the processor system until it meets cost or performance requirements.

Because the pins and logic resources in FPGA 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 processor system consumes only 5% of a large 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 processor system. FPGA offers a library of peripherals that easily connect to processor systems.

You are not required to create a new processor configuration for every new design. FPGA provides ready-made 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.

FPGA 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 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 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 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 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 processors.
• Program a device and verify your design in hardware.

You only need to purchase a license for the 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 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 cores supports what features, refer to the Core Implementation Details chapter of the Processor Reference Handbook.

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

The 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 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 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 Processor Reference Handbook.

For details about the rdprs and wrprs instructions, refer to the Instruction Set Reference chapter of the 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 Processor Reference Handbook.

For more information about adding reset signals and debug signals to the processor, refer to Advanced Features Tab and JTAG Debug Module Tab in the Instantiating the Processor chapter respectively.

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

The EIC selects among active interrupts and presents one interrupt to the 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 processor does not depend on any specific interrupt prioritization scheme in the EIC.

For every external interrupt, the EIC presents an interrupt level. The 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 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 FPGA vectored interrupt controller component, and thus is deprecated in . recommends using the EIC interface.

The flexible nature of the Nios II memory and I/O organization are the most notable difference between processor systems and traditional microcontrollers. Because 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 ^® Memory-Mapped (-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 -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 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 -MM master ports that adhere to the -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, 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 -MM master port. Support for pipelined -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 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 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 processor core might include one, both, or neither of the cache memories. Furthermore, for cores that provide data as well as 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 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 ldwio and stwio bypass the data cache and force an -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 Processor Reference Handbook.

cores optionally support a new peripheral region mechanism to indicate cacheability. The peripheral region cacheability mechanism allows a user at generation time to specify a region of address space that is treated as non-cacheable. The peripheral region is any integer power of 2 bytes from a minimum of 4096 bytes up to a maximum of 2 GBytes and must be located at a base address aligned to the size of the peripheral region. The peripheral region is available as long as an MMU is not present.

• 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 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.

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 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 Processor Reference Handbook.

You can optionally include the MMU when you instantiate the processor in your 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 Processor chapter of the 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 Processor Reference Handbook.

You can optionally include the MPU when you instantiate the processor in your 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 Processor chapter of the 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 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 Processor parameter editor in .

Soft processor cores such as the processor offer unique debug capabilities beyond the features of traditional, fixed processors. The soft nature of the 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 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 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 systems have simpler requirements where minimal system software or a small-footprint operating system (such as the FPGA^® 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 processor. Do not include an MMU in your 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 processor’s precise exceptions enable the system software to update the TLB, and then re-execute the instruction if desired.

The 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 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 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 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.

MPU protects user application. Therefore for interrupt service, the system must have access to the regions that may cause potential violation because MPU generates exception post access and does not prevent access to the memory region in hardware.

• 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 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 architecture supports up to 32 control registers. All non-reserved control registers have names recognized by the assembler.

The following sections describe the non-reserved 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 architecture supports up to 32 control registers. All non-reserved control registers have names recognized by the assembler.

The following sections describe the non-reserved control registers.

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

When the 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 Processor chapter of this document.

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 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 Processor chapter of this document.

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 Exceptions Table lists which exceptions write the badaddr register along with the value written.

When an exception occurs in /f processor, the badaddr register contains the byte instruction or data address associated with certain exceptions at the time the exception occurred. The 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 24-bit BASE field corresponds to bits 8 through 31 of the base address, making the base address always a multiple of 256 bytes. If the minimum region size (set in at generation time) is larger than 256 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 two least-significant bits of the BASE field (bits 8 through 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 can 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 generation-time option controls whether the mpuacc register contains a MASK or LIMIT field.

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.

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 >> 8) and the LIMIT field is set to 0x50 (0x5000 >> 8). 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 ldwio or stwio 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 ldwio or stwio instruction. The encoding of the MT field is setup to be backwards-compatible with the 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 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 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 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.MT, 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.MT, 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, FPGA 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 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.

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.

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 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).

Software running on the cannot directly inject an ECC error in an ITCM because the only writes ITCMs when correcting ECC errors. To inject an ECC in an ITCM, the TCM RAM must also be connected to a DTCM master. The provided DTCM error injection mechanism (i.e. ECCINJ register) is used to inject an error in the TCM RAM as follows:

1. Use a WRCTL instruction to set ECCINJ so that it injects ECC errors in the DTCM connected to the ITCM.
2. Use a STW instruction to write the DTCM.
3. Use a RDCTL instruction to ensure the value of the ECCINJ field written by the WRCTL is NOINJ.
4. Use a JMP instruction to jump to an instruction address in the ITCM.
5. The ECC error should be triggered on the target of the JMP instruction.

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 LOAD instruction from a data address to get the line in the cache. The line should be clean.
2. Use a WRCTL instruction to set ECCINJ.DCTAG to INJS or INJD.
3. Use a STORE instruction from a data address mapped to that line. The STORE instruction should hit in the data cache and write the tag RAM to set the dirty bit.
4. The ECC error is injected when the tag RAM is written.
5. Use a RDCTL instruction to ensure the value of ECCINJ.DCTAG is NOINJ. Before the RDCTL, use a FLUSHP instruction to avoid the RAW hazard on ECCINJ.
6. Do another LOAD or STORE instruction to the same line.
7. The ECC error should be triggered on this second LOAD/STORE instruction.

1. Use a FLUSHDA instruction to ensure the line isn’t in the data cache.
2. Use a LOAD instruction to load a clean data cache line.
3. Use a WRCTL instruction to set ECCINJ.DCDAT field to INJS or INJD.
4. Use a LOAD instruction to an address in the data cache line to inject the error.
5. Use a RDCTL instruction to ensure the values of the field written by the WRCTL to ECCINJ is NOINJ. Before the RDCTL, use a FLUSHP instruction to avoid the RAW hazard on ECCINJ.
6. Use a LOAD instruction from the same address.
7. The ECC error should be triggered on the LOAD instruction.

1. Use a LOAD instruction to load a data cache line.
2. Use a WRCTL instruction to set ECCINJ.DCDAT field to INJS or INJD (as desired).
3. Use a STORE instruction to an address in the data cache line.
4. Use a RDCTL instruction to ensure the values of the field written by the WRCTL to ECCINJ is NOINJ. Before the RDCTL, use a FLUSHP instruction to avoid the RAW hazard on ECCINJ.
5. Either use a LOAD instruction from the same address or trigger a writeback of the dirty line (e.g. FLUSHDA instruction)
6. The ECC error should be triggered on the LOAD instruction unless it is only detected during the writeback of a dirty line. In the writeback of a dirty line case, the ECC error is triggered an undefined number of instructions later.

1. Use a LOAD instruction to load a data cache line.
2. Use a WRCTL instruction to set ECCINJ.DCWB field to INJS or INJD (as desired).
3. Use a STORE instruction to an address in the data cache line.
4. Use a RDCTL instruction to ensure the values of the field written by the WRCTL to ECCINJ is NOINJ. Before the RDCTL, use a FLUSHP instruction to avoid the RAW hazard on ECCINJ.
5. Either use a LOAD instruction from the same address or trigger a writeback of the dirty line (e.g. FLUSHDA instruction)
6. The ECC error should be triggered on the LOAD instruction unless it is only detected during the writeback of a dirty line. In the writeback of a dirty line case, the ECC error is triggered an undefined number of instructions later.

1. Use a WRCTL instruction to set the ECCINJ.DTCM field to INJS or INJD for the desired DTCM.
2. Use a STW instruction to write an address in the DTCM.
3. Use a RDCTL instruction to ensure the value of the field written by the WRCTL to ECCINJ is NOINJ.
4. Use a LOAD instruction from the same address in the DTCM.
5. The ECC error should be triggered on the LOAD instruction.

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 is injected at this time and any associated uTLB entry can 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 processor. The internal interrupt controller is available in all revisions of the processor.
• Vectored interrupt controller (VIC)—an -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 non-overhead exception code, that is, specific to the exception type (device).
• Global interrupts—All maskable exceptions on the 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 processor is reset. Control is transferred to the reset address you specify in the 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 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 Exceptions Table. Control is transferred to the exception address you specify in the 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 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 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 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 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 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 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 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 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 Processor chapter of the 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 Processor Reference Handbook to see the unused opcodes and opcode extensions.

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

This exception is implemented only in 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 processors that include the MMU.

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

For information about controlling this option, refer to the Instantiating the Processor chapter of the 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 Processor chapter of the Processor Reference Handbook.

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

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 Processor parameter editor in , is called the fast TLB miss exception vector in the 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 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 53.  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 14	Yes	Yes	Yes

The 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.