Eclipse-->Run-->Run Configuration doesn't burn elf to ROM in NIOS II
- 7 months ago
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.