Teach Remote lab lessons

Teach lesson

Nios V on DE1-SoC (5/5): Tiny embedded hardware UI

Students design a tiny embedded hardware UI on Nios V, combining inputs, LEDs, HEX output, submitted code, and live hardware-test evidence.

  • Nios V for DE1-SoC
  • 50 min
  • Undergraduate CS/CE
  • English
  • Digital systems & FPGA ยท Embedded systems
Sign in to create a class session Have a class code?
Nios V for DE1-SoC
Nios V for DE1-SoC

Learning Outcomes

  • Design a small embedded behavior using memory-mapped I/O.

  • Choose C or RISC-V assembly based on implementation tradeoffs.

  • Use NSW/LEDR plus at least one validated extension peripheral.

  • Optionally use NB0..NB3 as logical JP1 button inputs.

  • Submit code, explanation, and hardware evidence.

Student activity preview

Activity Content

Preview only. In a class session, students can fill in responses and submit their work to the teacher.

1

Design brief

8 min

Design a small program for the DE1-SoC Nios V system. Start from a previous lesson example and adapt it; do not start from a blank file in this 50-minute version. Your program must use:

A fresh lab launch opens the starter source again. "Start from a previous
lesson example" means copy or recreate the relevant part of a previous example
and adapt it for this capstone, not that your earlier edits automatically carry
over into the new lab session.

- NSW0..NSW9 or another validated input source.
- LEDR0..LEDR9 or another validated output source.
- At least one validated extension peripheral from Lesson 4: HEX display or interval timer.

You may write C or RISC-V assembly. Use C if you want to focus on behavior and register use. Use assembly only if you can already trace the Lesson 3 load, store, shift, mask, and jump loop confidently.

Validated input sources are NSW0..NSW9 through JP1 bits 5 through 14 and NB0..NB3 through JP1 bits 0 through 3. Do not use FPGAcademy KEY0..KEY3 register exercises in this self-contained version; the current validated profile uses NB0..NB3 for button-like input.

Reference set for this design:

- Use the FPGAcademy DE1-SoC Computer with Nios V manual for the fixed system memory map, HEX display, and timer registers.
- Use Lesson 2 for the validated NSW to JP1 to LEDR path.
- Use Lesson 4 for the validated HEX display, timer, and optional NB button paths.

Capstone design pattern connecting validated inputs, student code, validated outputs, and evidence

A successful capstone keeps the design small: choose validated inputs, write one clear C or assembly behavior, observe validated outputs, and record evidence.

Keep the scope deliberately small. A finished capstone is better than an ambitious design that cannot be tested. Your minimum viable behavior should fit this pattern: one input pattern, one visible output rule, and one extension peripheral effect.

Which implementation path will you use?

Describe the behavior you plan to build. Include the input, the output, and the extension peripheral you will use.

State the smallest version that would still count as success. For example: "NSW0..NSW3 select a value, LEDR0..LEDR3 mirror it, and HEX0 displays the same low nibble."

2

Constraints

6 min

Your design must stay inside the current LabsLand Nios V workflow:

- Do not upload a custom .sof.
- Do not rely on source-level debugging or breakpoints.
- Do not use VGA, audio, ADC, PS/2, IrDA, serial-port, or video-in workflows.
- Use NSW0..NSW9 for the LabsLand logical switch controls. Do not call them the physical SW0..SW9 port.
- If you use buttons, call them NB0..NB3 and read them through JP1/GPIO. Do not call them KEY0..KEY3.

Which constraint is most important for your design, and why?

3

Build and test

24 min

  1. Open the C or assembly Nios V CodeIDE entry.

  2. Implement your small behavior.

  3. Click Build ELF.

  4. Upload it to the FPGA.

  5. Test at least three input/output cases.

  6. Record the result of each case.

Record at least three tests of your capstone. Use one row per input or behavior case: write the case, predict the visible result, test on the board, then mark pass, fail, or uncertain.

Test case Expected behavior Observed behavior Pass/fail

Submit the final source code or the key loop/function if the full file is too long.

Submit a short hardware evidence summary. Include terminal output, LED/HEX observations, or screenshots if available.

4

Explain the design

9 min

Explain which memory-mapped registers your program uses and what each register does.

What was easier in your chosen language, and what would have been easier in the other language?

5

Demo handoff

3 min

Write a 30-second demo script for showing your program to another group. Include what to click or press, what to observe, and what the result means.