Visible to Intel only — GUID: wim1638455571875
Ixiasoft
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
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 Configuration QSPI Flash
4.6. Nios® V Processor Booting from On-Chip Memory (OCRAM)
4.7. Nios® V Processor Booting from Tightly Coupled Memory (TCM)
4.8. Summary of Nios® V Processor Vector Configuration and BSP Settings
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
Visible to Intel only — GUID: wim1638455571875
Ixiasoft
4.4.2.1. Nios® V Processor Bootloader via Generic Serial Flash Interface
The Bootloader via GSFI is the Nios® V processor boot copier that supports QSPI flash memory in control block-based devices. The Bootloader via GSFI includes the following features:
- Locates the software application in non-volatile memory.
- Unpacks and copies the software application image to RAM.
- Automatically switches processor execution to application code in RAM after copy completes.
The boot image is located right after the boot copier. You need to ensure the Nios® V processor reset offset points to the start of the boot copier. The Figure: Memory Map for QSPI Flash with Bootloader via GSFI memory map for QSPI Flash with Bootloader via GSFI shows the flash memory map for QSPI flash when using a boot copier. This memory map assumes the flash memory memory stores the FPGA image and the application software.
Nios® V Processor Core | Bootloader via GSFI File Location |
---|---|
Nios® V/m processor | <Intel Quartus Installation Directory>/niosv/components/bootloader/niosv_m_bootloader.srec |
Nios® V/g processor | <Intel Quartus Installation Directory>/niosv/components/bootloader/niosv_g_bootloader.srec |
Figure 14. Memory Map for QSPI Flash with Bootloader via GSFI
Note:
- At the start of the memory map is the FPGA image followed by your data, which consists of boot copier and application code.
- You must set the Nios® V processor reset offset in Platform Designer and point it to the start of the boot copier.
- The size of the FPGA image is unknown.You can only know the exact size after the Quartus® Prime project compilation. You must determine an upper bound for the size of the Intel FPGA image. For example, if the size of the FPGA image is estimated to be less than 0x01E00000, set the Reset Offset to 0x01E00000 in Platform Designer, which is also the start of the boot copier.
- A good design practice consists of setting the reset vector offset at a flash sector boundary to ensure no partial erase of the FPGA image occurs in case the software application is updated.