- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I get new questions about burning ROM or flash.
in my Cyclone 10 FPGA, I instance NIOS II, RAM(120KB), ROM(80KB), UART, JTAG, but no EPCS Flash controller as which is not supported by Cyclone 10 family.
I am able to program jic file via JTAG and the tool: Quartus-->Tools-->Programmer.
but I can't add elf file to Quartus-->Tools-->Programmer. elf type file is not supported by Programmer which supports 5 types(sof, pof, jam, jbc, ekp, jic).
Eclipse-->NIOS II -->Flash Programmer, I can't program elf as well, because:
1) The tools report error: Target is broken and needs to be reset, however, Quartus-->Tools-->Programmer is able connect and burn jic file to flash.
2) I don't know where the elf is burned through Flash Programmer?
Eclipse-->Run-->Run Configuration, by this tool, I can
is there any detailed guide that tells me how to burn elf file to ROM that I instance in FPGA?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Answer for 1 and 3
.sopcinfo file does contain all IP base addresses and other configuration details (like IRQ, width, type, etc.) used in your Platform Designer system. These addresses are used by the Nios II HAL and BSP to generate C headers like system.h.
Specifically:
- system.h uses .sopcinfo to define macros like #define MY_IP_BASE 0x00081100
- The BSP tool parses .sopcinfo to generate device driver stubs and address definitions
For automated driver access, always include #include "system.h" in your Nios II C code.
Example for adding multiple UARTs in Platform Designer and generate the BSP, each UART will have its own macro name in system.h, like:
- #define UART_0_BASE ...
#define UART_1_BASE ...
#define UART_2_BASE ...
To use each UART explicitly:
1. For printf()
Set one UART as the STDOUT device in BSP Editor or settings.bsp:
#define ALT_STDOUT_UART_NAME "uart_0"
2. For communication or custom access
Use HAL API functions with explicit base addresses:
#include "altera_avalon_uart.h"
#include "system.h"
altera_avalon_uart_write(UART_1_BASE, 'A');
char c = altera_avalon_uart_read(UART_2_BASE, 0, &status);
You must manually manage which UART is used for which purpose by assigning consistent names (uart_for_jtag, uart_for_mcu, etc.) and referencing the correct *_BASE and *_IRQ macros
Answer for 2
In Platform Designer the pll_slave port on the ALTPLL IP is simply its Avalon‑MM “control/status register” interface. It lets Nios II read and write the PLL’s configuration and status registers at run‑time (e.g. to tweak phase, reconfigure frequencies, or poll the “locked” bit).
When you do not need to hook up pll_slave
- Static, compile‑time configuration: If you’re happy with the PLL settings you picked in the megafunction GUI (or tcl script) and you never intend to change them in software, you can leave pll_slave unconnected. The FPGA will still configure the PLL exactly as you specified before you even boot Nios II.
- No driver/library support: If you don’t plan on writing C code to poke the PLL’s registers (or you’re not going to use Altera’s ALTPLL_RECONFIG API), it’s dead weight.
When you should connect pll_slave
Dynamic reconfiguration: If you want your Nios II code to call into Altera’s PLL‑reconfig library (for example, the altpll_reconfig BSP component) to adjust the output frequency or phase on the fly, you must wire pll_slave up to your system bus:
- In Platform Designer, connect pll_slave to your Nios II’s data_master (and/or to the same interconnect as your other CSR ports).
- Export its base address (double‑click its port on the “Export” column) so that system.h sees something like #define ALTPLL_SLAVE_BASE 0x...?.
- Then in C you can use the reconfig API e.g.
#include "altera_pll_reconfig.h" ALT_PLL_RECONFIG_INSTANCE (my_pll, ALTPLL_SLAVE); altpll_init(&my_pll); // … later … altpll_reconfig(&my_pll, ALTPLL_RECONFIG_CMD_MHZ(100)); |
Status monitoring: Even if you never change frequencies, you might want to poll the PLL’s “locked” status bit to gate your system reset. That also requires the slave port.
Bottom line:
- No—you can safely leave pll_slave unconnected if you only need a fixed PLL setting, and you aren’t going to touch it from software.
- Yes—wire it up to your Nios II’s Avalon-MM bus (and export its CSR address) if you plan to use the Altera PLL reconfiguration/status API in your C code.
In the ALTPLL IP you see two “c” ports—c0 and c1—these are simply the PLL’s clock outputs. When you open the megafunction GUI you told it to generate up to N outputs (each can be a different frequency or phase), and they get named c0, c1, c2, … in the Qsys schematic.
- c0 is your first PLL output clock (often used as your main system clock)
- c1 is your second PLL output clock (maybe configured to a different frequency or phase)
What to do with them:
If you only need one clock domain
- Use c0 to drive all of your logic (for example connect c0 to the Nios II clk input).
- You can leave c1 un‑connected in Qsys—nothing bad happens.
If you need multiple clock domains
- Wire c0 into the clk input of the modules you want at frequency/phase #0.
- Wire c1 into any other modules that need the second frequency/phase.
Thanks.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Depending on your approach, if you are using nios2-download to program the .elf, you may refer to https://www.intel.com/content/www/us/en/docs/programmable/683218/21-2-1-5-1/generating-and-downloading-the-programming.html
but if you are using nios flash programmer, you may refer to https://www.intel.com/content/www/us/en/docs/programmable/683118/current/search.html?q=elf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here’s an updated and streamlined guide for embedding a Nios II .elf into FPGA ROM, using Intel’s official elf2hex documentation (Doc 683282):
Goal:
Embed a Nios II application (ELF) into on-chip ROM on Cyclone 10, using a .hex file generated via elf2hex, as defined in Altera's current best practices.
Required Tools:
Quartus + Platform Designer (Qsys)
Nios II Embedded Design Suite (EDS)
elf2hex utility (part of Nios II EDS)
Your compiled app.elf
Step-by-Step Flow (Updated per Intel Doc 683282)
1. Build the ELF
Compile your Nios II application normally (Debug or Release). Make sure the reset and exception vectors point to the on-chip ROM base address.
Result: app.elf with code + debug info.
2. Use elf2hex to Generate Memory Init File
elf2hex \
--input=app.elf \
--output=rom_init.hex \
--base=0x00000000 \
--end=0x00013FFF \
--width=32 \
--record-bytes=4
Key flags explained (from Intel doc 683282):
--input and --output: ELF in, HEX out
--base/--end: match the ROM’s address range
--width: memory data width (bits)
--record-bytes: bytes per memory word (typically 4 for 32-bit)
Note: Use correct ROM start address and size from Platform Designer.
3. Configure On-Chip ROM in Platform Designer
Add On-Chip Memory (ROM) component.
Set:
Memory size: match ELF footprint (e.g. 80 KB)
Data width: e.g. 32 bits
Contents: enable and point to rom_init.hex
Mode: ROM
4. Add to Quartus Project
If using command line:
Add meminit.qip (if using make mem_init_generate)
Or manually:
Add .hex to the memory IP via GUI
Ensure it’s included in the Quartus project file list
5. Compile Design
Run full Quartus compile
6. Program FPGA
Use Quartus Programmer to flash the .sof or .jic to FPGA or configuration flash.
Your program is now burned into ROM and runs at power-up.
7. Debug Using ELF (Optional)
In Eclipse/Nios II Debug Config:
Set ELF file
Uncheck “Download ELF to target”
Use JTAG to attach to running program
You can still set breakpoints and inspect variables using debug symbols.
Notes:
elf2hex (Doc 683282) replaces older positional usage with long-option flags.
If you have RAM for .data/.bss, ensure it’s initialized or writable.
Avoid writing to ROM; it’s for code and read-only sections.
Altera Reference:
Full official elf2hex usage documentation (Doc ID 683282):
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you!
please refer to my design in above picture.
I tried many times, but I cannot program flash. Finally, I found out one way:
1) add ROM, and Contents: enable and point to rom_init.hex which is compiled in Eclipse-->Project right mouse key --> Make Targets-->Build-->mem_init_generate
2) re-compile project in Quartus.
3) Quartus-->File --> Convert Programming Files-->convert sof file to jic
4) Quartus -->Tools-->Programmer--> program the jic file
5) Eclipse --> Run, the C code could be run to NIOS II RAM.
I got a few questions even though I could program and run the c code:
1) there is NIOS and an IP in my FPGA, I would like to access the IP(address is: 0x0008_1100 - 0x0008_11ff) register, what is the address of IP's register in NIOS C code?
2) what is pll_slave in the following picture? should I connect it or not?
3) I add 3 UART, when I call uart API in Eclipse to send/receive UART data, how to specify which UART is used in NIOS C code? For example, I added 3 UART. One UART is for printf, and the second one is for communication with another MCU, and the third one is for programming from computer. how to specify which UART is used for each purpose I mentioned?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Answer for 1 and 3
.sopcinfo file does contain all IP base addresses and other configuration details (like IRQ, width, type, etc.) used in your Platform Designer system. These addresses are used by the Nios II HAL and BSP to generate C headers like system.h.
Specifically:
- system.h uses .sopcinfo to define macros like #define MY_IP_BASE 0x00081100
- The BSP tool parses .sopcinfo to generate device driver stubs and address definitions
For automated driver access, always include #include "system.h" in your Nios II C code.
Example for adding multiple UARTs in Platform Designer and generate the BSP, each UART will have its own macro name in system.h, like:
- #define UART_0_BASE ...
#define UART_1_BASE ...
#define UART_2_BASE ...
To use each UART explicitly:
1. For printf()
Set one UART as the STDOUT device in BSP Editor or settings.bsp:
#define ALT_STDOUT_UART_NAME "uart_0"
2. For communication or custom access
Use HAL API functions with explicit base addresses:
#include "altera_avalon_uart.h"
#include "system.h"
altera_avalon_uart_write(UART_1_BASE, 'A');
char c = altera_avalon_uart_read(UART_2_BASE, 0, &status);
You must manually manage which UART is used for which purpose by assigning consistent names (uart_for_jtag, uart_for_mcu, etc.) and referencing the correct *_BASE and *_IRQ macros
Answer for 2
In Platform Designer the pll_slave port on the ALTPLL IP is simply its Avalon‑MM “control/status register” interface. It lets Nios II read and write the PLL’s configuration and status registers at run‑time (e.g. to tweak phase, reconfigure frequencies, or poll the “locked” bit).
When you do not need to hook up pll_slave
- Static, compile‑time configuration: If you’re happy with the PLL settings you picked in the megafunction GUI (or tcl script) and you never intend to change them in software, you can leave pll_slave unconnected. The FPGA will still configure the PLL exactly as you specified before you even boot Nios II.
- No driver/library support: If you don’t plan on writing C code to poke the PLL’s registers (or you’re not going to use Altera’s ALTPLL_RECONFIG API), it’s dead weight.
When you should connect pll_slave
Dynamic reconfiguration: If you want your Nios II code to call into Altera’s PLL‑reconfig library (for example, the altpll_reconfig BSP component) to adjust the output frequency or phase on the fly, you must wire pll_slave up to your system bus:
- In Platform Designer, connect pll_slave to your Nios II’s data_master (and/or to the same interconnect as your other CSR ports).
- Export its base address (double‑click its port on the “Export” column) so that system.h sees something like #define ALTPLL_SLAVE_BASE 0x...?.
- Then in C you can use the reconfig API e.g.
#include "altera_pll_reconfig.h" ALT_PLL_RECONFIG_INSTANCE (my_pll, ALTPLL_SLAVE); altpll_init(&my_pll); // … later … altpll_reconfig(&my_pll, ALTPLL_RECONFIG_CMD_MHZ(100)); |
Status monitoring: Even if you never change frequencies, you might want to poll the PLL’s “locked” status bit to gate your system reset. That also requires the slave port.
Bottom line:
- No—you can safely leave pll_slave unconnected if you only need a fixed PLL setting, and you aren’t going to touch it from software.
- Yes—wire it up to your Nios II’s Avalon-MM bus (and export its CSR address) if you plan to use the Altera PLL reconfiguration/status API in your C code.
In the ALTPLL IP you see two “c” ports—c0 and c1—these are simply the PLL’s clock outputs. When you open the megafunction GUI you told it to generate up to N outputs (each can be a different frequency or phase), and they get named c0, c1, c2, … in the Qsys schematic.
- c0 is your first PLL output clock (often used as your main system clock)
- c1 is your second PLL output clock (maybe configured to a different frequency or phase)
What to do with them:
If you only need one clock domain
- Use c0 to drive all of your logic (for example connect c0 to the Nios II clk input).
- You can leave c1 un‑connected in Qsys—nothing bad happens.
If you need multiple clock domains
- Wire c0 into the clk input of the modules you want at frequency/phase #0.
- Wire c1 into any other modules that need the second frequency/phase.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your reply!
one more question is:
which header file I should include in C code to use the api altera_avalon_uart_write?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You should include <altera_avalon_uart.h> in C code.
https://www.intel.com/content/www/us/en/docs/programmable/683130/24-3/uart-api-41542.html
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I perhaps know the reason why it is blank in the following picture.
I didn't add a flash controller in Platform Designer.
The reason why I cannot add flash controller in Platform Designer is that the flash I am using (M25P64 which is EPCS64) is not supported by Cyclone 10 family.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page