1. About the Nios® V Embedded Processor
2. Nios® V Processor Hardware System Design with Quartus® Prime Software and Platform Designer
3. Nios® V Processor Software System Design
4. Nios® V Processor Configuration and Booting Solutions
5. Nios® V Processor - Using the MicroC/TCP-IP Stack
6. Nios® V Processor Debugging, Verifying, and Simulating
7. Nios® V Processor — Remote System Update
8. Nios® V Processor — Using Custom Instruction
9. Nios® V Embedded Processor Design Handbook Archives
10. Document Revision History for the Nios® V Embedded Processor Design Handbook
2.1. Creating Nios® V Processor System Design with Platform Designer
2.2. Integrating Platform Designer System into the Quartus® Prime Project
2.3. Designing a Nios® V Processor Memory System
2.4. Clocks and Resets Best Practices
2.5. Assigning a Default Agent
2.6. Assigning a UART Agent for Printing
2.7. JTAG Signals
2.8. Optimizing Platform Designer System Performance
4.1. Introduction
4.2. Linking Applications
4.3. Nios® V Processor Booting Methods
4.4. Introduction to Nios® V Processor Booting Methods
4.5. Nios® V Processor Booting from On-Chip Flash (UFM)
4.6. Nios® V Processor Booting from General Purpose QSPI Flash
4.7. Nios® V Processor Booting from Configuration QSPI Flash
4.8. Nios® V Processor Booting from On-Chip Memory (OCRAM)
4.9. Nios® V Processor Booting from Tightly Coupled Memory (TCM)
4.10. Summary of Nios® V Processor Vector Configuration and BSP Settings
4.11. Reducing Nios® V Processor Booting Time
6.2.3.2.1. Enabling Signal Tap Logic Analyzer
6.2.3.2.2. Adding Signals for Monitoring and Debugging
6.2.3.2.3. Specifying Trigger Conditions
6.2.3.2.4. Assigning the Acquisition Clock, Sample Depth, and Memory Type, and Buffer Acquisition Mode
6.2.3.2.5. Compiling the Design and Programming the Target Device
6.6.1. Prerequisites
6.6.2. Setting Up and Generating Your Simulation Environment in Platform Designer
6.6.3. Creating Nios V Processor Software
6.6.4. Generating Memory Initialization File
6.6.5. Generating System Simulation Files
6.6.6. Running Simulation in the QuestaSim Simulator Using Command Line
4.5.2. Nios® V Processor Application Execute-In-Place from UFM
The Execute-In-Place from UFM solution is suitable for Nios® V processor applications which require limited on-chip memory usage. The alt_load() function operates as a mini boot copier that copies the data sections (.rodata, .rwdata, or .exceptions) from boot memory to RAM based on the BSP settings. The code section (.text), which is a read only section, remains in the MAX® 10 On-chip Flash memory region. This setup minimizes the RAM usage but may limit the code execution performance as access to the flash memory is slower than the on-chip RAM.
The Nios® V processor application is programmed into the UFM sector. The Nios® V processor's reset vector points to the UFM base address to execute code from the UFM after the system resets.
If you are using the source-level debugger to debug your application, you must use a hardware breakpoint. This is because the UFM does not support random memory access, which is necessary for soft breakpoint debugging.
Note: You cannot erase or write UFM while performing execute-in-place in the MAX® 10. Sswitch to boot copier approach if you need to erase or write the UFM.
Figure 33. Nios® V Processor Application XIP from UFM