Teach lesson
Nios V on DE1-SoC (1/5): First run
Students open Nios V CodeIDE on the DE1-SoC, run the prebuilt hello.elf program, and record JTAG UART terminal evidence from the real board.
Learning Outcomes
Run a prebuilt ELF on the fixed DE1-SoC Nios V system.
Identify Nios V as a RISC-V soft-core CPU implemented inside the FPGA.
Distinguish the fixed FPGA system image from the student ELF program.
Use the JTAG UART terminal as observable program output.
Student activity preview
Activity Content
Preview only. In a class session, students can fill in responses and submit their work to the teacher.
Fixed FPGA system, uploaded program
8 min
Goal of this first run: prove that a known software program can run on a real Nios V processor inside the DE1-SoC FPGA, and learn which parts of the system are fixed before you start editing code in later lessons.
An FPGA is a reconfigurable chip: its internal logic can be configured to behave like a digital system. In this lab, the DE1-SoC FPGA is already configured with the FPGAcademy DE1-SoC Computer with Nios V. You will not upload a custom .sof hardware image in this workshop.
RISC-V is an instruction set architecture: a specification for the instructions, registers, and basic execution model a compatible processor understands. Nios V is Intel's FPGA soft-core implementation of a RISC-V processor. "Soft-core" means the CPU is built from FPGA logic instead of being a separate fixed processor chip.
What you control in this lesson is the selected software program: a prebuilt Nios V ELF file. The .sof describes the FPGA hardware system: CPU, memory, and memory-mapped peripherals. The .elf contains the program instructions and data that the Nios V CPU executes inside that already-configured hardware system.
You will not edit source code in this first lesson. Code editing starts in Lesson 2. Here, the point is to connect the file you upload with the evidence you see: the JTAG UART terminal should print the message from the program.
The prebuilt hello.elf comes from a tiny program like this:
#include <stdio.h>
int main(void) {
printf("Hello from Nios V\n");
while (1) {
}
}
Useful references:
- Intel Nios V Processor
- Intel FPGA and Embedded Processors Overview
- FPGAcademy DE1-SoC Computer with Nios V
- RISC-V International: About RISC-V
You do not need to read all of those references before continuing. For this first lesson, use the explanations above as the required subset. The links are there so you can verify where Nios V, RISC-V, and the FPGAcademy DE1-SoC system fit in the larger ecosystem.
The fixed .sof hardware image is prepared server-side. In this workshop, your job is to select, build, or upload the .elf program and observe what it does through the terminal and board peripherals.
In your own words, what is the difference between the fixed .sof system image and the .elf program in this lab?
The program does not move motors or draw graphics. What output should you look for to know that hello.elf ran?
Run hello.elf
12 min
Open the Nios V upload lab and use the preloaded hello.elf program. This upload-only entry lets you select and run an ELF file; it does not show or edit the program source code.
Open the
Nios V for DE1-SoCupload-only entry.Select
hello.elfas the Nios V program if it is not already selected.Click
Verify program.Click
Upload to FPGA.Wait for the board session and the JTAG UART console.
Look for at least one
Hello from Nios Vline in the console.
After you run hello.elf, record the selected file, the exact console text you saw, whether the board session opened, and any delay or issue.
| Selected ELF | Console text observed | Board session opened? | Issue or delay observed |
|---|---|---|---|
Record the exact JTAG UART console line that proves the ELF ran. The expected line is Hello from Nios V. If the same line appears more than once, record that too; it can happen when the terminal reconnects or the program is re-run.
Workflow map
10 min
The upload-only workflow has several steps. Each step exists for a reason.
Which sequence best describes what happened?
This lab provides build/upload/run plus terminal and hardware observation. What kind of debugging support is not part of the current workflow?
Exit ticket
5 min
Write a three-sentence summary of the lab workflow: what hardware system was used, what file you ran, and how you observed the result.